From bpepple at fedoraproject.org  Mon Dec  1 00:38:10 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Sun, 30 Nov 2008 19:38:10 -0500
Subject: Package Review Stats for the week ending November 23, 2007
Message-ID: <1228091890.19905.5.camel@localhost.localdomain>

Top three FAS account holders who have completed reviewing "Package
review" components on bugzilla this week were Parag AN(????), Chris
Weyl,and Brian Pepple.  Below is the number of completed package reviews
done.

Parag AN(????) - 8
Chris Weyl - 6
Brian Pepple - 3
Levente Farkas - 3
Jason Tibbitts - 2
Lucian Langa - 2
Mamoru Tasaka - 2
Marcela Maslanova - 2
Dan Hor?k - 1
David Woodhouse - 1
Fabian Affolter - 1
Jussi Lehtola - 1
Michael Schwendt - 1
Miroslav Lichvar - 1
Stepan Kasal - 1
Xavier Lamien - 1

Total reviews: 36

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081130/db6fe3e5/attachment.sig>

From konrad at tylerc.org  Mon Dec  1 00:40:37 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sun, 30 Nov 2008 16:40:37 -0800
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <1228091890.19905.5.camel@localhost.localdomain>
References: <1228091890.19905.5.camel@localhost.localdomain>
Message-ID: <200811301640.37888.konrad@tylerc.org>

On Sunday 30 November 2008 04:38:10 pm Brian Pepple wrote:
> Top three FAS account holders who have completed reviewing "Package
> review" components on bugzilla this week were Parag AN(????), Chris
> Weyl,and Brian Pepple.  Below is the number of completed package reviews
> done.
>
> Parag AN(????) - 8
> Chris Weyl - 6
> Brian Pepple - 3
> Levente Farkas - 3
> Jason Tibbitts - 2
> Lucian Langa - 2
> Mamoru Tasaka - 2
> Marcela Maslanova - 2
> Dan Hor?k - 1
> David Woodhouse - 1
> Fabian Affolter - 1
> Jussi Lehtola - 1
> Michael Schwendt - 1
> Miroslav Lichvar - 1
> Stepan Kasal - 1
> Xavier Lamien - 1
>
> Total reviews: 36
>
> Later,
> /B

Any count of the number of outstanding reviews?

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>





From bpepple at fedoraproject.org  Mon Dec  1 00:49:05 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Sun, 30 Nov 2008 19:49:05 -0500
Subject: Reminder: FESCo election nominations open until Dec. 3rd
Message-ID: <1228092545.20163.3.camel@localhost.localdomain>

Hi all,

Just sending a reminder that nomination period for the upcoming FESCo
election is still open until December 3rd.  You may self-nominate. If
you wish to nominate someone else, please consult with that person ahead
of time. Wiki nomination pages [1] carry additional details about the
nominee which the nominee is expected to write.  Simply update the
respective wiki page with your nomination information.

     1. http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081130/d3f186bf/attachment.sig>

From zaitcev at redhat.com  Mon Dec  1 01:13:33 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sun, 30 Nov 2008 18:13:33 -0700
Subject: "nousb" poll
In-Reply-To: <1227587695.21853.28.camel@beck.corsepiu.local>
References: <20081122103552.86a26420.zaitcev@redhat.com>
	<1227376350.5833.30.camel@beck.corsepiu.local>
	<20081124194815.GC3145@nostromo.devel.redhat.com>
	<1227587695.21853.28.camel@beck.corsepiu.local>
Message-ID: <20081130181333.a8f67a68.zaitcev@redhat.com>

On Tue, 25 Nov 2008 05:34:54 +0100, Ralf Corsepius <rc040203 at freenet.de> wrote:

> > I don't see how it afffects low end at all - it certainly doesn't
> > save you any memory.

> Yes, making usb built-in killed the most of benefits nousb once had
> provided.

The "nousb" never saved any memory. To say otherwise is cargo cult
science. This is because a) "nousb" never affected the USB core, and
b) tests for it were located inside HCDs, so they had to be loaded
for it to have any effect.

-- Pete



From mike at cchtml.com  Mon Dec  1 01:42:09 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Sun, 30 Nov 2008 19:42:09 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <409676c70811270912q21f099e1p36ba2a6b5bb6e6d1@mail.gmail.com>
References: <492E05E7.2080708@cchtml.com>	<20081127093226.GA6829@amd.home.annexia.org>	<492E711B.2010803@leemhuis.info>	<20081127162328.GA8714@amd.home.annexia.org>
	<409676c70811270912q21f099e1p36ba2a6b5bb6e6d1@mail.gmail.com>
Message-ID: <493340F1.2060405@cchtml.com>

Trond Danielsen wrote:
>
> Last time I checked both man and info pages are available though the
> gnome yelp browser. That already provide a convenient and searchable
> interface for both experienced and inexperienced users.
>
> --
> Trond Danielsen
>
>   
While yelp is a nice tool, it lacks in the lightweight department. It 
eats 40 megs of RAM upon startup and more RAM once searching occurs or 
pages are opened. Sure, we're all getting gigabytes of RAM these days, 
but it's a HELP tool with TEXT.

yelp may provide a cross-help platform, but it isn't highly known about 
or advertised. Many users still use "man foo" in terminals or Google search.



From rhlinux123 at hotmail.com  Mon Dec  1 01:44:55 2008
From: rhlinux123 at hotmail.com (Curtis George)
Date: Sun, 30 Nov 2008 17:44:55 -0800
Subject: Suggestions to get sponsored
Message-ID: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>


Hi,

I would like some suggestions for a package to submit in order to get sponsored.  I'm thinking something that needs to be updated that doesn't have a maintainer, or a new package that needs to be added to Fedora.  I would preferably like it to be something that I personally use, but it's OK if it's not.  I would really like some suggestions to choose something that would be useful.

Thanks,

Curtis George

_________________________________________________________________
Windows Live Hotmail now works up to 70% faster.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081130/26dd0564/attachment.htm>

From mike at cchtml.com  Mon Dec  1 01:45:31 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Sun, 30 Nov 2008 19:45:31 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
Message-ID: <493341BB.10706@cchtml.com>

Gergely Buday wrote:
> I think you cannot make each software package maintainer to use your
> new tool. And, anyway, most people are fine with man pages. If there
> is one...
>
> But it is indeed possible to use modern tools to create textual
> documentation. With xmlto you can create man pages (and other formats)
> from the same docbook source. Yesterday I started using it and having
> found a basic docbook xml source I was able to write a small man page
> in two hours.
>
> Now the documentation project is in favor of the Publican system,
> which is yet unable to create man pages.
>
> - Gergely
>
>   
I'm not demanding this feature replace everything immediately.

Man pages, while informative, are limited. If examples or detailed 
information are required then you're back to Google searching.

Two hours? I should hope to create something in 10 minutes.



From mike at cchtml.com  Mon Dec  1 01:48:16 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Sun, 30 Nov 2008 19:48:16 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1188.1227768798@sss.pgh.pa.us>
References: <492E05E7.2080708@cchtml.com> <1188.1227768798@sss.pgh.pa.us>
Message-ID: <49334260.70403@cchtml.com>

Tom Lane wrote:
> Michael Cronenworth <mike at cchtml.com> writes:
>   
>
> And you're going to persuade all our thousands of upstream projects
> to buy into this and convert their documentation to $whateveritis?
>
> Pardon me for not holding my breath till it happens.
>
> 			regards, tom lane
>
>   

So we should continue to use hundreds of different forms of 
documentation systems? Many packages use their own proprietary formats. 
I'm not calling for an overnight transformation. My original e-mail was 
to inject some thinking into this mailing list. I hope I've succeeded.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081130/576a0493/attachment.htm>

From bashton at brennanashton.com  Mon Dec  1 02:08:07 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sun, 30 Nov 2008 18:08:07 -0800
Subject: Suggestions to get sponsored
In-Reply-To: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>
References: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>
Message-ID: <981da310811301808m35984068j8803a6d37a90d9f7@mail.gmail.com>

2008/11/30 Curtis George <rhlinux123 at hotmail.com>:
> Hi,
>
> I would like some suggestions for a package to submit in order to get
> sponsored.  I'm thinking something that needs to be updated that doesn't
> have a maintainer, or a new package that needs to be added to Fedora.  I
> would preferably like it to be something that I personally use, but it's OK
> if it's not.  I would really like some suggestions to choose something that
> would be useful.
>
> Thanks,
>
> Curtis George

Look here:
https://fedoraproject.org/wiki/PackageMaintainers/WishList

--Brennan Ashton



From rhlinux123 at hotmail.com  Mon Dec  1 02:21:40 2008
From: rhlinux123 at hotmail.com (Curtis George)
Date: Sun, 30 Nov 2008 18:21:40 -0800
Subject: Suggestions to get sponsored
In-Reply-To: <981da310811301808m35984068j8803a6d37a90d9f7@mail.gmail.com>
References: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>
	<981da310811301808m35984068j8803a6d37a90d9f7@mail.gmail.com>
Message-ID: <BAY122-W134CD20ECD26313E814A1483010@phx.gbl>


Thanks, I've seen that list.  None of them appealed to me personally, so I'm hoping that someone can suggest a specific one that they need.

Curtis George

> Date: Sun, 30 Nov 2008 18:08:07 -0800
> From: bashton at brennanashton.com
> To: fedora-devel-list at redhat.com
> Subject: Re: Suggestions to get sponsored
> 
> 2008/11/30 Curtis George <rhlinux123 at hotmail.com>:
> > Hi,
> >
> > I would like some suggestions for a package to submit in order to get
> > sponsored.  I'm thinking something that needs to be updated that doesn't
> > have a maintainer, or a new package that needs to be added to Fedora.  I
> > would preferably like it to be something that I personally use, but it's OK
> > if it's not.  I would really like some suggestions to choose something that
> > would be useful.
> >
> > Thanks,
> >
> > Curtis George
> 
> Look here:
> https://fedoraproject.org/wiki/PackageMaintainers/WishList
> 
> --Brennan Ashton
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

_________________________________________________________________
Windows Live Hotmail now works up to 70% faster.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081130/aab5c8e9/attachment.htm>

From ivazqueznet at gmail.com  Mon Dec  1 04:39:15 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sun, 30 Nov 2008 23:39:15 -0500
Subject: Round 2 starting (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <1227923821.3835.39.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
Message-ID: <1228106355.3835.132.camel@ignacio.lan>

A much shorter list this time, so I'll throw it in here:

awjb libopensync-plugin-python 
awjb scribus 
berrange autobuild-applet 
berrange virt-manager 
bochecha adonthell 
bpepple xchat-gnome 
caillon gnome-hearts 
caillon xchat 
caolanm openoffice.org 
deji exaile 
deji libscigraphica 
deji scigraphica 
denis k3d 
dnovotny mailman 
endur streamtuner 
frankb qtiplot 
gecko-maint epiphany 
georgiou ganglia 
hadess rhythmbox 
hadess totem 
hguemar listen 
huzaifas dia 
huzaifas gnumeric 
ixs bacula 
jbowes mod_wsgi 
jcollie quodlibet 
jdennis freeradius 
jwrdegoede cel 
jwrdegoede crystalspace 
jwrdegoede vegastrike 
karsten vim 
limb gnubg 
limb wesnoth 
lkundrak inkscape 
mtasaka gnome-commander 
orion gdl 
orion paraview 
pingou guake 
rathann ekg 
rathann ekg2 
rstrode gedit 
s4504kr blender 
salimma Io-language 
stingray weechat 
tanguy scidavis 
than kdeedu 
than kdeutils 
trasher gcompris 
wart crossfire 
wart cyphesis 

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081130/e0e0925c/attachment.sig>

From rc040203 at freenet.de  Mon Dec  1 05:02:08 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 01 Dec 2008 06:02:08 +0100
Subject: "nousb" poll
In-Reply-To: <20081130181333.a8f67a68.zaitcev@redhat.com>
References: <20081122103552.86a26420.zaitcev@redhat.com>
	<1227376350.5833.30.camel@beck.corsepiu.local>
	<20081124194815.GC3145@nostromo.devel.redhat.com>
	<1227587695.21853.28.camel@beck.corsepiu.local>
	<20081130181333.a8f67a68.zaitcev@redhat.com>
Message-ID: <1228107729.5593.902.camel@beck.corsepiu.local>

On Sun, 2008-11-30 at 18:13 -0700, Pete Zaitcev wrote:
> On Tue, 25 Nov 2008 05:34:54 +0100, Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > > I don't see how it afffects low end at all - it certainly doesn't
> > > save you any memory.
> 
> > Yes, making usb built-in killed the most of benefits nousb once had
> > provided.
> 
> The "nousb" never saved any memory.
It had caused the kernel not to load in uhci, ehci, etc.




From fedora at leemhuis.info  Mon Dec  1 06:20:08 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 01 Dec 2008 07:20:08 +0100
Subject: First set of names
In-Reply-To: <1228082073.3835.122.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>	<1228057466.3835.105.camel@ignacio.lan>	<4932C54E.3000901@leemhuis.info>	<1228080199.3835.115.camel@ignacio.lan>
	<1228082073.3835.122.camel@ignacio.lan>
Message-ID: <49338218.7020706@leemhuis.info>

On 30.11.2008 22:54, Ignacio Vazquez-Abrams wrote:
> On Sun, 2008-11-30 at 16:23 -0500, Ignacio Vazquez-Abrams wrote:
>> On Sun, 2008-11-30 at 17:54 +0100, Thorsten Leemhuis wrote:
>>> On 30.11.2008 16:04, Ignacio Vazquez-Abrams wrote:
>>>> The first cycle of rebuilds is done, and here's the results.
>>> Could you please add the username of the packager owner to your results 
>>> if you make further reports like this?
>> I apologize for not doing so. I blame the fact that I had been doing it
>> for about 20 hours straight with small breaks totaling about 3 hours.
> I took the time to process the list now that I'm awake.

Many thanks.

While at it: There is that old hack ^w script "fedoradev-pkgowners"  in 
the wiki at 
https://fedoraproject.org/wiki/PackageMaintainers/UsefulScripts -- it 
can he used to get the package owners from pgkdb to generate such lists. 
I wrote that script ages ago, but I got told (from Ignacio and others on 
IRC) that changes to the infra broke it.

I kind of had expected that, but I thing I saw better scripts on this 
list months ago. Those did what's needed in better ways -- they iirc 
were directly talking to the pkgdb. Hence I stopped updating that crappy 
script.

Seems none of those better script made it to the wiki. Maybe it's time 
to collect all the scripts, pick the best one and put them into 
fedora-packager?

CU
knurd



From pingou at pingoured.fr  Mon Dec  1 06:28:23 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Mon, 01 Dec 2008 07:28:23 +0100
Subject: Round 2 starting
In-Reply-To: <1228106355.3835.132.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228106355.3835.132.camel@ignacio.lan>
Message-ID: <49338407.90009@pingoured.fr>

Ignacio Vazquez-Abrams wrote:
> A much shorter list this time, so I'll throw it in here:
What are those ? The one you'll build, the one that failed your build ?

Thanks,

Pierre



From ivazqueznet at gmail.com  Mon Dec  1 06:31:49 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 01:31:49 -0500
Subject: Round 2 starting
In-Reply-To: <49338407.90009@pingoured.fr>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228106355.3835.132.camel@ignacio.lan> <49338407.90009@pingoured.fr>
Message-ID: <1228113109.3835.137.camel@ignacio.lan>

On Mon, 2008-12-01 at 07:28 +0100, Pierre-Yves wrote:
> Ignacio Vazquez-Abrams wrote:
> > A much shorter list this time, so I'll throw it in here:
> What are those ? The one you'll build, the one that failed your build ?

It's a set of packages that a different net caught. I used
python(abi)=2.5 for the first set in order to get the low-level
packages, and this one uses libpython2.5.so.1.0.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/83de0181/attachment.sig>

From nicolas.mailhot at laposte.net  Mon Dec  1 06:53:16 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 01 Dec 2008 07:53:16 +0100
Subject: Suggestions to get sponsored
In-Reply-To: <BAY122-W134CD20ECD26313E814A1483010@phx.gbl>
References: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>
	<981da310811301808m35984068j8803a6d37a90d9f7@mail.gmail.com>
	<BAY122-W134CD20ECD26313E814A1483010@phx.gbl>
Message-ID: <1228114396.32440.4.camel@arekh.okg>

Le dimanche 30 novembre 2008 ? 18:21 -0800, Curtis George a ?crit :
> Thanks, I've seen that list.  None of them appealed to me personally,
> so I'm hoping that someone can suggest a specific one that they need.

http://fedoraproject.org/wiki/Category:Font_wishlist

You have all sort of things in there, historic well-known fonts that
should have been packaged in fedora ages ago, fonts to support groups
which have no Fedora access right now, artistic fonts to please the arts
group, academic fonts needed by different branches of science, etc

If none of them appeal to you you're using some sort of text-less vocal
AI I've only seen in films so far.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/a8cd1bc9/attachment.sig>

From bashton at brennanashton.com  Mon Dec  1 07:16:32 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Mon, 1 Dec 2008 02:16:32 -0500
Subject: Suggestions to get sponsored
In-Reply-To: <1228114396.32440.4.camel@arekh.okg>
References: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>
	<981da310811301808m35984068j8803a6d37a90d9f7@mail.gmail.com>
	<BAY122-W134CD20ECD26313E814A1483010@phx.gbl>
	<1228114396.32440.4.camel@arekh.okg>
Message-ID: <981da310811302316x47f8ab16k1fdc2beed287c826@mail.gmail.com>

2008/12/1 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> If none of them appeal to you you're using some sort of text-less vocal
> AI I've only seen in films so far.

I found that doing a vocal AI was too complicated so I went straight
to mind reading,  but now I have to put on a aluminium hat around the
house and it wont let me turn it off.

Back on topic, I would like to see some more of the eclipse web
development plugins packaged if you are interested.

Or if you are into micro controllers, http://www.gnu-m68hc11.org/blog/
 I have spec files for some of those if you want, but you might have
to work with the fedora gcc fokes maybe they can be worked in as a
built in cross compiler i dont know.

--Brennan Ashton



From mcepl at redhat.com  Mon Dec  1 08:28:53 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 01 Dec 2008 09:28:53 +0100
Subject: Feature proposal: New, Standard Documentation System
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com>
Message-ID: <5rjc06xma9.ln2@ppp1053.in.ipex.cz>

On 2008-12-01, 01:45 GMT, Michael Cronenworth wrote:
> Man pages, while informative, are limited. If examples or 
> detailed information are required then you're back to Google 
> searching.

Yes, there are many manpages which are pretty bad. But expanding 
content won't happen by switching to different format, but fixing 
each manpage. Yes, one at the time.

> Two hours? I should hope to create something in 10 minutes.

Two hours include learning curve. After writing one manpage and 
learning how to do it, including collecting appropriate tools, it 
should be as fast as writing with anything else. I don't think 
that two hours of learning is too high price for creating 
structured, long-lasting documentation.

Best,

Mat?j



From pertusus at free.fr  Mon Dec  1 08:32:29 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 1 Dec 2008 09:32:29 +0100
Subject: How to pack cron jobs?
In-Reply-To: <ggv8d5$539$1@ger.gmane.org>
References: <ggs9m8$rsg$1@ger.gmane.org>
	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>
	<ggsd7q$5tn$1@ger.gmane.org> <20081130142237.GA16722@free.fr>
	<ggujhc$68k$1@ger.gmane.org> <20081130210724.GA2649@free.fr>
	<ggv8d5$539$1@ger.gmane.org>
Message-ID: <20081201083229.GA2735@free.fr>

On Mon, Dec 01, 2008 at 02:42:25AM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> Patrice Dumas ?????:
>> On Sun, Nov 30, 2008 at 08:46:20PM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>>> Great news. In this case really may be best solution add /etc/cron.d  
>>> into crontab package?
>>
>> I don't think so, at least if  cronie directly uses files in /etc/cron.d.
>>
>> --
>> Pat
>>
> AFIAK cronie do not use files from it, cronie only provide service to  
> handle jobs from this directory. And fcron will do the same.

It is advertized in the crond man page, so I think it is directly done
by cronie, (and I don't know where it would be configured otherwise).

> I thing in any way "Require crontabs" must be in both crons.

Not in the main package. User may want another crontab than the fedora
one.

> Furthermore if /etc/cron.d will be included into both crons, do not make  
> this conflicts (if both must be installed on the same machine off 
> course)??

Dir ownership doesn't lead to conflict, on the contrary, it is a rather
natural way to present virtual provides (as long as it is in /etc).

--
Pat



From rjones at redhat.com  Mon Dec  1 10:14:56 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 1 Dec 2008 10:14:56 +0000
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <200811301640.37888.konrad@tylerc.org>
References: <1228091890.19905.5.camel@localhost.localdomain>
	<200811301640.37888.konrad@tylerc.org>
Message-ID: <20081201101456.GA18568@thinkpad>

On Sun, Nov 30, 2008 at 04:40:37PM -0800, Conrad Meyer wrote:
> Any count of the number of outstanding reviews?

This page shows all bugs in the 'Package Review' component (8104
in total), but it includes closed bugs and merge reviews.  Probably
there is a better bugzilla search which would narrow it down a bit.

https://bugzilla.redhat.com/buglist.cgi?component=Package%20Review&product=Fedora

Rich.



From dominik at greysector.net  Mon Dec  1 10:21:18 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 1 Dec 2008 11:21:18 +0100
Subject: Round 2 starting
In-Reply-To: <1228113109.3835.137.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228106355.3835.132.camel@ignacio.lan>
	<49338407.90009@pingoured.fr>
	<1228113109.3835.137.camel@ignacio.lan>
Message-ID: <20081201102118.GB4906@mokona.greysector.net>

On Monday, 01 December 2008 at 07:31, Ignacio Vazquez-Abrams wrote:
> On Mon, 2008-12-01 at 07:28 +0100, Pierre-Yves wrote:
> > Ignacio Vazquez-Abrams wrote:
> > > A much shorter list this time, so I'll throw it in here:
> > What are those ? The one you'll build, the one that failed your build ?
> 
> It's a set of packages that a different net caught. I used
> python(abi)=2.5 for the first set in order to get the low-level
> packages, and this one uses libpython2.5.so.1.0.

So, IOW, they were missing Requires: python(abi) = 2.5. Am I correct?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From dominik at greysector.net  Mon Dec  1 10:22:58 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 1 Dec 2008 11:22:58 +0100
Subject: Suggestions to get sponsored
In-Reply-To: <981da310811302316x47f8ab16k1fdc2beed287c826@mail.gmail.com>
References: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>
	<981da310811301808m35984068j8803a6d37a90d9f7@mail.gmail.com>
	<BAY122-W134CD20ECD26313E814A1483010@phx.gbl>
	<1228114396.32440.4.camel@arekh.okg>
	<981da310811302316x47f8ab16k1fdc2beed287c826@mail.gmail.com>
Message-ID: <20081201102258.GC4906@mokona.greysector.net>

On Monday, 01 December 2008 at 08:16, Brennan Ashton wrote:
> 2008/12/1 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> > If none of them appeal to you you're using some sort of text-less vocal
> > AI I've only seen in films so far.
> 
> I found that doing a vocal AI was too complicated so I went straight
> to mind reading,  but now I have to put on a aluminium hat around the
> house and it wont let me turn it off.
> 
> Back on topic, I would like to see some more of the eclipse web
> development plugins packaged if you are interested.
> 
> Or if you are into micro controllers, http://www.gnu-m68hc11.org/blog/
>  I have spec files for some of those if you want, but you might have
> to work with the fedora gcc fokes maybe they can be worked in as a
> built in cross compiler i dont know.

There are probably tons of perl modules which are present in RPMForge
repositories but not in Fedora. One might want to look at those.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From galibert at pobox.com  Mon Dec  1 10:26:22 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Mon, 1 Dec 2008 11:26:22 +0100
Subject: Require failures
Message-ID: <20081201102622.GA59184@dspnet.fr.eu.org>

There are some packages impossible to install due to require failures
in the dvd.  I'm surprised there isn't an automatic check at release
time for that.

In base and the dvd (aka version issues):
- maven2-2.0.4-10.15.fc10.x86_64.rpm:
  - maven-doxia >= 1.0-0.a7.3 (avail: 0:1.0-0.2.a7.2.10.fc10)
  - maven-doxia >= 1.0-0.a7.3 (avail: 0:1.0-0.2.a7.2.10.fc10)
  - plexus-ant-factory >= 1.0-0.a1.2 (avail: 0:1.0-0.2.a1.1.9.fc10)
  - plexus-archiver >= 1.0-0.a6 (avail: 0:1.0-0.2.a7.1.2.fc10)
  - plexus-bsh-factory >= 1.0-0.a7s.2 (avail: 0:1.0-0.2.a7s.1.9.fc10)

In the dvd only (aka missing packages):
- checkstyle-4.1-5.fc10.noarch.rpm:
  - ant-javadoc
  - antlr-javadoc
  - jakarta-commons-beanutils-javadoc
  - xml-commons-apis-javadoc
- eclipse-jdt-3.4.1-5.fc10.x86_64.rpm:
  - java-javadoc

  OG.



From abu_hurayrah at hidayahonline.org  Mon Dec  1 10:42:14 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Mon, 01 Dec 2008 12:42:14 +0200
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com>  <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
Message-ID: <1228128134.3451.36.camel@beta>

On Mon, 2008-12-01 at 09:28 +0100, Matej Cepl wrote:
> On 2008-12-01, 01:45 GMT, Michael Cronenworth wrote:
> > Man pages, while informative, are limited. If examples or 
> > detailed information are required then you're back to Google 
> > searching.
> 
> Yes, there are many manpages which are pretty bad. But expanding 
> content won't happen by switching to different format, but fixing 
> each manpage. Yes, one at the time.
> 
> > Two hours? I should hope to create something in 10 minutes.
> 
> Two hours include learning curve. After writing one manpage and 
> learning how to do it, including collecting appropriate tools, it 
> should be as fast as writing with anything else. I don't think 
> that two hours of learning is too high price for creating 
> structured, long-lasting documentation.
> 
> Best,
> 
> Mat?j
> 
I've never written a man page or much documentation myself, but I think
this is a great area where non-programmers (or at least, those that
don't know the languages that are used inside of Fedora & other free
operating systems) can contribute back to the project.

If someone could setup a SIG for man page conversion or just leverage
the documentation team and make a focus on teaching how to do man pages,
I could see this bits of this task being chipped away significantly on
the road to F11.  I know that I'm definitely leaning towards the idea of
writing one or two man pages, because I've run into the missing-man-page
problem too often.

Here's a suggested action plan (forgive me if I am out of place for
suggesting it):

1) Identify which packages are missing man pages altogether in Fedora
	-- these should get top priority
	-- we can see if Debian or other projects already have some
		-- acceptable-licensing-pending, of course
2) Identify which packages having sub-par man pages
	-- after fulfilling 1), this should be the next priority
	-- similar methodology to 1), find ones that already exist first
3) Develop a "stub" template for packages that have no man pages
available
	-- at least we can include command-line arguments, authorship,
		web links for more info, etc.
		-- at first this isn't much better than -h/--help, but
			we can at least let it be a start
4) Once we have all of this information prepared, then we can get to
work on forming a project around this group, preparing a page in the
wiki with the packages that need man pages or whose man pages need
improvement, etc.
5) ???
6) Profit!

How does that sound?



From abu_hurayrah at hidayahonline.org  Mon Dec  1 10:53:34 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Mon, 01 Dec 2008 12:53:34 +0200
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1228128134.3451.36.camel@beta>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com>  <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
	<1228128134.3451.36.camel@beta>
Message-ID: <1228128814.3451.40.camel@beta>

On Mon, 2008-12-01 at 12:42 +0200, Basil Mohamed Gohar wrote:
> On Mon, 2008-12-01 at 09:28 +0100, Matej Cepl wrote:
> > On 2008-12-01, 01:45 GMT, Michael Cronenworth wrote:
> > > Man pages, while informative, are limited. If examples or 
> > > detailed information are required then you're back to Google 
> > > searching.
> > 
> > Yes, there are many manpages which are pretty bad. But expanding 
> > content won't happen by switching to different format, but fixing 
> > each manpage. Yes, one at the time.
> > 
> > > Two hours? I should hope to create something in 10 minutes.
> > 
> > Two hours include learning curve. After writing one manpage and 
> > learning how to do it, including collecting appropriate tools, it 
> > should be as fast as writing with anything else. I don't think 
> > that two hours of learning is too high price for creating 
> > structured, long-lasting documentation.
> > 
> > Best,
> > 
> > Mat?j
> > 
> I've never written a man page or much documentation myself, but I think
> this is a great area where non-programmers (or at least, those that
> don't know the languages that are used inside of Fedora & other free
> operating systems) can contribute back to the project.
> 
> If someone could setup a SIG for man page conversion or just leverage
> the documentation team and make a focus on teaching how to do man pages,
> I could see this bits of this task being chipped away significantly on
> the road to F11.  I know that I'm definitely leaning towards the idea of
> writing one or two man pages, because I've run into the missing-man-page
> problem too often.
> 
> Here's a suggested action plan (forgive me if I am out of place for
> suggesting it):
> 
> 1) Identify which packages are missing man pages altogether in Fedora
> 	-- these should get top priority
> 	-- we can see if Debian or other projects already have some
> 		-- acceptable-licensing-pending, of course
> 2) Identify which packages having sub-par man pages
> 	-- after fulfilling 1), this should be the next priority
> 	-- similar methodology to 1), find ones that already exist first
> 3) Develop a "stub" template for packages that have no man pages
> available
> 	-- at least we can include command-line arguments, authorship,
> 		web links for more info, etc.
> 		-- at first this isn't much better than -h/--help, but
> 			we can at least let it be a start
> 4) Once we have all of this information prepared, then we can get to
> work on forming a project around this group, preparing a page in the
> wiki with the packages that need man pages or whose man pages need
> improvement, etc.
> 5) ???
> 6) Profit!
> 
> How does that sound?
> 
By the way, I feel the work towards man pages is conducive to producing
better documentation across the board, including on the docs site as
well as guides/tips/whatever on the Wiki.

This is one of the main reasons, in fact, that I feel we should push for
man page updates.  I feel it will filter out, including upstream, to the
maximum benefit on all fronts for documentation purposes.

Should I present this idea to the docs project, pending the agreement of
most, if not all, those involved in this discussion?  I'm mulling the
idea of even heading it, if no one else is more appropriate for the
task...



From ivazqueznet at gmail.com  Mon Dec  1 10:56:55 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 05:56:55 -0500
Subject: It's all ASPLODY!
In-Reply-To: <1227557060.6715.54.camel@ignacio.lan>
References: <1227549240.6715.44.camel@ignacio.lan>
	<200811242125.20930.ville.skytta@iki.fi>
	<1227557060.6715.54.camel@ignacio.lan>
Message-ID: <1228129015.3835.162.camel@ignacio.lan>

On Mon, 2008-11-24 at 15:04 -0500, Ignacio Vazquez-Abrams wrote:
> The Python API version (1013) has not changed between 2.5 and 2.6,
> therefore the bytecode is compatible and .pyc and .pyo files in
> version-independent locations do not need to be recompiled.

*sigh*

I just did some actual testing, and I've discovered that this is false.
But don't worry, I'll handle it.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/10706996/attachment.sig>

From belegdol at gmail.com  Mon Dec  1 11:01:32 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 01 Dec 2008 12:01:32 +0100
Subject: evdev and multiple keyboards
Message-ID: <4933C40C.8040203@gmail.com>

Hi,

I recently upgraded to Fedora 10 and it seems there is a little issue
with evdev. I am a laptop user, but when at home I use a Logitech Alto
Cordless keyboard. The thing is, that the CapsLock LEDs are not
?coupled? - pressing caps lock on alto does not light up the diode on
the laptop and so on. This can lead to a funny situation when you will
have caps lock enabled and no led will show that. Is that a known issue?
 Apart from that, evdev keyboards seem to work fine, only 3 remappings
seem to be necessary. For laptop keyboard:
Cancel -> XF86AudioStop
For Logitech Alto Cordless:
XF86HomePage -> XF86WWW
XF86Tools -> XF86Media
Is the above submittable, and if so, where can I submit that? My Gnome
setting is evdev-managed keyboard.

Regards,
Julian



From ivazqueznet at gmail.com  Mon Dec  1 11:02:54 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 06:02:54 -0500
Subject: Require failures
In-Reply-To: <20081201102622.GA59184@dspnet.fr.eu.org>
References: <20081201102622.GA59184@dspnet.fr.eu.org>
Message-ID: <1228129374.3835.167.camel@ignacio.lan>

On Mon, 2008-12-01 at 11:26 +0100, Olivier Galibert wrote:
> There are some packages impossible to install due to require failures
> in the dvd.  I'm surprised there isn't an automatic check at release
> time for that.

That's funny, I was talking about that just last week...

Not on here, though.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/970adcdc/attachment.sig>

From ivazqueznet at gmail.com  Mon Dec  1 11:04:13 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 06:04:13 -0500
Subject: Round 2 starting
In-Reply-To: <20081201102118.GB4906@mokona.greysector.net>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228106355.3835.132.camel@ignacio.lan> <49338407.90009@pingoured.fr>
	<1228113109.3835.137.camel@ignacio.lan>
	<20081201102118.GB4906@mokona.greysector.net>
Message-ID: <1228129453.3835.169.camel@ignacio.lan>

On Mon, 2008-12-01 at 11:21 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 01 December 2008 at 07:31, Ignacio Vazquez-Abrams wrote:
> > On Mon, 2008-12-01 at 07:28 +0100, Pierre-Yves wrote:
> > > Ignacio Vazquez-Abrams wrote:
> > > > A much shorter list this time, so I'll throw it in here:
> > > What are those ? The one you'll build, the one that failed your build ?
> > 
> > It's a set of packages that a different net caught. I used
> > python(abi)=2.5 for the first set in order to get the low-level
> > packages, and this one uses libpython2.5.so.1.0.
> 
> So, IOW, they were missing Requires: python(abi) = 2.5. Am I correct?

Yes, but that isn't a problem since the Python shared object is
explicitly versioned.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/6d1671aa/attachment.sig>

From jonathan.underwood at gmail.com  Mon Dec  1 11:07:09 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 1 Dec 2008 11:07:09 +0000
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <1225921510.9784.0.camel@PB3.Linux>
References: <1225820483.24018.35.camel@luminos.localdomain>
	<645d17210811040956m7cbe7701mad0b49701e6222e5@mail.gmail.com>
	<3170f42f0811050629t6251d858r499d002c54ca69ca@mail.gmail.com>
	<1225921510.9784.0.camel@PB3.Linux>
Message-ID: <645d17210812010307m570d578aq5b652a70ba538456@mail.gmail.com>

2008/11/5 Paul <paul at all-the-johnsons.co.uk>:
> Hi,
>
>> > I would happily be a comaintainer for emacs. Emphasis on co :)
>>
>> Same here. :-)
>>
>> So who will be the first maintainer?
>
> /me steps to the plate...

Jesse - any progress on this? We've requested access to the packages ...



From debarshi.ray at gmail.com  Mon Dec  1 11:15:17 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 1 Dec 2008 16:45:17 +0530
Subject: Seahorse is orphaned?
Message-ID: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>

I just noticed that the 'seahorse' package is orphaned [1] although
Matthias and others seem to be taking care of it for some time. So is
the package really orphaned or is this just an oversight?

Cheers,
Debarshi

----
[1] https://admin.fedoraproject.org/pkgdb/packages/name/seahorse



From alcapcom at gmail.com  Mon Dec  1 11:27:31 2008
From: alcapcom at gmail.com (Alphonse Van Assche)
Date: Mon, 01 Dec 2008 12:27:31 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E05E7.2080708@cchtml.com>
References: <492E05E7.2080708@cchtml.com>
Message-ID: <4933CA23.1050400@gmail.com>

Michael Cronenworth a ?crit :
> <cut>
> 5. Global access
>  You should be able to access any and all documentation for all 
> software through a single window, be it X or console, without having 
> to open the corresponding program.
>
6.  a common way to find documentation about a given package. Here is 
what I do when I need to read docs on a given package.

1. rpm -ql pgkname
if there is a man page and/or README and/or .html and/or ... - done!
2. yum list pkgname\*
if there is sub-package named pkgname-doc - done!
3. rpm -qi pgkname
if the URL tag point to upstream web site - open firefox find the 
documentation page - done!
4. fedora-cvs pkgname - hoping that I know the language used and that 
the code is nicely documented ;-) - done!
5. ??

I thing that we can do something to optimize the search of documentation 
of a given package. To be honest I don't have any idea on the best way 
to do that  - but I'm sure that we can do something better.

Just my two cent.

Regards,
Alphonse



From mjg at redhat.com  Mon Dec  1 11:45:16 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Mon, 1 Dec 2008 11:45:16 +0000
Subject: evdev and multiple keyboards
In-Reply-To: <4933C40C.8040203@gmail.com>
References: <4933C40C.8040203@gmail.com>
Message-ID: <20081201114516.GA29466@srcf.ucam.org>

On Mon, Dec 01, 2008 at 12:01:32PM +0100, Julian Sikorski wrote:

>  Apart from that, evdev keyboards seem to work fine, only 3 remappings
> seem to be necessary. For laptop keyboard:
> Cancel -> XF86AudioStop

That probably needs to be filed against hal-info, along with the output 
of the lshal command.

> For Logitech Alto Cordless:
> XF86HomePage -> XF86WWW
> XF86Tools -> XF86Media
> Is the above submittable, and if so, where can I submit that? My Gnome
> setting is evdev-managed keyboard.

USB devices output standardised keycodes, so if these are incorrect it 
implies that the evdev map in xkb is wrong. I'd file against 
xkeyboard-config.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From ivazqueznet at gmail.com  Mon Dec  1 12:04:49 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 07:04:49 -0500
Subject: Second Report (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <1227923821.3835.39.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
Message-ID: <1228133089.3835.179.camel@ignacio.lan>

Same reasons as the first report. openoffice.org and gnumeric both
failed for (the same) two reasons.

Permissions:
ixs bacula
karsten vim
than kdebase-workspace

libtool:
(none)

pkgconfig:
caolanm openoffice.org
deji scigraphica
hadess rhythmbox
huzaifas gnumeric
mtasaka gnome-commander

SRPM build failures:
(none)

Dep problems:
(none)

Python version expectations:
wart cyphesis V

Never completed:
(none)

Runtime issues:
(none)

Code or packaging issues:
frankb qtiplot
jdennis freeradius
limb wesnoth
rstrode gedit
tanguy scidavis

Blocked by other packages, either from this round, or the first:
caolanm openoffice.org xulrunner
gecko-maint epiphany xulrunner
georgiou ganglia rrdtool
hguemar listen xulrunner
huzaifas gnumeric avahi
orion gdl avahi
than kdeedu kdebase-workspace
than kdeutils kdebindings


Raw data follows:
awjb libopensync-plugin-python libopensync
caolanm openoffice.org K/xulrunner
deji scigraphica K
frankb qtiplot C
gecko-maint epiphany xulrunner
georgiou ganglia rrdtool
hadess rhythmbox K
hguemar listen xulrunner
huzaifas gnumeric K/avahi
ixs bacula P
jdennis freeradius C
karsten vim P
limb wesnoth C
mtasaka gnome-commander K
orion gdl avahi
rstrode gedit C
tanguy scidavis C
than kdebase-workspace P
than kdeedu kdebase-workspace
than kdeutils kdebindings
wart cyphesis V

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/fef8ffff/attachment.sig>

From nicolas.mailhot at laposte.net  Mon Dec  1 12:19:14 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 1 Dec 2008 13:19:14 +0100 (CET)
Subject: evdev and multiple keyboards
In-Reply-To: <20081201114516.GA29466@srcf.ucam.org>
References: <4933C40C.8040203@gmail.com> <20081201114516.GA29466@srcf.ucam.org>
Message-ID: <6370808e3d1e7b8a261b34838e26e65c.squirrel@arekh.dyndns.org>



Le Lun 1 d?cembre 2008 12:45, Matthew Garrett a ?crit :

> USB devices output standardised keycodes, so if these are incorrect it
> implies that the evdev map in xkb is wrong.

Unfortunately that's not always 100% the case, and the kernel HID
driver maintains a quirk table for non conformant hardware.

The ultimate fix is thus to declare this model's quirks kernel-side,
by posting the usb id and needed changes on
http://vger.kernel.org/vger-lists.html#linux-input

-- 
Nicolas Mailhot



From belegdol at gmail.com  Mon Dec  1 12:32:42 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 01 Dec 2008 13:32:42 +0100
Subject: evdev and multiple keyboards
In-Reply-To: <20081201114516.GA29466@srcf.ucam.org>
References: <4933C40C.8040203@gmail.com> <20081201114516.GA29466@srcf.ucam.org>
Message-ID: <4933D96A.1030701@gmail.com>

Matthew Garrett pisze:
> On Mon, Dec 01, 2008 at 12:01:32PM +0100, Julian Sikorski wrote:
> 
>>  Apart from that, evdev keyboards seem to work fine, only 3 remappings
>> seem to be necessary. For laptop keyboard:
>> Cancel -> XF86AudioStop
> 
> That probably needs to be filed against hal-info, along with the output 
> of the lshal command.
> 
>> For Logitech Alto Cordless:
>> XF86HomePage -> XF86WWW
>> XF86Tools -> XF86Media
>> Is the above submittable, and if so, where can I submit that? My Gnome
>> setting is evdev-managed keyboard.
> 
> USB devices output standardised keycodes, so if these are incorrect it 
> implies that the evdev map in xkb is wrong. I'd file against 
> xkeyboard-config.
> 

Done:
https://bugzilla.redhat.com/show_bug.cgi?id=473904
https://bugzilla.redhat.com/show_bug.cgi?id=473908



From belegdol at gmail.com  Mon Dec  1 12:33:37 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 01 Dec 2008 13:33:37 +0100
Subject: evdev and multiple keyboards
In-Reply-To: <6370808e3d1e7b8a261b34838e26e65c.squirrel@arekh.dyndns.org>
References: <4933C40C.8040203@gmail.com> <20081201114516.GA29466@srcf.ucam.org>
	<6370808e3d1e7b8a261b34838e26e65c.squirrel@arekh.dyndns.org>
Message-ID: <4933D9A1.4030307@gmail.com>

Nicolas Mailhot pisze:
> 
> Le Lun 1 d?cembre 2008 12:45, Matthew Garrett a ?crit :
> 
>> USB devices output standardised keycodes, so if these are incorrect it
>> implies that the evdev map in xkb is wrong.
> 
> Unfortunately that's not always 100% the case, and the kernel HID
> driver maintains a quirk table for non conformant hardware.
> 
> The ultimate fix is thus to declare this model's quirks kernel-side,
> by posting the usb id and needed changes on
> http://vger.kernel.org/vger-lists.html#linux-input
> 
How to check if it's the evdev map or lack of conformance?

Julian



From nicolas.mailhot at laposte.net  Mon Dec  1 12:45:27 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 1 Dec 2008 13:45:27 +0100 (CET)
Subject: evdev and multiple keyboards
In-Reply-To: <4933D9A1.4030307@gmail.com>
References: <4933C40C.8040203@gmail.com> <20081201114516.GA29466@srcf.ucam.org>
	<6370808e3d1e7b8a261b34838e26e65c.squirrel@arekh.dyndns.org>
	<4933D9A1.4030307@gmail.com>
Message-ID: <afa4029dae96c9fbe741d4952cbe15ac.squirrel@arekh.dyndns.org>



Le Lun 1 d?cembre 2008 13:33, Julian Sikorski a ?crit :
>
> Nicolas Mailhot pisze:
>>
>> Le Lun 1 d?cembre 2008 12:45, Matthew Garrett a ?crit :
>>
>>> USB devices output standardised keycodes, so if these are incorrect
>>> it
>>> implies that the evdev map in xkb is wrong.
>>
>> Unfortunately that's not always 100% the case, and the kernel HID
>> driver maintains a quirk table for non conformant hardware.
>>
>> The ultimate fix is thus to declare this model's quirks kernel-side,
>> by posting the usb id and needed changes on
>> http://vger.kernel.org/vger-lists.html#linux-input
>>
> How to check if it's the evdev map or lack of conformance?

Ask on the list. People will tell you to check keypresses result in
standard codes kernel-side with the console equivalent of xev (I don't
remember the command name).

If your keyboard does not emit standard codes, trying to "fix" it
xkeyboard-config side will only break other hardware.


-- 
Nicolas Mailhot



From rawhide at fedoraproject.org  Mon Dec  1 13:12:06 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon,  1 Dec 2008 13:12:06 +0000 (UTC)
Subject: rawhide report: 20081201 changes
Message-ID: <20081201131206.AC5501F8252@releng2.fedora.phx.redhat.com>

Compose started at Mon Dec  1 06:01:12 UTC 2008

New package sugar-memorize
        Memorize for Sugar
Updated Packages:

akonadi-1.0.80-2.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 1.0.80-2
- own /usr/share/akonadi and /usr/share/akonadi/agents (#473595)


autodir-0.99.9-6.fc11
---------------------
* Sun Nov 30 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.99.9-6
- rebuild for dependencies


cdlabelgen-4.1.0-1.fc11
-----------------------
* Sun Nov 30 17:00:00 2008 Dominik 'Rathann' Mierzejewski <rpm at greysector.net> 4.1.0-1
- updated to 4.1.0
- fixed rpmlint warnings


cobbler-1.2.9-2.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.2.9-2
- Simple Python 2.6 rebuild for rawhide


cups-1.4-0.b1.4.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1:1.4-0.b1.4
- Own more directories (bug #473581).


fcron-3.0.4-2.fc11
------------------
* Sun Nov 30 17:00:00 2008 Patrice Dumas <pertusus[AT]free[DOT]fr> 3.0.4-2
- use newer post scripts
  - use .Package instead of .Dist
  - remove unused patches
  - correct paths in scripts
  - ship check_system_crontabs
  - LSB compliant initscript
  - add scripts that watch config files as daemons and sync fcron files
  - add a subpackage that can be used as a vixie cron replacement


firstaidkit-0.2.2-4.fc11
------------------------
* Sun Nov 30 17:00:00 2008 Joel Granados <jgranado at redhat.com> - 0.2.2-4
- Include the firstaidkit directories in the package.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-2
- Rebuild for Python 2.6


glpi-0.71.3-1.fc11
------------------
* Sun Nov 30 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> - 0.71.3-1
- update to 0.71.3 (bugfix release)

* Sun Sep 28 18:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> - 0.71.2-1.el4.1
- Fix MySQL 4.1 compatibility issue


gnubiff-2.2.10-1.fc11
---------------------
* Thu Nov 27 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 2.2.10-1
- Version bump to 2.2.10. Closes Red Hat Bugzilla bug #464012.
- Added 'Requires: sox'.
- Fixed directory ownership issues.


hatari-1.1.0-1.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Andrea Musuruane <musuruan at gmail.com> 1.1.0-1
- updated to upstream 1.1.0


ibus-table-0.1.1.20081014-2.fc11
--------------------------------
* Mon Dec  1 17:00:00 2008 Peng Huang <shawn.p.huang at gmail.com> - 0.1.1.20081014-2
- Modified spec file to own all directories created by ibus-table.


itext-2.1.4-1.fc11
------------------
* Sun Nov 30 17:00:00 2008 Orcan Ogetbil <orcanbahri[AT]yahoo[DOT].com> 2.1.4-1
- Updated to 2.1.4.
- Set debug="on" on javac part of the build script to compile the aot-bits
  correctly. (bug#472292)


javasqlite-20081006-2.fc11
--------------------------
* Sun Nov 30 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 20081006-2
- Own the /usr/lib*/javasqlite dir (#473609).

* Tue Oct  7 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 20081006-1
- 20081006; all upstreamable patches applied upstream.


jd-2.1.0-0.1.svn2537_trunk.fc11
-------------------------------
* Mon Dec  1 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2537


jna-3.0.9-2.fc11
----------------
* Sun Nov 30 17:00:00 2008 Colin Walters <walters at redhat.com> - 3.0.9-2
- Fix library mapping, remove upstreamed patches

* Fri Oct 31 18:00:00 2008 Colin Walters <walters at redhat.com> - 3.0.9-1
- Rebase on upstream 3.0.9


kdebase-workspace-4.1.80-6.fc11
-------------------------------
* Thu Nov 27 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.80-5
- use python_sitearch for x86_64 systems
- kephal seems to be disabled/removed, re-adapted file lists

* Thu Nov 27 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-6
- disable Logitech mouse KCM again until #399931 is fixed

* Tue Nov 25 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-4
- respin

* Sun Nov 23 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.80-3
- rebase kdebase-workspace-4.1.1-show-systemsettings.patch
- new library: Kephal -> adapt file lists

* Wed Nov 19 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged
- drop kdebase-workspace-4.1.2-kdm-i18n.patch, it's included in upstream
- drop kdebase-workspace-4.0.85-plasma-default-wallpaper.patch, it's included in upstream
- drop kdebase-workspace-4.1.65-consolekit-kdm.patch
- add kdebase-workspace-4.1.80-session-button.patch
- add kdebase-workspace-4.1.2-ldap.patch

* Wed Nov 19 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast
- drop _default_patch_fuzz 2
- rebase startkde patch
- rebase plasma-konsole patch
- rebase ck-shutdown patch
- add PyKDE4-devel, python-devel and PyQt4-devel to build plasma's python
  scripting interface
- BR google-gadgets-devel for google gadgets scriptengine
- BR libusb-devel for Logitech USB support in KControl

* Thu Nov 13 17:00:00 2008 Than Ngo <than at redhat.com>??4.1.3-5
- apply upstream patch to fix X crash when disabling compositing

* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


ksshaskpass-0.5.1-1.fc11
------------------------
* Sun Nov 30 17:00:00 2008 Aurelien Bompard <abompard at fedoraproject.org> 0.5.1-1
- version 0.5.1

* Tue Jun 24 18:00:00 2008 Aurelien Bompard <abompard at fedoraproject.org> 0.4.1-1
- version 0.4.1


libcompizconfig-0.7.8-1.fc11
----------------------------
* Sun Nov 30 17:00:00 2008 Mohd Izhar Firdaus Ismail <mohd.izhar.firdaus at gmail.com> 0.7.8-1
- update to 0.7.8


mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11
------------------------------------------------------
* Sun Nov 30 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.1-7.5.20080409svn100264.1
- rebuild again...


mysql++-3.0.8-1.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 3.0.8-1
- update to 3.0.8

* Sun Nov 23 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 3.0.7-1
- update to 3.0.7


openvpn-2.1-0.29.rc15.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 2.1-0.29
- Update to 2.1_rc15


publican-0.39-0.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Jeff Fearn <jfearn at redhat.com> 0.39
- Disable make.graphic.viewport. BZ #467368
- Add missing XEP namespace. BZ #467256
- Add catch for ValidateTables where table for tgroup could not be found. BZ #468789
- Fix right margin error on verbatim and admonitions in PDF. BZ #467654
- Added foreignphrase to list of validated tags.
- Add foreignphrase, acronym, hardware to list of tags aspell should ignore.
- Fixed left align of verbatim items in notes.
- Fixed contrib class in CSS. BZ #469595
- Changed para & simpara to div in HTML. BZ #469286
- Fix layout of author in Revision History. BZ #469986
- Validated function tag. BZ #471144
- Fixed menu entry text. BZ #470967
- Validated type, methodname, excAppendix.xmleptionname, varname, interfacename tags. BZ #461708
- Banned glosslist (untranslatable) BZ #461864
- Validated uri, mousebutton, hardware tags. BZ #461870
- Validated othername tag. BZ #464315
- Removed collab from front page to match PDF output. BZ #469298
- Formalised handling of draft mode, root node only. BZ #468305
- Removed old help text from create_book and make type case insensitive. BZ #471776
- Fixed footnote numbers collapsing together. BZ #462668
- Fix translation report for po in nested directories.
- Changed Formal Para Title to follow parent indent. BZ #466309
- Validated qandadiv, tweaked layout. BZ #472482
- Handle xslthl:annotation. BZ #472500
- Fix dot on docnav css. BZ #472627
- Fix ol display in article. BZ #472491
- Added section of Drafting rules. (bforte)
- Fix CCS display of image in term.
- Add product URL. Modify header to use product url.
- Fix formalpara missing div. BZ #473843
- Fix OL missing margin in article. BZ #473844


publican-fedora-0.16-0.fc11
---------------------------
* Mon Dec  1 17:00:00 2008 Jeff Fearn <jfearn at redhat.com> 0.16
- Add override for PROD_URL


rt3-3.8.1-2.fc11
----------------
* Sun Nov 30 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 3.8.1-2
- Fix rt3-mailgate's %defattr(-,root,root,-).


scim-python-0.1.13rc1-3.fc11
----------------------------
* Mon Dec  1 17:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.13rc1-3
- Modified spec file to own all directories created by scim-python-* (#473665).

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.13rc1-2
- Rebuild for Python 2.6


vdr-femon-1.6.4-1.fc11
----------------------
* Sun Nov 30 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.6.4-1
- 1.6.4.

* Mon Nov 10 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.6.3-1
- 1.6.3.


vdr-skinsoppalusikka-1.6.3-1.fc11
---------------------------------
* Sun Nov 30 17:00:00 2008 - Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> 1.6.3-1
- 1.6.3


vdr-sudoku-0.3.4-1.fc11
-----------------------
* Sun Nov 30 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.3.4-1
- 0.3.4.

* Sun Nov 23 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.3.3-1
- 0.3.3.
- Include sudoku_generator in package.


wordwarvi-0.23-1.fc11
---------------------
* Sun Nov 30 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.23-1
- New upstream release 0.23 (The xmas release)


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 29
Broken deps for i386
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-kde-0.7.8-4.fc11.i386 requires libplasma.so.2
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.i386 requires libltdl.so.3
	ettercap-gtk-0.7.3-26.fc10.i386 requires libltdl.so.3
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	foobillard-3.0a-8.fc10.i386 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.i386 requires libltdl.so.3
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	heartbeat-2.1.3-3.fc10.i386 requires libltdl.so.3
	heartbeat-gui-2.1.3-3.fc10.i386 requires libltdl.so.3
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.i386 requires libplasma.so.2
	kde-plasma-quickaccess-0.7.1-2.fc11.i386 requires libplasma.so.2
	kde-plasma-runcommand-0.7-1.fc11.i386 requires libplasma.so.2
	kdebindings-4.1.2-2.fc10.i386 requires libplasma.so.2
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kdeedu-4.1.2-2.fc10.i386 requires libplasma.so.2
	7:kdenetwork-4.1.2-3.fc10.i386 requires libplasma.so.2
	kdeplasma-addons-4.1.2-2.fc10.i386 requires libplasma.so.2
	kdesdk-4.1.2-4.fc10.i386 requires libplasma.so.2
	6:kdeutils-4.1.2-3.fc10.i386 requires libplasma.so.2
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-bitstring-2.0.0-5.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.i386 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	1:openoffice.org-langpack-ar-3.0.0-9.11.fc11.i386 requires dejavu-fonts
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pils-2.1.3-3.fc10.i386 requires libltdl.so.3
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.i386 requires python-pygame
	rcsslogplayer-12.1.2-1.fc10.i386 requires librcssbase.so.0
	rrdtool-1.3.4-2.fc10.i386 requires dejavu-lgc-fonts
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	stonith-2.1.3-3.fc10.i386 requires libltdl.so.3
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-kde-0.7.8-4.fc11.x86_64 requires libplasma.so.2()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.x86_64 requires libltdl.so.3()(64bit)
	ettercap-gtk-0.7.3-26.fc10.x86_64 requires libltdl.so.3()(64bit)
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	foobillard-3.0a-8.fc10.x86_64 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	gift-0.11.8.1-10.fc9.x86_64 requires libltdl.so.3()(64bit)
	heartbeat-2.1.3-3.fc10.i386 requires libltdl.so.3
	heartbeat-2.1.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	heartbeat-gui-2.1.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.i386 requires libplasma.so.2
	kde-plasma-lancelot-1.0.3-1.fc10.x86_64 requires libplasma.so.2()(64bit)
	kde-plasma-quickaccess-0.7.1-2.fc11.x86_64 requires libplasma.so.2()(64bit)
	kde-plasma-runcommand-0.7-1.fc11.x86_64 requires libplasma.so.2()(64bit)
	kdebindings-4.1.2-2.fc10.i386 requires libplasma.so.2
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.x86_64 requires libqscintilla2.so.4()(64bit)
	kdebindings-4.1.2-2.fc10.x86_64 requires libplasma.so.2()(64bit)
	kdeedu-4.1.2-2.fc10.i386 requires libplasma.so.2
	kdeedu-4.1.2-2.fc10.x86_64 requires libplasma.so.2()(64bit)
	7:kdenetwork-4.1.2-3.fc10.x86_64 requires libplasma.so.2()(64bit)
	kdeplasma-addons-4.1.2-2.fc10.i386 requires libplasma.so.2
	kdeplasma-addons-4.1.2-2.fc10.x86_64 requires libplasma.so.2()(64bit)
	kdesdk-4.1.2-4.fc10.x86_64 requires libplasma.so.2()(64bit)
	6:kdeutils-4.1.2-3.fc10.i386 requires libplasma.so.2
	6:kdeutils-4.1.2-3.fc10.x86_64 requires libplasma.so.2()(64bit)
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-bitstring-2.0.0-5.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlp5-5.10-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.x86_64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:openoffice.org-langpack-ar-3.0.0-9.11.fc11.x86_64 requires dejavu-fonts
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pils-2.1.3-3.fc10.i386 requires libltdl.so.3
	pils-2.1.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.x86_64 requires python-pygame
	rcsslogplayer-12.1.2-1.fc10.i386 requires librcssbase.so.0
	rcsslogplayer-12.1.2-1.fc10.x86_64 requires librcssbase.so.0()(64bit)
	rrdtool-1.3.4-2.fc10.i386 requires dejavu-lgc-fonts
	rrdtool-1.3.4-2.fc10.x86_64 requires dejavu-lgc-fonts
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	stonith-2.1.3-3.fc10.i386 requires libltdl.so.3
	stonith-2.1.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-kde-0.7.8-4.fc11.ppc requires libplasma.so.2
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.ppc requires libltdl.so.3
	ettercap-gtk-0.7.3-26.fc10.ppc requires libltdl.so.3
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	firstaidkit-plugin-grub-0.2.2-4.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc requires dejavu-fonts
	freeradius-2.1.1-2.fc10.ppc requires libltdl.so.3
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.ppc requires libltdl.so.3
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	heartbeat-2.1.3-3.fc10.ppc requires libltdl.so.3
	heartbeat-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	heartbeat-gui-2.1.3-3.fc10.ppc requires libltdl.so.3
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.ppc requires libplasma.so.2
	kde-plasma-lancelot-1.0.3-1.fc10.ppc64 requires libplasma.so.2()(64bit)
	kde-plasma-quickaccess-0.7.1-2.fc11.ppc requires libplasma.so.2
	kde-plasma-runcommand-0.7-1.fc11.ppc requires libplasma.so.2
	kdebindings-4.1.2-2.fc10.ppc requires libplasma.so.2
	kdebindings-4.1.2-2.fc10.ppc requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	kdebindings-4.1.2-2.fc10.ppc64 requires libplasma.so.2()(64bit)
	kdeedu-4.1.2-2.fc10.ppc requires libplasma.so.2
	kdeedu-4.1.2-2.fc10.ppc64 requires libplasma.so.2()(64bit)
	7:kdenetwork-4.1.2-3.fc10.ppc requires libplasma.so.2
	kdeplasma-addons-4.1.2-2.fc10.ppc requires libplasma.so.2
	kdeplasma-addons-4.1.2-2.fc10.ppc64 requires libplasma.so.2()(64bit)
	kdesdk-4.1.2-4.fc10.ppc requires libplasma.so.2
	6:kdeutils-4.1.2-3.fc10.ppc requires libplasma.so.2
	6:kdeutils-4.1.2-3.fc10.ppc64 requires libplasma.so.2()(64bit)
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-bitstring-2.0.0-5.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	1:openoffice.org-langpack-ar-3.0.0-9.11.fc11.ppc requires dejavu-fonts
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pils-2.1.3-3.fc10.ppc requires libltdl.so.3
	pils-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.ppc requires python-pygame
	rcsslogplayer-12.1.2-1.fc10.ppc requires librcssbase.so.0
	rcsslogplayer-12.1.2-1.fc10.ppc64 requires librcssbase.so.0()(64bit)
	rrdtool-1.3.4-2.fc10.ppc requires dejavu-lgc-fonts
	rrdtool-1.3.4-2.fc10.ppc64 requires dejavu-lgc-fonts
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	stonith-2.1.3-3.fc10.ppc requires libltdl.so.3
	stonith-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	compiz-kde-0.7.8-4.fc11.ppc64 requires libplasma.so.2()(64bit)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.ppc64 requires libltdl.so.3()(64bit)
	ettercap-gtk-0.7.3-26.fc10.ppc64 requires libltdl.so.3()(64bit)
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	firstaidkit-plugin-grub-0.2.2-4.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc64 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	heartbeat-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	heartbeat-gui-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.ppc64 requires libplasma.so.2()(64bit)
	kde-plasma-quickaccess-0.7.1-2.fc11.ppc64 requires libplasma.so.2()(64bit)
	kde-plasma-runcommand-0.7-1.fc11.ppc64 requires libplasma.so.2()(64bit)
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	kdebindings-4.1.2-2.fc10.ppc64 requires libplasma.so.2()(64bit)
	kdeedu-4.1.2-2.fc10.ppc64 requires libplasma.so.2()(64bit)
	7:kdenetwork-4.1.2-3.fc10.ppc64 requires libplasma.so.2()(64bit)
	kdeplasma-addons-4.1.2-2.fc10.ppc64 requires libplasma.so.2()(64bit)
	kdesdk-4.1.2-4.fc10.ppc64 requires libplasma.so.2()(64bit)
	6:kdeutils-4.1.2-3.fc10.ppc64 requires libplasma.so.2()(64bit)
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-bitstring-2.0.0-5.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:openoffice.org-langpack-ar-3.0.0-9.11.fc11.ppc64 requires dejavu-fonts
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pils-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.ppc64 requires python-pygame
	rcsslogplayer-12.1.2-1.fc10.ppc64 requires librcssbase.so.0()(64bit)
	rrdtool-1.3.4-2.fc10.ppc64 requires dejavu-lgc-fonts
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	stonith-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From bkearney at redhat.com  Mon Dec  1 13:24:33 2008
From: bkearney at redhat.com (Bryan Kearney)
Date: Mon, 01 Dec 2008 08:24:33 -0500
Subject: ace name conflict
In-Reply-To: <492D6A6E.7010205@ioa.s.u-tokyo.ac.jp>
References: <20081126123631.8BB4F1F823B@releng2.fedora.phx.redhat.com>	<ggjoqn$uft$1@ger.gmane.org>
	<492D6A6E.7010205@ioa.s.u-tokyo.ac.jp>
Message-ID: <4933E591.9020506@redhat.com>

Mamoru Tasaka wrote:
> Kevin Kofler wrote, at 11/27/2008 12:09 AM +9:00:
>> Rawhide Report wrote:
>>> New package ace
>>>         Appliance Configuration Engine
>>
>> Hmmm, this has a name conflict with another ace, from:
>> http://www.cs.wustl.edu/~schmidt/ACE.html
>> which has packages for Fedora named "ace":
>> http://dist.bonsai.com/ken/ace_tao_rpm/
>> These have existed for a while already.
> 
> Just for clarification, there is a review request for ace-tao (i.e.
> ace-tao is not imported into Fedora), however currently the
> review request is blocked by license issue:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=450164
> 
> Regards,
> Mamoru
> 

the thincrust ace has no real penetration (the recently added one), so 
if it is easier to rename that I would be happy to. I would just hope I 
dont need to go through the complete review cycle :)

-- bk




From lesmikesell at gmail.com  Mon Dec  1 13:56:00 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 01 Dec 2008 07:56:00 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
References: <492E05E7.2080708@cchtml.com>	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>	<493341BB.10706@cchtml.com>
	<5rjc06xma9.ln2@ppp1053.in.ipex.cz>
Message-ID: <4933ECF0.5000701@gmail.com>

Matej Cepl wrote:
> On 2008-12-01, 01:45 GMT, Michael Cronenworth wrote:
>> Man pages, while informative, are limited. If examples or 
>> detailed information are required then you're back to Google 
>> searching.
> 
> Yes, there are many manpages which are pretty bad. But expanding 
> content won't happen by switching to different format, but fixing 
> each manpage. Yes, one at the time.

Adding a few examples won't hurt, but man pages are not the place for 
conceptual fluff.  We need some other format to hold an overview of why 
you should use each program and how various program can be combined to 
accomplish different results.  Man pages should just contain a reference 
for that program's use, because you won't look there until you already 
know why you want to run it.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From ivazqueznet at gmail.com  Mon Dec  1 13:56:27 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 08:56:27 -0500
Subject: Round 3 starting (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <1227923821.3835.39.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
Message-ID: <1228139787.3835.189.camel@ignacio.lan>

This round is composed of packages that contain compiled Python code but
do not have a Requires of python(abi). Please note that this is a
packaging bug as the bytecode is specific to the version of the Python
it was compiled with. Whether this is a problem with rpm's macros or
with the package itself must be dealt with on a case-by-case basis.

Ajaxterm
aldrin
anaconda
ant
audit-viewer
beagle
bibus
booty
catfish
centerim
cluster
cobbler
cycle
decibel-audio-player
devhelp
dstat
eclipse
eclipse-pydev
eclipse-slide
edsadmin
emacs
emesene
enemies-of-carlotta
epiphany-extensions
expendable
fail2ban
flumotion
fontforge
frysk
fslint
fuse-gmailfs
garmin-sync
gdeskcal
gdesklets
gdesklets-goodweather
gedit-plugins
gimp
glump
gnome-applet-jalali-calendar
gnome-doc-utils
gnome-schedule
gquilt
gramps
gtkpod
heartbeat
honeyd
ht2html
hwbrowser
ibus-pinyin
ibus-table
ikiwiki
inn
jabbim
jbrout
jython
kdelibs
kdesdk
kdevelop
kexec-tools
koffice
konq-plugins
libopensync-plugin-moto
lilypond
luma
lyx
meld
mftrace
mirrormanager
moin-latex
openlierox
openmsx
pcapdiff
pinot
pitivi
pure-ftpd
pybliographer
pyicq-t
pypar2
pyroom
R-nws
rpmlint
sagator
scons
sectool
selinux-policy
setroubleshoot-plugins
sk2py
smolt
solfege
sugar-analyze
sugar-browse
sugar-calculator
sugar-chat
sugar-journal
sugar-jukebox
sugar-log
sugar-memorize
sugar-moon
sugar-presence-service
sugar-terminal
sugar-turtleart
sugar-write
switchdesk
system-config-bind
system-config-boot
system-config-cluster
system-config-date
system-config-display
system-config-firewall
system-config-httpd
system-config-kdump
system-config-keyboard
system-config-kickstart
system-config-language
system-config-lvm
system-config-netboot
system-config-network
system-config-nfs
system-config-rootpassword
system-config-users
system-config-vsftpd
system-switch-displaymanager
system-switch-java
system-switch-mail
tellico
tracker
tuxpaint
txt2tags
waf
wallpapoz
wastesedge
xastir
xemacs-packages-extra
xpilot-ng
yum-arch

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/84d6bbd8/attachment.sig>

From camilo at mesias.co.uk  Mon Dec  1 14:01:49 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Mon, 1 Dec 2008 14:01:49 +0000
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <4933ECF0.5000701@gmail.com>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com> <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
	<4933ECF0.5000701@gmail.com>
Message-ID: <d551e0e20812010601k55f88b2fpb09b5ef9980401c@mail.gmail.com>

2008/12/1 Les Mikesell <lesmikesell at gmail.com>:
> Adding a few examples won't hurt, but man pages are not the place for
> conceptual fluff.  We need some other format to hold an overview of why you
> should use each program and how various program can be combined to
> accomplish different results.  Man pages should just contain a reference for
> that program's use, because you won't look there until you already know why
> you want to run it.

Don't forget you can have manpages for conceptual fluff (try man
selinux / which selinux), and you can find out what command you need
to do using 'apropos'. Example: apropos security

The man system really has been round the block a few times...

-Cam



From dan at danny.cz  Mon Dec  1 14:02:20 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Mon, 01 Dec 2008 15:02:20 +0100
Subject: Server SIG - work areas
Message-ID: <1228140140.3664.72.camel@eagle.danny.cz>

Hello,

it has been some time when the Server SIG was announced. And one goal
has been already almost accomplished - to start discussion about the
needs of the server community. For "Server" specific issues I have
opened our own mailing list - subscribe at
https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list

One question raised during the discussions was "what is a server" and
the answer can be simple. The server is a combination of bootloader,
kernel and "the server", where "the server" can be a file server, web
server, database server, application server, etc. It is quite common to
have just one service running per hardware (both physical and virtual).
But a mix of running servers is also possible :-)

There are miscellaneous goals written on the wiki page, so it is time to
get them a little bit organized and to divide the work into more
specific areas. And they are here:

Installer
 - work with the anaconda team to keep anaconda suitable for server
installs (text mode, kickstarts, ...)
 - create a lightweight installer/bootstraper

Server services
 - bring more server packages into Fedora
 - encourage creation of EPEL branches for existing packages

Kernel
 - everything about the kernel side of servers

Admins corner
 - place for administration and monitoring technologies available in
Fedora
 - collects pointers to how-tos and other docs useful for administrators
 - work on the TUI counterparts of GUI system-config-* tools, should go
in hand with the backend/frontend separation

Security
 - improve/monitor the security standards for current server software
 - help the desktop developers with the security aspects of their work

QA
 - testing

If there are no objections I will update the wiki accordingly and
participants can then put their names/nicks to their area of interest.


		Dan




From lesmikesell at gmail.com  Mon Dec  1 14:05:04 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 01 Dec 2008 08:05:04 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <4933CA23.1050400@gmail.com>
References: <492E05E7.2080708@cchtml.com> <4933CA23.1050400@gmail.com>
Message-ID: <4933EF10.1080004@gmail.com>

Alphonse Van Assche wrote:
> Michael Cronenworth a ?crit :
>> <cut>
>> 5. Global access
>>  You should be able to access any and all documentation for all 
>> software through a single window, be it X or console, without having 
>> to open the corresponding program.
>>
> 6.  a common way to find documentation about a given package. Here is 
> what I do when I need to read docs on a given package.
> 
> 1. rpm -ql pgkname
> if there is a man page and/or README and/or .html and/or ... - done!
> 2. yum list pkgname\*
> if there is sub-package named pkgname-doc - done!
> 3. rpm -qi pgkname
> if the URL tag point to upstream web site - open firefox find the 
> documentation page - done!
> 4. fedora-cvs pkgname - hoping that I know the language used and that 
> the code is nicely documented ;-) - done!
> 5. ??
> 
> I thing that we can do something to optimize the search of documentation 
> of a given package. To be honest I don't have any idea on the best way 
> to do that  - but I'm sure that we can do something better.

Yes, that approach is horrible and your example starts from the point of 
already knowing the package name.  We need a reasonable way for someone 
to find a new package (or any package they don't know about) that would 
perform some operation useful to them even if they don't have it 
installed yet.  Google, of course, knows everything, but even with a 
carefully crafted search will usually return a lot of irrelevant results 
related to other OS's or different version numbers.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From bkearney at redhat.com  Mon Dec  1 14:01:13 2008
From: bkearney at redhat.com (Bryan Kearney)
Date: Mon, 01 Dec 2008 09:01:13 -0500
Subject: New users confused about Spins' Names
In-Reply-To: <1227718827.5276.56.camel@luminos.localdomain>
References: <492D38D3.1050303@students.iiit.ac.in>	<1227717355.5276.51.camel@luminos.localdomain>	<alpine.LFD.2.00.0811261145180.12357@localhost.localdomain>
	<1227718827.5276.56.camel@luminos.localdomain>
Message-ID: <4933EE29.5030603@redhat.com>

Jesse Keating wrote:
> On Wed, 2008-11-26 at 11:46 -0500, Seth Vidal wrote:
>> If I'm a user and I don't know where to go, the reality is, I go to 
>> google.
>>
>> type in 'fedora torrents' the first hit is torrent.fp.o - so that page 
>> needs to be relatively clear to users.
>>
>> Saying "We've already lost" doesn't help the reality at all, which is 
>> google directs. Let's work w/i the reality.
> 
> Glad we put so much effort into making get.fedoraproject.org so useful.
> 
> If people want better descriptions for the spins, the spin owners are
> going to have to provide those as part of the feature process to become
> a hosted spin for a release.  The amount of feedback and interaction
> between spin owners and releng when composing the spins, and feedback
> after spins went live for beta/preview/etc.. was appallingly
> non-existent in most cases.

Is the goal to add a better description on the torrents page, or have 
the get.fedoraproject.org "See all custom Spins" redirect to some place 
else? I would assume the latter.

-- bk




From mclasen at redhat.com  Mon Dec  1 14:17:46 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 01 Dec 2008 09:17:46 -0500
Subject: Seahorse is orphaned?
In-Reply-To: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
Message-ID: <1228141066.3391.6.camel@localhost.localdomain>

On Mon, 2008-12-01 at 16:45 +0530, Debarshi Ray wrote:
> I just noticed that the 'seahorse' package is orphaned [1] although
> Matthias and others seem to be taking care of it for some time. So is
> the package really orphaned or is this just an oversight?
> 

Hmm, funny. I've asked Tomas Bzatek to take it. He's the maintainer of
gnome-keyring-manager, and we are going to obsolete g-k-m in favour of
seahorse anyway...


Matthias



From shamardin at gmail.com  Mon Dec  1 14:41:49 2008
From: shamardin at gmail.com (Lev Shamardin)
Date: Mon, 01 Dec 2008 17:41:49 +0300
Subject: My (unpleasant) fedora 10 installation experience
Message-ID: <4933F7AD.1040904@gmail.com>

Hi all,

Today the file system on my wife's laptop got corrupted (that's another sad
fedora, kerneloops and tuxonice story) and I decided to reinstall everything
from scratch using Fedora 10 installation DVD. The laptop previously had Fedora
9 installed, so my plan was to reinstall the system and then restore the /home
partition with fsck & co.

The installation process from the DVD went quite smoothly, but when I got to the
first boot there were some surprises. Since I was going to recover /home later,
I was not planning to create any users at the first boot, but skipping the
"Create user" screen required to press the "Use network login..." button and
cancel the dialog, otherwise the firstboot continued to complain that I
definitely need to create a user.

This laptop uses wireless to connect to the internet, and guess what? Is is NOT
yet configured when you are running the firstboot. On the Date & Time screen I
selected "Enable network time protocol", pressed forward, and then hit Cancel on
the "Contacting NTP..." dialog (I supposed that I don't want to wait for the
network timeout) and... Firstboot crashed leaving me with an empty screen with a
mouse cursor on it. Ctrl-Alt-F1/F2/etc. brought me to another empty screen,
without a mouse this time. Fortunately Ctrl-Alt-Del from that mouseless screen
worked fine.

Next boot showed firstboot again allowing to test these bugs and finally get
through them to discover another surprise.

I've selected "Russian" keyboard during the installation process. Usually this
assumed that there are two keyboard layouts (English and Russian) and you can
switch between them with a hotkey. But not in the default state of the GDM after
the first boot. The only option I had was Russian input! I tried all common
layout switch shortcuts but have not managed to find one to switch the layout to
english, but I had to type something in english since I have not created any
users and my root user had both english login name and password. So I had to go
to the menus, search for USA keyboard layout and only after this had a chance to
try login to the system. It really seems to me that these layout defaults are
insane. Is it that common to have non-english login names and passwords, really?

Anyway, I failed to login interactively to X as root ("Cannot authenticate
user") and after that even selecting Keyboard: USA did not bring english input
to the gdm! I tried to switch several times, nothing happened. Adding a second
USA layout (USA international this time) partially solved the problem with
switching input language, but I still was not able to login as root to a
graphical terminal to recover the system. Of course some searching in google
delivered the answer that I have to modify the gdm PAM settings, but that only
brought me to a discovery that gdm forgets the input language and layout
settings after asking for the user name! So the complete "root login" procedure
looks like this:
1. Press "other user..." [Why should I do this if there are no users in the
system except root?]
2. Switch layout to USA. [First switch is broken, so]
3. Switch layout to USA (intl). [Aha, english letters finally]
4. Enter user name
5. Switch layout to USA. [Don't forget: the first switch is broken]
6. Switch layout to USA (intl).
7. Enter the root password.

Phew, That was easy!

Never ever before a fresh Fedora installation was that hostile towards system
recovery... Especially to a non-US user. That is sad.

With best regards,
Lev.



From notting at redhat.com  Mon Dec  1 14:56:17 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 1 Dec 2008 09:56:17 -0500
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <200811261650.53746.sgrubb@redhat.com>
References: <200811261539.31233.sgrubb@redhat.com>
	<20081126205253.GA13998@nostromo.devel.redhat.com>
	<200811261650.53746.sgrubb@redhat.com>
Message-ID: <20081201145617.GA7246@nostromo.devel.redhat.com>

Steve Grubb (sgrubb at redhat.com) said: 
> On Wednesday 26 November 2008 15:52:53 Bill Nottingham wrote:
> > > Why are we doing it like this?
> >
> > It's handled via ConsoleKit - is it running? Is it functioning correctly?
> 
> I believe its running. But gdm now has no way of shutting down if you log in 
> and type init 5. If you boot to run level 5 its OK.

Was both your console login and gdm on the same tty?

Bill



From abu_hurayrah at hidayahonline.org  Mon Dec  1 14:28:09 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Mon, 01 Dec 2008 16:28:09 +0200
Subject: Server SIG - work areas
In-Reply-To: <1228140140.3664.72.camel@eagle.danny.cz>
References: <1228140140.3664.72.camel@eagle.danny.cz>
Message-ID: <1228141690.3451.65.camel@beta>

On Mon, 2008-12-01 at 15:02 +0100, Dan Hor?k wrote:
> Hello,
> 
> it has been some time when the Server SIG was announced. And one goal
> has been already almost accomplished - to start discussion about the
> needs of the server community. For "Server" specific issues I have
> opened our own mailing list - subscribe at
> https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
> 
> One question raised during the discussions was "what is a server" and
> the answer can be simple. The server is a combination of bootloader,
> kernel and "the server", where "the server" can be a file server, web
> server, database server, application server, etc. It is quite common to
> have just one service running per hardware (both physical and virtual).
> But a mix of running servers is also possible :-)
> 
> There are miscellaneous goals written on the wiki page, so it is time to
> get them a little bit organized and to divide the work into more
> specific areas. And they are here:
> 
> Installer
>  - work with the anaconda team to keep anaconda suitable for server
> installs (text mode, kickstarts, ...)
>  - create a lightweight installer/bootstraper
> 
> Server services
>  - bring more server packages into Fedora
>  - encourage creation of EPEL branches for existing packages
> 
> Kernel
>  - everything about the kernel side of servers
> 
> Admins corner
>  - place for administration and monitoring technologies available in
> Fedora
>  - collects pointers to how-tos and other docs useful for administrators
>  - work on the TUI counterparts of GUI system-config-* tools, should go
> in hand with the backend/frontend separation
> 
> Security
>  - improve/monitor the security standards for current server software
>  - help the desktop developers with the security aspects of their work
> 
> QA
>  - testing
> 
> If there are no objections I will update the wiki accordingly and
> participants can then put their names/nicks to their area of interest.
> 
> 
> 		Dan

Signed-up for the list.  This all sounds great for a start, Dan.  I'm
sure it'll develop more over time, as long as we're flexible enough to
allow for that.



From notting at redhat.com  Mon Dec  1 15:04:53 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 1 Dec 2008 10:04:53 -0500
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <20081127153327.GA21300@srcf.ucam.org>
References: <20081127153327.GA21300@srcf.ucam.org>
Message-ID: <20081201150453.GB7246@nostromo.devel.redhat.com>

Matthew Garrett (mjg at redhat.com) said: 
> The first is relatime. I've just pushed Ingo's smarter relatime code 
> towards upstream again. In this configuration atime will only be updated 
> if the current atime is either older than ctime or mtime, or if the 
> current atime is more than a day in the past. The amount of time 
> required before atime is updated will be a tunable, and a norelatime 
> mount parameter will be available to mount filesystems without this 
> behaviour. This shouldn't affect the behaviour of any applications.

Works for me.

> The second is to increase the value of dirty_writeback_centisecs. This 
> will result in dirty data spending more time in memory before being 
> pushed out to disk. This is probably more controversial. The effect of 
> this is that a power interruption will potentially result in more data 
> being lost. It doesn't alter the behaviour of fsync(), so paranoid 
> applications will still get to ensure that their data is on disk. Of 
> course, it would also be helpful to stop applications generating dirty 
> pages where possible. This would obviously be reverted if the system 
> enters a critical power state.
> 
> Thirdly, I'd like to enable laptop mode by default. The effect of this 
> is that any access that goes to disk will trigger an opportunistic 
> flushing of dirty data shortly afterwards. To an extent this mitigates 
> the change to dirty_writeback_centisecs, but there's obviously still 
> some increased chance of data loss.

I'd be curious how this affects various workloads if we're changing
the global defaults. Were you planning on flipping the kernel defaults,
or just setting a default in sysctl.conf? (It occurs to me that laptop_mode
is horribly named.)

Bill



From pingou at pingoured.fr  Mon Dec  1 15:08:46 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Mon, 01 Dec 2008 16:08:46 +0100
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <4933F7AD.1040904@gmail.com>
References: <4933F7AD.1040904@gmail.com>
Message-ID: <4933FDFE.5090308@pingoured.fr>

Lev Shamardin wrote:
> Hi all,
> 
> Today the file system on my wife's laptop got corrupted (that's another sad
> fedora, kerneloops and tuxonice story) and I decided to reinstall everything
> from scratch using Fedora 10 installation DVD. The laptop previously had Fedora
> 9 installed, so my plan was to reinstall the system and then restore the /home
> partition with fsck & co.
> 
> The installation process from the DVD went quite smoothly, but when I got to the
> first boot there were some surprises. Since I was going to recover /home later,
> I was not planning to create any users at the first boot, but skipping the
> "Create user" screen required to press the "Use network login..." button and
> cancel the dialog, otherwise the firstboot continued to complain that I
> definitely need to create a user.
> 
> This laptop uses wireless to connect to the internet, and guess what? Is is NOT
> yet configured when you are running the firstboot. On the Date & Time screen I
> selected "Enable network time protocol", pressed forward, and then hit Cancel on
> the "Contacting NTP..." dialog (I supposed that I don't want to wait for the
> network timeout) and... Firstboot crashed leaving me with an empty screen with a
> mouse cursor on it. Ctrl-Alt-F1/F2/etc. brought me to another empty screen,
> without a mouse this time. Fortunately Ctrl-Alt-Del from that mouseless screen
> worked fine.
> 
> Next boot showed firstboot again allowing to test these bugs and finally get
> through them to discover another surprise.
> 
> I've selected "Russian" keyboard during the installation process. Usually this
> assumed that there are two keyboard layouts (English and Russian) and you can
> switch between them with a hotkey. But not in the default state of the GDM after
> the first boot. The only option I had was Russian input! I tried all common
> layout switch shortcuts but have not managed to find one to switch the layout to
> english, but I had to type something in english since I have not created any
> users and my root user had both english login name and password. So I had to go
> to the menus, search for USA keyboard layout and only after this had a chance to
> try login to the system. It really seems to me that these layout defaults are
> insane. Is it that common to have non-english login names and passwords, really?

Actually I can answer to that one: Yes it is ! :)


About the installation I also saved my /home while I switched to Fedora 
10 from Fedora 9.
On the partition screen I said this partition is my /home and on the 
firstboot I said I want to create user foo. I had a nice popup saying 
that user "foo" already has a /home folder do you want to use it, or do 
you want a new one ?"
I said I want to keep my /home... Here I was, new F10 no data lost on 
/home and the same user...

Dunno if that can help you...

Best regards,

Pierre



From P at draigBrady.com  Mon Dec  1 15:09:22 2008
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Mon, 1 Dec 2008 15:09:22 +0000
Subject: Round 3 starting
In-Reply-To: <1228139787.3835.189.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228139787.3835.189.camel@ignacio.lan>
Message-ID: <4933FE22.8050103@draigBrady.com>

Ignacio Vazquez-Abrams wrote:
> This round is composed of packages that contain compiled Python code but
> do not have a Requires of python(abi). Please note that this is a
> packaging bug as the bytecode is specific to the version of the Python
> it was compiled with. Whether this is a problem with rpm's macros or
> with the package itself must be dealt with on a case-by-case basis.
> 
> fslint

/usr/share/fslint/fslint/supprt/rmlint/fixdup.py
/usr/share/fslint/fslint/supprt/rmlint/fixdup.pyc
/usr/share/fslint/fslint/supprt/rmlint/fixdup.pyo

fixdup.py is a small support script that I don't
want a precompiled version of as it's not imported.

Hrm, something must go autocompiling *.py or something.

http://fedoraproject.org/wiki/Packaging/Python#Byte_Compiled_Files

Ah, so I need to explicitly %exclude them?

cheers,
P?draig.



From shamardin at gmail.com  Mon Dec  1 15:21:57 2008
From: shamardin at gmail.com (Lev Shamardin)
Date: Mon, 01 Dec 2008 18:21:57 +0300
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <4933FDFE.5090308@pingoured.fr>
References: <4933F7AD.1040904@gmail.com> <4933FDFE.5090308@pingoured.fr>
Message-ID: <49340115.7090007@gmail.com>

On 12/01/2008 06:08 PM, Pierre-Yves wrote:
>> insane. Is it that common to have non-english login names and
>> passwords, really?
> 
> Actually I can answer to that one: Yes it is ! :)

I'm talking about the account names, not the geckos. As far as I know it is not
allowed to have anything except english low case letters and numbers as an
account name. On the system I'm recovering now even

adduser -m ??????

says "useradd: invalid user name '??????'".

> About the installation I also saved my /home while I switched to Fedora
> 10 from Fedora 9.
> On the partition screen I said this partition is my /home and on the
> firstboot I said I want to create user foo. I had a nice popup saying
> that user "foo" already has a /home folder do you want to use it, or do
> you want a new one ?"

In my case /home had severe file system errors, it should not be mounted in
read/write without accurate manual fixing, so I had an empty (unmounted) /home

> Dunno if that can help you...

I'm not looking for help, I'm trying to raise a discussion about insane default
assumptions made by installer for a fresh fedora 10 system.

--
Lev.



From martin.langhoff at gmail.com  Mon Dec  1 15:23:02 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Mon, 1 Dec 2008 13:23:02 -0200
Subject: Server SIG - work areas
In-Reply-To: <1228140140.3664.72.camel@eagle.danny.cz>
References: <1228140140.3664.72.camel@eagle.danny.cz>
Message-ID: <46a038f90812010723x6bd9efb6q53a257862a5de762@mail.gmail.com>

On Mon, Dec 1, 2008 at 12:02 PM, Dan Hor?k <dan at danny.cz> wrote:
> opened our own mailing list - subscribe at
> https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list

Cool - signing up. Excellent high level list of topics - matches
perfectly with my OLPC School Server needs.

I guess specific technical discussions do come back to
fedora-devel-list@ still... we can't really do it without help --
however indirect -- from the wider dev community.

(If we do take all "server" discussions there, we could succeed in
removing them from here, effectively lowering awareness of the server
needs. That would be... counterproductive...)

cheers,


m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From nicolas.mailhot at laposte.net  Mon Dec  1 15:27:22 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 1 Dec 2008 16:27:22 +0100 (CET)
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <4933F7AD.1040904@gmail.com>
References: <4933F7AD.1040904@gmail.com>
Message-ID: <dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>



Le Lun 1 d?cembre 2008 15:41, Lev Shamardin a ?crit :
> It really seems to me that these layout
> defaults are
> insane. Is it that common to have non-english login names and
> passwords, really?

Many non-us layouts include latin keys so they don't need a us layout
to type english. It's only countries that do not use the latin script
for their own language which have problems.

This is all a result of more complete system and gui integration,
which exposes all the missing/semi-working bits system side. When
there was little integration xorg could have totally different
settings and people didn't care non-xorg console was an i18n mess.

Regards,

-- 
Nicolas Mailhot



From shamardin at gmail.com  Mon Dec  1 15:35:50 2008
From: shamardin at gmail.com (Lev Shamardin)
Date: Mon, 01 Dec 2008 18:35:50 +0300
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>
References: <4933F7AD.1040904@gmail.com>
	<dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>
Message-ID: <49340456.7050802@gmail.com>

On 12/01/2008 06:27 PM, Nicolas Mailhot wrote:
> 
> Le Lun 1 d?cembre 2008 15:41, Lev Shamardin a ?crit :
>> It really seems to me that these layout
>> defaults are
>> insane. Is it that common to have non-english login names and
>> passwords, really?
> 
> Many non-us layouts include latin keys so they don't need a us layout
> to type english. It's only countries that do not use the latin script
> for their own language which have problems.

Well, at least Fedora 5 - 9 in the described case allowed switching of the input
layout with one of the default shortcuts, but you still had to guess which
default shortcut to use. And now not only this old feature is broken, but even
new features are not working as advertised.

> This is all a result of more complete system and gui integration,
> which exposes all the missing/semi-working bits system side. When
> there was little integration xorg could have totally different
> settings and people didn't care non-xorg console was an i18n mess.

Er... So what? Can't get your point. I'm talking about the xorg gdm login
screen, fortunately the non-xorg console still has a great vanilla english (US)
input without any chances to switch to russian layout without manual messing
with extra configuration files.

And by the way, the graphical root gnome session has the English (US) default
layout.

--
Lev.



From nicolas.mailhot at laposte.net  Mon Dec  1 15:48:22 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 1 Dec 2008 16:48:22 +0100 (CET)
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <49340456.7050802@gmail.com>
References: <4933F7AD.1040904@gmail.com>
	<dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>
	<49340456.7050802@gmail.com>
Message-ID: <bf967e93f32794940b6560b82c859ae9.squirrel@arekh.dyndns.org>



Le Lun 1 d?cembre 2008 16:35, Lev Shamardin a ?crit :
>
> On 12/01/2008 06:27 PM, Nicolas Mailhot wrote:

>> This is all a result of more complete system and gui integration,
>> which exposes all the missing/semi-working bits system side. When
>> there was little integration xorg could have totally different
>> settings and people didn't care non-xorg console was an i18n mess.
>
> Er... So what? Can't get your point. I'm talking about the xorg gdm
> login screen,

xorg in Fedora now runs in no-configuration-file mode which means the
layout preferences have to be read somewhere else.

Ideally this somewhere else would be the same somewhere else as for
the console, exactly like unified kernel-side modesetting. But since
the console is not providing good layout options, there is a new
script in F10 that tries to workaround this mismatch.

Obviously, in your case, it fails.

-- 
Nicolas Mailhot



From dhuff at redhat.com  Mon Dec  1 15:57:39 2008
From: dhuff at redhat.com (David Huff)
Date: Mon, 01 Dec 2008 10:57:39 -0500
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <1226699696.11393.65.camel@luminos.localdomain>
References: <20081114192450.18827.51863@faldor.intranet>	<491DD575.1070200@redhat.com>	<20081114213352.2f073127.mschwendt@gmail.com>	<gfkq8p$bms$1@ger.gmane.org>
	<491DF130.7040403@redhat.com>
	<1226699696.11393.65.camel@luminos.localdomain>
Message-ID: <49340973.4040204@redhat.com>

Jesse Keating wrote:
> Er, what exactly is the issue at hand?

I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch" to
the spec file however it is still reporting broken dep of qemu for ppc64.

So either the rpm *is* being pulled in to the tree eventhough 
ExclusiveArch is set,  or whatever is checking for broken deops is 
reporting incorrectly.


-D

I know this is an old thread however I just got two more notifications 
for two new RPMs:

Michael Schwendt wrote:
 > Your following packages in the repository suffer from broken 
dependencies:
 >
 > package: appliance-tools-003.9-1.fc10.noarch from fedora-updates-10-ppc64
 >   unresolved deps:
 >      qemu-img
 >
 > Your following packages in the repository suffer from broken 
dependencies:
 >
 > package: appliance-tools-002.8-1.fc9.noarch from 
fedora-updates-testing-9-ppc64
 >   unresolved deps:
 >      qemu-img





From a.badger at gmail.com  Mon Dec  1 16:26:06 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 01 Dec 2008 08:26:06 -0800
Subject: Round 3 starting
In-Reply-To: <4933FE22.8050103@draigBrady.com>
References: <1227923821.3835.39.camel@ignacio.lan>	<1228139787.3835.189.camel@ignacio.lan>
	<4933FE22.8050103@draigBrady.com>
Message-ID: <4934101E.4000105@gmail.com>

P?draig Brady wrote:
> Ignacio Vazquez-Abrams wrote:
>> This round is composed of packages that contain compiled Python code but
>> do not have a Requires of python(abi). Please note that this is a
>> packaging bug as the bytecode is specific to the version of the Python
>> it was compiled with. Whether this is a problem with rpm's macros or
>> with the package itself must be dealt with on a case-by-case basis.
>>
>> fslint
> 
> /usr/share/fslint/fslint/supprt/rmlint/fixdup.py
> /usr/share/fslint/fslint/supprt/rmlint/fixdup.pyc
> /usr/share/fslint/fslint/supprt/rmlint/fixdup.pyo
> 
> fixdup.py is a small support script that I don't
> want a precompiled version of as it's not imported.
> 
> Hrm, something must go autocompiling *.py or something.
> 
> http://fedoraproject.org/wiki/Packaging/Python#Byte_Compiled_Files
> 
> Ah, so I need to explicitly %exclude them?
> 
Yep, either explicitly %exclude or name them without the *.py extension.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/9849338e/attachment.sig>

From gbuday at gmail.com  Mon Dec  1 16:29:57 2008
From: gbuday at gmail.com (Gergely Buday)
Date: Mon, 1 Dec 2008 17:29:57 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1228128134.3451.36.camel@beta>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com> <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
	<1228128134.3451.36.camel@beta>
Message-ID: <90d975d30812010829k65aabfft2ec6c85f417bcb96@mail.gmail.com>

Basil Mohamed Gohar

> If someone could setup a SIG for man page conversion or just leverage
> the documentation team and make a focus on teaching how to do man pages,
> I could see this bits of this task being chipped away significantly on
> the road to F11.  I know that I'm definitely leaning towards the idea of
> writing one or two man pages, because I've run into the missing-man-page
> problem too often.

I do not have the time this week being ill but am willing to do this.
Could anyone please point me to a corner of Fedora wiki that would be
suitable for such a page? OK I can create a page on my own with a name
of my like, but where to put links?

- Gergely



From mschwendt at gmail.com  Mon Dec  1 16:37:08 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 1 Dec 2008 17:37:08 +0100
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <49340973.4040204@redhat.com>
References: <20081114192450.18827.51863@faldor.intranet>
	<491DD575.1070200@redhat.com>
	<20081114213352.2f073127.mschwendt@gmail.com>
	<gfkq8p$bms$1@ger.gmane.org> <491DF130.7040403@redhat.com>
	<1226699696.11393.65.camel@luminos.localdomain>
	<49340973.4040204@redhat.com>
Message-ID: <20081201173708.c09281bf.mschwendt@gmail.com>

On Mon, 01 Dec 2008 10:57:39 -0500, David Huff wrote:

> Jesse Keating wrote:
> > Er, what exactly is the issue at hand?
> 
> I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch" to
> the spec file however it is still reporting broken dep of qemu for ppc64.
> 
> So either the rpm *is* being pulled in to the tree eventhough 
> ExclusiveArch is set,  or whatever is checking for broken deops is 
> reporting incorrectly.

Explain how you think the broken deps checker would be broken!
The package _is_ in the ppc64 tree, isn't it?

http://download.fedora.redhat.com/pub/fedora/linux/updates/10/ppc64/appliance-tools-003.9-1.fc10.noarch.rpm

Btw:

$ rpm -qp --qf '[%{exclusivearch} ]' appliance-tools-003.9-1.fc10.src.rpm 
i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 ppc alpha sparc armv4l

I leave the 2nd part of the exercise to you. Find out whether "mash" evaluates
%exclusivearch.

> 
> -D
> 
> I know this is an old thread however I just got two more notifications 
> for two new RPMs:
> 
> Michael Schwendt wrote:
>  > Your following packages in the repository suffer from broken 
> dependencies:
>  >
>  > package: appliance-tools-003.9-1.fc10.noarch from fedora-updates-10-ppc64
>  >   unresolved deps:
>  >      qemu-img
>  >
>  > Your following packages in the repository suffer from broken 
> dependencies:
>  >
>  > package: appliance-tools-002.8-1.fc9.noarch from 
> fedora-updates-testing-9-ppc64
>  >   unresolved deps:
>  >      qemu-img
> 
> 
> 


-- 
Michael Schwendt <mschwendt at fedoraproject.org>
Fedora release 10 (Cambridge) - Linux 2.6.27.5-117.fc10.i686
loadavg: 2.75 2.48 2.18



From lesmikesell at gmail.com  Mon Dec  1 16:44:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 01 Dec 2008 10:44:23 -0600
Subject: Server SIG - work areas
In-Reply-To: <46a038f90812010723x6bd9efb6q53a257862a5de762@mail.gmail.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<46a038f90812010723x6bd9efb6q53a257862a5de762@mail.gmail.com>
Message-ID: <49341467.4030103@gmail.com>

Martin Langhoff wrote:
> On Mon, Dec 1, 2008 at 12:02 PM, Dan Hor?k <dan at danny.cz> wrote:
>> opened our own mailing list - subscribe at
>> https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
> 
> Cool - signing up. Excellent high level list of topics - matches
> perfectly with my OLPC School Server needs.
> 
> I guess specific technical discussions do come back to
> fedora-devel-list@ still... we can't really do it without help --
> however indirect -- from the wider dev community.
> 
> (If we do take all "server" discussions there, we could succeed in
> removing them from here, effectively lowering awareness of the server
> needs. That would be... counterproductive...)

Yes, note that nothing server-centric is really opposed to being client 
or desktop oriented as any machine may need to provide a mix of services 
while running as a client itself.  Consider a single machine acting as a 
server for LTSP thin clients and/or multiuser freenx sessions as an 
example. It would likely provide dhcp/dns/http/ftp/samba/nfs/email and 
perhaps act as a nat internet gateway, but it still needs all desktop 
functionality for multiple users.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Mon Dec  1 16:55:01 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 01 Dec 2008 10:55:01 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <d551e0e20812010601k55f88b2fpb09b5ef9980401c@mail.gmail.com>
References: <492E05E7.2080708@cchtml.com>	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>	<493341BB.10706@cchtml.com>
	<5rjc06xma9.ln2@ppp1053.in.ipex.cz>	<4933ECF0.5000701@gmail.com>
	<d551e0e20812010601k55f88b2fpb09b5ef9980401c@mail.gmail.com>
Message-ID: <493416E5.5040003@gmail.com>

Camilo Mesias wrote:
> 2008/12/1 Les Mikesell <lesmikesell at gmail.com>:
>> Adding a few examples won't hurt, but man pages are not the place for
>> conceptual fluff.  We need some other format to hold an overview of why you
>> should use each program and how various program can be combined to
>> accomplish different results.  Man pages should just contain a reference for
>> that program's use, because you won't look there until you already know why
>> you want to run it.
> 
> Don't forget you can have manpages for conceptual fluff (try man
> selinux / which selinux), and you can find out what command you need
> to do using 'apropos'. Example: apropos security

But I would never have thought to use 'man' on a meta-package name, so 
that's only useful after some user training (or the tutorial where such 
information really belongs anyway).  And 'apropos security' should 
probably list every program with any security related aspect.  That is, 
if it worked like it should, there would be too many results to be useful.

> The man system really has been round the block a few times...

And it only really worked when it was accompanied by a separate tutorial 
and overview and the list of programs was small enough to browse with 
xman or search with 'man -k'.  The pages themselves are generally fine 
once you get to the point of wanting refernce details, but now that 
there are many thousands of choices you need to know where to start.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From katzj at redhat.com  Mon Dec  1 16:54:05 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 01 Dec 2008 11:54:05 -0500
Subject: Round 3 starting
In-Reply-To: <4933FE22.8050103@draigBrady.com>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228139787.3835.189.camel@ignacio.lan>
	<4933FE22.8050103@draigBrady.com>
Message-ID: <1228150445.26997.1.camel@aglarond.local>

On Mon, 2008-12-01 at 15:09 +0000, P?draig Brady wrote:
> Ignacio Vazquez-Abrams wrote:
> > This round is composed of packages that contain compiled Python code but
> > do not have a Requires of python(abi). Please note that this is a
> > packaging bug as the bytecode is specific to the version of the Python
> > it was compiled with. Whether this is a problem with rpm's macros or
> > with the package itself must be dealt with on a case-by-case basis.
> > 
> > fslint
> 
> /usr/share/fslint/fslint/supprt/rmlint/fixdup.py
> /usr/share/fslint/fslint/supprt/rmlint/fixdup.pyc
> /usr/share/fslint/fslint/supprt/rmlint/fixdup.pyo
> 
> fixdup.py is a small support script that I don't
> want a precompiled version of as it's not imported.

If it's just a small support script, then you're better off having it
named 'fixdup' as opposed to 'fixdup.py'.  It avoids things like this
and it also keeps you one step removed from implementation details.  

Jeremy



From abu_hurayrah at hidayahonline.org  Mon Dec  1 17:08:44 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Mon, 01 Dec 2008 19:08:44 +0200
Subject: Server SIG - work areas
In-Reply-To: <46a038f90812010723x6bd9efb6q53a257862a5de762@mail.gmail.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<46a038f90812010723x6bd9efb6q53a257862a5de762@mail.gmail.com>
Message-ID: <1228151324.3451.73.camel@beta>

On Mon, 2008-12-01 at 13:23 -0200, Martin Langhoff wrote:
> On Mon, Dec 1, 2008 at 12:02 PM, Dan Hor?k <dan at danny.cz> wrote:
> > opened our own mailing list - subscribe at
> > https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
> 
> Cool - signing up. Excellent high level list of topics - matches
> perfectly with my OLPC School Server needs.
> 
> I guess specific technical discussions do come back to
> fedora-devel-list@ still... we can't really do it without help --
> however indirect -- from the wider dev community.
> 
> (If we do take all "server" discussions there, we could succeed in
> removing them from here, effectively lowering awareness of the server
> needs. That would be... counterproductive...)
> 
> cheers,
> 
> 
> m
> -- 
>  martin.langhoff at gmail.com
>  martin at laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
> 
I think the whole point of having a list dedicated to the server
concepts is important precisely because of a separation between the dev
& lists and the new server one.  The traffic will be more focused, and
it *will* keep traffic off the dev list, something I see as an
advantage.

Then, where some insight from the dev folks is needed, we can do a cross
posting to both lists to get some thoughts on the matter flowing.

That's just my opinion, and I think the dev list is already quite full
as it is, having just joined myself a few days ago!



From lfarkas at lfarkas.org  Mon Dec  1 17:52:40 2008
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Mon, 01 Dec 2008 18:52:40 +0100
Subject: filesystem cleanup in /usr would be useful
Message-ID: <49342468.207@lfarkas.org>

hi,
after an upgrade to f10 i'd like to search for files which is on my
filesystem but now owned by any packages. i find this utility:
http://www.cpan.org/authors/id/J/JW/JWIED/rpmquery-19991213
and run by:
rpmquery --unknown --skipdir=/var --skipdir=/tmp --skipdir=/sys
--skipdir=/home
it's turn out there are hundreds of such files. what's more there are
many config, temporary or generated files under /usr eg:
/usr/share/mime/
/usr/share/texmf/web2c
/usr/share/icons
/usr/lib/openoffice.org/share/uno_packages/cache
some of the like the above remain there after the f9->f10 update but
some of them seems to be a wrong packaging and programing style (ie. put
cache and registry under /usr).
it's be useful to fix them in the packages and also in anaconda during
the update process.

ps. also would be useful to include such a small and even smarter script
in yum-utils or rpm.

-- 
  Levente                               "Si vis pacem para bellum!"



From tmz at pobox.com  Mon Dec  1 17:57:26 2008
From: tmz at pobox.com (Todd Zullinger)
Date: Mon, 1 Dec 2008 12:57:26 -0500
Subject: Heads-up: Enabling generation of pkg-config requires
In-Reply-To: <alpine.LFD.2.00.0811291856590.2808@turre.koti.laiskiainen.org>
References: <alpine.LFD.2.00.0811291856590.2808@turre.koti.laiskiainen.org>
Message-ID: <20081201175726.GB20204@inocybe.teonanacatl.org>

Panu Matilainen wrote:
> Just a heads-up, I'm (finally) enabling the generation of automatic
> pkg-config and libtool requires in rpm. Provides for these have been
> generated since first rpm 4.6.0 alpha hit rawhide, so with a bit of
> luck, all/most involved packages have been rebuilt since then and
> already have  the needed provides for satisfying the new requires.
>
> But if you see unsatisfied dependencies on pkgconfig(foo) and
> libtool(foo), request a rebuild of the dependant package, that's all
> it  should take. Except if you happen to hit a big chain of
> pkg-config using  packages that haven't been rebuilt in several
> months, or bugs in the  dependency generation, or buggy pkg-config
> .pc files...

A recent build of gtkpod failed to install libgpod-devel?, which
requires pkgconfig(gobject-2.0).  Shouldn't glib2-devel provide that?
It's certainly been rebuilt recently, yet the only pkgconfig provides
it has is pkgconfig(glib-2.0).  The latest glib2-devel package has a
number of .pc files though:

$ rpm -qpl glib2-devel-2.19.1-2.fc11.i386.rpm | grep '\.pc$'
/usr/lib/pkgconfig/gio-2.0.pc
/usr/lib/pkgconfig/gio-unix-2.0.pc
/usr/lib/pkgconfig/glib-2.0.pc
/usr/lib/pkgconfig/gmodule-2.0.pc
/usr/lib/pkgconfig/gmodule-export-2.0.pc
/usr/lib/pkgconfig/gmodule-no-export-2.0.pc
/usr/lib/pkgconfig/gobject-2.0.pc
/usr/lib/pkgconfig/gthread-2.0.pc

So, is this a bug in the libgpod packaging or in the rpm pkgconfig
provides stuff?

? http://koji.fedoraproject.org/koji/getfile?taskID=966791&name=root.log

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Abstainer, n.: A weak person who yields to the temptation of denying
himself a pleasure.
    -- Ambrose Bierce, "The Devil's Dictionary"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/9adce817/attachment.sig>

From jmoyer at redhat.com  Mon Dec  1 17:59:00 2008
From: jmoyer at redhat.com (Jeff Moyer)
Date: Mon, 01 Dec 2008 12:59:00 -0500
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <20081128131816.GA4434@srcf.ucam.org> (Matthew Garrett's message
	of "Fri, 28 Nov 2008 13:18:16 +0000")
References: <20081127153327.GA21300@srcf.ucam.org>
	<492EC3CC.9080105@redhat.com> <20081127164406.GB22963@srcf.ucam.org>
	<1227875633.3636.7.camel@macbook.infradead.org>
	<20081128131816.GA4434@srcf.ucam.org>
Message-ID: <x49fxl793q3.fsf@segfault.boston.devel.redhat.com>

Matthew Garrett <mjg at redhat.com> writes:

> On Fri, Nov 28, 2008 at 12:33:53PM +0000, David Woodhouse wrote:
>> On Thu, 2008-11-27 at 16:44 +0000, Matthew Garrett wrote:
>> > It would be nice to have the kernel export disk access via a socket or 
>> > something rather than the currently available debug option, which is to 
>> > dump to dmesg which then triggers log writes which triggers more 
>> > messages and fail occurs.
>> 
>> Does blktrace trigger log writes?
>
> I was thinking of the vm_dump interface - I'd never noticed blktrace, 
> which looks pretty much ideal. Now we just need a user-friendly 
> front-end.

Define user-friendly.  There is blkparse, which will format things for
you.

Cheers,
Jeff



From jmoyer at redhat.com  Mon Dec  1 18:03:53 2008
From: jmoyer at redhat.com (Jeff Moyer)
Date: Mon, 01 Dec 2008 13:03:53 -0500
Subject: autofs - patches in %doc?
In-Reply-To: <20081128112055.7692379c.mschwendt@gmail.com> (Michael Schwendt's
	message of "Fri, 28 Nov 2008 11:20:55 +0100")
References: <20081128112055.7692379c.mschwendt@gmail.com>
Message-ID: <x49bpvv93hy.fsf@segfault.boston.devel.redhat.com>

Michael Schwendt <mschwendt at gmail.com> writes:

> $ du -h /usr/share/doc/autofs-5.0.3/*.patch
> 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.10-v5-update.patch
> 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.11-v5-update.patch
> 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.12-v5-update.patch
> 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.13-v5-update.patch
> 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.14-v5-update.patch
> 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.15-v5-update.patch
> 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.16-v5-update.patch
> 28K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.17-v5-update.patch
> 28K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.18-v5-update.patch
> 20K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.19-v5-update.patch
> 16K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.20-v5-update.patch
> 8.0K    /usr/share/doc/autofs-5.0.3/autofs4-2.6.21-v5-update.patch
> 8.0K    /usr/share/doc/autofs-5.0.3/autofs4-2.6.22-v5-update.patch
> 4.0K    /usr/share/doc/autofs-5.0.3/autofs4-2.6.23-v5-update.patch
> 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.9-v5-update.patch
> 4.0K    /usr/share/doc/autofs-5.0.3/util-linux-2.12a-flock.patch
> 4.0K    /usr/share/doc/autofs-5.0.3/util-linux-2.12q-flock.patch
>
> [$ du -h autofs-5.0.4/patches
> 2.0M    autofs-5.0.4/patches
> ]
>
> So, we've got ~48K of %changelog details in the autofs.spec, but the
> question why the %doc line explicitly includes  patches/*  is not answered.
> That clutters up the docdir unnecessarily.
>
> Who can tell why this is done?

I presume Ian can.

Cheers,
Jeff



From gilboad at gmail.com  Mon Dec  1 18:25:28 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 01 Dec 2008 20:25:28 +0200
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <4933F7AD.1040904@gmail.com>
References: <4933F7AD.1040904@gmail.com>
Message-ID: <1228155928.2360.7.camel@gilboa-work-dev.localdomain>

On Mon, 2008-12-01 at 17:41 +0300, Lev Shamardin wrote:
> Hi all,
> 
> Today the file system on my wife's laptop got corrupted (that's another sad
> fedora, kerneloops and tuxonice story) and I decided to reinstall everything
> from scratch using Fedora 10 installation DVD. The laptop previously had Fedora
> 9 installed, so my plan was to reinstall the system and then restore the /home
> partition with fsck & co.
> 
> The installation process from the DVD went quite smoothly, but when I got to the
> first boot there were some surprises. Since I was going to recover /home later,
> I was not planning to create any users at the first boot, but skipping the
> "Create user" screen required to press the "Use network login..." button and
> cancel the dialog, otherwise the firstboot continued to complain that I
> definitely need to create a user.
> 
> This laptop uses wireless to connect to the internet, and guess what? Is is NOT
> yet configured when you are running the firstboot. On the Date & Time screen I
> selected "Enable network time protocol", pressed forward, and then hit Cancel on
> the "Contacting NTP..." dialog (I supposed that I don't want to wait for the
> network timeout) and... Firstboot crashed leaving me with an empty screen with a
> mouse cursor on it. Ctrl-Alt-F1/F2/etc. brought me to another empty screen,
> without a mouse this time. Fortunately Ctrl-Alt-Del from that mouseless screen
> worked fine.
> 
> Next boot showed firstboot again allowing to test these bugs and finally get
> through them to discover another surprise.
> 
> I've selected "Russian" keyboard during the installation process. Usually this
> assumed that there are two keyboard layouts (English and Russian) and you can
> switch between them with a hotkey. But not in the default state of the GDM after
> the first boot. The only option I had was Russian input! I tried all common
> layout switch shortcuts but have not managed to find one to switch the layout to
> english, but I had to type something in english since I have not created any
> users and my root user had both english login name and password. So I had to go
> to the menus, search for USA keyboard layout and only after this had a chance to
> try login to the system. It really seems to me that these layout defaults are
> insane. Is it that common to have non-english login names and passwords, really?
> 
> Anyway, I failed to login interactively to X as root ("Cannot authenticate
> user") and after that even selecting Keyboard: USA did not bring english input
> to the gdm! I tried to switch several times, nothing happened. Adding a second
> USA layout (USA international this time) partially solved the problem with
> switching input language, but I still was not able to login as root to a
> graphical terminal to recover the system. Of course some searching in google
> delivered the answer that I have to modify the gdm PAM settings, but that only
> brought me to a discovery that gdm forgets the input language and layout
> settings after asking for the user name! So the complete "root login" procedure
> looks like this:
> 1. Press "other user..." [Why should I do this if there are no users in the
> system except root?]
> 2. Switch layout to USA. [First switch is broken, so]
> 3. Switch layout to USA (intl). [Aha, english letters finally]
> 4. Enter user name
> 5. Switch layout to USA. [Don't forget: the first switch is broken]
> 6. Switch layout to USA (intl).
> 7. Enter the root password.
> 
> Phew, That was easy!
> 
> Never ever before a fresh Fedora installation was that hostile towards system
> recovery... Especially to a non-US user. That is sad.
> 
> With best regards,
> Lev.
> 

Lev,

I'd suggest you file a bug report against firstboot (Cannot skip user
creation, broken NTP due to broken NetworkManager auto-configuration)
and GDM (Invalid language selection, missing switch-to-US-English
option) and post the BZ# here.

I doubt that anyone here will disagree that these bugs should be fixed
in F11, so beyond venting, I doubt that a starting a discussion about
these bugs will produce anything useful.

- Gilboa



From pmatilai at laiskiainen.org  Mon Dec  1 19:02:57 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 1 Dec 2008 21:02:57 +0200 (EET)
Subject: Heads-up: Enabling generation of pkg-config requires
In-Reply-To: <20081201175726.GB20204@inocybe.teonanacatl.org>
References: <alpine.LFD.2.00.0811291856590.2808@turre.koti.laiskiainen.org>
	<20081201175726.GB20204@inocybe.teonanacatl.org>
Message-ID: <alpine.LFD.2.00.0812012102230.19910@turre.koti.laiskiainen.org>

On Mon, 1 Dec 2008, Todd Zullinger wrote:

> Panu Matilainen wrote:
>> Just a heads-up, I'm (finally) enabling the generation of automatic
>> pkg-config and libtool requires in rpm. Provides for these have been
>> generated since first rpm 4.6.0 alpha hit rawhide, so with a bit of
>> luck, all/most involved packages have been rebuilt since then and
>> already have  the needed provides for satisfying the new requires.
>>
>> But if you see unsatisfied dependencies on pkgconfig(foo) and
>> libtool(foo), request a rebuild of the dependant package, that's all
>> it  should take. Except if you happen to hit a big chain of
>> pkg-config using  packages that haven't been rebuilt in several
>> months, or bugs in the  dependency generation, or buggy pkg-config
>> .pc files...
>
> A recent build of gtkpod failed to install libgpod-devel?, which
> requires pkgconfig(gobject-2.0).  Shouldn't glib2-devel provide that?
> It's certainly been rebuilt recently, yet the only pkgconfig provides
> it has is pkgconfig(glib-2.0).  The latest glib2-devel package has a
> number of .pc files though:
>
> $ rpm -qpl glib2-devel-2.19.1-2.fc11.i386.rpm | grep '\.pc$'
> /usr/lib/pkgconfig/gio-2.0.pc
> /usr/lib/pkgconfig/gio-unix-2.0.pc
> /usr/lib/pkgconfig/glib-2.0.pc
> /usr/lib/pkgconfig/gmodule-2.0.pc
> /usr/lib/pkgconfig/gmodule-export-2.0.pc
> /usr/lib/pkgconfig/gmodule-no-export-2.0.pc
> /usr/lib/pkgconfig/gobject-2.0.pc
> /usr/lib/pkgconfig/gthread-2.0.pc
>
> So, is this a bug in the libgpod packaging or in the rpm pkgconfig
> provides stuff?

Bug in rpm pkgconfig generation, see 
https://bugzilla.redhat.com/show_bug.cgi?id=473814

 	- Panu -



From shamardin at gmail.com  Mon Dec  1 19:40:32 2008
From: shamardin at gmail.com (Lev Shamardin)
Date: Mon, 01 Dec 2008 22:40:32 +0300
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <1228155928.2360.7.camel@gilboa-work-dev.localdomain>
References: <4933F7AD.1040904@gmail.com>
	<1228155928.2360.7.camel@gilboa-work-dev.localdomain>
Message-ID: <49343DB0.3060907@gmail.com>

On 12/01/2008 09:25 PM, Gilboa Davara wrote:
> I'd suggest you file a bug report against firstboot (Cannot skip user
> creation, broken NTP due to broken NetworkManager auto-configuration)
> and GDM (Invalid language selection, missing switch-to-US-English
> option) and post the BZ# here.

Done.

User creation: https://bugzilla.redhat.com/show_bug.cgi?id=474007
NTP firstboot crash: https://bugzilla.redhat.com/show_bug.cgi?id=474009
Invalid gdm input language by default:
https://bugzilla.redhat.com/show_bug.cgi?id=474010
Broken keyboard switching in GDM: https://bugzilla.redhat.com/show_bug.cgi?id=474011
GDM changes layout after the username prompt before entering password
https://bugzilla.redhat.com/show_bug.cgi?id=474014

> I doubt that anyone here will disagree that these bugs should be fixed
> in F11, so beyond venting, I doubt that a starting a discussion about
> these bugs will produce anything useful.

Some time ago there was a proposed feature - Stabilization which haven't got
enough attention. For me or any other cyrillic user (and perhaps not only
cyrillic but any language that does not use latin characters for scripting) all
these bugs are a great regression since last 4-5 fedora releases.

I think that first, developers could draw more attention to multilingual
changes, especially when they are changing long established defaults, they could
also consider if the new change makes any sense at all (as with non-english
login names). And second, this stuff new stuff should not be changed without
sufficient feedback from users/testers.

If you are lacking testers for a significant change, may be you could just
announce that "hey, this feature could possibly break the things, since it
changes the habitual defaults, please test it or be warned". This could bring
more testers, especially those interested in features to be broken.

To summarize: almost all the stuff above was not broken in previous fedora
releases. It was not tested enough but it was released. And it can surely spoil
the first fedora experience for the newcomers which is definitely not a benefit
for fedora.

--
Lev.



From ivazqueznet at gmail.com  Mon Dec  1 19:49:02 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 14:49:02 -0500
Subject: Third Report (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <1227923821.3835.39.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
Message-ID: <1228160942.29612.12.camel@ignacio.lan>

Requested to be skipped:
pbrady fslint

Modified by maintainer:
awjb koffice
jcollie pitivi
mdehaan cobbler

Permissions:
than kdelibs

libtool:
(none)

pkgconfig:
cagney frysk
deji tracker
drago01 beagle
drago01 pinot
luya gdesklets
nphilipp gimp
rakesh gedit-plugins
steve tuxpaint
tmz gtkpod

SRPM build failures:
dwalsh selinux-policy

Dep problems:
caillon epiphany-extensions
mbarnes devhelp

Python version expectations:
(none)

Never completed:
(none)

Runtime issues:
(none)

Code or packaging issues:
lucilanga xastir
ondrejj sagator
svahl konq-plugins

Blocked by other packages:
awjb libopensync-plugin-moto libopensync
bkearney sugar-moon gnome-python2-desktop/xapian-bindings
bkearney sugar-turtleart gnome-python2-desktop/xapian-bindings
deji tracker gnome-python2-desktop
drago01 beagle xulrunner
dsugar eclipse-slide xulrunner
erikos sugar-browse gnome-python2-desktop/xapian-bindings
erikos sugar-log gnome-python2-desktop/xapian-bindings
fab sugar-analyze gnome-python2-desktop/xapian-bindings
fab sugar-memorize gnome-python2-desktop/xapian-bindings
katzj sugar-calculator gnome-python2-desktop/xapian-bindings
katzj sugar-chat gnome-python2-desktop/xapian-bindings
katzj sugar-terminal gnome-python2-desktop/xapian-bindings
katzj sugar-write gnome-python2-desktop/xapian-bindings
mnowak eclipse-pydev xulrunner
mpg sugar-journal gnome-python2-desktop/xapian-bindings
nphilipp system-config-date gnome-python2-extras
overholt eclipse xulrunner
pknirsch system-config-httpd alchemist
rakesh gedit-plugins gedit
sdz sugar-jukebox gnome-python2-desktop/xapian-bindings
spot R-nws avahi
than kdesdk kdebase-workspace

Raw data follows:
awjb koffice /
awjb libopensync-plugin-moto libopensync
bkearney sugar-moon gnome-python2-desktop/xapian-bindings
bkearney sugar-turtleart gnome-python2-desktop/xapian-bindings
cagney frysk K
caillon epiphany-extensions D
deji tracker K/gnome-python2-desktop
drago01 beagle K/xulrunner
drago01 pinot K
dsugar eclipse-slide xulrunner
dwalsh selinux-policy S
erikos sugar-browse gnome-python2-desktop/xapian-bindings
erikos sugar-log gnome-python2-desktop/xapian-bindings
fab sugar-analyze gnome-python2-desktop/xapian-bindings
fab sugar-memorize gnome-python2-desktop/xapian-bindings
jcollie pitivi /
katzj sugar-calculator gnome-python2-desktop/xapian-bindings
katzj sugar-chat gnome-python2-desktop/xapian-bindings
katzj sugar-terminal gnome-python2-desktop/xapian-bindings
katzj sugar-write gnome-python2-desktop/xapian-bindings
lucilanga xastir C
luya gdesklets K
mbarnes devhelp D
mdehaan cobbler /
mnowak eclipse-pydev xulrunner
mpg sugar-journal gnome-python2-desktop/xapian-bindings
nphilipp gimp K
nphilipp system-config-date gnome-python2-extras
ondrejj sagator C
overholt eclipse xulrunner
pbrady fslint =
pknirsch system-config-httpd alchemist
rakesh gedit-plugins K/gedit
sdz sugar-jukebox gnome-python2-desktop/xapian-bindings
spot R-nws avahi
steve tuxpaint K
svahl konq-plugins C
than kdelibs P
than kdesdk kdebase-workspace
tmz gtkpod K

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/887006ac/attachment.sig>

From mschwendt at gmail.com  Mon Dec  1 20:11:22 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 1 Dec 2008 21:11:22 +0100
Subject: FHS violations
Message-ID: <20081201211122.994a7940.mschwendt@gmail.com>

https://fedoraproject.org/wiki/Packaging/Guidelines#Filesystem_Layout

| Fedora follows the Filesystem Hierarchy Standard with regards to
| filesystem layout. The FHS defines where files should be placed on the
| system. Fedora packages should follow the FHS whenever possible. Any
| deviation from the FHS should be rationalized when the package is
| reviewed.
|
| There is one notable exception, libexecdir. 

Contrary to that, package "spu-binutils" creates directories

  /spu
  /usr/spu

which is a violation of the FHS. And I've been told there are more
packages that do something similar.

I'd like to propose that above guideline is updated with a "MUST"
clause: The rationale for deviating from the FHS must be given in
a comment in the package .spec file.

Why is it not feasible to create an own tree like

  %{_libdir}/spu/
  %{_libdir}/spu/bin/
  ...
?



From opensource at till.name  Mon Dec  1 20:11:31 2008
From: opensource at till.name (Till Maas)
Date: Mon, 01 Dec 2008 21:11:31 +0100
Subject: cmake preserving timestamps?
Message-ID: <200812012111.42307.opensource@till.name>

Hiyas,

I wonder whether cmake also preserves the timestamp of installed files, 
because it seems to be not that easy to check this during review. There is no 
actual command displayed that does the installation and the cmake guidelines 
do not say anything about this. But since there is already a %cmake macro, I 
guess/hope that it does the right thing about this.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/90b077e9/attachment.sig>

From forum at ru.bir.ru  Mon Dec  1 20:18:50 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 01 Dec 2008 23:18:50 +0300
Subject: How to pack cron jobs?
In-Reply-To: <20081201083229.GA2735@free.fr>
References: <ggs9m8$rsg$1@ger.gmane.org>	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>	<ggsd7q$5tn$1@ger.gmane.org>
	<20081130142237.GA16722@free.fr>	<ggujhc$68k$1@ger.gmane.org>
	<20081130210724.GA2649@free.fr>	<ggv8d5$539$1@ger.gmane.org>
	<20081201083229.GA2735@free.fr>
Message-ID: <gh1grb$v31$1@ger.gmane.org>

Patrice Dumas ?????:
> On Mon, Dec 01, 2008 at 02:42:25AM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>> Patrice Dumas ?????:
>>> On Sun, Nov 30, 2008 at 08:46:20PM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>>>> Great news. In this case really may be best solution add /etc/cron.d  
>>>> into crontab package?
>>> I don't think so, at least if  cronie directly uses files in /etc/cron.d.
>>>
>>> --
>>> Pat
>>>
>> AFIAK cronie do not use files from it, cronie only provide service to  
>> handle jobs from this directory. And fcron will do the same.
> 
> It is advertized in the crond man page, so I think it is directly done
> by cronie, (and I don't know where it would be configured otherwise).
I can't find any mention of cron.d in man of crond.
$ rpm -q cronie
cronie-1.0-7.fc9.i386

Furthermore, as mentioned above, fcron will does the same in short time.
> 
>> I thing in any way "Require crontabs" must be in both crons.
> 
> Not in the main package.
Not in main package? Is there any subpackage of crontab in Fedora??
$ repoquery 'crontab*'
crontabs-0:1.10-19.fc9.noarch

Or you suppose create new one?
> User may want another crontab than the fedora
> one.
Off course. What to obstruct the create another one to replace fedora 
variant? Do not see any problem there.

>> Furthermore if /etc/cron.d will be included into both crons, do not make  
>> this conflicts (if both must be installed on the same machine off 
>> course)??
> 
> Dir ownership doesn't lead to conflict, on the contrary, it is a rather
> natural way to present virtual provides (as long as it is in /etc).
> 
> --
> Pat
> 



From jkeating at redhat.com  Mon Dec  1 20:23:10 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 01 Dec 2008 12:23:10 -0800
Subject: New users confused about Spins' Names
In-Reply-To: <4933EE29.5030603@redhat.com>
References: <492D38D3.1050303@students.iiit.ac.in>
	<1227717355.5276.51.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811261145180.12357@localhost.localdomain>
	<1227718827.5276.56.camel@luminos.localdomain>
	<4933EE29.5030603@redhat.com>
Message-ID: <1228162990.3608.2.camel@localhost.localdomain>

On Mon, 2008-12-01 at 09:01 -0500, Bryan Kearney wrote:
> Is the goal to add a better description on the torrents page, or have 
> the get.fedoraproject.org "See all custom Spins" redirect to some place 
> else? I would assume the latter.

I would assume the latter as well, a list of each spin and a link to a
site for that spin.  I think that's the concept that Mo worked up at
last FUDCon.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/63ce6893/attachment.sig>

From jkeating at redhat.com  Mon Dec  1 20:38:05 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 01 Dec 2008 12:38:05 -0800
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <20081201173708.c09281bf.mschwendt@gmail.com>
References: <20081114192450.18827.51863@faldor.intranet>
	<491DD575.1070200@redhat.com>
	<20081114213352.2f073127.mschwendt@gmail.com>
	<gfkq8p$bms$1@ger.gmane.org> <491DF130.7040403@redhat.com>
	<1226699696.11393.65.camel@luminos.localdomain>
	<49340973.4040204@redhat.com>
	<20081201173708.c09281bf.mschwendt@gmail.com>
Message-ID: <1228163885.3608.4.camel@localhost.localdomain>

On Mon, 2008-12-01 at 17:37 +0100, Michael Schwendt wrote:
> Explain how you think the broken deps checker would be broken!
> The package _is_ in the ppc64 tree, isn't it?
> 
> http://download.fedora.redhat.com/pub/fedora/linux/updates/10/ppc64/appliance-tools-003.9-1.fc10.noarch.rpm
> 
> Btw:
> 
> $ rpm -qp --qf '[%{exclusivearch} ]'
> appliance-tools-003.9-1.fc10.src.rpm 
> i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 ppc alpha
> sparc armv4l

Looking at the spec itself, I see:

ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch

I think that 'noarch' is throwing mash off when it's trying to determine
if a noarch package is suitable for an arch.  Please remove that and try
again (trying it in rawhide should be suitable to test mash before
pushing an update).

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/c21b95bc/attachment.sig>

From tibbs at math.uh.edu  Mon Dec  1 20:50:56 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 01 Dec 2008 14:50:56 -0600
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <20081201101456.GA18568@thinkpad>
References: <1228091890.19905.5.camel@localhost.localdomain>
	<200811301640.37888.konrad@tylerc.org>
	<20081201101456.GA18568@thinkpad>
Message-ID: <ufa1vwrwrf3.fsf@epithumia.math.uh.edu>

>>>>> "RWMJ" == Richard W M Jones <rjones at redhat.com> writes:

RWMJ> On Sun, Nov 30, 2008 at 04:40:37PM -0800, Conrad Meyer wrote:
>> Any count of the number of outstanding reviews?

RWMJ> This page shows all bugs in the 'Package Review' component (8104
RWMJ> in total),

Why not just look at http://fedoraproject.org/PackageReviewStatus/ ?

 - J<



From ville.skytta at iki.fi  Mon Dec  1 20:53:26 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 1 Dec 2008 22:53:26 +0200
Subject: FHS violations
In-Reply-To: <20081201211122.994a7940.mschwendt@gmail.com>
References: <20081201211122.994a7940.mschwendt@gmail.com>
Message-ID: <200812012253.27413.ville.skytta@iki.fi>

On Monday 01 December 2008, Michael Schwendt wrote:

> I'd like to propose that above guideline is updated with a "MUST"
> clause: The rationale for deviating from the FHS must be given in
> a comment in the package .spec file.

+1



From tibbs at math.uh.edu  Mon Dec  1 20:53:26 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 01 Dec 2008 14:53:26 -0600
Subject: Suggestions to get sponsored
In-Reply-To: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>
References: <BAY123-W20C998834E09A91CEE133683010@phx.gbl>
Message-ID: <ufawsejvcqh.fsf@epithumia.math.uh.edu>

>>>>> "CG" == Curtis George <rhlinux123 at hotmail.com> writes:

CG> I would like some suggestions for a package to submit in order to
CG> get sponsored.

Why do you need to be sponsored if you don't already have a package
you want to maintain?

 - J<



From opensource at till.name  Mon Dec  1 20:22:47 2008
From: opensource at till.name (Till Maas)
Date: Mon, 01 Dec 2008 21:22:47 +0100
Subject: Displaying %doc and language specific files of an rpm
Message-ID: <200812012123.02056.opensource@till.name>

Hiyas,

I would like to get the output of "rpm -qpl foo.rpm" with an additional 
marker, when a file is marked as %doc or specific for a specific language. 
For the docfiles, there is at least a not so easily readable way to get this 
information (rpm --dump), but I cannot find a way to get this for the 
language specific files.

It would be nice to get the output formated like this:

/sbin/foo
D /usr/share/man/man8/foo.8.gz
D de /usr/share/man/de/man8/foo.8.gz

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/fae74c82/attachment.sig>

From kevin.kofler at chello.at  Mon Dec  1 20:58:29 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 01 Dec 2008 21:58:29 +0100
Subject: FHS violations
References: <20081201211122.994a7940.mschwendt@gmail.com>
Message-ID: <gh1j5m$b66$1@ger.gmane.org>

Michael Schwendt wrote:
> Contrary to that, package "spu-binutils" creates directories
> 
>   /spu
>   /usr/spu
> 
> which is a violation of the FHS. And I've been told there are more
> packages that do something similar.

It's a cross-toolchain. Using a directory like this is the established
practice for GNU cross-toolchains (and also used by some other
cross-toolchains) and the consensus among Fedora packagers working on
cross-compilation is that this is the way to go. Unfortunately, the
guideline which was supposed to formally codify it never made it to an FPC
vote because of process issues.

        Kevin Kofler



From a.badger at gmail.com  Mon Dec  1 20:59:58 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 01 Dec 2008 12:59:58 -0800
Subject: First Report
In-Reply-To: <1228057466.3835.105.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan>
Message-ID: <4934504E.4050501@gmail.com>

Ignacio Vazquez-Abrams wrote:
> python-configobj
Fixed and built to dist-f11-python

> python-cherrypy

Fixed and built to dist-f11-python.  Updated from 3.0 to 3.1.1.

> python-cherrypy2

Fixed and built to dist-f11-python

> python-sqlalchemy

Updated to 0.5.0rc4 which is supposed to fix this but doesn't.  Looking
into that now.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/68cf05d8/attachment.sig>

From mike at miketc.net  Mon Dec  1 21:03:01 2008
From: mike at miketc.net (Mike Chambers)
Date: Mon, 01 Dec 2008 15:03:01 -0600
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <49343DB0.3060907@gmail.com>
References: <4933F7AD.1040904@gmail.com>
	<1228155928.2360.7.camel@gilboa-work-dev.localdomain>
	<49343DB0.3060907@gmail.com>
Message-ID: <1228165381.23367.3.camel@scrappy.miketc.net>

On Mon, 2008-12-01 at 22:40 +0300, Lev Shamardin wrote:

> User creation: https://bugzilla.redhat.com/show_bug.cgi?id=474007

Not sure I understand this one.  You may be restoring your /home dir,
but you still need that user created anyway, so if at least
group/passwd/gdm/etc.. are all set?  The home dir will just get written
over during restore, so that makes no difference?

> NTP firstboot crash: https://bugzilla.redhat.com/show_bug.cgi?id=474009

This one I get.  I am not sure why maybe NM isn't brought up during
this, and first might I add, then anything network related would  be
brought up?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From limb at jcomserv.net  Mon Dec  1 21:03:05 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 1 Dec 2008 15:03:05 -0600 (CST)
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <ufa1vwrwrf3.fsf@epithumia.math.uh.edu>
References: <1228091890.19905.5.camel@localhost.localdomain>
	<200811301640.37888.konrad@tylerc.org>
	<20081201101456.GA18568@thinkpad>
	<ufa1vwrwrf3.fsf@epithumia.math.uh.edu>
Message-ID: <360f42acea018573951d974f75130677.squirrel@mail.jcomserv.net>


>>>>>> "RWMJ" == Richard W M Jones <rjones at redhat.com> writes:
>
> RWMJ> On Sun, Nov 30, 2008 at 04:40:37PM -0800, Conrad Meyer wrote:
>>> Any count of the number of outstanding reviews?
>
> RWMJ> This page shows all bugs in the 'Package Review' component (8104
> RWMJ> in total),
>
> Why not just look at http://fedoraproject.org/PackageReviewStatus/ ?

Contents:

Index of /PackageReviewStatus

      Name                    Last modified      Size  Description     
Parent Directory                             -
      ACCEPT.html             01-Dec-2008 21:01  2.3M
      NEW.html                01-Dec-2008 21:01  361K
      REJECT.html             01-Dec-2008 21:01   45K
      REVIEW.html             01-Dec-2008 21:01  132K

Apache/2.2.3 (Red Hat) Server at app1.fedora.phx.redhat.com Port 80

>  - J<
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From jkeating at redhat.com  Mon Dec  1 21:09:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 01 Dec 2008 13:09:17 -0800
Subject: Displaying %doc and language specific files of an rpm
In-Reply-To: <200812012123.02056.opensource@till.name>
References: <200812012123.02056.opensource@till.name>
Message-ID: <1228165757.3608.7.camel@localhost.localdomain>

On Mon, 2008-12-01 at 21:22 +0100, Till Maas wrote:
> 
> It would be nice to get the output formated like this:
> 
> /sbin/foo
> D /usr/share/man/man8/foo.8.gz
> D de /usr/share/man/de/man8/foo.8.gz

This would be in addition to the existing rpm -qd ? (query for
documentation files)

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/af7a0cd0/attachment.sig>

From ville.skytta at iki.fi  Mon Dec  1 21:14:09 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 1 Dec 2008 23:14:09 +0200
Subject: cmake preserving timestamps?
In-Reply-To: <200812012111.42307.opensource@till.name>
References: <200812012111.42307.opensource@till.name>
Message-ID: <200812012314.10709.ville.skytta@iki.fi>

On Monday 01 December 2008, Till Maas wrote:

> There is
> no actual command displayed that does the installation and the cmake
> guidelines do not say anything about this.

Perhaps passing -DCMAKE_VERBOSE_MAKEFILE=ON to %cmake will help with that?

See also https://bugzilla.redhat.com/474053



From llange at redhat.com  Mon Dec  1 21:14:54 2008
From: llange at redhat.com (Lutz Lange)
Date: Mon, 01 Dec 2008 22:14:54 +0100
Subject: Anyone else tried fedora-ds on F10?
Message-ID: <493453CE.5070101@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

just a quick question, has anyone else tried to run fedora-ds on f10?
I had some problems and could not get the admin server running.

See also https://bugzilla.redhat.com/show_bug.cgi?id=474033

Cheers and tx
Lutz

- --
Lutz Lange
GLS Instructor
Red Hat GmbH
Hauptst?tterstrasse 58
D-70178 Stuttgart - Germany

Tel.    +49 711 96 437 570
Mobile  +49 172 75 285 17
Fax     +49 711 96 437 111
Email:  llange at redhat.com
____________________________________________________________________
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFJNFPK15TuH1mPaRURAh65AJwPSnFZRcD0U6UfqzuO3fVB6g4w9gCgpDjt
zgzCedfL8Z02kJ5qQ4/PVhU=
=bqkY
-----END PGP SIGNATURE-----



From pmatilai at laiskiainen.org  Mon Dec  1 21:14:28 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 1 Dec 2008 23:14:28 +0200 (EET)
Subject: Displaying %doc and language specific files of an rpm
In-Reply-To: <200812012123.02056.opensource@till.name>
References: <200812012123.02056.opensource@till.name>
Message-ID: <alpine.LFD.2.00.0812012306570.19910@turre.koti.laiskiainen.org>

On Mon, 1 Dec 2008, Till Maas wrote:
> Hiyas,
>
> I would like to get the output of "rpm -qpl foo.rpm" with an additional
> marker, when a file is marked as %doc or specific for a specific language.
> For the docfiles, there is at least a not so easily readable way to get this
> information (rpm --dump), but I cannot find a way to get this for the
> language specific files.
>
> It would be nice to get the output formated like this:
>
> /sbin/foo
> D /usr/share/man/man8/foo.8.gz
> D de /usr/share/man/de/man8/foo.8.gz

Docs, config files, ghosts and the like can be viewed with this ('d' is 
for doc):
rpm -qp --qf "[%{fileflags:fflags} %{filenames}\n]" <pkg>

For languages there are no special formatters but this will give you the 
languages associated (if any) to each file:
--qf "[%{filelangs} %{filenames}\n]"

 	- Panu -



From opensource at till.name  Mon Dec  1 21:19:38 2008
From: opensource at till.name (Till Maas)
Date: Mon, 01 Dec 2008 22:19:38 +0100
Subject: Displaying %doc and language specific files of an rpm
In-Reply-To: <1228165757.3608.7.camel@localhost.localdomain>
References: <200812012123.02056.opensource@till.name>
	<1228165757.3608.7.camel@localhost.localdomain>
Message-ID: <200812012219.51772.opensource@till.name>

On Mon December 1 2008, Jesse Keating wrote:
> On Mon, 2008-12-01 at 21:22 +0100, Till Maas wrote:
> > It would be nice to get the output formated like this:
> >
> > /sbin/foo
> > D /usr/share/man/man8/foo.8.gz
> > D de /usr/share/man/de/man8/foo.8.gz
>
> This would be in addition to the existing rpm -qd ? (query for
> documentation files)

Yes, the rpm -qd does only show the documentation files and seems not to show, 
whether the files are specific for a certain language. E.g. it does not allow 
easily to spot files that should probably marked as %doc, but are not in 
package reviews. Btw. it also seems that directories that only 
contain %doc-files are not marked as %doc, e.g. /usr/share/doc/foo-1.23, is 
this intended?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/e6e5e4cf/attachment.sig>

From tibbs at math.uh.edu  Mon Dec  1 21:22:12 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 01 Dec 2008 15:22:12 -0600
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <360f42acea018573951d974f75130677.squirrel@mail.jcomserv.net>
References: <1228091890.19905.5.camel@localhost.localdomain>
	<200811301640.37888.konrad@tylerc.org>
	<20081201101456.GA18568@thinkpad>
	<ufa1vwrwrf3.fsf@epithumia.math.uh.edu>
	<360f42acea018573951d974f75130677.squirrel@mail.jcomserv.net>
Message-ID: <ufaskp7vbej.fsf@epithumia.math.uh.edu>

>>>>> "JC" == Jon Ciesla <limb at jcomserv.net> writes:

JC> Contents:

Yes, precisely.  Is there some problem with that?

 - J<



From opensource at till.name  Mon Dec  1 21:30:33 2008
From: opensource at till.name (Till Maas)
Date: Mon, 01 Dec 2008 22:30:33 +0100
Subject: cmake preserving timestamps?
In-Reply-To: <200812012314.10709.ville.skytta@iki.fi>
References: <200812012111.42307.opensource@till.name>
	<200812012314.10709.ville.skytta@iki.fi>
Message-ID: <200812012230.38148.opensource@till.name>

On Mon December 1 2008, Ville Skytt? wrote:

> Perhaps passing -DCMAKE_VERBOSE_MAKEFILE=ON to %cmake will help with that?
>
> See also https://bugzilla.redhat.com/474053

I tried to use "make install VERBOSE=1", but I belive that I did not find any 
useful information about whether or not timestamps were preserved. But I will 
test this.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/bb9bd684/attachment.sig>

From opensource at till.name  Mon Dec  1 21:33:32 2008
From: opensource at till.name (Till Maas)
Date: Mon, 01 Dec 2008 22:33:32 +0100
Subject: Displaying %doc and language specific files of an rpm
In-Reply-To: <alpine.LFD.2.00.0812012306570.19910@turre.koti.laiskiainen.org>
References: <200812012123.02056.opensource@till.name>
	<alpine.LFD.2.00.0812012306570.19910@turre.koti.laiskiainen.org>
Message-ID: <200812012233.33722.opensource@till.name>

On Mon December 1 2008, Panu Matilainen wrote:

> Docs, config files, ghosts and the like can be viewed with this ('d' is
> for doc):
> rpm -qp --qf "[%{fileflags:fflags} %{filenames}\n]" <pkg>
>
> For languages there are no special formatters but this will give you the
> languages associated (if any) to each file:
> --qf "[%{filelangs} %{filenames}\n]"

Thank you very much, this is so great! :-D

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/7a37b58b/attachment.sig>

From jfm512 at free.fr  Mon Dec  1 21:36:41 2008
From: jfm512 at free.fr (Jean Francois Martinez)
Date: Mon, 01 Dec 2008 22:36:41 +0100
Subject: Status of driver ov511 based cameras
In-Reply-To: <4931577B.6060607@hhs.nl>
References: <1227901448.3603.17.camel@agnes.fremen.dune>
	<4931577B.6060607@hhs.nl>
Message-ID: <1228167401.3953.6.camel@agnes.fremen.dune>

On Sat, 2008-11-29 at 15:53 +0100, Hans de Goede wrote:
> 
> Jean Francois Martinez wrote:
> > There are two drivers for those cameras:
> > 
> > -the 1.x driver who is in the kernel and is basically useless since the
> > only OV511 cameras who are not by today standards as obsolete as a 20
> > Mhz 386 don't work with it.
> > 
> > -the 2.x driver at alpha.dyndns.com/ov511.  This is the only one who
> > works with
> > the late models who used this chip (and the ones who are still useful).
> > Probelm is that the author has not updated its site in two years and
> > that it no longer compiles with present day kernel.  I fixed it for
> > 2.6.16 kernels and sent the patches to the author but got no answer.
> > And kernel 2.6.24 (I think) broke it again (or more exactly made it
> > no longer compile).
> > 
> > Question if I fix it again what are the chances it ends in Fedora?   How
> > are orphaned drivers handled in the kernel?  Someone, who doesn't seem
> > to be the original author, has been ensuring the 1.x continues compiling
> > in 2.6.27 despite the changes in interface.
> > 
> > JF Martinez
> > 
> > 
> 
> Hi JF,
> 
> Most webcam based driver development now a days happens within / on top of the 
> gspcav2 framework, which has been merged into the 2.6.27 kernel. gspcav2 
> already supports ov519 based cams, adding support to the existing driver for 
> ov518 based cams should be easy, as those are mostly the same. The big 
> difference is that ov518 based cams use a slightly non standard form of JPEG 
> compression one of the first things that need doing is adding support for this 
> compression to libv4l.
> 
> Would you be interested in working on this? Here are some references explaining 
> how to get the latest gspca driver, and about the why, how and what of libv4l
> http://hansdegoede.livejournal.com/6630.html
> http://hansdegoede.livejournal.com/6317.html
> http://hansdegoede.livejournal.com/3636.html
> 

Yes but I am no C programmer.  In case you thought that because I fixed
the OV511 I was one  the fixng I did was cosmetic (changing includes,
things who had been renamed).  

However I will se what I can do and to begin with I can test.


> You can get the latest libv4l here:
> http://people.atrpms.net/~hdegoede/libv4l-0.5.6.tar.gz
> 
> Regards,
> 
> Hans
> 



From dhuff at redhat.com  Mon Dec  1 21:39:21 2008
From: dhuff at redhat.com (David Huff)
Date: Mon, 01 Dec 2008 16:39:21 -0500
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <1228163885.3608.4.camel@localhost.localdomain>
References: <20081114192450.18827.51863@faldor.intranet>	<491DD575.1070200@redhat.com>	<20081114213352.2f073127.mschwendt@gmail.com>	<gfkq8p$bms$1@ger.gmane.org>
	<491DF130.7040403@redhat.com>	<1226699696.11393.65.camel@luminos.localdomain>	<49340973.4040204@redhat.com>	<20081201173708.c09281bf.mschwendt@gmail.com>
	<1228163885.3608.4.camel@localhost.localdomain>
Message-ID: <49345989.5040704@redhat.com>

Jesse Keating wrote:
> On Mon, 2008-12-01 at 17:37 +0100, Michael Schwendt wrote:
>> Explain how you think the broken deps checker would be broken!
>> The package _is_ in the ppc64 tree, isn't it?
>>
>> http://download.fedora.redhat.com/pub/fedora/linux/updates/10/ppc64/appliance-tools-003.9-1.fc10.noarch.rpm
>>
>> Btw:
>>
>> $ rpm -qp --qf '[%{exclusivearch} ]'
>> appliance-tools-003.9-1.fc10.src.rpm 
>> i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 ppc alpha
>> sparc armv4l
> 
> Looking at the spec itself, I see:
> 
> ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch
> 
> I think that 'noarch' is throwing mash off when it's trying to determine
> if a noarch package is suitable for an arch.  Please remove that and try
> again (trying it in rawhide should be suitable to test mash before
> pushing an update).
> 
> 

If I take out noarch in the ExclusiveArch list the build will fail:
"error: Architecture is not included: noarch"

more info:
https://koji.fedoraproject.org/koji/taskinfo?taskID=968280

-D



From pmatilai at laiskiainen.org  Mon Dec  1 21:42:27 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 1 Dec 2008 23:42:27 +0200 (EET)
Subject: Displaying %doc and language specific files of an rpm
In-Reply-To: <200812012219.51772.opensource@till.name>
References: <200812012123.02056.opensource@till.name>
	<1228165757.3608.7.camel@localhost.localdomain>
	<200812012219.51772.opensource@till.name>
Message-ID: <alpine.LFD.2.00.0812012341360.19910@turre.koti.laiskiainen.org>

On Mon, 1 Dec 2008, Till Maas wrote:

> On Mon December 1 2008, Jesse Keating wrote:
>> On Mon, 2008-12-01 at 21:22 +0100, Till Maas wrote:
>>> It would be nice to get the output formated like this:
>>>
>>> /sbin/foo
>>> D /usr/share/man/man8/foo.8.gz
>>> D de /usr/share/man/de/man8/foo.8.gz
>>
>> This would be in addition to the existing rpm -qd ? (query for
>> documentation files)
>
> Yes, the rpm -qd does only show the documentation files and seems not to show,
> whether the files are specific for a certain language. E.g. it does not allow
> easily to spot files that should probably marked as %doc, but are not in
> package reviews. Btw. it also seems that directories that only
> contain %doc-files are not marked as %doc, e.g. /usr/share/doc/foo-1.23, is
> this intended?

Yes, the directories are not documentation, the contents are :)

 	- Panu -



From kevin.kofler at chello.at  Mon Dec  1 21:42:16 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 01 Dec 2008 22:42:16 +0100
Subject: rawhide report: 20081201 changes
References: <20081201131206.AC5501F8252@releng2.fedora.phx.redhat.com>
	<650764.58253.qm@web52609.mail.re2.yahoo.com>
Message-ID: <gh1lnp$lf0$1@ger.gmane.org>

Antonio Olivares wrote:
>   file /usr/share/config/plasmoids.knsrc from install of
>   kdelibs-6:4.1.80-5.fc11.i386 conflicts with file from package
>   kdebase-workspace-4.1.2-14.fc10.i386 file
(and more like this)

These are conflicts between an old kdebase-workspace and a new kdelibs. The
kdebase-workspace-4.1.80 build now in Rawhide should fix this. (But now the
problem is that stuff still depends on the libplasma in the old
kdebase-workspace instead of the one in the new kdelibs, we're working on
fixing the broken dependencies, but this takes time! Rawhide is currently
unfit for use for KDE users.)

>   /usr/share/icons/oxygen/16x16/actions/transform-crop-and-resize.png from
>   install of oxygen-icon-theme-4.1.80-4.fc11.noarch conflicts with file
>   from package digikam-0.10.0-0.6.beta5.fc10.i386 file
(and more like this)

Some icons Digikam shipped were merged into upstream Oxygen. We should
remove the icons from Digikam in Rawhide.

>   /usr/lib/libkwalletbackend.so from install of
>   kdebase-runtime-4.1.80-4.fc11.i386 conflicts with file from package
>   kdelibs3-devel-3.5.10-1.fc10.i386 file

This one needs to use the /usr/lib/kde4/devel hack (assuming it's getting
linked from outside of the package at all, otherwise rm -f might also be a
solution).

>   /usr/share/kde4/apps/ksmserver/windowmanagers/compiz-custom.desktop from
>   install of kdebase-runtime-4.1.80-4.fc11.i386 conflicts with file from
>   package kdebase-workspace-4.1.2-14.fc10.i386 file
>   /usr/share/kde4/apps/ksmserver/windowmanagers/compiz.desktop from
>   install of kdebase-runtime-4.1.80-4.fc11.i386 conflicts with file from
>   package kdebase-workspace-4.1.2-14.fc10.i386 file
>   /usr/share/kde4/apps/ksmserver/windowmanagers/metacity.desktop from
>   install of kdebase-runtime-4.1.80-4.fc11.i386 conflicts with file from
>   package kdebase-workspace-4.1.2-14.fc10.i386 file
>   /usr/share/kde4/apps/ksmserver/windowmanagers/openbox.desktop from
>   install of kdebase-runtime-4.1.80-4.fc11.i386 conflicts with file from
>   package kdebase-workspace-4.1.2-14.fc10.i386 file

These are conflicts between an old kdebase-workspace and a new
kdebase-runtime. The kdebase-workspace-4.1.80 build now in Rawhide should
fix this. (But see above for the libplasma deps.)

>   /usr/lib/libakonadi-kabc.so.4 from install of
>   kdepimlibs-4.1.80-2.fc11.i386 conflicts with file from package
>   kdepim-libs-6:4.1.2-5.fc10.i386

This is a conflict between an old kdepim and a new kdepimlibs. It will be
fixed when we get kdepim-4.1.80 built.

        Kevin Kofler



From mschwendt at gmail.com  Mon Dec  1 21:49:27 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 1 Dec 2008 22:49:27 +0100
Subject: FHS violations
In-Reply-To: <gh1j5m$b66$1@ger.gmane.org>
References: <20081201211122.994a7940.mschwendt@gmail.com>
	<gh1j5m$b66$1@ger.gmane.org>
Message-ID: <20081201224927.8cf44c69.mschwendt@gmail.com>

On Mon, 01 Dec 2008 21:58:29 +0100, Kevin Kofler wrote:

> Michael Schwendt wrote:
> > Contrary to that, package "spu-binutils" creates directories
> > 
> >   /spu
> >   /usr/spu
> > 
> > which is a violation of the FHS. And I've been told there are more
> > packages that do something similar.
> 
> It's a cross-toolchain.

I know.

> Using a directory like this is the established
> practice for GNU cross-toolchains (and also used by some other
> cross-toolchains) and the consensus among Fedora packagers working on
> cross-compilation is that this is the way to go. Unfortunately, the
> guideline which was supposed to formally codify it never made it to an FPC
> vote because of process issues.

I think I've seen %_exec_prefix/%_target before (I can imagine that trying
to change that might result in symlink-hell), but a root-level directory is
strange. That one is also "established practice"?

And this hasn't passed FPC and neither FESCo?



From jkeating at redhat.com  Mon Dec  1 21:50:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 01 Dec 2008 13:50:06 -0800
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <49345989.5040704@redhat.com>
References: <20081114192450.18827.51863@faldor.intranet>
	<491DD575.1070200@redhat.com>	<20081114213352.2f073127.mschwendt@gmail.com>
	<gfkq8p$bms$1@ger.gmane.org> <491DF130.7040403@redhat.com>
	<1226699696.11393.65.camel@luminos.localdomain>
	<49340973.4040204@redhat.com>	<20081201173708.c09281bf.mschwendt@gmail.com>
	<1228163885.3608.4.camel@localhost.localdomain>
	<49345989.5040704@redhat.com>
Message-ID: <1228168206.3608.11.camel@localhost.localdomain>

On Mon, 2008-12-01 at 16:39 -0500, David Huff wrote:
> 
> If I take out noarch in the ExclusiveArch list the build will fail:
> "error: Architecture is not included: noarch"
> 
> more info:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=968280

Hrm, I'm looking through everything that was successfully excluded in
the last compose, everything seems to be using ExcludeArch instead of
ExclusiveArch.  It's possible our treatment of ExclusiveArch isn't
correct, again because we have to add noarch to the list.  What's the
reasoning for your use of Exclusive vs ExcludeArch ?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/5cee081e/attachment.sig>

From dhuff at redhat.com  Mon Dec  1 22:02:46 2008
From: dhuff at redhat.com (David Huff)
Date: Mon, 01 Dec 2008 17:02:46 -0500
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <1228168206.3608.11.camel@localhost.localdomain>
References: <20081114192450.18827.51863@faldor.intranet>	<491DD575.1070200@redhat.com>	<20081114213352.2f073127.mschwendt@gmail.com>	<gfkq8p$bms$1@ger.gmane.org>
	<491DF130.7040403@redhat.com>	<1226699696.11393.65.camel@luminos.localdomain>	<49340973.4040204@redhat.com>	<20081201173708.c09281bf.mschwendt@gmail.com>	<1228163885.3608.4.camel@localhost.localdomain>	<49345989.5040704@redhat.com>
	<1228168206.3608.11.camel@localhost.localdomain>
Message-ID: <49345F06.9060908@redhat.com>

Jesse Keating wrote:
  > Hrm, I'm looking through everything that was successfully excluded in
> the last compose, everything seems to be using ExcludeArch instead of
> ExclusiveArch.  It's possible our treatment of ExclusiveArch isn't
> correct, again because we have to add noarch to the list.  What's the
> reasoning for your use of Exclusive vs ExcludeArch ?
> 
> 

I used ExclusiveArch to match qemu, which is what it depends on, however 
qemu is an arch specific rpm.

Building with ExcludeArch does build.  I'll throw it against
rawhide and see if mash picks it up or not.

-D



From kevin.kofler at chello.at  Mon Dec  1 22:08:24 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 01 Dec 2008 23:08:24 +0100
Subject: FHS violations
References: <20081201211122.994a7940.mschwendt@gmail.com>
	<gh1j5m$b66$1@ger.gmane.org>
	<20081201224927.8cf44c69.mschwendt@gmail.com>
Message-ID: <gh1n8o$qt0$1@ger.gmane.org>

Michael Schwendt wrote:
> I think I've seen %_exec_prefix/%_target before (I can imagine that trying
> to change that might result in symlink-hell), but a root-level directory
> is strange. That one is also "established practice"?

The top-level /spu (not in /usr) is weird indeed, I'm not sure where this
comes from.

        Kevin Kofler



From mschwendt at gmail.com  Mon Dec  1 22:16:50 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 1 Dec 2008 23:16:50 +0100
Subject: FHS violations
In-Reply-To: <gh1n8o$qt0$1@ger.gmane.org>
References: <20081201211122.994a7940.mschwendt@gmail.com>
	<gh1j5m$b66$1@ger.gmane.org>
	<20081201224927.8cf44c69.mschwendt@gmail.com>
	<gh1n8o$qt0$1@ger.gmane.org>
Message-ID: <20081201231650.79a38efe.mschwendt@gmail.com>

On Mon, 01 Dec 2008 23:08:24 +0100, Kevin Kofler wrote:

> Michael Schwendt wrote:
> > I think I've seen %_exec_prefix/%_target before (I can imagine that trying
> > to change that might result in symlink-hell), but a root-level directory
> > is strange. That one is also "established practice"?
> 
> The top-level /spu (not in /usr) is weird indeed, I'm not sure where this
> comes from.

Fortunately, only /usr/spu is left (albeit "unowned"), but another
root-dir has popped up: /ace  => https://bugzilla.redhat.com/473620



From mjs at clemson.edu  Mon Dec  1 22:17:21 2008
From: mjs at clemson.edu (Matthew Saltzman)
Date: Mon, 01 Dec 2008 22:17:21 +0000
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <1228165381.23367.3.camel@scrappy.miketc.net>
References: <4933F7AD.1040904@gmail.com>
	<1228155928.2360.7.camel@gilboa-work-dev.localdomain>
	<49343DB0.3060907@gmail.com>
	<1228165381.23367.3.camel@scrappy.miketc.net>
Message-ID: <1228169841.19246.14.camel@valkyrie.localdomain>


On Mon, 2008-12-01 at 15:03 -0600, Mike Chambers wrote:
> On Mon, 2008-12-01 at 22:40 +0300, Lev Shamardin wrote:
> 
> > User creation: https://bugzilla.redhat.com/show_bug.cgi?id=474007
> 
> Not sure I understand this one.  You may be restoring your /home dir,
> but you still need that user created anyway, so if at least
> group/passwd/gdm/etc.. are all set?  The home dir will just get written
> over during restore, so that makes no difference?

AIUI, he had a damaged /home and intended to fix it with fsck after
installation, but was forced to create a user (hence write to /home)
before he could get to the repair step.

I'm mostly just a user, but I don't think I'd expect that to work.  I'd
boot the CD to rescue mode and make sure all my carry-over file systems
were sound before commencing an installation.

Developers and other users, is his expectation a reasonable one?

> 
> > NTP firstboot crash: https://bugzilla.redhat.com/show_bug.cgi?id=474009
> 
> This one I get.  I am not sure why maybe NM isn't brought up during
> this, and first might I add, then anything network related would  be
> brought up?
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From kevin.kofler at chello.at  Mon Dec  1 22:22:19 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 01 Dec 2008 23:22:19 +0100
Subject: rawhide report: 20081201 changes
References: <20081201131206.AC5501F8252@releng2.fedora.phx.redhat.com>
	<650764.58253.qm@web52609.mail.re2.yahoo.com>
	<gh1lnp$lf0$1@ger.gmane.org>
Message-ID: <gh1o2r$t3q$1@ger.gmane.org>

I wrote:
>>   /usr/lib/libkwalletbackend.so from install of
>>   kdebase-runtime-4.1.80-4.fc11.i386 conflicts with file from package
>>   kdelibs3-devel-3.5.10-1.fc10.i386 file
> 
> This one needs to use the /usr/lib/kde4/devel hack (assuming it's getting
> linked from outside of the package at all, otherwise rm -f might also be a
> solution).

Actually, as this is in kdebase-runtime, nothing should be building against
it (and nothing currently does according to repoquery), and as there's no
kdebase-runtime-devel (for that very reason: kdebase-runtime is for runtime
files, stuff needed for development should be in kdelibs-devel), I just
removed the file (new kdebase-runtime building now). If something turns out
needing it, we can always resurrect it (and either remove the KDE 3 one or
use /usr/lib/kde4/devel), but it would mean introducing a
kdebase-runtime-devel.

>>   /usr/lib/libakonadi-kabc.so.4 from install of
>>   kdepimlibs-4.1.80-2.fc11.i386 conflicts with file from package
>>   kdepim-libs-6:4.1.2-5.fc10.i386
> 
> This is a conflict between an old kdepim and a new kdepimlibs. It will be
> fixed when we get kdepim-4.1.80 built.

This is building now and appears to be successful (i386 and x86_64 already
completed successfully).

        Kevin Kofler



From stickster at gmail.com  Mon Dec  1 17:19:10 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Mon, 1 Dec 2008 12:19:10 -0500
Subject: FUDCon F11 Boston
Message-ID: <20081201171910.GO18297@localhost.localdomain>

FUDCon F11 Boston -- News Update!
=================================

* All of our location information is confirmed -- we will be holding
  the conference as predicted, at MIT in the Sloan Building.  There
  will be plentiful space for hackfests and BarCamp sessions over the
  course of the weekend.

* FUDPub will be held at Flat Top Johnny's on Saturday night (January
  10) from 6:00-10:00pm.

* The wiki remains open for registration.  Please remember to note
  your shirt size, whether you prefer vegetarian fare for lunch on
  Saturday, and any other important information (in the "Comments"
  section).

* The hotel group rate is good until DECEMBER 19.  After that, it will
  be up to the hotel to decide whether or not to extend their offer of
  $99/night.  So sign up now!

And here's some further news to sweeten the pot -- the One Laptop Per
Child and SugarLabs communities will be joining us for FUDCon, to
address areas of common interest like packaging and building for these
unique projects, and to talk to Fedora community members about getting
involved.  This should make FUDCon a very exciting event and I look
forward to seeing everyone there who can make 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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/c11d5a86/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From opensource at till.name  Mon Dec  1 22:27:16 2008
From: opensource at till.name (Till Maas)
Date: Mon, 01 Dec 2008 23:27:16 +0100
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <49343DB0.3060907@gmail.com>
References: <4933F7AD.1040904@gmail.com>
	<1228155928.2360.7.camel@gilboa-work-dev.localdomain>
	<49343DB0.3060907@gmail.com>
Message-ID: <200812012327.25645.opensource@till.name>

On Mon December 1 2008, Lev Shamardin wrote:

> If you are lacking testers for a significant change, may be you could just
> announce that "hey, this feature could possibly break the things, since it
> changes the habitual defaults, please test it or be warned". This could
> bring more testers, especially those interested in features to be broken.

Any test release of Fedora is announced with this message, e.g. Jesse Keating 
wrote in the F10 Beta announcement:

| There is also a Beta contest! Test five things in the Beta that are
| important to you as a user. If you find a bug *and* report it, you get
| the free attention of a package maintainer on a problem personally
| important to you!

Thanks to the live media, it is also pretty easy to test new releases without 
the need to actually install the release and if you want to install it, it is 
very fast if you use a live medium as source. Therefore please test what is 
important for you once the F11 Alpha is released and then there is a high 
probability that your issues will be fixed. At least I made this 
experience. :-D

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/6d3d0361/attachment.sig>

From a.badger at gmail.com  Mon Dec  1 22:34:19 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 01 Dec 2008 14:34:19 -0800
Subject: First Report
In-Reply-To: <1228057466.3835.105.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan>
Message-ID: <4934666B.6010200@gmail.com>

Ignacio Vazquez-Abrams wrote:
> 
> There were 29 packages with non-trivial code or packaging issues:
> python-sqlalchemy

This one is now fixed.

Working on python-cheetah unless someone beats me to it :-)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/a052a8bf/attachment.sig>

From kevin.kofler at chello.at  Mon Dec  1 22:43:32 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 01 Dec 2008 23:43:32 +0100
Subject: Round 3 starting (was: Re: Python 2.6 clear for Rawhide)
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228139787.3835.189.camel@ignacio.lan>
Message-ID: <gh1pal$2iq$1@ger.gmane.org>

Ignacio Vazquez-Abrams wrote:
> This round is composed of packages that contain compiled Python code but
> do not have a Requires of python(abi). Please note that this is a
> packaging bug as the bytecode is specific to the version of the Python
> it was compiled with. Whether this is a problem with rpm's macros or
> with the package itself must be dealt with on a case-by-case basis.

Are you really _sure_ all those packages contain Python bytecode?

In particular, where's the bytecode in these?
> kdelibs
> kdesdk
> kdevelop
> koffice
> konq-plugins

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec  1 22:52:18 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 01 Dec 2008 23:52:18 +0100
Subject: Round 3 starting (was: Re: Python 2.6 clear for Rawhide)
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228139787.3835.189.camel@ignacio.lan>
	<gh1pal$2iq$1@ger.gmane.org>
Message-ID: <gh1pr2$4h1$1@ger.gmane.org>

I wrote:
> In particular, where's the bytecode in these?
>> kdelibs
>> kdesdk
>> kdevelop
>> koffice
>> konq-plugins

Actually I found at least one offender in kdesdk:
/usr/bin/kdelnk2desktop.py
/usr/bin/kdelnk2desktop.pyc
/usr/bin/kdelnk2desktop.pyo

I suppose the others are something similar.

        Kevin Kofler



From chris.stone at gmail.com  Mon Dec  1 23:18:12 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 1 Dec 2008 15:18:12 -0800
Subject: First Report (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <1228057466.3835.105.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan>
Message-ID: <d9c612bf0812011518q7afd2920k29aabfbaef4ad21@mail.gmail.com>

2008/11/30 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> The first cycle of rebuilds is done, and here's the results.
>
> There were 3 packages that expected Python, but not 2.6:
>
...
> pypoker-eval

Fixed in pypoker-eval-135.0-3.fc11.1
http://koji.fedoraproject.org/koji/taskinfo?taskID=968584



From pertusus at free.fr  Mon Dec  1 20:58:47 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 1 Dec 2008 21:58:47 +0100
Subject: How to pack cron jobs?
In-Reply-To: <gh1grb$v31$1@ger.gmane.org>
References: <ggs9m8$rsg$1@ger.gmane.org>
	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>
	<ggsd7q$5tn$1@ger.gmane.org> <20081130142237.GA16722@free.fr>
	<ggujhc$68k$1@ger.gmane.org> <20081130210724.GA2649@free.fr>
	<ggv8d5$539$1@ger.gmane.org> <20081201083229.GA2735@free.fr>
	<gh1grb$v31$1@ger.gmane.org>
Message-ID: <20081201205847.GB2796@free.fr>

On Mon, Dec 01, 2008 at 11:18:50PM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> I can't find any mention of cron.d in man of crond.
> $ rpm -q cronie
> cronie-1.0-7.fc9.i386

      Cron is  checking  those  files  or  directories:  /etc/crontab system
      crontab   is  usually  for  running  daily,  weekly,  monthly jobs.
      /etc/cron.d/ where are system cronjobs stored for  different users.
      /var/spool/cron that?s mean spool directory for user crontables.


> Furthermore, as mentioned above, fcron will does the same in short time.

Not really done reliably already ;-). But indeed, soon.

>> Not in the main package.
> Not in main package? Is there any subpackage of crontab in Fedora??
> $ repoquery 'crontab*'
> crontabs-0:1.10-19.fc9.noarch
>
> Or you suppose create new one?

That's not what I meant. I meant the main cronie and fcron packages
should not require crontabs.

> Off course. What to obstruct the create another one to replace fedora  
> variant? Do not see any problem there.

I mean not have /etc/crontab from a package but rather do it by
hand. In fact it is a dependency of fcron-watch-config, so with fcron it
is not really possible to have a hand made /etc/crontab out of a
package.

--
Pat



From poelstra at redhat.com  Mon Dec  1 23:59:50 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 01 Dec 2008 15:59:50 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-12-01 
Message-ID: <49347A76.3010600@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-dec-01

Please make corrections and clarifications to the wiki page.


== Fedora 11 Schedule ==
* Draft schedule agreed to by release engineering
** sending to FESCo for final approval at next meeting
** https://fedoraproject.org/wiki/Releases/11/Schedule
* desire to be stricter around freezes and tracking feature status

== Other Plans for Fedora 11 ==
* build out documentation so we can grow Release Engineering beyond 
current members
* signing server
* more automation around check-ins and builds

== Fedora 11 Naming ==
* f13 to check with Josh Boyer (jwb) on running the process

== IRC Transcript ==



From stickster at gmail.com  Tue Dec  2 00:14:18 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Mon, 1 Dec 2008 19:14:18 -0500
Subject: Fedora Release Engineering Meeting Recap 2008-12-01
In-Reply-To: <49347A76.3010600@redhat.com>
References: <49347A76.3010600@redhat.com>
Message-ID: <20081202001418.GA953@localhost.localdomain>

On Mon, Dec 01, 2008 at 03:59:50PM -0800, John Poelstra wrote:
> == Fedora 11 Naming ==
> * f13 to check with Josh Boyer (jwb) on running the process

https://fedoraproject.org/wiki/Guidelines_for_release_names
https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_11

Josh and I worked on the guidelines last release after encountering
far too many name suggestions that were legally or otherwise
encumbered.  We both hope we'll have a smoother process this release
and that we can hand the Artwork team a name much sooner.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/eac358da/attachment.sig>

From mbarnes at redhat.com  Tue Dec  2 00:41:42 2008
From: mbarnes at redhat.com (Matthew Barnes)
Date: Mon, 01 Dec 2008 19:41:42 -0500
Subject: FC9: mock -r fedora-rawhide-i386 init fails
In-Reply-To: <1225179655.3897.38.camel@beck.corsepiu.local>
References: <1225179655.3897.38.camel@beck.corsepiu.local>
Message-ID: <1228178502.30498.2.camel@localhost.localdomain>

On Tue, 2008-10-28 at 08:40 +0100, Ralf Corsepius wrote:
> Since this morning, initializing fedora-rawhide-i386 mock chroots fail
> for me on FC9:
> 
> # mock -r fedora-rawhide-i386 init
> INFO: mock.py version 0.9.9 starting...
> ...
> ERROR: Command failed: 
>  # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-i386/root/
> groupinstall buildsys-build
> ...
> /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot
> open shared object file: No such file or directory
> error: %post(bash-3.2-28.fc10.i386) scriptlet failed, exit status 127
> ...

I'm seeing this issue now in Koji, on a post-F10 rawhide build I
attempted today:

http://koji.fedoraproject.org/koji/getfile?taskID=968841&name=root.log

...
DEBUG util.py:250:  Total download size: 104 M
DEBUG util.py:250:  /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
DEBUG util.py:250:  error: %post(bash-3.2-29.fc10.i386) scriptlet failed, exit status 127

Is there anything I need to change on my end?

Matthew Barnes



From jwboyer at gmail.com  Tue Dec  2 00:51:51 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 1 Dec 2008 19:51:51 -0500
Subject: Fedora Release Engineering Meeting Recap 2008-12-01
In-Reply-To: <20081202001418.GA953@localhost.localdomain>
References: <49347A76.3010600@redhat.com>
	<20081202001418.GA953@localhost.localdomain>
Message-ID: <20081202005151.GA25631@zod.rchland.ibm.com>

On Mon, Dec 01, 2008 at 07:14:18PM -0500, Paul W. Frields wrote:
>On Mon, Dec 01, 2008 at 03:59:50PM -0800, John Poelstra wrote:
>> == Fedora 11 Naming ==
>> * f13 to check with Josh Boyer (jwb) on running the process
>
>https://fedoraproject.org/wiki/Guidelines_for_release_names
>https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_11
>
>Josh and I worked on the guidelines last release after encountering
>far too many name suggestions that were legally or otherwise
>encumbered.  We both hope we'll have a smoother process this release
>and that we can hand the Artwork team a name much sooner.

In addition to that, naming suggestions will open very very soon.
Keep your eyes open on the lists for the announcement.

josh



From jkeating at redhat.com  Tue Dec  2 01:01:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 01 Dec 2008 17:01:33 -0800
Subject: FC9: mock -r fedora-rawhide-i386 init fails
In-Reply-To: <1228178502.30498.2.camel@localhost.localdomain>
References: <1225179655.3897.38.camel@beck.corsepiu.local>
	<1228178502.30498.2.camel@localhost.localdomain>
Message-ID: <1228179693.11576.1.camel@localhost.localdomain>

On Mon, 2008-12-01 at 19:41 -0500, Matthew Barnes wrote:
> DEBUG util.py:250:  Total download size: 104 M
> DEBUG util.py:250:  /bin/sh: error while loading shared libraries:
> libtinfo.so.5: cannot open shared object file: No such file or
> directory
> DEBUG util.py:250:  error: %post(bash-3.2-29.fc10.i386) scriptlet
> failed, exit status 127
> 
> Is there anything I need to change on my end?

No.  As of yet, this error seems non-fatal.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/4cd62f1c/attachment.sig>

From ivazqueznet at gmail.com  Tue Dec  2 01:14:54 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 20:14:54 -0500
Subject: Synopsis (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <1227923821.3835.39.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
Message-ID: <1228180494.29612.27.camel@ignacio.lan>

The major rebuilds are complete, and I am *very* pleased with the
results. Out of 831 source packages, all but about 160 have been built.
Once avahi, xulrunner, and rpm (Bug 473814) are rebuilt, another 100 or
so will build and we'll be in the final stretch.

At this time, I am going to recommend that we merge the dist-f11-python
tag with dist-f11 this Thursday, December 4, 2008. From there we can
pick off the stragglers one by one and get this done.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/a540b2ec/attachment.sig>

From cra at WPI.EDU  Tue Dec  2 01:49:05 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 1 Dec 2008 20:49:05 -0500
Subject: Fedora Release Engineering Meeting Recap 2008-12-01
In-Reply-To: <20081202005151.GA25631@zod.rchland.ibm.com>
References: <49347A76.3010600@redhat.com>
	<20081202001418.GA953@localhost.localdomain>
	<20081202005151.GA25631@zod.rchland.ibm.com>
Message-ID: <20081202014905.GB32346@angus.ind.WPI.EDU>

On Mon, Dec 01, 2008 at 07:51:51PM -0500, Josh Boyer wrote:
> On Mon, Dec 01, 2008 at 07:14:18PM -0500, Paul W. Frields wrote:
> >On Mon, Dec 01, 2008 at 03:59:50PM -0800, John Poelstra wrote:
> >> == Fedora 11 Naming ==
> >> * f13 to check with Josh Boyer (jwb) on running the process
> >
> >https://fedoraproject.org/wiki/Guidelines_for_release_names
> >https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_11
> >
> >Josh and I worked on the guidelines last release after encountering
> >far too many name suggestions that were legally or otherwise
> >encumbered.  We both hope we'll have a smoother process this release
> >and that we can hand the Artwork team a name much sooner.
> 
> In addition to that, naming suggestions will open very very soon.
> Keep your eyes open on the lists for the announcement.

Does the "is-a" relationship between F10 and F11 have to be the 
already-chosen "original code name of Red Hat Linux", or are we 
allowed to come up with a new "is-a" relationship between Cambridge 
and the F11 name?



From raven at themaw.net  Tue Dec  2 02:18:31 2008
From: raven at themaw.net (Ian Kent)
Date: Tue, 02 Dec 2008 11:18:31 +0900
Subject: autofs - patches in %doc?
In-Reply-To: <x49bpvv93hy.fsf@segfault.boston.devel.redhat.com>
References: <20081128112055.7692379c.mschwendt@gmail.com>
	<x49bpvv93hy.fsf@segfault.boston.devel.redhat.com>
Message-ID: <1228184311.2954.10.camel@zeus.themaw.net>

On Mon, 2008-12-01 at 13:03 -0500, Jeff Moyer wrote:
> Michael Schwendt <mschwendt at gmail.com> writes:
> 
> > $ du -h /usr/share/doc/autofs-5.0.3/*.patch
> > 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.10-v5-update.patch
> > 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.11-v5-update.patch
> > 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.12-v5-update.patch
> > 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.13-v5-update.patch
> > 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.14-v5-update.patch
> > 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.15-v5-update.patch
> > 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.16-v5-update.patch
> > 28K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.17-v5-update.patch
> > 28K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.18-v5-update.patch
> > 20K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.19-v5-update.patch
> > 16K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.20-v5-update.patch
> > 8.0K    /usr/share/doc/autofs-5.0.3/autofs4-2.6.21-v5-update.patch
> > 8.0K    /usr/share/doc/autofs-5.0.3/autofs4-2.6.22-v5-update.patch
> > 4.0K    /usr/share/doc/autofs-5.0.3/autofs4-2.6.23-v5-update.patch
> > 76K     /usr/share/doc/autofs-5.0.3/autofs4-2.6.9-v5-update.patch
> > 4.0K    /usr/share/doc/autofs-5.0.3/util-linux-2.12a-flock.patch
> > 4.0K    /usr/share/doc/autofs-5.0.3/util-linux-2.12q-flock.patch
> >
> > [$ du -h autofs-5.0.4/patches
> > 2.0M    autofs-5.0.4/patches
> > ]
> >
> > So, we've got ~48K of %changelog details in the autofs.spec, but the
> > question why the %doc line explicitly includes  patches/*  is not answered.
> > That clutters up the docdir unnecessarily.
> >
> > Who can tell why this is done?

Oh .. oops.
        
Once upon a time there were only a couple patches and they were small
and they weren't included in the kernel so it was sensible to place them
in the docs directory in case they were needed.
        
But nowadays they aren't needed so much, especially the patches for the
older kernels, as the updates make there way into Fedora kernels in
reasonable time.
        
Log a bug and we'll fix this.
    
Ian




From rc040203 at freenet.de  Tue Dec  2 02:30:55 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 02 Dec 2008 03:30:55 +0100
Subject: FHS violations
In-Reply-To: <gh1n8o$qt0$1@ger.gmane.org>
References: <20081201211122.994a7940.mschwendt@gmail.com>
	<gh1j5m$b66$1@ger.gmane.org>
	<20081201224927.8cf44c69.mschwendt@gmail.com>
	<gh1n8o$qt0$1@ger.gmane.org>
Message-ID: <1228185055.5593.2718.camel@beck.corsepiu.local>

On Mon, 2008-12-01 at 23:08 +0100, Kevin Kofler wrote:
> Michael Schwendt wrote:
> > I think I've seen %_exec_prefix/%_target before (I can imagine that trying
> > to change that might result in symlink-hell), but a root-level directory
> > is strange. That one is also "established practice"?
GCC uses $PREFIX/$TARGET for cross-toolchains.

So, if a cross-toolchain uses --target=spu these files land in /usr/spu

Whether using --target=spu is a clever idea and whether this makes sense
is a different matter. IMNSHO, it is none of both.

> The top-level /spu (not in /usr) is weird indeed, I'm not sure where this
> comes from.
/spu is nonsense. I'd suggest to have FESCO block and withdraw this
package.

Ralf




From peter.hutterer at who-t.net  Tue Dec  2 02:53:47 2008
From: peter.hutterer at who-t.net (Peter Hutterer)
Date: Tue, 2 Dec 2008 12:53:47 +1000
Subject: evdev and multiple keyboards
In-Reply-To: <afa4029dae96c9fbe741d4952cbe15ac.squirrel@arekh.dyndns.org>
References: <4933C40C.8040203@gmail.com> <20081201114516.GA29466@srcf.ucam.org>
	<6370808e3d1e7b8a261b34838e26e65c.squirrel@arekh.dyndns.org>
	<4933D9A1.4030307@gmail.com>
	<afa4029dae96c9fbe741d4952cbe15ac.squirrel@arekh.dyndns.org>
Message-ID: <20081202025346.GA25194@dingo.redhat.com>

On Mon, Dec 01, 2008 at 01:45:27PM +0100, Nicolas Mailhot wrote:
> Le Lun 1 d?cembre 2008 13:33, Julian Sikorski a ?crit :
> >
> > Nicolas Mailhot pisze:
> >>
> >> Le Lun 1 d?cembre 2008 12:45, Matthew Garrett a ?crit :
> >>
> >>> USB devices output standardised keycodes, so if these are incorrect
> >>> it
> >>> implies that the evdev map in xkb is wrong.
> >>
> >> Unfortunately that's not always 100% the case, and the kernel HID
> >> driver maintains a quirk table for non conformant hardware.
> >>
> >> The ultimate fix is thus to declare this model's quirks kernel-side,
> >> by posting the usb id and needed changes on
> >> http://vger.kernel.org/vger-lists.html#linux-input
> >>
> > How to check if it's the evdev map or lack of conformance?
> 
> Ask on the list. People will tell you to check keypresses result in
> standard codes kernel-side with the console equivalent of xev (I don't
> remember the command name).

evtest

There's a copy on http://people.freedesktop.org/~whot/evtest.c

Cheers,
  Peter



From mtasaka at ioa.s.u-tokyo.ac.jp  Tue Dec  2 02:58:26 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Tue, 02 Dec 2008 11:58:26 +0900
Subject: rpms/libxml2/devel libxml2.spec,1.64,1.65
In-Reply-To: <20081201234328.D1D6570119@cvs1.fedora.phx.redhat.com>
References: <20081201234328.D1D6570119@cvs1.fedora.phx.redhat.com>
Message-ID: <4934A452.4070806@ioa.s.u-tokyo.ac.jp>

Ignacio Vazquez-Abrams wrote, at 12/02/2008 08:43 AM +9:00:
> Author: ivazquez
> 
> Update of /cvs/pkgs/rpms/libxml2/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22811
> 
> Modified Files:
> 	libxml2.spec 
> Log Message:
> Rebuild for pkgconfig logic
> 
> 
> Index: libxml2.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/libxml2/devel/libxml2.spec,v
> retrieving revision 1.64
> retrieving revision 1.65
> diff -u -r1.64 -r1.65
> --- libxml2.spec	29 Nov 2008 04:53:43 -0000	1.64
> +++ libxml2.spec	1 Dec 2008 23:42:58 -0000	1.65
> @@ -1,7 +1,7 @@
>  Summary: Library providing XML and HTML support
>  Name: libxml2
>  Version: 2.7.2
> -Release: 3%{?dist}%{?extra_release}
> +Release: 4%{?dist}%{?extra_release}
>  License: MIT
>  Group: Development/Libraries
>  Source: ftp://xmlsoft.org/libxml2/libxml2-%{version}.tar.gz
> @@ -145,6 +145,9 @@
>  %doc doc/python.html
>  
>  %changelog
> +* Mon Dec  1 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.7.2-4
> +- Rebuild for pkgconfig logic
> +
>  * Fri Nov 28 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.7.2-3
>  - Rebuild for Python 2.6

This will cause no effect unless bug 473978 is fixed.

Regards,
Mamoru



From ivazqueznet at gmail.com  Tue Dec  2 03:01:30 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 01 Dec 2008 22:01:30 -0500
Subject: rpms/libxml2/devel libxml2.spec,1.64,1.65
In-Reply-To: <4934A452.4070806@ioa.s.u-tokyo.ac.jp>
References: <20081201234328.D1D6570119@cvs1.fedora.phx.redhat.com>
	<4934A452.4070806@ioa.s.u-tokyo.ac.jp>
Message-ID: <1228186890.29612.34.camel@ignacio.lan>

On Tue, 2008-12-02 at 11:58 +0900, Mamoru Tasaka wrote:
> >  %changelog
> > +* Mon Dec  1 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.7.2-4
> > +- Rebuild for pkgconfig logic
> > +
> 
> This will cause no effect unless bug 473978 is fixed.

Yes, I realized that once I looked at the log. I'll requeue it once rpm
is fixed.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081201/2010bf1a/attachment.sig>

From limb at jcomserv.net  Tue Dec  2 03:10:05 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 1 Dec 2008 21:10:05 -0600 (CST)
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <ufaskp7vbej.fsf@epithumia.math.uh.edu>
References: <1228091890.19905.5.camel@localhost.localdomain>
	<200811301640.37888.konrad@tylerc.org>
	<20081201101456.GA18568@thinkpad>
	<ufa1vwrwrf3.fsf@epithumia.math.uh.edu>
	<360f42acea018573951d974f75130677.squirrel@mail.jcomserv.net>
	<ufaskp7vbej.fsf@epithumia.math.uh.edu>
Message-ID: <b17e84260502cdfe3ede8cccc4dd6779.squirrel@mail.chuzibooks.com>


>>>>>> "JC" == Jon Ciesla <limb at jcomserv.net> writes:
>
> JC> Contents:
>
> Yes, precisely.  Is there some problem with that?

Not really, just extra clicks.

>  - J<
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From petersen at redhat.com  Tue Dec  2 03:28:53 2008
From: petersen at redhat.com (Jens Petersen)
Date: Mon, 1 Dec 2008 22:28:53 -0500 (EST)
Subject: Status of libtool 2.2.X?
In-Reply-To: <loom.20081011T161204-624@post.gmane.org>
Message-ID: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Kevin Kofler" <kevin.kofler at chello.at> wrote:
> * start discouraging shipping pregenerated files, instead make sure that 
> autoreconf actually works (which mainly amounts to the above point about 
> backwards compatibility).
> But unfortunately, this won't solve the problem of the reliance on the shell, 
> and as configure.ac scripts can contain arbitrary shell snippets, this can't 
> really be fixed without a major redesign, the result of which would effectively 
> no longer be autotools.

I would add:

* do not start new projects using autotools as far as possible



From behdad at behdad.org  Tue Dec  2 03:33:08 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Mon, 01 Dec 2008 22:33:08 -0500
Subject: Status of libtool 2.2.X?
In-Reply-To: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4934AC74.6050808@behdad.org>

Jens Petersen wrote:
> ----- "Kevin Kofler" <kevin.kofler at chello.at> wrote:
>> * start discouraging shipping pregenerated files, instead make sure that 
>> autoreconf actually works (which mainly amounts to the above point about 
>> backwards compatibility).
>> But unfortunately, this won't solve the problem of the reliance on the shell, 
>> and as configure.ac scripts can contain arbitrary shell snippets, this can't 
>> really be fixed without a major redesign, the result of which would effectively 
>> no longer be autotools.
> 
> I would add:
> 
> * do not start new projects using autotools as far as possible

Maybe you can offer an alternative?  And no, I don't mean reciting names of
some hacks some cool kids may have put together for their birthday...  And not
something that requires me to install it first before I can build this tarball
I downloaded.

behdad



From orion at cora.nwra.com  Tue Dec  2 03:45:10 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 01 Dec 2008 20:45:10 -0700
Subject: cmake preserving timestamps?
In-Reply-To: <200812012230.38148.opensource@till.name>
References: <200812012111.42307.opensource@till.name>	<200812012314.10709.ville.skytta@iki.fi>
	<200812012230.38148.opensource@till.name>
Message-ID: <4934AF46.4070807@cora.nwra.com>

Till Maas wrote:
> On Mon December 1 2008, Ville Skytt? wrote:
> 
>> Perhaps passing -DCMAKE_VERBOSE_MAKEFILE=ON to %cmake will help with that?
>>
>> See also https://bugzilla.redhat.com/474053
> 
> I tried to use "make install VERBOSE=1", but I belive that I did not find any 
> useful information about whether or not timestamps were preserved. But I will 
> test this.
> 
> Regards,
> Till
> 

make VERBOSE=1 and setting CMAKE_VERBOSE_MAKEFILE=ON should do the same 
thing.

- Orion



From notting at redhat.com  Tue Dec  2 03:49:20 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 1 Dec 2008 22:49:20 -0500
Subject: Fedora Release Engineering Meeting Recap 2008-12-01
In-Reply-To: <20081202014905.GB32346@angus.ind.WPI.EDU>
References: <49347A76.3010600@redhat.com>
	<20081202001418.GA953@localhost.localdomain>
	<20081202005151.GA25631@zod.rchland.ibm.com>
	<20081202014905.GB32346@angus.ind.WPI.EDU>
Message-ID: <20081202034920.GC23424@nostromo.devel.redhat.com>

Chuck Anderson (cra at WPI.EDU) said: 
> Does the "is-a" relationship between F10 and F11 have to be the 
> already-chosen "original code name of Red Hat Linux", or are we 
> allowed to come up with a new "is-a" relationship between Cambridge 
> and the F11 name?

No. The connection used to get from Sulphur to Cambridge was a
city, so that's the 'is-a' that's out of bounds.

Bill



From konrad at tylerc.org  Tue Dec  2 03:54:28 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 1 Dec 2008 19:54:28 -0800
Subject: Status of libtool 2.2.X?
In-Reply-To: <4934AC74.6050808@behdad.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<4934AC74.6050808@behdad.org>
Message-ID: <200812011954.28959.konrad@tylerc.org>

On Monday 01 December 2008 07:33:08 pm Behdad Esfahbod wrote:
> Jens Petersen wrote:
> > ----- "Kevin Kofler" <kevin.kofler at chello.at> wrote:
> >> * start discouraging shipping pregenerated files, instead make sure that
> >> autoreconf actually works (which mainly amounts to the above point about
> >> backwards compatibility).
> >> But unfortunately, this won't solve the problem of the reliance on the
> >> shell, and as configure.ac scripts can contain arbitrary shell snippets,
> >> this can't really be fixed without a major redesign, the result of which
> >> would effectively no longer be autotools.
> >
> > I would add:
> >
> > * do not start new projects using autotools as far as possible
>
> Maybe you can offer an alternative?  And no, I don't mean reciting names of
> some hacks some cool kids may have put together for their birthday...  And
> not something that requires me to install it first before I can build this
> tarball I downloaded.
>
> behdad

In other words, you'll accept nothing less than an autotools clone, or 
autotools itself?

-- 
Conrad Meyer <konrad at tylerc.org>




From konrad at tylerc.org  Tue Dec  2 03:55:53 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 1 Dec 2008 19:55:53 -0800
Subject: Status of libtool 2.2.X?
In-Reply-To: <4934AC74.6050808@behdad.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<4934AC74.6050808@behdad.org>
Message-ID: <200812011955.53675.konrad@tylerc.org>

On Monday 01 December 2008 07:33:08 pm Behdad Esfahbod wrote:
> Jens Petersen wrote:
> > ----- "Kevin Kofler" <kevin.kofler at chello.at> wrote:
> >> * start discouraging shipping pregenerated files, instead make sure that
> >> autoreconf actually works (which mainly amounts to the above point about
> >> backwards compatibility).
> >> But unfortunately, this won't solve the problem of the reliance on the
> >> shell, and as configure.ac scripts can contain arbitrary shell snippets,
> >> this can't really be fixed without a major redesign, the result of which
> >> would effectively no longer be autotools.
> >
> > I would add:
> >
> > * do not start new projects using autotools as far as possible
>
> Maybe you can offer an alternative?  And no, I don't mean reciting names of
> some hacks some cool kids may have put together for their birthday...  And
> not something that requires me to install it first before I can build this
> tarball I downloaded.
>
> behdad

Oh, and I suggest trying to get everyone to distribute their software such 
that users need not install anything to build the tarball -- they should ship 
gcc with the tarball under that logic.

-- 
Conrad Meyer <konrad at tylerc.org>




From rc040203 at freenet.de  Tue Dec  2 04:08:09 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 02 Dec 2008 05:08:09 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1228190889.5593.2817.camel@beck.corsepiu.local>

On Mon, 2008-12-01 at 22:28 -0500, Jens Petersen wrote:
> ----- "Kevin Kofler" <kevin.kofler at chello.at> wrote:
> > * start discouraging shipping pregenerated files, instead make sure that 
> > autoreconf actually works (which mainly amounts to the above point about 
> > backwards compatibility).
> > But unfortunately, this won't solve the problem of the reliance on the shell, 
> > and as configure.ac scripts can contain arbitrary shell snippets, this can't 
> > really be fixed without a major redesign, the result of which would effectively 
> > no longer be autotools.
> 
> I would add:
> 
> * do not start new projects using autotools as far as possible

I would recommend you to stop spreading FUD.







From braden at endoframe.com  Tue Dec  2 04:23:03 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Mon, 01 Dec 2008 23:23:03 -0500
Subject: Status of libtool 2.2.X?
In-Reply-To: <200812011954.28959.konrad@tylerc.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<4934AC74.6050808@behdad.org>
	<200812011954.28959.konrad@tylerc.org>
Message-ID: <4934B827.3040802@endoframe.com>

Conrad Meyer wrote:
> On Monday 01 December 2008 07:33:08 pm Behdad Esfahbod wrote:
>> Jens Petersen wrote:
>>> ----- "Kevin Kofler" <kevin.kofler at chello.at> wrote:
>>>> * start discouraging shipping pregenerated files, instead make sure that
>>>> autoreconf actually works (which mainly amounts to the above point about
>>>> backwards compatibility).
>>>> But unfortunately, this won't solve the problem of the reliance on the
>>>> shell, and as configure.ac scripts can contain arbitrary shell snippets,
>>>> this can't really be fixed without a major redesign, the result of which
>>>> would effectively no longer be autotools.
>>> I would add:
>>>
>>> * do not start new projects using autotools as far as possible
>> Maybe you can offer an alternative?  And no, I don't mean reciting names of
>> some hacks some cool kids may have put together for their birthday...  And
>> not something that requires me to install it first before I can build this
>> tarball I downloaded.
>>
>> behdad
> 
> In other words, you'll accept nothing less than an autotools clone, or 
> autotools itself?

How about simply solving the problems the autotools solve and then some?

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>



From shamardin at gmail.com  Tue Dec  2 05:57:17 2008
From: shamardin at gmail.com (Lev Shamardin)
Date: Tue, 02 Dec 2008 08:57:17 +0300
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <1228165381.23367.3.camel@scrappy.miketc.net>
References: <4933F7AD.1040904@gmail.com>	<1228155928.2360.7.camel@gilboa-work-dev.localdomain>	<49343DB0.3060907@gmail.com>
	<1228165381.23367.3.camel@scrappy.miketc.net>
Message-ID: <4934CE3D.8010805@gmail.com>

On 12/02/2008 12:03 AM, Mike Chambers wrote:
>> User creation: https://bugzilla.redhat.com/show_bug.cgi?id=474007
>
> Not sure I understand this one.  You may be restoring your /home dir,
> but you still need that user created anyway, so if at least
> group/passwd/gdm/etc.. are all set?  The home dir will just get written
> over during restore, so that makes no difference?

Why would I need that user? Just to delete it after recovery?
I left /home partition in damaged state and intended to recover in a comfort
environment of the new running system, not from a recovery disc. Also I was not
going to recreate any users manually, that computer had more then one user
account, and I was going to transfer records from passwd/shadow/group/gshadow
from old installation which were backed up from a rescue environment. And I did
all the things described above, but clean Fedora 10 did create enough
unjustified obstacles to complete this process.

Anyway, firstboot user creation dialog does not give enough advanced control
over the user creation (I cannot specify uid/groups manually for example) so
this feature is not useful for any kind of advanced machine configuration and
must not be dictated by the firstboot.

>> NTP firstboot crash: https://bugzilla.redhat.com/show_bug.cgi?id=474009
>
> This one I get.  I am not sure why maybe NM isn't brought up during
> this, and first might I add, then anything network related would  be
> brought up?

Consider you are working in environment where you need manual NM configuration
for networking (e.g. encryption setup). How is this expected to work in such case?

--
Lev.



From mschwendt at gmail.com  Tue Dec  2 08:49:05 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 2 Dec 2008 09:49:05 +0100
Subject: FHS violations
In-Reply-To: <1228185055.5593.2718.camel@beck.corsepiu.local>
References: <20081201211122.994a7940.mschwendt@gmail.com>
	<gh1j5m$b66$1@ger.gmane.org>
	<20081201224927.8cf44c69.mschwendt@gmail.com>
	<gh1n8o$qt0$1@ger.gmane.org>
	<1228185055.5593.2718.camel@beck.corsepiu.local>
Message-ID: <20081202094905.6d18763b.mschwendt@gmail.com>

On Tue, 02 Dec 2008 03:30:55 +0100, Ralf Corsepius wrote:

> On Mon, 2008-12-01 at 23:08 +0100, Kevin Kofler wrote:
> > Michael Schwendt wrote:
> > > I think I've seen %_exec_prefix/%_target before (I can imagine that trying
> > > to change that might result in symlink-hell), but a root-level directory
> > > is strange. That one is also "established practice"?
> GCC uses $PREFIX/$TARGET for cross-toolchains.
> 
> So, if a cross-toolchain uses --target=spu these files land in /usr/spu
> 
> Whether using --target=spu is a clever idea and whether this makes sense
> is a different matter. IMNSHO, it is none of both.
> 
> > The top-level /spu (not in /usr) is weird indeed, I'm not sure where this
> > comes from.
> /spu is nonsense. I'd suggest to have FESCO block and withdraw this
> package.

As pointed out in another message, only /usr/spu remains currently.

Though, there's an indication that temporarily some packages created bad
paths unintentionally, because of broken RPM macro values in %files.
This needs extra checks.



From rawhide at fedoraproject.org  Tue Dec  2 12:39:50 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue,  2 Dec 2008 12:39:50 +0000 (UTC)
Subject: rawhide report: 20081202 changes
Message-ID: <20081202123950.D10681F825D@releng2.fedora.phx.redhat.com>

Compose started at Tue Dec  2 06:01:08 UTC 2008

New package log4cxx
        A port to C++ of the Log4j project
New package perl-B-Hooks-EndOfScope
        Execute code after scope compilation finishes
New package perl-Catalyst-Log-Log4perl
        Log::Log4perl logging for Catalyst
New package perl-Catalyst-Plugin-Session-Store-File
        File storage backend for session data
New package perl-MooseX-ConfigFromFile
        An abstract Moose role for setting attributes from a configfile
New package perl-rpm-build-perl
        Perl compiler backend to extract Perl dependencies
New package pympdtouchgui
        PyMPDTouchGUI is a client for MPD that is usable via touchscreen
Removed package seahorse
Updated Packages:

Cython-0.10.2-1.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.10.2-1
- Update to 0.10.2

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.1-2
- Rebuild for Python 2.6


VLGothic-fonts-20081029-1.fc10
------------------------------
* Wed Oct 29 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 20081029-1
- update to 20081029 release.


alsa-utils-1.0.18-6.fc10
------------------------
* Fri Nov 21 17:00:00 2008 Jaroslav Kysela <jkysela at redhat.com> 1.0.18-6
- fix alsactl restore when driver has more controls than asound.state file

* Tue Nov  4 17:00:00 2008 Jaroslav Kysela <jkysela at redhat.com> 1.0.18-5
- fixed building

* Tue Nov  4 17:00:00 2008 Jaroslav Kysela <jkysela at redhat.com> 1.0.18-4
- updated to 1.0.18 final
- updated alsa-info.sh script


amarok-1.98-1.fc10
------------------
* Fri Nov 21 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.98-1
- amarok-1.98 (2rc1)


appliance-tools-003.9-1.fc10
----------------------------
* Fri Nov 14 17:00:00 2008 David Huff <dhuff at redhat.com> - 003.9
- Fixed bug in globbing files under a directory (pmyers)

* Fri Nov 14 17:00:00 2008 David Huff <dhuff at redhat.com> - 003.8
- Fixed bug that causes appliance-creator to stacktrace when -i is omitted (pmyers)

* Wed Nov 12 17:00:00 2008 David Huff <dhuff at redhat.com> - 003.7
- Fixed problem with -i only taking one file, now can include a dir
- Fixed versioning of source file, ie. 003.7

* Mon Nov 10 17:00:00 2008 David Huff <dhuff at redhat.com> - 003-6
- Fixed broken dependencies for specific archs where qemu is not available

* Fri Nov  7 17:00:00 2008 David Huff <dhuff at redhat.com> - 003-5
- Added error for Incomplete partition info (#465988)
- Fixed problem with long move operations (#466278)
- Fixed error converting disk formats (#464798)
- Added support for tar archives (#470292)
- Added md5/sha256 disk signature support (jboggs)
- Modified zip functionality can now do with or with out 64bit ext.
- Added support for including extra file in the package (#470337)
- Added option for -o outdir, no longer uses name
- OutPut is now in a seprate dir under appliance name


audacity-1.3.5-0.8.beta.fc10
----------------------------
* Tue Nov  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.3.5-0.8.beta
- insert a guard in ImportFLAC next to the import assertion

* Tue Nov  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.3.5-0.7.beta
- BR vamp-plugin-sdk-devel
- no longer build with included Vamp API, also drop Vamp multilib patch


audit-1.7.9-1.fc10
------------------
* Wed Nov  5 17:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.9-1
- New upstream release


blender-2.48a-4.fc10
--------------------
* Mon Nov  3 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 2.48a-4
- Fix security issue (#469655, CVE-2008-4863)


bluez-4.21-1.fc11
-----------------
* Mon Dec  1 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.21-1
- Update to 4.21


bluez-gnome-1.8-9.fc11
----------------------
* Mon Dec  1 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-9
- Add patches to move the PIN quirks to an external database


bro-1.4-0.3.20080804svn.fc10
----------------------------
* Mon Nov 10 17:00:00 2008 Daniel Kopecek <dkopecek at redhat.com> - 1.4-0.3.20080804svn
- Removed bind-devel from BuildRequires


cel-1.2-4.fc11
--------------
* Mon Dec  1 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.2-4
- Fix unowned directories (rh 473632)

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2-3
- Rebuild for Python 2.6


certmaster-0.23-2.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Adrian Likins <alikins at redhat.com> - 0.23-2
- rev for python2.6


cfdg-fe-0.1-2.fc11
------------------
* Mon Dec  1 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 0.1-2
- Directory ownership fix, BZ 473634.


check-0.9.5-3.fc11
------------------
* Mon Dec  1 17:00:00 2008 Jerry James <loganjerry at gmail.com> - 0.9.5-3
- Fix unowned directory (bz 473635)
- Drop unnecessary BuildRequires
- Replace patches with addition of -fPIC to CFLAGS in the spec file
- Add some more documentation files


chess-1.0-21.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.0-21
- Use dejavu instead of bitstream-vera font (rh 473564)


cloudy-07.02.01-5.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> 07.02.01-5
- Directory not owned by package (bz #473639)


cluster-2.99.12-2.fc10
----------------------
* Fri Nov 21 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 2.99.12-2
- import several important fixes from upstream.
- fix_fence_xvmd: make fence xvmd work with recent versions of libvirt
- fix_make_args*: handle correctly args to fence agents
- fix_monlist: make LDOM and ePowerSwitch agents work
- fix_qdisk: make qdisk work again when device= is used in config.
- fix_rgmanager_build*: rgmanager was not build correctly due to a CFLAGS leak.
- fix_shell_quoting: fix quoting of OCF variable.
- fix_smb: fix small (user invisible) regression.
- fix_xmlloader*: fix severe regression in xml parsing.


compiz-0.7.8-5.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.7.8-5
- Patch and rebuild for new libplasma, BR plasma-devel


cpuspeed-1.5-2.fc10
-------------------
* Mon Nov  3 17:00:00 2008 Jarod Wilson <jarod at redhat.com> 1.5-2
- Revive p4-clockmod support, for passive cooling only, when
  all else fails on Intel boxes


crontabs-1.10-25.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> 1.10-25
- Added /etc/cron.{hourly,daily,weekly,monthly} dirs again. bz#473353


deskbar-applet-2.25.1-4.fc11
----------------------------
* Mon Dec  1 17:00:00 2008 Luke Macken <lmacken at redhat.com> - 2.25.1-4
- Require python-simplejson for the google search handler

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.25.1-3
- Rebuild for Python 2.6


devhelp-0.22-1.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 0.22-1
- Update to 0.22
- Add BR: WebKit-gtk-devel

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.21-4
- Rebuild for Python 2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.21-3
- Tweak description


digikam-0.10.0-0.8.beta6.fc11
-----------------------------
* Mon Dec  1 17:00:00 2008 Rex Dieter <rdieter at fedoraprojectd.org> - 0.10.0-0.8.beta6
- omit kde42 (icon) conflicts (F-10+)

* Tue Nov 25 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.10.0-0.7.beta6
- digikam-0.10.0-beta6
- lensfun support


diveintopython-5.4-14.fc10
--------------------------

drupal-cck-6.x.2.0-3.fc10
-------------------------
* Wed Nov  5 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 6.x.2.0-3
- New upstream, fixes DRUPAL-SA-2008-069.

* Tue Nov  4 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 6.x.2.0-2.rc10
- New upstream.


drupal-date-6.x.2.0-2.rc4.fc10
------------------------------
* Tue Nov  4 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 6.x.2.0-2.rc4
- Update to new version.


drupal-views-6.x.2.1-1.fc10
---------------------------
* Tue Nov  4 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 6.x.2.1-1
- New upstream.


dvipng-1.11-1.fc10
------------------
* Thu Nov  6 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 1.11-1
- Update to version 1.11


em8300-0.17.2-1.fc10
--------------------
* Sun Nov  9 17:00:00 2008 Felix Kaechele <felix at fetzig dot org> - 0.17.2-1
- 0.17.2


emacs-common-ebib-1.7.2-1.fc10
------------------------------
* Thu Nov  6 17:00:00 2008 RPM building account <jonathan.underwood at gmail.com> - 1.7.2-1
- Update to version 1.7.2
- Fix Source0 URL
- Correct email adresses in spec file changelog
- Remove ebib-1.5.2-info-fix.patch


etherboot-5.4.4-7.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Eduardo Habkost <ehabkost at redhat.com> - 5.4.5-7
- Updated prebuilt-binaries tarball to binaries from 5.4.5-6

* Mon Dec  1 17:00:00 2008 Eduardo Habkost <ehabkost at redhat.com> - 5.4.5-6
- New subpackages: -zroms and -zroms-kvm

* Mon Dec  1 17:00:00 2008 Eduardo Habkost <ehabkost at redhat.com> - 5.4.4-5
- Make packages own /usr/share/etherboot directory


evolution-data-server-2.25.2-1.fc11
-----------------------------------
* Mon Dec  1 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.2-1.fc11
- Update to 2.25.2


evolution-sharp-0.18.1-1.fc10
-----------------------------
* Fri Nov  7 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 0.18.1-1.fc10
- Update to 0.18.1


fedora-package-config-apt-10-3
------------------------------
* Mon Nov 24 17:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 10-3
- Update to F10.

* Wed May 21 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 9.89-2
- fix license tag


fedora-package-config-smart-10-15
---------------------------------
* Mon Nov 24 17:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 10-15
- Switch to stable release.


florence-0.3.0-2.fc10
---------------------
* Wed Nov 19 17:00:00 2008 Simon Wesp <cassmodiah at fedoraproject.org> - 0.3.0-2
- Correct URL
- Correct categories of desktop-file (Bug #472174)


fotoxx-5.7-1.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 5.7-1
- Rebuild for 5.7


freefem++-2.24-5.2.fc11
-----------------------
* Wed Oct  1 18:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> 2.24-5.2
- fix encoding of some doc files
- fix author's name in COPYRIGHT


freeradius-2.1.1-6.fc10
-----------------------
* Mon Nov 24 17:00:00 2008 John Dennis <jdennis at redhat.com> - 2.1.1-6
- add readline-devel BuildRequires

* Fri Nov 21 17:00:00 2008 John Dennis <jdennis at redhat.com> - 2.1.1-3
- make spec file buildable on RHEL5.2 by making perl-devel a fedora only dependency.
- remove diaupadmin packages, it's not well supported and there are problems with it.


fslint-2.28-3.fc11
------------------
* Mon Dec  1 17:00:00 2008 P??draig Brady <P at draigBrady.com> - 2.28-3
- Remove redundant py[co] files (dependency on python(abi))

* Mon Nov 24 17:00:00 2008 P??draig Brady <P at draigBrady.com> - 2.28-2
- Update summary as per Richard Hughes' request


fsvs-1.1.17-1.fc10
------------------
* Mon Nov  3 17:00:00 2008 David Fraser <davidf at sjsoft.com> 1.1.17-1
- Upgraded to 1.1.17
- Updated home page and download location


ftp-0.17-49.fc11
----------------
* Mon Dec  1 17:00:00 2008 Jiri Skala <jskala at redhat.com> - 0.17-49
- Resolves: #473491  unchecked malloc


func-0.23-2.fc11
----------------
* Mon Dec  1 17:00:00 2008 Adrian Likins <alikins at redhat.com> - 0.23-2
- rev for python 2.6

* Fri Jul 18 18:00:00 2008 Adrian Likins <alikins at redhat.com> - 0.23-1
- remove requirement for pyyaml, add python-simplejson

* Fri Jul 11 18:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 0.23-1
- (for ssalevan) adding in mapping/delegation tools

* Mon Jul  7 18:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 0.22-1
- packaged func-transmit script


games-menus-0.3.2-2.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.3.2-2
- Fix minor spelling error in Italian translation (rh 473385)


ghc-6.10.1-6.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 6.10.1-6
- update macros.ghc to latest proposed revised packaging guidelines:
  - use runghc
  - drop trivial cabal_build and cabal_haddock macros
  - ghc_register_pkg and ghc_unregister_pkg replace ghc_preinst_script,
    ghc_postinst_script, ghc_preun_script, and ghc_postun_script
- library templates prof subpackage requires main library again
- make cabal2spec work on .cabal files too, and
  read and check name and version directly from .cabal file
- ghc-prof does not need to own libraries dirs owned by main package


ghc-zlib-0.5.0.0-3.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.5.0.0-3
- sync with lib template:
  - add build_prof and build_doc
  - prof requires main package
  - update scriptlet macro names


gimp-2.6.3-2.fc11
-----------------

glib2-2.19.2-1.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.19.2-1
- Update to 2.19.2

* Mon Dec  1 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.19.1-2
- Update to 2.19.1


gmm-3.1-1.fc11
--------------
* Mon Dec  1 17:00:00 2008 Steven Parrish <smparrish at shallowcreek.net> 3.1-1
- New upstream release


gnumeric-1.8.2-4.fc10
---------------------
* Mon Nov 17 17:00:00 2008 Huzaifa Sidhpurwala <huzaifas at redhat.com> 1:1.8.2-4
- Version bump

* Mon Nov 17 17:00:00 2008 Huzaifa Sidhpurwala <huzaifas at redhat.com> 1:1.8.2-3
- Changed the desktop patch


gpicview-0.1.10-2.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Marc Wiriadisastra <marc at mwiriadi.id.au> - 0.1.10-2
- Rebuild of gpicview after updates from Patrice. Thanks and credit
 go to Patrice.


gtkhtml3-3.25.2-1.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 3.25.2-1.fc11
- Update to 3.25.2


guidance-power-manager-4.1.3-1.fc10
-----------------------------------
* Fri Nov 14 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


gupnp-av-0.2.1-6.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.2.1-6
- Fix directory ownership


hal-info-20081127-1.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 20081127-1
- Update to latest upstream release


hamster-applet-2.24.2-2.fc11
----------------------------
* Mon Dec  1 17:00:00 2008 Mads Villadsen <maxx at krakoa.dk> - 2.24.2-2
- Update to latest upstream release

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.24.0-2
- Rebuild for Python 2.6


hedgewars-0.9.7-1.fc10
----------------------
* Tue Nov  4 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.9.7-1
- New upstream release 0.9.7


homestead-0.95-1.fc10
---------------------

incollector-1.0-6.fc9.1
-----------------------
* Mon Nov 17 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Rebuild against newer gtk-sharp2 (bug 468055)


inn-2.4.5-5.fc11
----------------
* Mon Dec  1 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 2.4.5-5
- do own /usr/include/inn in devel package (#473922)


irda-utils-0.9.18-6.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 0.9.18-6
- use macros, fix Source0


jabberpy-0.5-0.17.fc10
----------------------

joda-time-1.5.2-10.tzdata2008i.fc10
-----------------------------------
* Fri Oct 31 18:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 1.5.2-10.tzdata2008i
- New tzdata.


kazehakase-0.5.6-1.fc10
-----------------------

kchmviewer-4.0-0.4.beta3.fc10.1
-------------------------------

kcoloredit-4.1.3-1.fc10
-----------------------
* Fri Nov 14 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kde-l10n-4.1.3-1.fc10
---------------------
* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com>  4.1.3-1
- 4.1.3


kdeaccessibility-4.1.3-1.fc10
-----------------------------
* Tue Nov 11 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- KDE 4.1.3


kdeartwork-4.1.3-3.fc10
-----------------------
* Thu Nov 27 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.3-3
- reenable webcollage since xscreensaver now has a sane default setting for it

* Tue Nov 18 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-2
- drop webcollage bz#461926

* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- KDE 4.1.3


kdebase-runtime-4.1.80-5.fc11
-----------------------------
* Mon Dec  1 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-5
- don't ship libkwalletbackend.so devel symlink (conflicts with kdelibs3-devel,
  and should be in a -devel package if it gets shipped)


kdebase-workspace-4.1.80-9.fc11
-------------------------------
* Tue Dec  2 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-9
- keep libweather_ion.so in libdir

* Tue Dec  2 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-8
- keep libplasmaclock.so in libdir

* Mon Dec  1 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-7
- rebuild for Python 2.6


kdebindings-4.1.80-4.fc11
-------------------------
* Mon Dec  1 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-4
- don't require kdebase-workspace(-devel)

* Thu Nov 27 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-3
- BR plasma-devel instead of kdebase-workspace-devel
- disable smoke,ruby (for now, busted)

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast

* Mon Nov 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-2.1
- respin (qscintilla)

* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kdeedu-4.1.80-5.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-5
- BR plasma-devel instead of kdebase-workspace-devel
- fix file list

* Sun Nov 30 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.80-4
- adjust file lists (and fix build)

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.80-1
- 4.1.80
- BR cmake 2.6.2
- BR python-devel
- make install/fast
- drop kbruch and related files from filelists

* Thu Nov 20 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-3
- readd kbruch, has been reenabled in 4.1.80
- remove kpercentage, has been dropped in favor of percentage exercises newly
  added to kbruch

* Mon Nov 10 17:00:00 2008 Luk???? Tinkl <ltinkl at redhat.com> 4.1.3-1
- KDE 4.1.3


kdegames-4.1.3-1.fc10
---------------------
* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kdegraphics-4.1.80-3.fc11
-------------------------
* Mon Dec  1 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.80-3
- Obsoletes: libkdcraw libkexiv2 libkipi (F10+)
- cleanup Obsoletes: kdegraphics-extras

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 7:4.1.72-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast

* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kdemultimedia-4.1.3-1.fc10
--------------------------
* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com>  4.1.3-1
- 4.1.3


kdenetwork-4.1.80-3.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 7:4.1.80-4
- fix up %description
- versioned Obsoletes
- scriptlets fixes
- BR: plasma-devel

* Fri Nov 28 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> 7:4.1.80-3
- fix build (updated file lists)

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> 7:4.1.72-1
- 4.1.80
- BR cmake 2.6
- make install/fast

* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kdepim-4.1.80-3.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.80-3
- kdepim-4.1.80-libqgpgme-link-fix.patch
  fix libqgpgme linking errors

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast
- kdepim-4.1.2-kabcdistlistupdater.patch upstreamed

* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kdeplasma-addons-4.1.3-1.fc10
-----------------------------
* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kdesdk-4.1.80-3.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-3
- BR plasma-devel instead of kdebase-workspace-devel
- don't require kdebase-workspace
- rebase Lokalize quit menu patch
- BR libical-devel

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> 4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast
- kdesdk-4.1.2-kdecore.patch upstreamed, dropped

* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kdetoys-4.1.3-1.fc10
--------------------
* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kdeutils-4.1.80-3.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-3
- BR plasma-devel instead of kdebase-workspace-devel

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast

* Wed Nov 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


kexec-tools-2.0.0-6.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Neil Horman <nhorman at redhat.com> - 2.0.0.6
- adding makedumpfile man page updates (bz 473212)

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.0-5
- Rebuild for Python 2.6

* Wed Nov  5 17:00:00 2008 Neil Horman <nhorman at redhat.com> - 2.0.0-3
- Correct source file to use proper lang package (bz 335191)

* Wed Oct 29 18:00:00 2008 Neil Horman <nhorman at redhat.com> - 2.0.0-2
- Fix mkdumprd typo (bz 469001)


kgrab-0.1.1-11.fc10
-------------------
* Tue Nov 11 17:00:00 2008 Sebastian Vahl <fedora at deadbabylon.de> 0.1.1-11
- 4.1.3


kiconedit-4.1.3-2.fc10
----------------------
* Mon Nov 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.3-2
- scriptlet, dependency fixes

* Sun Nov  9 17:00:00 2008 Sebastian Vahl <fedora at deadbabylon.de> 4.1.3-1
- 4.1.3


konq-plugins-4.1.3-2.fc10
-------------------------
* Tue Nov 11 17:00:00 2008 Sebastian Vahl <fedora at deadbabylon.de> 4.1.3-2
- include adblock language files

* Tue Nov 11 17:00:00 2008 Sebastian Vahl <fedora at deadbabylon.de> 4.1.3-1
- 4.1.3


koules-1.4-3.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 1.4-3
- Own /usr/libexec/koules (#473931)


ksplice-0.9.4-1.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 0.9.4-1
- New upstream release


ktorrent-3.1.5-1.fc10
---------------------
* Mon Nov 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.1.5-1
- ktorrent-3.1.5 (#469870)


latexmk-4.02b-1.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Jerry James <loganjerry at gmail.com> - 4.02b-1
- Update to 4.02b to fix bz 473430


lensfun-0.2.3-2.fc10
--------------------

libcaptury-0.3.0-0.2.20080323gitcca4e3c.fc11
--------------------------------------------
* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.3.0-0.2.20080323gitcca4e3c
- Include /usr/include/captury directory.


libhangul-0.0.8-2.fc10
----------------------
* Tue Oct 28 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.0.8-2
- add hanjac and hanja.bin to filelists

* Tue Oct 28 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.0.8-1
- update to 0.0.8 (#468817)


libnasl-2.2.11-2.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.2.11-2
- in doc pkg: include missing dirs and mark files as %doc


libnfnetlink-0.0.39-3.fc10
--------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.0.39-3
- Fix Patch0:/%patch mismatch.


libpng-1.2.33-1.fc10
--------------------
* Sun Nov  2 17:00:00 2008 Tom Lane <tgl at redhat.com> 2:1.2.33-1
- Update to libpng 1.2.33


libsoup-2.25.2-1.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.2-1
- Update to 2.25.2


libspe2-2.3.0.135-3.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Jochen Roth <jroth at linux.vnet.ibm.com> 2.3.0.135-3
- spu-binutils now owns /usr/spu directory. (BZ 473666)
- libspe2-devel now owns /usr/spu/include directory. (BZ 473666)


libwfut-0.2.1-2.fc10
--------------------
* Tue Nov  4 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.2.1-2
- Removing rpath

* Tue Nov  4 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.2.1-1
- Update to 0.2.1


libxml++-2.23.2-2.fc11
----------------------
* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.23.2-2
- Include unowned directories


lynx-2.8.6-18.fc10
------------------
* Fri Nov  7 17:00:00 2008 Jiri Moskovcak <jmoskovc at redhat.com> - 2.8.6-18
- Fixed CVE-2008-4690 lynx: remote arbitrary command execution.
  via a crafted lynxcgi: URL (thoger)


m17n-contrib-1.1.8-2.fc10
-------------------------
* Wed Nov  5 17:00:00 2008 Parag Nemade <pnemade at redhat.com> -1.1.8-2.fc10
- Resolves: Bug 466748-[or_IN] Needed ZWJ & ZWNJ for Oriya Inscript keymap


man-pages-cs-0.17.20080113-3.fc11
---------------------------------
* Mon Dec  1 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 0.17.20080113-3
- update part of coreutils man-pages (patches are from Kamil Dudka)


maven-wagon-1.0-0.1.a5.3.5.fc11
-------------------------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0:1.0-0.1.a5.3.5
- include missing dir below _docdir


maxima-5.16.3-4.fc10
--------------------
* Wed Nov  5 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 5.16.3-4
- respin (sbcl)


mcpp-2.7.2-1.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Kiyoshi Matsui <kmatsui at t3.rim.or.jp> 2.7.2-1
- Upstream new release.


mediatomb-0.11.0-4.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.11.0-4
- Include /usr/share/mediatomb directory.


mercurial-1.0.2-3.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 1.0.2-3
- Remove BR asciidoc
- Use macro for python executable

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.2-2
- Rebuild for Python 2.6


mkdst-0.9-2.fc11
----------------
* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.9-2
- include /usr/share/mkdst directory


mkvtoolnix-2.4.0-3.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> 2.4.0-3
- dropped obsolete mkvtoolnix-gcc43.patch

* Mon Dec  1 17:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> 2.4.0-2
- fixed boost detection on ppc64 (and sparc64) (bug #473976)

* Sun Nov 30 17:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> 2.4.0-1
- updated to 2.4.0
- rebased patch
- added new BRs
- added missing Requires: hicolor-icon-theme for hicolor icon dirs
- build and include more tools


monosim-1.3.0.2-1.fc9.1
-----------------------
* Mon Nov 17 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Rebuild against newer gtk-sharp2 (bug 468055)


monotorrent-0.50-2.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.50-2
- include unowned directory


mtools-4.0.0-1.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Adam Tkac <atkac redhat com> 4.0.0-1
- updated to 4.0.0


muine-0.8.10-1.fc11
-------------------
* Tue Dec  2 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.8.10-1
- Update to final 0.8.10 release
- Add patch to workaround build bug with mono 2.0, see gnome bz #555908


mypaint-0.5.1-2.fc10
--------------------
* Mon Nov  3 17:00:00 2008 Marc Wiriadisastra <marc at mwiriadi.id.au> - 0.5.1-2
- Add new website and download link
- Fix mydrawwidget location for F-10


nabi-0.99.2-1.fc10
------------------
* Tue Oct 28 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.99.2-1
- update to 0.99.2 release
- no longer need nabi-makefile.patch and theme-removal.sh
- add icon to xinput conf


ncompress-4.2.4-51.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 4.2.4-51
- check malloc success (#473488)
- fix few compiler warnings, free malloc memory before exit
- new URL


net-snmp-5.4.2.1-5.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Jan Safranek <jsafranek at redhat.com> 5.4.2.1-5
- fix rpm ownership of all created directories (#473582)

* Mon Dec  1 17:00:00 2008 Jan Safranek <jsafranek at redhat.com> 5.4.2.1-4
- Rebuild for fixed rpm (#473420)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:5.4.2.1-3
- Rebuild for Python 2.6

* Mon Nov  3 17:00:00 2008 Jan Safranek <jsafranek at redhat.com> 5.4.2.1-1
- explicitly require the right version and release of net-snmp and
  net-snmp-libs
- update to net-snmp-5.4.2.1 to fix CVE-2008-4309


nfs-utils-1.1.4-5.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-5
- Make sure /proc/fs/nfsd exists when the nfs init script
  does the exports (bz 473396)
- Fixed typo in nfs init script that caused rpc.rquotad daemons
  to be started but not stoppped (bz 473929)


nspluginwrapper-1.1.8-1.fc11
----------------------------
* Mon Dec  1 17:00:00 2008 Martin Stransky <stransky at redhat.com> 1.1.8-1
- Updated to 1.1.8
- Removed already upstreamed patches


ochusha-0.5.99.68-0.4.cvs20081201T1430.fc11
-------------------------------------------
* Mon Dec  1 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


openoffice.org-3.0.1-12.1.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-12.1
- Move to 3.0.1 preparation milestones
- Resolves: rhbz#473553 font package splits
- drop integrated workspace.impress163.patch
- drop integrated workspace.dba301a.patch
- drop integrated openoffice.org-3.0.0.ooo95341.cppcanvas.patch

* Thu Nov 27 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.12
- Require extra Norwegian hyphenators and thesauri


parprouted-0.70-3.fc10
----------------------

perl-File-Comments-0.07-1.fc10
------------------------------

perl-Mail-Box-2.084-1.fc10
--------------------------
* Tue Nov  4 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.084-1
- update to 2.084


perl-Net-SSH-Perl-1.33-2.fc10
-----------------------------

perl-PDF-API2-0.72.003-1.fc11
-----------------------------
* Mon Dec  1 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.72.003-1
- v 0.72.003


perl-XML-LibXSLT-1.66-2.fc10
----------------------------
* Mon Nov  3 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 1.66-2
- require XML::LibXML of the same version


php-Smarty-2.6.20-2.fc10
------------------------
* Sun Nov  2 17:00:00 2008 Christopher Stone <chris.stone at gmail.com> 2.6.20-2
- Add security patch (bz #469648)
- Add RHL dist tag conditional for Requires


pngcrush-1.6.10-3.fc10
----------------------

pngnq-0.5-5.fc10
----------------

policycoreutils-2.0.60-1.fc11
-----------------------------
* Mon Dec  1 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.60-1
- Update to upstream
	* semanage: use semanage_mls_enabled() from Stephen Smalley.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.59-2
- Rebuild for Python 2.6


postgresql-8.3.5-1.fc10
-----------------------
* Sun Nov  2 17:00:00 2008 Tom Lane <tgl at redhat.com> 8.3.5-1
- Update to PostgreSQL 8.3.5.
- Improve display from init script's initdb action, per Michael Schwendt


powertop-1.10-1.fc10
--------------------
* Thu Nov  6 17:00:00 2008 Josh Boyer <jwboyer at gmail.com> - 1.10-1
- Update to latest release
- Drop upstreamed patch

* Wed May 21 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.9-4
- fix license tag


printoxx-1.7-1.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 1.7-1
- Rebuild for 1.7


pybliographer-1.2.12-1.fc11
---------------------------
* Mon Dec  1 17:00:00 2008 Zoltan Kota <z.kota at gmx.net> - 1.2.12-1
- update to 1.2.12
- drop patch, fixed upstream


pypoker-eval-135.0-3.fc11
-------------------------
* Mon Dec  1 17:00:00 2008 Christopher Stone <chris.stone at gmail.com> 135.0-3
- Add patch for python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 135.0-2
- Rebuild for Python 2.6


pyroom-0.3.1.1-4.fc10
---------------------
* Sun Nov  2 17:00:00 2008 Sven Lankes <sven at lank.es> - 0.3.1.1-4
- add manpage to package

* Sat Nov  1 18:00:00 2008 Sven Lankes <sven at lank.es> - 0.3.1.1-3
- add %U to .desktop-file

* Sat Nov  1 18:00:00 2008 Sven Lankes <sven at lank.es> - 0.3.1.1-2
- add missing BR

* Sat Nov  1 18:00:00 2008 Sven Lankes <sven at lank.es> - 0.3.1.1-1
- new upstream Version (closes bz #464325)
- currently doesn't include any translations
- reworked specfile as upstream now supplies a setup.py


python-cherrypy2-2.3.0-6.fc11
-----------------------------
* Mon Dec  1 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> 2.3.0-6
- Set tests to be non-interactive via the commandline instead of a patch.
- Patch to fix test errors with Python-2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.3.0-5
- Rebuild for Python 2.6


python-virtualenv-1.3.1-3.fc11
------------------------------
* Mon Dec  1 17:00:00 2008 Steve 'Ashcrow' Milner <me at stevemilner.org> - 1.3.1-3
- Added missing dependencies.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.1-2
- Rebuild for Python 2.6


qt-4.4.3-6.fc10
---------------
* Wed Nov 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.4.3-6
- qt-copy-patches-20081112

* Tue Nov 11 17:00:00 2008 Than Ngo <than at redhat.com> 4.4.3-5
- drop 0256-fix-recursive-backingstore-sync-crash.diff, it's
  included in qt-copy-pathes-20081110

* Mon Nov 10 17:00:00 2008 Than Ngo <than at redhat.com> 4.4.3-3
- apply 0256-fix-recursive-backingstore-sync-crash.diff

* Mon Nov 10 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.4.3-4
- qt-copy-patches-20081110


rcsslogplayer-13.0.0-1.fc10
---------------------------
* Wed Nov  5 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.0.0-1
- Updated to the new released version (13.0.0)


rcssmonitor-13.0.0-2.fc10
-------------------------
* Wed Nov  5 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.0.0-2
- New release because of incorrect tagging.

* Wed Nov  5 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.0.0-1
- Updated to the new released version: 13.0.0


revisor-2.1.3-1.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.1.3-1
- Rebuild for Fedora 10
- Include modisolinux and modreuseinstaller

* Wed Oct 22 18:00:00 2008 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.1.2-2
- Fix anaconda removing splittree.py
- Latest rebuild
- Minor bugfixes (#344 pkgorder traceback)
- Add SELinux Check


rpm-4.6.0-0.rc2.5
-----------------
* Mon Dec  1 17:00:00 2008 Jindrich Novy <jnovy at redhat.com>
- include rpmfileutil.h from rpmmacro.h, unbreaks
  net-snmp (#473420)

* Sun Nov 30 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- rebuild for python 2.6


rpmlint-0.85-2.fc10
-------------------
* Thu Oct 30 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.85-2
- Apply upstream patch to load all *config from /etc/rpmlint.


rrdtool-1.3.4-4.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Jarod Wilson <jarod at redhat.com> 1.3.4-4
- Update dejavu font dependencies (#473551)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.4-3
- Rebuild for Python 2.6


sbcl-1.0.22-1.fc10
------------------
* Thu Oct 30 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0.22-1
- sbcl-1.0.22


scim-hangul-0.3.2-5.fc11
------------------------
* Tue Dec  2 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.3.2-5
- own datadir/scim/hangul


scipy-0.6.0-8.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-8
- Rebuild for Python 2.6


sectool-0.9.1-6
---------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.9.1-6
- Include /usr/share/pixmaps/sectool directory in -gui package.

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.1-5
- Rebuild for Python 2.6


selinux-policy-3.5.13-26.fc10
-----------------------------
* Tue Nov 25 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-26
- Allow dhcpc to read ypbind.pid

* Tue Nov 25 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-25
- Allow postfix_smtpd to getattr on directories and file systems

* Mon Nov 24 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-24
- Fix certwatch creating cache

* Mon Nov 24 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-23
- Add afs_client port definition

* Tue Nov 18 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-22
- Allow ftp to search fusefs

* Fri Nov 14 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-21
- Allow sambagui to use nsswitch

* Mon Nov 10 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-20
- Change default boolean settings for xguest
- Allow mount to r/w image files
- Fix labes for several libraries that need textrel_shlib_t
- portreserve needs to be able to sendrecv unlabeled_t
- Fix Kerberos labeling
- Fix cups printing on hp printers
- Allow relabeling on blk devices on the homedir
- Allow nslpugin to r/w inodefs


sepostgresql-8.3.5-2.1183.fc10
------------------------------
* Wed Nov  5 17:00:00 2008 <kaigai at kaigai.gr.jp> - 8.3.5-2.1182
- upgrade base PostgreSQL version 8.3.4->8.3.5
- backport cumulative bugfixes from 8.4devel series


setools-3.3.5-4.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 3.3.5-4
- Include %tcllibdir directory in -libs-tcl package.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.3.5-3
- Rebuild for Python 2.6

* Wed Sep 17 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> 3.3.5-2
- fix building in sparc and s390 arches


sextractor-2.5.0-7.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.5.0-7
- Include unowned directory.


sip-redirect-0.1.2-2.fc10
-------------------------

siril-0.8-5.fc11
----------------
* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.8-5
- Include unowned directories


ski-1.3.2-6.fc10
----------------
* Sat Nov  1 18:00:00 2008 Dan Horak <dan[at]danny.cz> 1.3.2-6
- rename the ppc patch to nohayes and add other arches without TIOC[GS]HAYESESP


sleuthkit-3.0.0-1.fc10
----------------------
* Tue Oct 28 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.0.0-1
- Update to 3.0.0 (final)


spu-binutils-2.19.50.0.1-1.fc11
-------------------------------
* Mon Dec  1 17:00:00 2008 Jochen Roth <jroth at linux.vnet.ibm.com> 2.19.50.0.1-1
- Rebase sources on 2.19.50.0.1 tarball. Update all patches, trimming
  those that are no longer needed.
- Add build-id patch to ensure that section contents are incorporated
  into a build id. (BZ 472152)

* Mon Dec  1 17:00:00 2008 Jochen Roth <jroth at linux.vnet.ibm.com> 2.18.50.0.9-10
- spu-binutils now owns /usr/spu

* Tue Nov  4 17:00:00 2008 Jochen Roth <jroth at linux.vnet.ibm.com> 2.18.50.0.9-9
- adopted to changes in binutils spec file:
- binutils-devel now requires zlib-devel (BZ 463101 comment 5).
- Fix complains on .gnu.linkonce.r relocations to their discarded
  .gnu.linkonce.t counterparts
- Fix %{_prefix}/include/bfd.h on 32-bit hosts due to the 64-bit BFD target
  support from 2.18.50.0.8-2 (BZ 468495)

* Tue Oct 28 18:00:00 2008 Jochen Roth <jroth at linux.vnet.ibm.com> 2.18.50.0.9-8
- ppc64 and ppc version of spu-binutils caused a file conflict (BZ 468996)
- fixed some rpmlint complaints


stk-4.3.1-7.fc11
----------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 4.3.1-7
- Include /usr/share/stk directory in main package.


subcommander-1.9.94-3.fc10
--------------------------
* Wed Nov  5 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 1.9.94-3
- Fix svn_ra_dav-1 issue

* Thu Sep 18 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 1.9.94-0
- New upstream release


sylpheed-2.6.0-0.1.rc.fc11
--------------------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.6.0-0.1.rc
- update to 2.6.0rc


telepathy-glib-0.7.19-1.fc11
----------------------------
* Mon Dec  1 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.19-1
- Update to 0.7.19.


thunderbird-2.0.0.18-1.fc10
---------------------------
* Wed Nov 19 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 2.0.0.18-1
- Update to 2.0.0.18


tomcat-native-1.1.16-1.fc10
---------------------------
* Thu Nov 20 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.1.16-1
- 1.1.16.


trustedqsl-1.11-3.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.11-3
- fix unowned directories


ufraw-0.14.1-2.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 0.14.1-2
- change license to GPLv2+


unbound-1.1.1-3.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 1.1.1-3
- We did not own the /etc/unbound directory (#474020)
- Fixed cvs anomalies


vavoom-1.29-1.fc10
------------------
* Tue Oct 28 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.29-1
- New upstream release 1.29


vim-7.2.060-1.fc11
------------------
* Mon Dec  1 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 7.2.060-1
- patchlevel 60

* Mon Nov 10 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 7.2.032-1
- patchlevel 32

* Mon Nov  3 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 7.2.026-2
- add more /usr/share/vim/vimfiles directories (#444387)

* Mon Nov  3 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 7.2.026-1
- patchlevel 26
- own some directories in /usr/share/vim/vimfiles (#469491)


virt-manager-0.6.0-5.fc11
-------------------------
* Mon Dec  1 17:00:00 2008 Cole Robinson <crobinso at redhat.com> - 0.6.0-5.fc10
- Fix spec for building on F9
- Update 'New VM' virt descriptions to be less black and white (bz 470563)

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-4
- Rebuild for Python 2.6


vte-0.19.1-1.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> 0.19.1-1
- Update to 0.19.1

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.17.4-2
- Rebuild for Python 2.6


wesnoth-1.4.6-1.fc10
--------------------
* Tue Nov 18 17:00:00 2008 Warren Togami <wtogami at redhat.com>
- split into -data noarch subpackage to save mirror space

* Mon Nov 17 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.4.6-1
- New upstream release.


wxMaxima-0.7.6-1.fc10
---------------------
* Wed Nov  5 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.7.6-1
- wxMaxima-0.7.6


wxsvg-1.0-2.fc10
----------------
* Thu Nov 20 17:00:00 2008 Stewart Adam <s.adam at diffingo.com> - 1.0-2
- Use autogen.sh to generate ./configure

* Thu Nov 13 17:00:00 2008 Stewart Adam <s.adam at diffingo.com> - 1.0-1
- Update to 1.0 final
- Patch out the internal expat build


xblast-2.10.4-6.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.10.4-6
- Replace bitstream-vera with dejave font (rh 473563)


xorg-x11-drv-ati-6.9.0-59.fc10
------------------------------
* Thu Nov 27 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-59
- radeon-6.9.0-exa-dst-a8-r100-r200.patch - fix dst a8 with dst alpha (#469556)

* Wed Nov 26 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-58
- radeon/kms: use a big hammer on rs4xx/rs6xx

* Tue Nov 25 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-57
- radeon/kms: hopefully fix some rs690 stability issues

* Sun Nov 23 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-56
- fix some issues with UTS and 2d state flush


xorg-x11-drv-nouveau-0.0.11-1.20081119git65b956f.fc10
-----------------------------------------------------
* Wed Nov 19 17:00:00 2008 Dave Airlie <airlied at redhat.com> 0.0.11-1.20081119git65b956f
- update to latest upstream snapshot


zlib-1.2.3-19.fc11
------------------
* Mon Dec  1 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 1.2.3-19
- fix 473490 - unchecked malloc


Summary:
Added Packages: 7
Removed Packages: 1
Modified Packages: 181
Broken deps for i386
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(libstartup-notification-1.0) >= 0:0.7
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(libxml-2.0)
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	devhelp-devel-0.22-1.fc11.i386 requires pkgconfig(gtk+-2.0)
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.i386 requires libltdl.so.3
	ettercap-gtk-0.7.3-26.fc10.i386 requires libltdl.so.3
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-data-server-devel-2.25.2-1.fc11.i386 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.i386 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	foobillard-3.0a-8.fc10.i386 requires dejavu-fonts
	freeradius-2.1.1-6.fc10.i386 requires libltdl.so.3
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	gtkhtml3-devel-3.25.2-1.fc11.i386 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	heartbeat-2.1.3-3.fc10.i386 requires libltdl.so.3
	heartbeat-gui-2.1.3-3.fc10.i386 requires libltdl.so.3
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.i386 requires libplasma.so.2
	kde-plasma-quickaccess-0.7.1-2.fc11.i386 requires libplasma.so.2
	kde-plasma-runcommand-0.7-1.fc11.i386 requires libplasma.so.2
	kdeplasma-addons-4.1.3-1.fc10.i386 requires libplasma.so.2
	kipi-plugins-0.2.0-0.4.beta3.fc10.i386 requires libkipi.so.5
	kphotoalbum-3.2-0.4.20081007svn.fc10.i386 requires libkipi.so.5
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libsoup-devel-2.25.2-1.fc11.i386 requires pkgconfig(gio-2.0)
	libsoup-devel-2.25.2-1.fc11.i386 requires pkgconfig(gobject-2.0)
	libxml++-devel-2.23.2-2.fc11.i386 requires pkgconfig(libxml-2.0)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	muine-devel-0.8.10-1.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-bitstring-2.0.0-5.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.i386 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pils-2.1.3-3.fc10.i386 requires libltdl.so.3
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.i386 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	seahorse-plugins-2.25.1-1.fc11.i386 requires libcryptui.so.0
	seahorse-plugins-2.25.1-1.fc11.i386 requires seahorse >= 0:2.23.6
	stonith-2.1.3-3.fc10.i386 requires libltdl.so.3
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	telepathy-glib-devel-0.7.19-1.fc11.i386 requires pkgconfig(gobject-2.0) >= 0:2.16
	vte-devel-0.19.1-1.fc11.i386 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	vte-devel-0.19.1-1.fc11.i386 requires pkgconfig(gobject-2.0)
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(libstartup-notification-1.0) >= 0:0.7
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(libxml-2.0)
	compiz-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(libstartup-notification-1.0) >= 0:0.7
	compiz-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(libxml-2.0)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	devhelp-devel-0.22-1.fc11.i386 requires pkgconfig(gtk+-2.0)
	devhelp-devel-0.22-1.fc11.x86_64 requires pkgconfig(gtk+-2.0)
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.x86_64 requires libltdl.so.3()(64bit)
	ettercap-gtk-0.7.3-26.fc10.x86_64 requires libltdl.so.3()(64bit)
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	evolution-data-server-devel-2.25.2-1.fc11.i386 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.i386 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	evolution-data-server-devel-2.25.2-1.fc11.x86_64 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.x86_64 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	foobillard-3.0a-8.fc10.x86_64 requires dejavu-fonts
	freeradius-2.1.1-6.fc10.x86_64 requires libltdl.so.3()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	gift-0.11.8.1-10.fc9.x86_64 requires libltdl.so.3()(64bit)
	gtkhtml3-devel-3.25.2-1.fc11.i386 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	gtkhtml3-devel-3.25.2-1.fc11.x86_64 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	heartbeat-2.1.3-3.fc10.i386 requires libltdl.so.3
	heartbeat-2.1.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	heartbeat-gui-2.1.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.i386 requires libplasma.so.2
	kde-plasma-lancelot-1.0.3-1.fc10.x86_64 requires libplasma.so.2()(64bit)
	kde-plasma-quickaccess-0.7.1-2.fc11.x86_64 requires libplasma.so.2()(64bit)
	kde-plasma-runcommand-0.7-1.fc11.x86_64 requires libplasma.so.2()(64bit)
	kdeplasma-addons-4.1.3-1.fc10.i386 requires libplasma.so.2
	kdeplasma-addons-4.1.3-1.fc10.x86_64 requires libplasma.so.2()(64bit)
	kipi-plugins-0.2.0-0.4.beta3.fc10.i386 requires libkipi.so.5
	kipi-plugins-0.2.0-0.4.beta3.fc10.x86_64 requires libkipi.so.5()(64bit)
	kphotoalbum-3.2-0.4.20081007svn.fc10.x86_64 requires libkipi.so.5()(64bit)
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libsoup-devel-2.25.2-1.fc11.i386 requires pkgconfig(gio-2.0)
	libsoup-devel-2.25.2-1.fc11.i386 requires pkgconfig(gobject-2.0)
	libsoup-devel-2.25.2-1.fc11.x86_64 requires pkgconfig(gio-2.0)
	libsoup-devel-2.25.2-1.fc11.x86_64 requires pkgconfig(gobject-2.0)
	libxml++-devel-2.23.2-2.fc11.i386 requires pkgconfig(libxml-2.0)
	libxml++-devel-2.23.2-2.fc11.x86_64 requires pkgconfig(libxml-2.0)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	muine-devel-0.8.10-1.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	muine-devel-0.8.10-1.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-bitstring-2.0.0-5.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlp5-5.10-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.x86_64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pils-2.1.3-3.fc10.i386 requires libltdl.so.3
	pils-2.1.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.x86_64 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	seahorse-plugins-2.25.1-1.fc11.x86_64 requires seahorse >= 0:2.23.6
	seahorse-plugins-2.25.1-1.fc11.x86_64 requires libcryptui.so.0()(64bit)
	stonith-2.1.3-3.fc10.i386 requires libltdl.so.3
	stonith-2.1.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	telepathy-glib-devel-0.7.19-1.fc11.i386 requires pkgconfig(gobject-2.0) >= 0:2.16
	telepathy-glib-devel-0.7.19-1.fc11.x86_64 requires pkgconfig(gobject-2.0) >= 0:2.16
	vte-devel-0.19.1-1.fc11.i386 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	vte-devel-0.19.1-1.fc11.i386 requires pkgconfig(gobject-2.0)
	vte-devel-0.19.1-1.fc11.x86_64 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	vte-devel-0.19.1-1.fc11.x86_64 requires pkgconfig(gobject-2.0)
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-devel-0.7.8-5.fc11.ppc requires pkgconfig(libstartup-notification-1.0) >= 0:0.7
	compiz-devel-0.7.8-5.fc11.ppc requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.ppc requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.ppc requires pkgconfig(libxml-2.0)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(libstartup-notification-1.0) >= 0:0.7
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(libxml-2.0)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	devhelp-devel-0.22-1.fc11.ppc requires pkgconfig(gtk+-2.0)
	devhelp-devel-0.22-1.fc11.ppc64 requires pkgconfig(gtk+-2.0)
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.ppc requires libltdl.so.3
	ettercap-gtk-0.7.3-26.fc10.ppc requires libltdl.so.3
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-data-server-devel-2.25.2-1.fc11.ppc requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.ppc requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	evolution-data-server-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	firstaidkit-plugin-grub-0.2.2-4.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc requires dejavu-fonts
	freeradius-2.1.1-6.fc10.ppc requires libltdl.so.3
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.ppc requires libltdl.so.3
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gtkhtml3-devel-3.25.2-1.fc11.ppc requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	gtkhtml3-devel-3.25.2-1.fc11.ppc64 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	heartbeat-2.1.3-3.fc10.ppc requires libltdl.so.3
	heartbeat-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	heartbeat-gui-2.1.3-3.fc10.ppc requires libltdl.so.3
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.ppc requires libplasma.so.2
	kde-plasma-lancelot-1.0.3-1.fc10.ppc64 requires libplasma.so.2()(64bit)
	kde-plasma-quickaccess-0.7.1-2.fc11.ppc requires libplasma.so.2
	kde-plasma-runcommand-0.7-1.fc11.ppc requires libplasma.so.2
	kdeplasma-addons-4.1.3-1.fc10.ppc requires libplasma.so.2
	kdeplasma-addons-4.1.3-1.fc10.ppc64 requires libplasma.so.2()(64bit)
	kipi-plugins-0.2.0-0.4.beta3.fc10.ppc requires libkipi.so.5
	kipi-plugins-0.2.0-0.4.beta3.fc10.ppc64 requires libkipi.so.5()(64bit)
	kphotoalbum-3.2-0.4.20081007svn.fc10.ppc requires libkipi.so.5
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libsoup-devel-2.25.2-1.fc11.ppc requires pkgconfig(gio-2.0)
	libsoup-devel-2.25.2-1.fc11.ppc requires pkgconfig(gobject-2.0)
	libsoup-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(gio-2.0)
	libsoup-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(gobject-2.0)
	libxml++-devel-2.23.2-2.fc11.ppc requires pkgconfig(libxml-2.0)
	libxml++-devel-2.23.2-2.fc11.ppc64 requires pkgconfig(libxml-2.0)
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	muine-devel-0.8.10-1.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-bitstring-2.0.0-5.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pils-2.1.3-3.fc10.ppc requires libltdl.so.3
	pils-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.ppc requires python-pygame
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	seahorse-plugins-2.25.1-1.fc11.ppc requires libcryptui.so.0
	seahorse-plugins-2.25.1-1.fc11.ppc requires seahorse >= 0:2.23.6
	stonith-2.1.3-3.fc10.ppc requires libltdl.so.3
	stonith-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	telepathy-glib-devel-0.7.19-1.fc11.ppc requires pkgconfig(gobject-2.0) >= 0:2.16
	telepathy-glib-devel-0.7.19-1.fc11.ppc64 requires pkgconfig(gobject-2.0) >= 0:2.16
	vte-devel-0.19.1-1.fc11.ppc requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	vte-devel-0.19.1-1.fc11.ppc requires pkgconfig(gobject-2.0)
	vte-devel-0.19.1-1.fc11.ppc64 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	vte-devel-0.19.1-1.fc11.ppc64 requires pkgconfig(gobject-2.0)
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	appliance-tools-003.9-1.fc10.noarch requires qemu-img
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(libstartup-notification-1.0) >= 0:0.7
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(libxml-2.0)
	devhelp-devel-0.22-1.fc11.ppc64 requires pkgconfig(gtk+-2.0)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.ppc64 requires libltdl.so.3()(64bit)
	ettercap-gtk-0.7.3-26.fc10.ppc64 requires libltdl.so.3()(64bit)
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-data-server-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	firstaidkit-plugin-grub-0.2.2-4.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc64 requires dejavu-fonts
	freeradius-2.1.1-6.fc10.ppc64 requires libltdl.so.3()(64bit)
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gtkhtml3-devel-3.25.2-1.fc11.ppc64 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	heartbeat-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	heartbeat-gui-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.ppc64 requires libplasma.so.2()(64bit)
	kde-plasma-quickaccess-0.7.1-2.fc11.ppc64 requires libplasma.so.2()(64bit)
	kde-plasma-runcommand-0.7-1.fc11.ppc64 requires libplasma.so.2()(64bit)
	kdeplasma-addons-4.1.3-1.fc10.ppc64 requires libplasma.so.2()(64bit)
	kipi-plugins-0.2.0-0.4.beta3.fc10.ppc64 requires libkipi.so.5()(64bit)
	kphotoalbum-3.2-0.4.20081007svn.fc10.ppc64 requires libkipi.so.5()(64bit)
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libsoup-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(gio-2.0)
	libsoup-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(gobject-2.0)
	libxml++-devel-2.23.2-2.fc11.ppc64 requires pkgconfig(libxml-2.0)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-bitstring-2.0.0-5.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pils-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.ppc64 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	seahorse-plugins-2.25.1-1.fc11.ppc64 requires seahorse >= 0:2.23.6
	seahorse-plugins-2.25.1-1.fc11.ppc64 requires libcryptui.so.0()(64bit)
	stonith-2.1.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	telepathy-glib-devel-0.7.19-1.fc11.ppc64 requires pkgconfig(gobject-2.0) >= 0:2.16
	vte-devel-0.19.1-1.fc11.ppc64 requires pkgconfig(gtk+-2.0) >= 0:2.12.0
	vte-devel-0.19.1-1.fc11.ppc64 requires pkgconfig(gobject-2.0)
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From jwboyer at gmail.com  Tue Dec  2 13:56:07 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 2 Dec 2008 08:56:07 -0500
Subject: F11 Naming: Sulphur -> Cambridge -> <NewName>?
Message-ID: <20081202135607.GA2344@yoda.jdub.homelinux.org>

Hi All,

It's that time of year again.  Time to start the naming process
for the next Fedora release.

To recap on the rules:

1) <NewName> must have some link to Cambridge

More specifically, the link should be
	Cambridge is a <blank> and
	<NewName> is a <blank>
Where <blank> is the same for both

2) The link between <NewName> and Cambridge cannot be the same as
between Sulphur and Cambridge.  That link was "both are cities".

We're doing the name collection differently this year than in
the past.  Contributors wishing to make a suggestion are asked to
go to the F11 naming wiki page, and add an entry to the suggestion
table found there:

https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_11

The naming submissions are open starting now until Dec 8.  The
rest of the schedule is outlined on the wiki page.

So, put on your thinking caps and come up with some really good
suggestions!

Happy naming.

josh

_______________________________________________
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  Tue Dec  2 17:31:13 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Tue, 2 Dec 2008 10:31:13 -0700
Subject: Fedora IRC Classes - Teachers needed
Message-ID: <20081202103113.395c6cb9@ohm.scrye.com>

Hey folks. 

This coming weekend we are going to have the second set of sessions in
the #fedora-classroom irc channel. The first set of classes went very
nicely. This time we have shifted the times to allow those in other
timezones to attend. 

We are still lacking teachers for sessions on sunday. 

If there is anyone who would be willing to teach a class, please do
sign up on the wiki: 

https://fedoraproject.org/wiki/Communicate/IRC/Classroom

This is a great way to connect with our users and show them exciting
parts of Fedora. ;) 

Feel free to email me or catch me on irc with any questions...

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/54ecd001/attachment.sig>

From a.badger at gmail.com  Tue Dec  2 19:06:34 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 02 Dec 2008 11:06:34 -0800
Subject: First Report
In-Reply-To: <1228057466.3835.105.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan>
Message-ID: <4935873A.9090708@gmail.com>

Ignacio Vazquez-Abrams wrote:
> python-cheetah

This has been fixed but not well.  python-cheetah provides an
importHook() that had the potential to break with python-2.5+ due to
python providing relative vs absolute import information to the hook.
python-2.6's stdlib has a module that exposes the bug.  I've made
importHook() function accept the extra data but it doesn't currently do
anything with it.  BZ opened if anyone wants to deal with it:
  https://bugzilla.redhat.com/show_bug.cgi?id=474090


> bodhi python-cherrypy2
> ipa python-cherrypy2
> python-tgcaptcha python-cherrypy2
> python-turboflot python-cherrypy2
> python-TurboMail python-cherrypy2
> TurboGears python-cherrypy2

TurboGears (and from that, the rest of these) are currently blocking on
python-ruledispatch.  python-ruledispatch was built and thus not in the
list but I discovered that it wasn't running it's testsuite.  When
that's enabled, the build bombs due to ruledispatch defining a method
which is a keyword in python-2.5+.  There doesn't appear to be any work
on ruledispatch upstream to fix this so I'd propose to block that from
the rawhide repo and work on updating to TurboGears-1.1(beta) which does
not have the ruledispatch dependency.

I'm going to get started on that by building a snapshot of the 1.1 tree
today.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/7d3582fc/attachment.sig>

From bpepple at fedoraproject.org  Tue Dec  2 19:24:27 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 02 Dec 2008 14:24:27 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
Message-ID: <1228245867.5858.3.camel@localhost.localdomain>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Wednesday at 17:00
UTC in #fedora-meeting on irc.freenode.org:

/topic FESCo-Meeting - Final F11 Schedule -
https://fedoraproject.org/wiki/Releases/11/Schedule - 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.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/d4e48f4c/attachment.sig>

From bpepple at fedoraproject.org  Tue Dec  2 19:29:11 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 02 Dec 2008 14:29:11 -0500
Subject: Package Review Stats for the week ending November 30, 2008
Message-ID: <1228246151.5858.7.camel@localhost.localdomain>

Top two FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending November 30th, 2008
were Manuel Wolfshant and Parag AN(????).  Below is the number of
completed package reviews done.

manuel wolfshant - 10
Parag AN(????) - 6
Bryan Kearney - 1
Chris Weyl - 1
Jason Tibbitts - 1
Mamoru Tasaka - 1
Orcan 'oget' Ogetbil - 1
Paul F. Johnson - 1
Peter Lemenkov - 1
Ville Skytt? - 1

Total reviews: 24

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/2f2c5622/attachment.sig>

From deadbabylon at googlemail.com  Tue Dec  2 17:20:39 2008
From: deadbabylon at googlemail.com (Sebastian Vahl)
Date: Tue, 2 Dec 2008 18:20:39 +0100
Subject: KDE-SIG weekly report (49/2008)
Message-ID: <200812021820.49831.deadbabylon@googlemail.com>

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: 49/2008

Time: 2008-12-02 16:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-12-02

Meeting log: https://fedoraproject.org/w/uploads/d/d1/KDE-SIG-2008-12-02.txt

----------------------------------------------------------------------------------

= Participants =

*  BalajiGurudass (G__81)
* ChristopherStone (XulChris)
* JaroslavReznik
* KevinKofler
* LukasTinkl
* RexDieter
* SebastianVahl
* ThanNgo 

----------------------------------------------------------------------------------

= Agenda =

* kde-4.1.80 rawhide import report 

= Summary =

kde-4.1.80 rawhide import report:
- - - - -
* Half of the import should be done already.
* Work is going on with packages depending on Plasma. 

Open discussion:
- - - - -
* _default_patch_fuzz:
- All patches were rediffed in devel, so the new _default_patch_fuzz there is 
0 (it was 2 in F10).
- For new patches a fuzz level of 0 should be used were reasonable. 


----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-12-09
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/e9ff3202/attachment.sig>

From forum at ru.bir.ru  Tue Dec  2 20:11:29 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Tue, 02 Dec 2008 23:11:29 +0300
Subject: How to pack cron jobs?
In-Reply-To: <20081201205847.GB2796@free.fr>
References: <ggs9m8$rsg$1@ger.gmane.org>	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>	<ggsd7q$5tn$1@ger.gmane.org>
	<20081130142237.GA16722@free.fr>	<ggujhc$68k$1@ger.gmane.org>
	<20081130210724.GA2649@free.fr>	<ggv8d5$539$1@ger.gmane.org>
	<20081201083229.GA2735@free.fr>	<gh1grb$v31$1@ger.gmane.org>
	<20081201205847.GB2796@free.fr>
Message-ID: <gh44ph$5v8$1@ger.gmane.org>

Patrice Dumas ?????:
>>> Not in the main package.
>> Not in main package? Is there any subpackage of crontab in Fedora??
>> $ repoquery 'crontab*'
>> crontabs-0:1.10-19.fc9.noarch
>>
>> Or you suppose create new one?
> 
> That's not what I meant. I meant the main cronie and fcron packages
> should not require crontabs.

May be, may be.
But return to initial my question - how I should pack cron jobs 
correctly? If crons independent from crontab, directories layout also 
depend from cron variant...
May be I must "Require /etc/cron.d" directly in my rpm?



From mschwendt at gmail.com  Tue Dec  2 20:16:58 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 2 Dec 2008 21:16:58 +0100
Subject: mono-winforms requires libgdiplus-devel
Message-ID: <20081202211658.35bb8439.mschwendt@gmail.com>

$ rpm -qR mono-winforms | grep ^lib
libgdiplus-devel  

Sorry, this is inacceptable. -devel packages ought to stay optional.
Not only does this break rpmdev-rmdevelrpms,

    $ sudo rpmdev-rmdevelrpms -y
    [...]
    ...whose removal would cause unresolved dependencies:
      mono-winforms-2.0.1-12.fc10 requires libgdiplus-devel
    Not removed due to dependencies.

and it also pulls in pkg-config and leads to broken pkg-config deps:

    $ cat /usr/lib/pkgconfig/libgdiplus.pc | grep Req
    Requires: glib-2.0 gmodule-2.0 gthread-2.0

Looking at mono.spec, the file doesn't explain this. With luck I found
this F8 ticket:

    missing link ln -s libgdiplus.so.0.0.0 libgdiplus.so
    https://bugzilla.redhat.com/426519

Is that the reason for the unusual "Requires" of a -devel pkg?
Do you only need the libgdiplus.so link?

Can't mono-winforms be patched to accept libgdiplus.so.0 instead?



From pertusus at free.fr  Tue Dec  2 20:23:46 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 2 Dec 2008 21:23:46 +0100
Subject: How to pack cron jobs?
In-Reply-To: <gh44ph$5v8$1@ger.gmane.org>
References: <46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>
	<ggsd7q$5tn$1@ger.gmane.org> <20081130142237.GA16722@free.fr>
	<ggujhc$68k$1@ger.gmane.org> <20081130210724.GA2649@free.fr>
	<ggv8d5$539$1@ger.gmane.org> <20081201083229.GA2735@free.fr>
	<gh1grb$v31$1@ger.gmane.org> <20081201205847.GB2796@free.fr>
	<gh44ph$5v8$1@ger.gmane.org>
Message-ID: <20081202202346.GA6090@free.fr>

On Tue, Dec 02, 2008 at 11:11:29PM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>
> May be, may be.
> But return to initial my question - how I should pack cron jobs  
> correctly? If crons independent from crontab, directories layout also  
> depend from cron variant...
> May be I must "Require /etc/cron.d" directly in my rpm?

Indeed.

Now if you rely on cron.hourly and so on and so forth, maybe you should
require crontabs. And crontabs could depend on /etc/cron.d.

--
Pat



From davej at redhat.com  Tue Dec  2 21:07:34 2008
From: davej at redhat.com (Dave Jones)
Date: Tue, 2 Dec 2008 16:07:34 -0500
Subject: rawhide status page.
Message-ID: <20081202210734.GA6778@redhat.com>

I'm sure something like this used to exist on the wiki at
some point, but I'm having trouble finding it.

I think it would be useful to have a 'rawhide status' page
on the wiki, updated daily with the latest problems
be they dependancy failures, or broken installers, or
broken kernels or whatever.

The idea being, by checking this page, people can decide
whether it's worth rsyncing a few hundred MB of packages,
or whether it's better to sit it out and try again the next day.

Does this exist already and I've just overlooked it?

	Dave

-- 
http://www.codemonkey.org.uk



From notting at redhat.com  Tue Dec  2 21:13:30 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 2 Dec 2008 16:13:30 -0500
Subject: rawhide status page.
In-Reply-To: <20081202210734.GA6778@redhat.com>
References: <20081202210734.GA6778@redhat.com>
Message-ID: <20081202211330.GA837@nostromo.devel.redhat.com>

Dave Jones (davej at redhat.com) said: 
> I'm sure something like this used to exist on the wiki at
> some point, but I'm having trouble finding it.
> 
> I think it would be useful to have a 'rawhide status' page
> on the wiki, updated daily with the latest problems
> be they dependancy failures, or broken installers, or
> broken kernels or whatever.
> 
> The idea being, by checking this page, people can decide
> whether it's worth rsyncing a few hundred MB of packages,
> or whether it's better to sit it out and try again the next day.
> 
> Does this exist already and I've just overlooked it?

https://bugzilla.redhat.com/show_bug.cgi?id=204584

Bill



From davej at redhat.com  Tue Dec  2 21:23:09 2008
From: davej at redhat.com (Dave Jones)
Date: Tue, 2 Dec 2008 16:23:09 -0500
Subject: rawhide status page.
In-Reply-To: <20081202211330.GA837@nostromo.devel.redhat.com>
References: <20081202210734.GA6778@redhat.com>
	<20081202211330.GA837@nostromo.devel.redhat.com>
Message-ID: <20081202212309.GB6778@redhat.com>

On Tue, Dec 02, 2008 at 04:13:30PM -0500, Bill Nottingham wrote:
 > Dave Jones (davej at redhat.com) said: 
 > > I'm sure something like this used to exist on the wiki at
 > > some point, but I'm having trouble finding it.
 > > 
 > > I think it would be useful to have a 'rawhide status' page
 > > on the wiki, updated daily with the latest problems
 > > be they dependancy failures, or broken installers, or
 > > broken kernels or whatever.
 > > 
 > > The idea being, by checking this page, people can decide
 > > whether it's worth rsyncing a few hundred MB of packages,
 > > or whether it's better to sit it out and try again the next day.
 > > 
 > > Does this exist already and I've just overlooked it?
 > 
 > https://bugzilla.redhat.com/show_bug.cgi?id=204584

That starts out along the same lines I was thinking, and
then goes into overcomplicating something that should be
fairly simple.

Not that it wouldn't be neat to have automated reports etc,
but I think it's overkill for the simple "is it busted" cases,
which will be the majority.

	Dave

-- 
http://www.codemonkey.org.uk



From vonbrand at inf.utfsm.cl  Tue Dec  2 21:28:49 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 02 Dec 2008 18:28:49 -0300
Subject: rawhide status page.
In-Reply-To: <20081202212309.GB6778@redhat.com>
References: <20081202210734.GA6778@redhat.com>
	<20081202211330.GA837@nostromo.devel.redhat.com>
	<20081202212309.GB6778@redhat.com>
Message-ID: <200812022128.mB2LSnHa007959@laptop14.inf.utfsm.cl>

Dave Jones <davej at redhat.com> wrote:
> On Tue, Dec 02, 2008 at 04:13:30PM -0500, Bill Nottingham wrote:
>  > Dave Jones (davej at redhat.com) said: 
>  > > I'm sure something like this used to exist on the wiki at
>  > > some point, but I'm having trouble finding it.
>  > > 
>  > > I think it would be useful to have a 'rawhide status' page
>  > > on the wiki, updated daily with the latest problems
>  > > be they dependancy failures, or broken installers, or
>  > > broken kernels or whatever.
>  > > 
>  > > The idea being, by checking this page, people can decide
>  > > whether it's worth rsyncing a few hundred MB of packages,
>  > > or whether it's better to sit it out and try again the next day.
>  > > 
>  > > Does this exist already and I've just overlooked it?
>  > 
>  > https://bugzilla.redhat.com/show_bug.cgi?id=204584
> 
> That starts out along the same lines I was thinking, and
> then goes into overcomplicating something that should be
> fairly simple.
> 
> Not that it wouldn't be neat to have automated reports etc,
> but I think it's overkill for the simple "is it busted" cases,
> which will be the majority.

How do you know if it is busted or not, before people scream it is?
-- 
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 rakesh.pandit at gmail.com  Tue Dec  2 21:27:09 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Wed, 3 Dec 2008 02:57:09 +0530
Subject: php-pear-Auth in EPEL?
In-Reply-To: <200812010940.30170.ville.skytta@iki.fi>
References: <200812010005.46431.ville.skytta@iki.fi>
	<b401d2530811301940v5521a152v8f712c30e6cf108e@mail.gmail.com>
	<200812010940.30170.ville.skytta@iki.fi>
Message-ID: <b401d2530812021327m7cabd1e5ifdeaa53299bea6c6@mail.gmail.com>

2008/12/1 Ville Skytt? <ville.skytta at iki.fi>:
> On Monday 01 December 2008, you wrote:
>> 2008/12/1 Ville Skytt? <ville.skytta at iki.fi>:
>> > Hi Rakesh,
>> >
>> > I have an app that requires php-pear-Auth that I'd like to install on
>> > EL-5, but php-pear-Auth is not available in the EPEL 5 repo.  Would you
>> > mind maintaining it for EL-5 as well as Fedora?
>>
[..]
>
> Thanks in advance.  By the way, php-pear-Auth requires php-pear-SOAP which is
> not available in EPEL - I have already contacted its Fedora maintainer and he
> promised to look into getting it into EPEL.  There may be some other
> dependencies missing from EPEL as well, some of the dependencies I got
> installed might have come from CentOS Extras so it could be that some
> additional packages should be put to EPEL as well (I suppose EPEL can't count
> on CentOS Extras being available as things there need to work with RHEL as
> well).
>

Any one willing to maintain php-pear-Auth and php-pear-SOAP for EPEL ?

-- 
rakesh



From davej at redhat.com  Tue Dec  2 21:46:14 2008
From: davej at redhat.com (Dave Jones)
Date: Tue, 2 Dec 2008 16:46:14 -0500
Subject: rawhide status page.
In-Reply-To: <200812022128.mB2LSnHa007959@laptop14.inf.utfsm.cl>
References: <20081202210734.GA6778@redhat.com>
	<20081202211330.GA837@nostromo.devel.redhat.com>
	<20081202212309.GB6778@redhat.com>
	<200812022128.mB2LSnHa007959@laptop14.inf.utfsm.cl>
Message-ID: <20081202214614.GA9959@redhat.com>

On Tue, Dec 02, 2008 at 06:28:49PM -0300, Horst H. von Brand wrote:

 > > Not that it wouldn't be neat to have automated reports etc,
 > > but I think it's overkill for the simple "is it busted" cases,
 > > which will be the majority.
 > 
 > How do you know if it is busted or not, before people scream it is?

For the 'everyone will hit this' problems, it only takes one person
to edit the wiki.

	Dave

-- 
http://www.codemonkey.org.uk



From Fedora at FamilleCollet.com  Tue Dec  2 21:56:04 2008
From: Fedora at FamilleCollet.com (Remi Collet)
Date: Tue, 02 Dec 2008 22:56:04 +0100
Subject: php-pear-Auth in EPEL?
In-Reply-To: <b401d2530812021327m7cabd1e5ifdeaa53299bea6c6@mail.gmail.com>
References: <200812010005.46431.ville.skytta@iki.fi>	<b401d2530811301940v5521a152v8f712c30e6cf108e@mail.gmail.com>	<200812010940.30170.ville.skytta@iki.fi>
	<b401d2530812021327m7cabd1e5ifdeaa53299bea6c6@mail.gmail.com>
Message-ID: <4935AEF4.4010803@FamilleCollet.com>

Rakesh Pandit a ?crit :

> Any one willing to maintain php-pear-Auth and php-pear-SOAP for EPEL ?
> 

php-pear-SOAP 0.11.0 is on the road to epel-testing (freshly build)

++



From mschwendt at gmail.com  Tue Dec  2 22:32:56 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 2 Dec 2008 23:32:56 +0100
Subject: mono-winforms requires libgdiplus-devel
In-Reply-To: <20081202211658.35bb8439.mschwendt@gmail.com>
References: <20081202211658.35bb8439.mschwendt@gmail.com>
Message-ID: <20081202233256.9cf5965f.mschwendt@gmail.com>

On Tue, 2 Dec 2008 21:16:58 +0100, Michael wrote:

> $ rpm -qR mono-winforms | grep ^lib
> libgdiplus-devel  
> 
> Sorry, this is inacceptable. -devel packages ought to stay optional.
> Not only does this break rpmdev-rmdevelrpms,
> 
>     $ sudo rpmdev-rmdevelrpms -y
>     [...]
>     ...whose removal would cause unresolved dependencies:
>       mono-winforms-2.0.1-12.fc10 requires libgdiplus-devel
>     Not removed due to dependencies.
> 
> and it also pulls in pkg-config and leads to broken pkg-config deps:
> 
>     $ cat /usr/lib/pkgconfig/libgdiplus.pc | grep Req
>     Requires: glib-2.0 gmodule-2.0 gthread-2.0
> 
> Looking at mono.spec, the file doesn't explain this. With luck I found
> this F8 ticket:
> 
>     missing link ln -s libgdiplus.so.0.0.0 libgdiplus.so
>     https://bugzilla.redhat.com/426519
> 
> Is that the reason for the unusual "Requires" of a -devel pkg?
> Do you only need the libgdiplus.so link?
> 
> Can't mono-winforms be patched to accept libgdiplus.so.0 instead?

Old story it seems. Bugzilla 380131 and several others, which complain
about this too, have been closed as duplicate. Bz 426519 now contains
a demo patch. There are probably other ways to do it.



From paul at all-the-johnsons.co.uk  Wed Dec  3 00:11:20 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 03 Dec 2008 00:11:20 +0000
Subject: Quick sed question
Message-ID: <1228263080.31448.88.camel@PB3.Linux>

Hi,

I'm about to rebuild mono-2.x with Mike's patch for libgdiplus but would
like to know what the following sed line means (it's caused a problem
with building for x86_64 mono)

's,@''bindir@,$(bindir),g'

what does the ,g do?

The reason I'm asking is that in order to get things to build with mono
easier (and causing fewer upgrade hassles in trying to find *every* use
of /usr/lib rather than %{_libdir}), I've started to use a find-all sed
script. Unfortunately, on x86_64, this is giving me /usr/lib6464 and I'm
wondering if the ,g has anything to do with the replication of the the
64 (I doubt it has).

The script works fine in other mono-based applications, so I'm trying to
find why mono would act in such a way.

The script is as follows

find . -name Makefile.in -or -name Makefile.am -or -name \*.pc.in \
       -or -name \*.in -or -name \*.make \
       | while read f ;
         do
           sed -i -e 's!$(prefix)/lib!%{_libdir}!' "$f" 
           sed -i -e 's!@prefix@/lib!%{_libdir}!' "$f"
           sed -i -e 's!/usr/lib!%{_libdir}!' "$f"
           sed -i -e 's!${prefix}/lib!%{_libdir}!' "$f"
           sed -i -e 's!${exec_prefix}/lib!%{_libdir}!' "$f" 
           sed -i -e 's!${prefix}/@reloc_libdir@!%{_libdir}!' "$f";
         done

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/a37a7265/attachment.sig>

From andrewparker at bigfoot.com  Wed Dec  3 00:14:34 2008
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Tue, 2 Dec 2008 19:14:34 -0500
Subject: Quick sed question
In-Reply-To: <1228263080.31448.88.camel@PB3.Linux>
References: <1228263080.31448.88.camel@PB3.Linux>
Message-ID: <6c3f5e6c0812021614m2c085743t2314a11f3645fd83@mail.gmail.com>

2008/12/2 Paul <paul at all-the-johnsons.co.uk>:
>
> 's,@''bindir@,$(bindir),g'
>
> what does the ,g do?
>

(each) "," is a delimiter, the "g" means replace every instance of
@''bindir@ on each line - without it it would just be the first
instance on every line.



From paul at all-the-johnsons.co.uk  Wed Dec  3 00:16:35 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 03 Dec 2008 00:16:35 +0000
Subject: Quick sed question
In-Reply-To: <6c3f5e6c0812021614m2c085743t2314a11f3645fd83@mail.gmail.com>
References: <1228263080.31448.88.camel@PB3.Linux>
	<6c3f5e6c0812021614m2c085743t2314a11f3645fd83@mail.gmail.com>
Message-ID: <1228263395.31448.89.camel@PB3.Linux>

Hi,

> > 's,@''bindir@,$(bindir),g'
> >
> > what does the ,g do?
> >
> 
> (each) "," is a delimiter, the "g" means replace every instance of
> @''bindir@ on each line - without it it would just be the first
> instance on every line.

Thanks. Doesn't help in why x86_64 has a repeat of the 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/13542cd7/attachment.sig>

From dbn.lists at gmail.com  Wed Dec  3 00:19:52 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 2 Dec 2008 16:19:52 -0800
Subject: Quick sed question
In-Reply-To: <1228263080.31448.88.camel@PB3.Linux>
References: <1228263080.31448.88.camel@PB3.Linux>
Message-ID: <91705d080812021619y601c5c69pd954cfae04cb9552@mail.gmail.com>

2008/12/2 Paul <paul at all-the-johnsons.co.uk>:
> Hi,
>
> I'm about to rebuild mono-2.x with Mike's patch for libgdiplus but would
> like to know what the following sed line means (it's caused a problem
> with building for x86_64 mono)
>
> 's,@''bindir@,$(bindir),g'
>
> what does the ,g do?

The g mean, keep finding every match on a given line. Otherwise, you
just get the first match, which may be what you want.

> The reason I'm asking is that in order to get things to build with mono
> easier (and causing fewer upgrade hassles in trying to find *every* use
> of /usr/lib rather than %{_libdir}), I've started to use a find-all sed
> script. Unfortunately, on x86_64, this is giving me /usr/lib6464 and I'm
> wondering if the ,g has anything to do with the replication of the the
> 64 (I doubt it has).
>
> The script works fine in other mono-based applications, so I'm trying to
> find why mono would act in such a way.
>
> The script is as follows
>
> find . -name Makefile.in -or -name Makefile.am -or -name \*.pc.in \
>       -or -name \*.in -or -name \*.make \
>       | while read f ;
>         do
>           sed -i -e 's!$(prefix)/lib!%{_libdir}!' "$f"
>           sed -i -e 's!@prefix@/lib!%{_libdir}!' "$f"
>           sed -i -e 's!/usr/lib!%{_libdir}!' "$f"
>           sed -i -e 's!${prefix}/lib!%{_libdir}!' "$f"
>           sed -i -e 's!${exec_prefix}/lib!%{_libdir}!' "$f"
>           sed -i -e 's!${prefix}/@reloc_libdir@!%{_libdir}!' "$f";
>         done

Maybe the g is causing the problem, but you'd have to see more context
to know. Two suggestions:

1. sed takes multiple -e patterns, so you don't need to fork it 6
times per file.

2. Giving an argument to -i (on sed > 4.1.2 I think) will make a
backup with the argument as suffix. E.g., `sed -i.bak s/foo/bar/ file'
will give you file and the original file.bak. Then you can diff them
to see what you just did.

--
Dan



From ivazqueznet at gmail.com  Wed Dec  3 00:21:06 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 02 Dec 2008 19:21:06 -0500
Subject: Quick sed question
In-Reply-To: <1228263080.31448.88.camel@PB3.Linux>
References: <1228263080.31448.88.camel@PB3.Linux>
Message-ID: <1228263666.29612.63.camel@ignacio.lan>

On Wed, 2008-12-03 at 00:11 +0000, Paul wrote:
> The reason I'm asking is that in order to get things to build with mono
> easier (and causing fewer upgrade hassles in trying to find *every* use
> of /usr/lib rather than %{_libdir}), I've started to use a find-all sed
> script. Unfortunately, on x86_64, this is giving me /usr/lib6464 and I'm
> wondering if the ,g has anything to do with the replication of the the
> 64 (I doubt it has).

's,lib\([^6]\|$\),lib64\1,g'

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/ee4180b1/attachment.sig>

From ivazqueznet at gmail.com  Tue Dec  2 23:35:09 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 02 Dec 2008 18:35:09 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <1228245867.5858.3.camel@localhost.localdomain>
References: <1228245867.5858.3.camel@localhost.localdomain>
Message-ID: <1228260910.29612.60.camel@ignacio.lan>

On Tue, 2008-12-02 at 14:24 -0500, 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.  You can also propose topics
> in the meeting while it is in the "Free discussion around Fedora" phase.

I'd like to get a final yea or nay on this:

https://fedorahosted.org/rel-eng/ticket/1114

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/d40b6cf9/attachment.sig>

From bpepple at fedoraproject.org  Wed Dec  3 01:16:07 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 02 Dec 2008 20:16:07 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <1228260910.29612.60.camel@ignacio.lan>
References: <1228245867.5858.3.camel@localhost.localdomain>
	<1228260910.29612.60.camel@ignacio.lan>
Message-ID: <1228266967.11197.0.camel@localhost.localdomain>

On Tue, 2008-12-02 at 18:35 -0500, Ignacio Vazquez-Abrams wrote:
> On Tue, 2008-12-02 at 14:24 -0500, 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.  You can also propose topics
> > in the meeting while it is in the "Free discussion around Fedora" phase.
> 
> I'd like to get a final yea or nay on this:
> 
> https://fedorahosted.org/rel-eng/ticket/1114

Added to the schedule. Are you going to be available for any questions
that might come up?

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/aa1c6d7e/attachment.sig>

From a.badger at gmail.com  Wed Dec  3 03:04:05 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 02 Dec 2008 19:04:05 -0800
Subject: Quick sed question
In-Reply-To: <91705d080812021619y601c5c69pd954cfae04cb9552@mail.gmail.com>
References: <1228263080.31448.88.camel@PB3.Linux>
	<91705d080812021619y601c5c69pd954cfae04cb9552@mail.gmail.com>
Message-ID: <4935F725.9060404@gmail.com>

Dan Nicholson wrote:
> 2008/12/2 Paul <paul at all-the-johnsons.co.uk>:
>> Hi,
>>
>> I'm about to rebuild mono-2.x with Mike's patch for libgdiplus but would
>> like to know what the following sed line means (it's caused a problem
>> with building for x86_64 mono)
>>
>> 's,@''bindir@,$(bindir),g'
>>
>> what does the ,g do?
> 
> The g mean, keep finding every match on a given line. Otherwise, you
> just get the first match, which may be what you want.
> 
>> The reason I'm asking is that in order to get things to build with mono
>> easier (and causing fewer upgrade hassles in trying to find *every* use
>> of /usr/lib rather than %{_libdir}), I've started to use a find-all sed
>> script. Unfortunately, on x86_64, this is giving me /usr/lib6464 and I'm
>> wondering if the ,g has anything to do with the replication of the the
>> 64 (I doubt it has).
>>
>> The script works fine in other mono-based applications, so I'm trying to
>> find why mono would act in such a way.
>>
>> The script is as follows
>>
>> find . -name Makefile.in -or -name Makefile.am -or -name \*.pc.in \
>>       -or -name \*.in -or -name \*.make \
>>       | while read f ;
>>         do
>>           sed -i -e 's!$(prefix)/lib!%{_libdir}!' "$f"
>>           sed -i -e 's!@prefix@/lib!%{_libdir}!' "$f"
>>           sed -i -e 's!/usr/lib!%{_libdir}!' "$f"
>>           sed -i -e 's!${prefix}/lib!%{_libdir}!' "$f"
>>           sed -i -e 's!${exec_prefix}/lib!%{_libdir}!' "$f"
>>           sed -i -e 's!${prefix}/@reloc_libdir@!%{_libdir}!' "$f";
>>         done
> 
> Maybe the g is causing the problem, but you'd have to see more context
> to know. Two suggestions:
> 
> 1. sed takes multiple -e patterns, so you don't need to fork it 6
> times per file.
> 
> 2. Giving an argument to -i (on sed > 4.1.2 I think) will make a
> backup with the argument as suffix. E.g., `sed -i.bak s/foo/bar/ file'
> will give you file and the original file.bak. Then you can diff them
> to see what you just did.
> 
You're substituting some lines multiple times with the given sequence of
substitutions.  For instance:

start with:
  LIBDIR=@prefix@/lib
This line runs:
  sed -i -e 's!@prefix@/lib!%{_libdir}!' "$f"
And you have:
  LIBDIR=/usr/lib64
Then this line runs:
  sed -i -e 's!/usr/lib!%{_libdir}!' "$f"
And you have:
  LIBDIR=/usr/lib6464

Ignacio's message has a solution for this since it checks that the "lib"
pattern doesn't have a "6" after it.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/8913cfa1/attachment.sig>

From ivazqueznet at gmail.com  Wed Dec  3 03:15:48 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 02 Dec 2008 22:15:48 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <1228266967.11197.0.camel@localhost.localdomain>
References: <1228245867.5858.3.camel@localhost.localdomain>
	<1228260910.29612.60.camel@ignacio.lan>
	<1228266967.11197.0.camel@localhost.localdomain>
Message-ID: <1228274148.29612.67.camel@ignacio.lan>

On Tue, 2008-12-02 at 20:16 -0500, Brian Pepple wrote:
> On Tue, 2008-12-02 at 18:35 -0500, Ignacio Vazquez-Abrams wrote:
> > On Tue, 2008-12-02 at 14:24 -0500, 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.  You can also propose topics
> > > in the meeting while it is in the "Free discussion around Fedora" phase.
> > 
> > I'd like to get a final yea or nay on this:
> > 
> > https://fedorahosted.org/rel-eng/ticket/1114
> 
> Added to the schedule. Are you going to be available for any questions
> that might come up?

I will indeed.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/199d7e6f/attachment.sig>

From pertusus at free.fr  Tue Dec  2 23:30:31 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 3 Dec 2008 00:30:31 +0100
Subject: looking for inotifywait and similar help
Message-ID: <20081202233031.GA30159@free.fr>

Hello,

Trying to have fcron do the same than cronie, that is regenerate
binary crontabs when /etc/crontab /etc/cron.d/ (or /etc/fcrontab since it
is the same, but for fcron) change, I made a script to watch for 
/etc/cron.d/ and /etc/crontab and /etc/fcrontab if they exist (and then
launch a script coming from debian that does all the regeneration work). 
However the issue I have is that I don't know how to have inotifywait do 
something when /etc/crontab or /etc/fcrontab is created since if I give
a non-existing file as argument it will error out.

Also maybe I should not listen to all the events but only some.

And lastly maybe inotifywait is not the right tool?

The script is here:
http://cvs.fedoraproject.org/viewvc/rpms/fcron/devel/fcron_watch_config?revision=1.2&view=markup

It is launched by an init script through another script,
http://cvs.fedoraproject.org/viewvc/rpms/fcron/devel/daemon_fcron_watch_config?revision=1.2&view=markup
that doesn't do anything else that starting it with setsid.

Anybody knows what I should do?

--
Pat



From silfreed at silfreed.net  Wed Dec  3 03:41:22 2008
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Tue, 02 Dec 2008 22:41:22 -0500
Subject: Orphaning thinkfinger
Message-ID: <4935FFE2.8050402@silfreed.net>

I picked up this package thinking I could give it some love, but the bugs that 
exist are out of my expertise.  I believe thinkfinger is largely being 
superseded by libfprint, as well.

Open bugs:
multiarch conflicts in thinkfinger (bug #343271) [1]
Thinkfinger's PAM module emits annoying RETURN key when using password (bug 
#356921) [2]
Thinkfinger causing lockup of kde session (bug #394181) [3]
100% CPU Usage (bug #439669) [4]
pam_thinkfinger requires kernel module uinput (bug #443314) [5]

-Doug

[1] https://bugzilla.redhat.com/show_bug.cgi?id=343271
[2] https://bugzilla.redhat.com/show_bug.cgi?id=356921
[3] https://bugzilla.redhat.com/show_bug.cgi?id=394181
[4] https://bugzilla.redhat.com/show_bug.cgi?id=439669
[5] https://bugzilla.redhat.com/show_bug.cgi?id=443314

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081202/793f6b73/attachment.sig>

From dbn.lists at gmail.com  Wed Dec  3 04:16:54 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 2 Dec 2008 20:16:54 -0800
Subject: looking for inotifywait and similar help
In-Reply-To: <20081202233031.GA30159@free.fr>
References: <20081202233031.GA30159@free.fr>
Message-ID: <91705d080812022016q7e2bc529t3eb64c9c24ead925@mail.gmail.com>

On Tue, Dec 2, 2008 at 3:30 PM, Patrice Dumas <pertusus at free.fr> wrote:
> Hello,
>
> Trying to have fcron do the same than cronie, that is regenerate
> binary crontabs when /etc/crontab /etc/cron.d/ (or /etc/fcrontab since it
> is the same, but for fcron) change, I made a script to watch for
> /etc/cron.d/ and /etc/crontab and /etc/fcrontab if they exist (and then
> launch a script coming from debian that does all the regeneration work).
> However the issue I have is that I don't know how to have inotifywait do
> something when /etc/crontab or /etc/fcrontab is created since if I give
> a non-existing file as argument it will error out.

I think if you want to catch file creation, you have to watch /etc,
wait for create events and filter for the crontab files. So, I think
it would have to be something like:

out=`inotifywait -e create /etc`; do
if [ $? = 0 ]; then
    set -- $out
    case "$3" in
    crontab|fcrontab) do stuff ;;
    *) ;;
    esac
fi

Or, more likely is that you'll have to check whether crontab or
fcrontab exist initially and modify your command accordingly.

--
Dan



From g at socallinuxexpo.org  Wed Dec  3 05:32:23 2008
From: g at socallinuxexpo.org (Gareth J. Greenaway)
Date: Tue, 02 Dec 2008 21:32:23 -0800
Subject: Women in Open Source at SCALE 7x
Message-ID: <493619E7.4090601@socallinuxexpo.org>

The Linux Expo of Southern California is proud to announce their second 
Women in
Open Source Conference. The conference will be held on February 20th, 
2009 in
conjunction with the 7th Annual So Cal Linux Expo.

The SCALE 7X Women In Open Source conference continues last year's work in
encouraging women of all ages to participate in the Free and Open Source
Software (FOSS) community. The WIOS conference will be held on Friday,
February 20th, prior to the 7th Annual So Cal Linux Expo. Widespread
acceptance and encouragement from the user community has established
SCALE as a premiere conference in the Southern California region.
2009 marks the seventh year that SCALE has been engaging and inspiring
the open source community in southern California. Our event is uniquely
community-based and attracts a wide variety of sponsors, non-profit groups,
user groups, and attendees.

Continuing our efforts to encourage women of all ages to be a part of the
Free and Open Source community, we invite you to showcase your work in the
Free and Open Source community. Join us in sharing recent accomplishments,
success stories, and advancements. Past attendees at this event have 
included
women in technology, teachers, and parents of young girls. As a woman, if
you've had experience working on an Free & Open Source project, 
deploying Free
and Open Source software or been involved in the Free and Open Source
community, please join us.

Widespread acceptance of the Linux Expo and participation by the user 
community
have established SCALE as the premiere Open Source conference in the 
Southwest.
2009 marks the seventh year that SCALE has been engaging and inspiring 
the open
source community. Our event is uniquely community-based and attracts a wide
variety of sponsors, non-profit groups, user groups, and attendees.

The Call For Papers for the Women In Open Source conference can be found 
here:
http://scale7x.socallinuxexpo.org/conference-info/women-in-open-source-call-for-papers

-- 
Gareth J. Greenaway  | g at socallinuxexpo.org
Voice - 877-831-2569 x130
Southern California Linux Expo
http://www.socallinuxexpo.org




From fedora at leemhuis.info  Wed Dec  3 06:57:29 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 03 Dec 2008 07:57:29 +0100
Subject: Server SIG - work areas
In-Reply-To: <1228140140.3664.72.camel@eagle.danny.cz>
References: <1228140140.3664.72.camel@eagle.danny.cz>
Message-ID: <49362DD9.9060601@leemhuis.info>

On 01.12.2008 15:02, Dan Hor?k wrote:
> [...]
> Admins corner
> [...]
>  - work on the TUI counterparts of GUI system-config-* tools, should go
> in hand with the backend/frontend separation

Just thinking aloud: By "TUI" you mean command line apps with a 
interactive, ncurses-like interface?

Are those really worth the work? I for one (and a lot of other linux 
users I know) either use graphical configuration Tools (with or without 
remote forwarding) or (if there is no graphical environment or in 
scripts) simple command line configuration tools (without an interactive 
interface) -- I doubt a third way in the middle (and a second one for 
text mode configuration) makes much sense. Improving some of the command 
line configuration tools (those without an interactive interface) OTOH 
might.

But well, maybe that just my odd point of view.

CU
knurd



From chris.stone at gmail.com  Wed Dec  3 07:22:08 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Tue, 2 Dec 2008 23:22:08 -0800
Subject: Server SIG - work areas
In-Reply-To: <1228140140.3664.72.camel@eagle.danny.cz>
References: <1228140140.3664.72.camel@eagle.danny.cz>
Message-ID: <d9c612bf0812022322v56ec7d5jd107a9848dd88f8@mail.gmail.com>

On Mon, Dec 1, 2008 at 6:02 AM, Dan Hor?k <dan at danny.cz> wrote:
> Hello,

Hi.

There are probably a ton of packages which Require optional desktop
dependencies, like gnuplot [1].  Identifying and splitting out the GUI
components of these packages is going to be your most difficult hurdle
I would guess.

Should we have a standard on how to name subpackages for optional
desktop dependencies?  Is everyone here willing to split up their
packages?

[1] http://lists.fedoraproject.org/pipermail/fedora-server-list/2008-December/000008.html



From dan at danny.cz  Wed Dec  3 07:27:51 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 03 Dec 2008 08:27:51 +0100
Subject: Server SIG - work areas
In-Reply-To: <49362DD9.9060601@leemhuis.info>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<49362DD9.9060601@leemhuis.info>
Message-ID: <1228289271.3625.32.camel@eagle.danny.cz>


Thorsten Leemhuis p??e v St 03. 12. 2008 v 07:57 +0100:
> On 01.12.2008 15:02, Dan Hor?k wrote:
> > [...]
> > Admins corner
> > [...]
> >  - work on the TUI counterparts of GUI system-config-* tools, should go
> > in hand with the backend/frontend separation
> 
> Just thinking aloud: By "TUI" you mean command line apps with a 
> interactive, ncurses-like interface?

yes

> Are those really worth the work? I for one (and a lot of other linux 
> users I know) either use graphical configuration Tools (with or without 
> remote forwarding) or (if there is no graphical environment or in 
> scripts) simple command line configuration tools (without an interactive 
> interface) -- I doubt a third way in the middle (and a second one for 
> text mode configuration) makes much sense. Improving some of the command 
> line configuration tools (those without an interactive interface) OTOH 
> might.
> 
> But well, maybe that just my odd point of view.

Well, naturally not every GUI tool needs TUI counterpart, but there are
users (and Red Hat customers) that would really appreciate when they
will exist. They offer more comfort than CLI, but require lower
resources.


		Dan




From nikolay at vladimiroff.com  Wed Dec  3 07:57:52 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Wed, 3 Dec 2008 09:57:52 +0200
Subject: rawhide status page.
In-Reply-To: <20081202214614.GA9959@redhat.com>
References: <20081202210734.GA6778@redhat.com>
	<20081202211330.GA837@nostromo.devel.redhat.com>
	<20081202212309.GB6778@redhat.com>
	<200812022128.mB2LSnHa007959@laptop14.inf.utfsm.cl>
	<20081202214614.GA9959@redhat.com>
Message-ID: <a2e85ed0812022357l5fbcc8f7o4917f140bb5b6e44@mail.gmail.com>

2008/12/2 Dave Jones <davej at redhat.com>:
> On Tue, Dec 02, 2008 at 06:28:49PM -0300, Horst H. von Brand wrote:
>
>  > > Not that it wouldn't be neat to have automated reports etc,
>  > > but I think it's overkill for the simple "is it busted" cases,
>  > > which will be the majority.
>  >
>  > How do you know if it is busted or not, before people scream it is?
>
> For the 'everyone will hit this' problems, it only takes one person
> to edit the wiki.
>
>        Dave
>
> --
> http://www.codemonkey.org.uk
>

Why not just use this list(like we do now)? If you use rawhide it's
almost certain that your subscribed to fedora-devel.
I like email. I will never go to some page to check if rawhide is
broken. I always update and hope for the best.
The point of rawhide is to be broken :). And if I mess up my  fedora
then I can test the rawhide install.


-- 
NV



From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec  3 08:26:25 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 03 Dec 2008 09:26:25 +0100
Subject: looking for inotifywait and similar help
In-Reply-To: <91705d080812022016q7e2bc529t3eb64c9c24ead925@mail.gmail.com>
	(Dan Nicholson's message of "Tue, 2 Dec 2008 20:16:54 -0800")
References: <20081202233031.GA30159@free.fr>
	<91705d080812022016q7e2bc529t3eb64c9c24ead925@mail.gmail.com>
Message-ID: <877i6hzmtq.fsf@sheridan.bigo.ensc.de>

"Dan Nicholson" <dbn.lists at gmail.com> writes:

>> However the issue I have is that I don't know how to have inotifywait
>> do something when /etc/crontab or /etc/fcrontab is created since if I
>> give a non-existing file as argument it will error out.
>
> I think if you want to catch file creation, you have to watch /etc,
> wait for create events and filter for the crontab files. So, I think
> it would have to be something like:
>
> out=`inotifywait -e create /etc`; do
> if [ $? = 0 ]; then
> ...

Beside the syntax error, there is a race when file was created shortly
before inotifywait. You have to check whether the file exists *after*
inotify_add_watch(2) like in

             https://www.cvg.de/people/ensc/wait-for-file.c


I filed a request a year ago to include similar functionality into
inotifytools but this does not seem to implemented yet

  http://sourceforge.net/mailarchive/message.php?msg_name=lylkdk440g.fsf%40ensc-pc.intern.sigma-chemnitz.de



Enrico



From nicolas.mailhot at laposte.net  Wed Dec  3 08:28:42 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 3 Dec 2008 09:28:42 +0100 (CET)
Subject: rawhide status page.
In-Reply-To: <a2e85ed0812022357l5fbcc8f7o4917f140bb5b6e44@mail.gmail.com>
References: <20081202210734.GA6778@redhat.com>
	<20081202211330.GA837@nostromo.devel.redhat.com>
	<20081202212309.GB6778@redhat.com>
	<200812022128.mB2LSnHa007959@laptop14.inf.utfsm.cl>
	<20081202214614.GA9959@redhat.com>
	<a2e85ed0812022357l5fbcc8f7o4917f140bb5b6e44@mail.gmail.com>
Message-ID: <e7ab25987637887a478c6e9ccfcf2a6f.squirrel@arekh.dyndns.org>



Le Mer 3 d?cembre 2008 08:57, Nikolay Vladimirov a ?crit :

> The point of rawhide is to be broken :).

No it isn't. The point of rawhide is to get different development
tracks in sync, in a non-broken state that can be QAed.


-- 
Nicolas Mailhot



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Dec  3 08:56:35 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 03 Dec 2008 17:56:35 +0900
Subject: rpms/elfinfo/devel elfinfo.spec,1.2,1.3
In-Reply-To: <20081203084407.4F78C7011D@cvs1.fedora.phx.redhat.com>
References: <20081203084407.4F78C7011D@cvs1.fedora.phx.redhat.com>
Message-ID: <493649C3.8060309@ioa.s.u-tokyo.ac.jp>

Parag Nemade wrote, at 12/03/2008 05:44 PM +9:00:
 
> Index: elfinfo.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/elfinfo/devel/elfinfo.spec,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- elfinfo.spec	3 Dec 2008 08:35:17 -0000	1.2
> +++ elfinfo.spec	3 Dec 2008 08:43:36 -0000	1.3
> @@ -13,7 +13,7 @@
>  This package can work without libelf.
>  
>  %prep
> -%setup -q
> +#%setup -q
>  
>  %build
>  make CFALGS="$RPM_OPT_FLAGS" %{?_smp_mflags} 
> 

This is not allowed. The correct method is to use "%setup -q -c".

Mamoru



From konrad at tylerc.org  Wed Dec  3 08:58:45 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 3 Dec 2008 00:58:45 -0800
Subject: rpms/elfinfo/devel elfinfo.spec,1.2,1.3
In-Reply-To: <493649C3.8060309@ioa.s.u-tokyo.ac.jp>
References: <20081203084407.4F78C7011D@cvs1.fedora.phx.redhat.com>
	<493649C3.8060309@ioa.s.u-tokyo.ac.jp>
Message-ID: <200812030058.45641.konrad@tylerc.org>

On Wednesday 03 December 2008 12:56:35 am Mamoru Tasaka wrote:
> Parag Nemade wrote, at 12/03/2008 05:44 PM +9:00:
> > Index: elfinfo.spec
> > ===================================================================
> > RCS file: /cvs/pkgs/rpms/elfinfo/devel/elfinfo.spec,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -r1.2 -r1.3
> > --- elfinfo.spec	3 Dec 2008 08:35:17 -0000	1.2
> > +++ elfinfo.spec	3 Dec 2008 08:43:36 -0000	1.3
> > @@ -13,7 +13,7 @@
> >  This package can work without libelf.
> >
> >  %prep
> > -%setup -q
> > +#%setup -q
> >
> >  %build
> >  make CFALGS="$RPM_OPT_FLAGS" %{?_smp_mflags}
>
> This is not allowed. The correct method is to use "%setup -q -c".
>
> Mamoru

Not to mention CFLAGS, not CFALGS.

-- 
Conrad Meyer <konrad at tylerc.org>




From panemade at gmail.com  Wed Dec  3 09:04:23 2008
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Wed, 3 Dec 2008 14:34:23 +0530
Subject: rpms/elfinfo/devel elfinfo.spec,1.2,1.3
In-Reply-To: <493649C3.8060309@ioa.s.u-tokyo.ac.jp>
References: <20081203084407.4F78C7011D@cvs1.fedora.phx.redhat.com>
	<493649C3.8060309@ioa.s.u-tokyo.ac.jp>
Message-ID: <f4586a2e0812030104y5fbd79ddlcc23b1861b2ebeb1@mail.gmail.com>

Hi,
On Wed, Dec 3, 2008 at 2:26 PM, Mamoru Tasaka
<mtasaka at ioa.s.u-tokyo.ac.jp>wrote:

> Parag Nemade wrote, at 12/03/2008 05:44 PM +9:00:
>
> > Index: elfinfo.spec
> > ===================================================================
> > RCS file: /cvs/pkgs/rpms/elfinfo/devel/elfinfo.spec,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -r1.2 -r1.3
> > --- elfinfo.spec      3 Dec 2008 08:35:17 -0000       1.2
> > +++ elfinfo.spec      3 Dec 2008 08:43:36 -0000       1.3
> > @@ -13,7 +13,7 @@
> >  This package can work without libelf.
> >
> >  %prep
> > -%setup -q
> > +#%setup -q
> >
> >  %build
> >  make CFALGS="$RPM_OPT_FLAGS" %{?_smp_mflags}
> >
>
> This is not allowed. The correct method is to use "%setup -q -c".
>

      Ahh. By mistake I removed that thing. Thanks. Fixed now.

>
> Mamoru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/ffa9f561/attachment.htm>

From kevin.kofler at chello.at  Wed Dec  3 09:16:17 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 10:16:17 +0100
Subject: Status of libtool 2.2.X?
References: <loom.20081011T161204-624@post.gmane.org>
	<1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <gh5ip1$401$1@ger.gmane.org>

Jens Petersen wrote:
> I would add:
> 
> * do not start new projects using autotools as far as possible

Of course. That's what CMake is for. :-)

My suggestions were for how to redesign the autotools so they actually stop
sucking, but I know very well that this is never going to happen.

        Kevin Kofler



From nikolay at vladimiroff.com  Wed Dec  3 09:16:29 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Wed, 3 Dec 2008 11:16:29 +0200
Subject: rawhide status page.
In-Reply-To: <e7ab25987637887a478c6e9ccfcf2a6f.squirrel@arekh.dyndns.org>
References: <20081202210734.GA6778@redhat.com>
	<20081202211330.GA837@nostromo.devel.redhat.com>
	<20081202212309.GB6778@redhat.com>
	<200812022128.mB2LSnHa007959@laptop14.inf.utfsm.cl>
	<20081202214614.GA9959@redhat.com>
	<a2e85ed0812022357l5fbcc8f7o4917f140bb5b6e44@mail.gmail.com>
	<e7ab25987637887a478c6e9ccfcf2a6f.squirrel@arekh.dyndns.org>
Message-ID: <a2e85ed0812030116s7374b65biff68b1af2e9862e7@mail.gmail.com>

2008/12/3 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>
>
> Le Mer 3 d?cembre 2008 08:57, Nikolay Vladimirov a ?crit :
>
>> The point of rawhide is to be broken :).
>
> No it isn't. The point of rawhide is to get different development
> tracks in sync, in a non-broken state that can be QAed.
>
>
> --
> Nicolas Mailhot
>
>Le Mer 3 d?cembre 2008 09:42, Nikolay Vladimirov a ?crit :
> You're right. This statement was intended to be humorous, reflecting
> on the general case that there is always something not working as it
> should(or as you expect it) .

2008/12/3 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>Such statements are dangerous because they lower tester expectations
>(causing them not to report problems or not to test at all) and
>confort packagers that dump broken packages in rawhide without
>pre-testing and without allocating time to process problem reports
>once testes complain.

I disagree. Just sharing my experience with rawhide.

-- 
NV



From kevin.kofler at chello.at  Wed Dec  3 09:22:00 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 10:22:00 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
Message-ID: <gh5j3o$5cp$1@ger.gmane.org>

Ralf Corsepius wrote:

> On Mon, 2008-12-01 at 22:28 -0500, Jens Petersen wrote:
>
>> I would add:
>> 
>> * do not start new projects using autotools as far as possible
> 
> I would recommend you to stop spreading FUD.

What FUD? There's an alternative which is:
* easier to learn,
* more portable,
* more backwards-compatible (with its own previous versions),
* faster,
* generating nicer makefiles (progress percentages, color output),
* designed in a better way (information is kept in central places instead of
being copied into hundreds of projects),
* used by more and more software, including big projects like KDE 4.

It's called CMake.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Dec  3 09:30:21 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 10:30:21 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<4934AC74.6050808@behdad.org>
Message-ID: <gh5jje$73c$1@ger.gmane.org>

Behdad Esfahbod wrote:
> Maybe you can offer an alternative?  And no, I don't mean reciting names
> of some hacks some cool kids may have put together for their birthday...

CMake, but...

> And not something that requires me to install it first before I can build
> this tarball I downloaded.

... this requirement is broken by design. As Conrad points out, you have to
install tools such as GCC, Binutils and Make anyway, why not CMake?

The perverse idea of allowing to build software using a certain build system
without actually installing that build system in the main reason the
autotools suck as much as they do. (It means relying on slow shell code
which is really ugly because it has to work around bugs of various obscure
systems' shells, and it means autogenerating files and passing them off
as "source code".) Not to mention that a *nix shell is actually harder to
install than a CMake binary on some systems. (Not all the world is a *nix.)

How hard is it to "yum install cmake"?

        Kevin Kofler



From rc040203 at freenet.de  Wed Dec  3 09:31:20 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 03 Dec 2008 10:31:20 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh5j3o$5cp$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
Message-ID: <1228296680.20451.1794.camel@beck.corsepiu.local>

On Wed, 2008-12-03 at 10:22 +0100, Kevin Kofler wrote:
> Ralf Corsepius wrote:
> 
> > On Mon, 2008-12-01 at 22:28 -0500, Jens Petersen wrote:
> >
> >> I would add:
> >> 
> >> * do not start new projects using autotools as far as possible
> > 
> > I would recommend you to stop spreading FUD.
> 
> What FUD? 
>
> There's an alternative which is:
> * easier to learn,
> * more portable,
> * more backwards-compatible (with its own previous versions),
> * faster,
> * generating nicer makefiles (progress percentages, color output),
> * designed in a better way (information is kept in central places instead of
> being copied into hundreds of projects),
> * used by more and more software, including big projects like KDE 4.
> 
> It's called CMake.
See, all FUD, you simply are spraying hatred against something you don't
understand or don't want to understand.

To me, cmake is
* not easier to learn, just different
* non-portable/inflexible.
* overladden with non-helpful gimmicks like progress percentages and
color output
* a crack ridden design (using a central database), reinvention of
imake, comprising it's design flaws.
* a kde proprietary tool.






From panemade at gmail.com  Wed Dec  3 09:36:48 2008
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Wed, 3 Dec 2008 15:06:48 +0530
Subject: rpms/elfinfo/devel elfinfo.spec,1.2,1.3
In-Reply-To: <200812030058.45641.konrad@tylerc.org>
References: <20081203084407.4F78C7011D@cvs1.fedora.phx.redhat.com>
	<493649C3.8060309@ioa.s.u-tokyo.ac.jp>
	<200812030058.45641.konrad@tylerc.org>
Message-ID: <f4586a2e0812030136s3ba8a3dbh2cf03790a8ccfb42@mail.gmail.com>

Hi all,
On Wed, Dec 3, 2008 at 2:28 PM, Conrad Meyer <konrad at tylerc.org> wrote:

> On Wednesday 03 December 2008 12:56:35 am Mamoru Tasaka wrote:
> > Parag Nemade wrote, at 12/03/2008 05:44 PM +9:00:
> > > Index: elfinfo.spec
> > > ===================================================================
> > > RCS file: /cvs/pkgs/rpms/elfinfo/devel/elfinfo.spec,v
> > > retrieving revision 1.2
> > > retrieving revision 1.3
> > > diff -u -r1.2 -r1.3
> > > --- elfinfo.spec    3 Dec 2008 08:35:17 -0000       1.2
> > > +++ elfinfo.spec    3 Dec 2008 08:43:36 -0000       1.3
> > > @@ -13,7 +13,7 @@
> > >  This package can work without libelf.
> > >
> > >  %prep
> > > -%setup -q
> > > +#%setup -q
> > >
> > >  %build
> > >  make CFALGS="$RPM_OPT_FLAGS" %{?_smp_mflags}
> >
> > This is not allowed. The correct method is to use "%setup -q -c".
> >
> > Mamoru
>
> Not to mention CFLAGS, not CFALGS.
>

     Looks like beacuse of this mistake elfinfo was building fine
previously. But now after correcting it, build is failed. But if i remove
CFLAGS then build is sucessfull.

Regards,
Parag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/ec90d87e/attachment.htm>

From konrad at tylerc.org  Wed Dec  3 09:36:45 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 3 Dec 2008 01:36:45 -0800
Subject: Status of libtool 2.2.X?
In-Reply-To: <1228296680.20451.1794.camel@beck.corsepiu.local>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
Message-ID: <200812030136.45621.konrad@tylerc.org>

On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote:
> On Wed, 2008-12-03 at 10:22 +0100, Kevin Kofler wrote:
> > Ralf Corsepius wrote:
> > > On Mon, 2008-12-01 at 22:28 -0500, Jens Petersen wrote:
> > >> I would add:
> > >>
> > >> * do not start new projects using autotools as far as possible
> > >
> > > I would recommend you to stop spreading FUD.
> >
> > What FUD?
> >
> > There's an alternative which is:
> > * easier to learn,
> > * more portable,
> > * more backwards-compatible (with its own previous versions),
> > * faster,
> > * generating nicer makefiles (progress percentages, color output),
> > * designed in a better way (information is kept in central places instead
> > of being copied into hundreds of projects),
> > * used by more and more software, including big projects like KDE 4.
> >
> > It's called CMake.
>
> See, all FUD, you simply are spraying hatred against something you don't
> understand or don't want to understand.
>
> To me, cmake is
> * not easier to learn, just different

Learning a new thing is always different. He's not telling you it's easier for 
*you* to learn something new than something *you* already know, but that it's 
easier for someone unfamiliar with autotools nor CMake to learn CMake than 
autotools.

> * non-portable/inflexible.

"FUD! FUD!"

> * overladden with non-helpful gimmicks like progress percentages and
> color output

Agreed, but it's not like they get in the way.

> * a crack ridden design (using a central database), reinvention of
> imake, comprising it's design flaws.

Reinvention of build-system-tools-in-general. Like a new version of autotools 
(they don't pretend to be backwards compatible).

> * a kde proprietary tool.

Uh, what?

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From rjones at redhat.com  Wed Dec  3 10:05:01 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 3 Dec 2008 10:05:01 +0000
Subject: FHS violations
In-Reply-To: <gh1j5m$b66$1@ger.gmane.org>
References: <20081201211122.994a7940.mschwendt@gmail.com>
	<gh1j5m$b66$1@ger.gmane.org>
Message-ID: <20081203100501.GA2008@thinkpad.nomadix.com>

On Mon, Dec 01, 2008 at 09:58:29PM +0100, Kevin Kofler wrote:
> Michael Schwendt wrote:
> > Contrary to that, package "spu-binutils" creates directories
> > 
> >   /spu
> >   /usr/spu
> > 
> > which is a violation of the FHS. And I've been told there are more
> > packages that do something similar.
> 
> It's a cross-toolchain. Using a directory like this is the established
> practice for GNU cross-toolchains (and also used by some other
> cross-toolchains) and the consensus among Fedora packagers working on
> cross-compilation is that this is the way to go. Unfortunately, the
> guideline which was supposed to formally codify it never made it to an FPC
> vote because of process issues.

MinGW uses /usr/i686-pc-mingw32.  I don't really like it, but it's
what gcc wants to use, and everything depends on it.  We also formally
had the use of this path approved (just for mingw32-* packages) by FPC.

Rich.



From ralph+fedora at strg-alt-entf.org  Wed Dec  3 10:04:37 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Wed, 3 Dec 2008 11:04:37 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <200812030136.45621.konrad@tylerc.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<200812030136.45621.konrad@tylerc.org>
Message-ID: <20081203100437.GM1499@br-online.de>

Conrad Meyer wrote:
> On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote:
> > See, all FUD, you simply are spraying hatred against something you don't
> > understand or don't want to understand.
[...]
> > * a kde proprietary tool.
> 
> Uh, what?

FUD >:)

Cheers,

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/167a1171/attachment.sig>

From kevin.kofler at chello.at  Wed Dec  3 10:09:03 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 11:09:03 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
Message-ID: <gh5ls0$edm$1@ger.gmane.org>

Ralf Corsepius wrote:
> See, all FUD, you simply are spraying hatred against something you don't
> understand or don't want to understand.

Your reply is the FUD. ;-)

> To me, cmake is
> * not easier to learn, just different

Probably because you already learned the autotools, so you don't notice its
learning curve anymore. Or you just haven't really tried CMake yet and so
don't know how easy it is to get things done in it.

The fact is, the autotools are a PITA to really understand. Things like:
* when what file needs regenerating and/or gets automatically regenerated
during make and why,
* m4's arcane syntax, including considerations like when to quote things
where, but also just the syntax itself (dnl for comments, [] for quoting
etc.)
and some other stuff work like black magic. (The first issue is also why
the "autoreconf" sledgehammer, which got frowned upon earlier in this
thread by some libtool developer(s), exists.)

Then there's also the fact that there are too many tools: with CMake, you
write all the definitions in one language/syntax, and it's up to you
whether you want it all in one CMakeLists.txt or in several (e.g. one per
directory, you can also have Find*.cmake files for library detection code,
though those usually ought to be provided centrally, and finally you can
also include any arbitrarily-named file). With the autotools, you have to
provide at least 2 files (configure.ac and Makefile.am) with completely
different syntax. And configure.ac itself is a mix of shell and m4. You
also have to manually list all the makefiles to generate in configure.ac
even if automake already knows about them, because autoconf doesn't.
(Something I keep forgetting when I add a subdirectory to an
autotools-using project.)

> * non-portable/inflexible.

How is it not portable? It works on all the major platforms and getting it
to work on some obscure *nix system is fairly easy. As for non-*nix
systems, good luck getting the autotools to work on those! They can't even
cope with Window$ without workarounds like MSYS. CMake can be ported to
basically anything which supports C++.

And it's really more flexible than you think.

> * overladden with non-helpful gimmicks like progress percentages and
> color output

You can call color output a "non-helpful gimmick" (though it really helps
visually separating the lines just saying what is being built from any
error or warning messages), but progress percentages are definitely useful!
Do you not want to know how far your build actually is?

> * a crack ridden design (using a central database), reinvention of
> imake, comprising it's design flaws.

It's not crack-ridden, it allows fixing any bugs in a single central place.
It also saves disk space. And if you really need to provide your own
Find*.cmake files, you can. CMake is flexible like that.

I haven't used imake so I don't know how it compares to that.

> * a kde proprietary tool.

Not true. CMake has been developed by Kitware for use in other projects, it
got adopted by KDE only later. It has not been developed specifically for
KDE. And several non-KDE projects are also switching to it. CMake is not
KDE-specific.

And no, it's not proprietary in the sense of "proprietary software" either,
but I think you know that already. ;-)

        Kevin Kofler



From rjones at redhat.com  Wed Dec  3 10:10:27 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 3 Dec 2008 10:10:27 +0000
Subject: Status of libtool 2.2.X?
In-Reply-To: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <loom.20081011T161204-624@post.gmane.org>
	<1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <20081203101027.GB2008@thinkpad.nomadix.com>

On Mon, Dec 01, 2008 at 10:28:53PM -0500, Jens Petersen wrote:
> I would add:
> 
> * do not start new projects using autotools as far as possible

This is stupid advice.  Autotools is by far the easiest way to build
successfully on all platforms, and to cross-compile code.  I invite
you to try cross-compiling (for example) gtk2 versus boost, and you
will see that writing your own build system, or using a lesser build
system that doesn't have all the experience behind it of autotools (or
cmake), is an idiotic idea.

Rich.



From rc040203 at freenet.de  Wed Dec  3 10:10:28 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 03 Dec 2008 11:10:28 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081203100437.GM1499@br-online.de>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<200812030136.45621.konrad@tylerc.org>
	<20081203100437.GM1499@br-online.de>
Message-ID: <1228299028.20451.1858.camel@beck.corsepiu.local>

On Wed, 2008-12-03 at 11:04 +0100, Ralph Angenendt wrote:
> Conrad Meyer wrote:
> > On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote:
> > > See, all FUD, you simply are spraying hatred against something you don't
> > > understand or don't want to understand.
> [...]
> > > * a kde proprietary tool.
> > 
> > Uh, what?
> 
> FUD >:)
No, it's a badly formulated sentence.

Should better have been something as "A tool with marginal importance
outside of KDE".






From mschwendt at gmail.com  Wed Dec  3 10:17:36 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 3 Dec 2008 11:17:36 +0100
Subject: rpms/elfinfo/devel elfinfo.spec,1.2,1.3
In-Reply-To: <f4586a2e0812030136s3ba8a3dbh2cf03790a8ccfb42@mail.gmail.com>
References: <20081203084407.4F78C7011D@cvs1.fedora.phx.redhat.com>
	<493649C3.8060309@ioa.s.u-tokyo.ac.jp>
	<200812030058.45641.konrad@tylerc.org>
	<f4586a2e0812030136s3ba8a3dbh2cf03790a8ccfb42@mail.gmail.com>
Message-ID: <20081203111736.b9b2d725.mschwendt@gmail.com>

On Wed, 3 Dec 2008 15:06:48 +0530, Parag wrote:

>      Looks like beacuse of this mistake elfinfo was building fine
> previously. But now after correcting it, build is failed. But if i remove
> CFLAGS then build is sucessfull.

Veto.

Fix it please. Patch attached.

Also note that running programs in quiet make mode (like "@gcc") is
something your reviewer should have blocked in reviews. We want build
output in the logs.

-- 
Michael Schwendt <mschwendt at fedoraproject.org>
Fedora release 10 (Cambridge) - Linux 2.6.27.5-117.fc10.i686
loadavg: 1.11 1.19 1.21
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elfinfo-1.1-build.patch
Type: application/octet-stream
Size: 439 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/b20d4aa1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elfinfo.spec.patch
Type: application/octet-stream
Size: 909 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/b20d4aa1/attachment-0001.obj>

From rc040203 at freenet.de  Wed Dec  3 10:21:10 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 03 Dec 2008 11:21:10 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <200812030136.45621.konrad@tylerc.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<200812030136.45621.konrad@tylerc.org>
Message-ID: <1228299670.20451.1879.camel@beck.corsepiu.local>

On Wed, 2008-12-03 at 01:36 -0800, Conrad Meyer wrote:
> On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote:
> > On Wed, 2008-12-03 at 10:22 +0100, Kevin Kofler wrote:
> > > Ralf Corsepius wrote:
> > > > On Mon, 2008-12-01 at 22:28 -0500, Jens Petersen wrote:
> > > >> I would add:
> > > >>
> > > >> * do not start new projects using autotools as far as possible
> > > >
> > > > I would recommend you to stop spreading FUD.
> > >
> > > What FUD?
> > >
> > > There's an alternative which is:
> > > * easier to learn,
> > > * more portable,
> > > * more backwards-compatible (with its own previous versions),
> > > * faster,
> > > * generating nicer makefiles (progress percentages, color output),
> > > * designed in a better way (information is kept in central places instead
> > > of being copied into hundreds of projects),
> > > * used by more and more software, including big projects like KDE 4.
> > >
> > > It's called CMake.
> >
> > See, all FUD, you simply are spraying hatred against something you don't
> > understand or don't want to understand.
> >
> > To me, cmake is
> > * not easier to learn, just different
> 
> Learning a new thing is always different. He's not telling you it's easier for 
> *you* to learn something new than something *you* already know, but that it's 
> easier for someone unfamiliar with autotools nor CMake to learn CMake than 
> autotools.

I would agree to "it's very simple to get into cmake for trivial cases".

For slightly non trivial cases, the autotools and cmake are more or less
on par wrt. difficulties. 

For complex cases, the flexibility the autotools provide pay off very
soon. On the downside, it's very easy to shoot yourselves into the foot
with them.

> > * non-portable/inflexible.
> 
> "FUD! FUD!"
Absolutely not: Try to bring cmake to a new OS and you'll experience the difference.

> > * a crack ridden design (using a central database), reinvention of
> > imake, comprising it's design flaws.
> 
> Reinvention of build-system-tools-in-general. Like a new version of autotools 
> (they don't pretend to be backwards compatible).
The autotools do not apply a central data base, they keep
"configuration" and "installation" as separate jobs. cmake lumps them
together.

It's a different approach.




From opensource at till.name  Wed Dec  3 10:24:06 2008
From: opensource at till.name (Till Maas)
Date: Wed, 03 Dec 2008 11:24:06 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh5ls0$edm$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org>
Message-ID: <200812031124.11838.opensource@till.name>

On Wed December 3 2008, Kevin Kofler wrote:
> Ralf Corsepius wrote:

> > * overladden with non-helpful gimmicks like progress percentages and
> > color output
>
> You can call color output a "non-helpful gimmick" (though it really helps
> visually separating the lines just saying what is being built from any
> error or warning messages), but progress percentages are definitely useful!
> Do you not want to know how far your build actually is?

I am only interested to know, when it finished. But this is already taken care 
of by koji. :-)
Is it possible to disable the progress percentages? It looks to me, that it 
increases the build.log with a lot of lines. Or does it somehow help to know 
at which percentage a build failed?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/ab55dd1b/attachment.sig>

From rjones at redhat.com  Wed Dec  3 10:29:19 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 3 Dec 2008 10:29:19 +0000
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh5j3o$5cp$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
Message-ID: <20081203102859.GC2008@thinkpad.nomadix.com>

On Wed, Dec 03, 2008 at 10:22:00AM +0100, Kevin Kofler wrote:
> It's called CMake.

CMake is the only alternative I'd recommend, *but* it's still not done
right.  A good alternative would be a purely declarative language
which integrates well with other declarative systems of dependencies
(eg. RPM's BuildRequires).  I've not seen anything like that which is,
at the same time, at the level of completeness of autotools or cmake.

Rich.



From rc040203 at freenet.de  Wed Dec  3 10:31:14 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 03 Dec 2008 11:31:14 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <200812031124.11838.opensource@till.name>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org> <200812031124.11838.opensource@till.name>
Message-ID: <1228300274.20451.1893.camel@beck.corsepiu.local>

On Wed, 2008-12-03 at 11:24 +0100, Till Maas wrote:
> On Wed December 3 2008, Kevin Kofler wrote:
> > Ralf Corsepius wrote:
> 
> > > * overladden with non-helpful gimmicks like progress percentages and
> > > color output
> >
> > You can call color output a "non-helpful gimmick" (though it really helps
> > visually separating the lines just saying what is being built from any
> > error or warning messages), but progress percentages are definitely useful!
> > Do you not want to know how far your build actually is?
> 
> I am only interested to know, when it finished.
The color gimmicks help you better than the lines displaying what the
tools underneath are doing?

Pardon, but this logic escapes me.

>  But this is already taken care 
> of by koji. :-)

As a developer, maintainer and/or packager you normally want to see what
the tools are doing, e.g. if the compiler has received the correct
flags, is using the correct libraries etc.

Ralf




From konrad at tylerc.org  Wed Dec  3 10:36:43 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 3 Dec 2008 02:36:43 -0800
Subject: Status of libtool 2.2.X?
In-Reply-To: <1228299670.20451.1879.camel@beck.corsepiu.local>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812030136.45621.konrad@tylerc.org>
	<1228299670.20451.1879.camel@beck.corsepiu.local>
Message-ID: <200812030236.43778.konrad@tylerc.org>

On Wednesday 03 December 2008 02:21:10 am Ralf Corsepius wrote:
> On Wed, 2008-12-03 at 01:36 -0800, Conrad Meyer wrote:
> > On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote:
> > > To me, cmake is
> > > * not easier to learn, just different
> >
> > Learning a new thing is always different. He's not telling you it's
> > easier for *you* to learn something new than something *you* already
> > know, but that it's easier for someone unfamiliar with autotools nor
> > CMake to learn CMake than autotools.
>
> I would agree to "it's very simple to get into cmake for trivial cases".
>
> For slightly non trivial cases, the autotools and cmake are more or less
> on par wrt. difficulties.
>
> For complex cases, the flexibility the autotools provide pay off very
> soon. On the downside, it's very easy to shoot yourselves into the foot
> with them.
>
> > > * non-portable/inflexible.
> >
> > "FUD! FUD!"
>
> Absolutely not: Try to bring cmake to a new OS and you'll experience the
> difference.

What "new OS" has come out in the past 5 years or so that CMake doesn't 
already support?

> > > * a crack ridden design (using a central database), reinvention of
> > > imake, comprising it's design flaws.
> >
> > Reinvention of build-system-tools-in-general. Like a new version of
> > autotools (they don't pretend to be backwards compatible).
>
> The autotools do not apply a central data base, they keep
> "configuration" and "installation" as separate jobs. cmake lumps them
> together.
>
> It's a different approach.

Saves resources on koji, if nothing less.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From panemade at gmail.com  Wed Dec  3 10:39:44 2008
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Wed, 3 Dec 2008 16:09:44 +0530
Subject: rpms/elfinfo/devel elfinfo.spec,1.2,1.3
In-Reply-To: <20081203111736.b9b2d725.mschwendt@gmail.com>
References: <20081203084407.4F78C7011D@cvs1.fedora.phx.redhat.com>
	<493649C3.8060309@ioa.s.u-tokyo.ac.jp>
	<200812030058.45641.konrad@tylerc.org>
	<f4586a2e0812030136s3ba8a3dbh2cf03790a8ccfb42@mail.gmail.com>
	<20081203111736.b9b2d725.mschwendt@gmail.com>
Message-ID: <f4586a2e0812030239h5d24d85cr412d74bddacea3f8@mail.gmail.com>

Hi,

2008/12/3 Michael Schwendt <mschwendt at gmail.com>

> On Wed, 3 Dec 2008 15:06:48 +0530, Parag wrote:
>
> >      Looks like beacuse of this mistake elfinfo was building fine
> > previously. But now after correcting it, build is failed. But if i remove
> > CFLAGS then build is sucessfull.
>
> Veto.
>
> Fix it please. Patch attached.
>
> Also note that running programs in quiet make mode (like "@gcc") is
> something your reviewer should have blocked in reviews. We want build
> output in the logs.
>

      Thanks for your patches. Unfortunately, I was the reviewer for this
package and took over from initial ower in F11/EPEL branch. I will make sure
this to check "@gcc" thing now onwards.
Regards,
Parag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/0fb1615b/attachment.htm>

From opensource at till.name  Wed Dec  3 10:46:13 2008
From: opensource at till.name (Till Maas)
Date: Wed, 03 Dec 2008 11:46:13 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <1228300274.20451.1893.camel@beck.corsepiu.local>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812031124.11838.opensource@till.name>
	<1228300274.20451.1893.camel@beck.corsepiu.local>
Message-ID: <200812031146.18966.opensource@till.name>

On Wed December 3 2008, Ralf Corsepius wrote:
> On Wed, 2008-12-03 at 11:24 +0100, Till Maas wrote:
> > On Wed December 3 2008, Kevin Kofler wrote:
> > > Ralf Corsepius wrote:
> > > > * overladden with non-helpful gimmicks like progress percentages and
> > > > color output
> > >
> > > You can call color output a "non-helpful gimmick" (though it really
> > > helps visually separating the lines just saying what is being built
> > > from any error or warning messages), but progress percentages are
> > > definitely useful! Do you not want to know how far your build actually
> > > is?
> >
> > I am only interested to know, when it finished.
>
> The color gimmicks help you better than the lines displaying what the
> tools underneath are doing?

No, but I also see no colors in the build.log file. :-) I do not need any 
progress report, because I only care when it is finished.

> Pardon, but this logic escapes me.
>
> >  But this is already taken care
> > of by koji. :-)
>
> As a developer, maintainer and/or packager you normally want to see what
> the tools are doing, e.g. if the compiler has received the correct
> flags, is using the correct libraries etc.

Yes, this is already taken care of in %cmake in rawhide, it makes at least the 
compiler flags visible in the make.log. Previously this could be achieved 
with VERBOSE=1 in the make invocation. This is also written in the cmake 
guidelines btw. If you read my complete mail, you can see that I complained 
about the progress percentages, because they fill up the build.log.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/463ed9fa/attachment.sig>

From rc040203 at freenet.de  Wed Dec  3 10:55:40 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 03 Dec 2008 11:55:40 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <200812030236.43778.konrad@tylerc.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812030136.45621.konrad@tylerc.org>
	<1228299670.20451.1879.camel@beck.corsepiu.local>
	<200812030236.43778.konrad@tylerc.org>
Message-ID: <1228301740.20451.1934.camel@beck.corsepiu.local>

On Wed, 2008-12-03 at 02:36 -0800, Conrad Meyer wrote:
> On Wednesday 03 December 2008 02:21:10 am Ralf Corsepius wrote:
> > On Wed, 2008-12-03 at 01:36 -0800, Conrad Meyer wrote:
> > > On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote:
> > > > To me, cmake is
> > > > * not easier to learn, just different
> > >
> > > Learning a new thing is always different. He's not telling you it's
> > > easier for *you* to learn something new than something *you* already
> > > know, but that it's easier for someone unfamiliar with autotools nor
> > > CMake to learn CMake than autotools.
> >
> > I would agree to "it's very simple to get into cmake for trivial cases".
> >
> > For slightly non trivial cases, the autotools and cmake are more or less
> > on par wrt. difficulties.
> >
> > For complex cases, the flexibility the autotools provide pay off very
> > soon. On the downside, it's very easy to shoot yourselves into the foot
> > with them.
> >
> > > > * non-portable/inflexible.
> > >
> > > "FUD! FUD!"
> >
> > Absolutely not: Try to bring cmake to a new OS and you'll experience the
> > difference.
> 
> What "new OS" has come out in the past 5 years or so that CMake doesn't 
> already support?
That's the same school of thought which had killed imake.

It dominated the world for almost a decade, then came Linux and the
databases became unmaintainable, the X-consortium et.al. divorced, ...

> > > > * a crack ridden design (using a central database), reinvention of
> > > > imake, comprising it's design flaws.
> > >
> > > Reinvention of build-system-tools-in-general. Like a new version of
> > > autotools (they don't pretend to be backwards compatible).
> >
> > The autotools do not apply a central data base, they keep
> > "configuration" and "installation" as separate jobs. cmake lumps them
> > together.
> >
> > It's a different approach.
> 
> Saves resources on koji, if nothing less.
It doesn't do so. The only difference is cmake carrying a vendor's
preferences inside of itself, instead of rpm (from where autotools based
configurations receive it).

Helps vendors and package suites which are living in their "own
solarsystem" (such as KDE), but isn't helpful in most other cases.

Ralf




From d.lesca at solinos.it  Wed Dec  3 11:00:03 2008
From: d.lesca at solinos.it (Dario Lesca)
Date: Wed, 03 Dec 2008 12:00:03 +0100
Subject: f10.x86_64: laptop HP: Problem to see all 4Gb of memory
Message-ID: <1228302003.5911.192.camel@lesca>

Hi, I have install 4Gb of ram on this HP Pavilion dv6000 laptop:
http://www.smolts.org/client/show_all/pub_4d5ac78f-b263-4f95-a26d-5d248e5659aa

The BIOS showed only 3Gb of RAM.

Then I have update the BIOS with last version released from HP.

Now the BIOS show correctly 4Gb of RAM, but Fedora10 x86_64 show only
3Gb of RAM (also smolt show 3Gb of RAM):
> [root at lesca ~]# free
>              total       used       free     shared    buffers     cached
> Mem:       3093172    2771984     321188          0       1712    1549504
> -/+ buffers/cache:    1220768    1872404
> Swap:      6291448      93716    6197732

On this laptop I have test also Fedora9 with last kernel-PAE-x.x.x.i686
but also in this case the memori show is only 3Gb.

Some suggest?

Is a BIOS problem?

Thanks for reply.

-- 
Dario Lesca <d.lesca at solinos.it>



From nicolas.mailhot at laposte.net  Wed Dec  3 11:44:36 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 3 Dec 2008 12:44:36 +0100 (CET)
Subject: f10.x86_64: laptop HP: Problem to see all 4Gb of memory
In-Reply-To: <1228302003.5911.192.camel@lesca>
References: <1228302003.5911.192.camel@lesca>
Message-ID: <ec94d098731e690c93f4c2bb8c947cf6.squirrel@arekh.dyndns.org>



Le Mer 3 d?cembre 2008 12:00, Dario Lesca a ?crit :

> Some suggest?

Run the Intel Linux Firmware Kit and report errors to your vendor
http://linuxfirmwarekit.org/

Regards,

-- 
Nicolas Mailhot



From vonbrand at inf.utfsm.cl  Wed Dec  3 12:23:10 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 03 Dec 2008 09:23:10 -0300
Subject: Server SIG - work areas
In-Reply-To: <49362DD9.9060601@leemhuis.info>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<49362DD9.9060601@leemhuis.info>
Message-ID: <200812031223.mB3CNAUZ008660@laptop14.inf.utfsm.cl>

Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> On 01.12.2008 15:02, Dan Hor??k wrote:
> > [...]
> > Admins corner
> > [...]
> >  - work on the TUI counterparts of GUI system-config-* tools, should go
> > in hand with the backend/frontend separation
> 
> Just thinking aloud: By "TUI" you mean command line apps with a
> interactive, ncurses-like interface?
> 
> Are those really worth the work? I for one (and a lot of other linux
> users I know) either use graphical configuration Tools (with or
> without remote forwarding) or (if there is no graphical environment or
> in scripts) simple command line configuration tools (without an
> interactive interface) -- I doubt a third way in the middle (and a
> second one for text mode configuration) makes much sense. Improving
> some of the command line configuration tools (those without an
> interactive interface) OTOH might.
> 
> But well, maybe that just my odd point of view.

Two odds make an even? ;-)


Fully agree. But please, CLI tools with complete manpages and --help.
-- 
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 vonbrand at inf.utfsm.cl  Wed Dec  3 12:24:31 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 03 Dec 2008 09:24:31 -0300
Subject: Server SIG - work areas
In-Reply-To: <d9c612bf0812022322v56ec7d5jd107a9848dd88f8@mail.gmail.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<d9c612bf0812022322v56ec7d5jd107a9848dd88f8@mail.gmail.com>
Message-ID: <200812031224.mB3COVpB008672@laptop14.inf.utfsm.cl>

Christopher Stone <chris.stone at gmail.com> wrote:
> On Mon, Dec 1, 2008 at 6:02 AM, Dan Hor??k <dan at danny.cz> wrote:
> > Hello,
> 
> Hi.
> 
> There are probably a ton of packages which Require optional desktop
> dependencies, like gnuplot [1].  Identifying and splitting out the GUI
> components of these packages is going to be your most difficult hurdle
> I would guess.

Sorry, but I see little use for gnuplot on a server. And if needed, it will
have some GUI.

Please enligthen.
-- 
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 vonbrand at inf.utfsm.cl  Wed Dec  3 12:27:23 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 03 Dec 2008 09:27:23 -0300
Subject: rawhide status page.
In-Reply-To: <a2e85ed0812030116s7374b65biff68b1af2e9862e7@mail.gmail.com>
References: <20081202210734.GA6778@redhat.com>
	<20081202211330.GA837@nostromo.devel.redhat.com>
	<20081202212309.GB6778@redhat.com>
	<200812022128.mB2LSnHa007959@laptop14.inf.utfsm.cl>
	<20081202214614.GA9959@redhat.com>
	<a2e85ed0812022357l5fbcc8f7o4917f140bb5b6e44@mail.gmail.com>
	<e7ab25987637887a478c6e9ccfcf2a6f.squirrel@arekh.dyndns.org>
	<a2e85ed0812030116s7374b65biff68b1af2e9862e7@mail.gmail.com>
Message-ID: <200812031227.mB3CRNtG008696@laptop14.inf.utfsm.cl>

Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> 2008/12/3 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> > Le Mer 3 d??cembre 2008 08:57, Nikolay Vladimirov a ??crit :
> >
> >> The point of rawhide is to be broken :).
> >
> > No it isn't. The point of rawhide is to get different development
> > tracks in sync, in a non-broken state that can be QAed.

> >Le Mer 3 d??cembre 2008 09:42, Nikolay Vladimirov a ??crit :
> > You're right. This statement was intended to be humorous, reflecting
> > on the general case that there is always something not working as it
> > should(or as you expect it) .

> 2008/12/3 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> >Such statements are dangerous because they lower tester expectations
> >(causing them not to report problems or not to test at all) and
> >confort packagers that dump broken packages in rawhide without
> >pre-testing and without allocating time to process problem reports
> >once testes complain.

> I disagree. Just sharing my experience with rawhide.

Yes, rawhide is a bit broken most of the time. Yes, that does lower my
expectations somewhat. No, it doesn't cause me not to report problems, I
run rawhide precisely because I want to help out a bit by testing and
reporting problems.
-- 
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 andreas at bawue.net  Wed Dec  3 12:34:48 2008
From: andreas at bawue.net (Andreas Thienemann)
Date: Wed, 3 Dec 2008 13:34:48 +0100 (CET)
Subject: Server SIG - work areas
In-Reply-To: <200812031224.mB3COVpB008672@laptop14.inf.utfsm.cl>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<d9c612bf0812022322v56ec7d5jd107a9848dd88f8@mail.gmail.com>
	<200812031224.mB3COVpB008672@laptop14.inf.utfsm.cl>
Message-ID: <Pine.LNX.4.61.0812031332220.6625@gonzo.dicp.de>

On Wed, 3 Dec 2008, Horst H. von Brand wrote:

> Sorry, but I see little use for gnuplot on a server. And if needed, it will
> have some GUI.
>
> Please enligthen.

Think webserver generating plots. Incidentially, I'm sometimes using a 
traffic monitoring server which uses gnuplot to generate ping time 
statistic. IIRC the server in question has a "special" RPM preventing 
linking against the desktop stack.

But there are other unsolved problems: e.g. php-gd pulled in half of the 
X11 stack for a long time, I think this was partly fixed by now but the 
dependency chain is still quite long.

regards,
  andreas



From j.w.r.degoede at hhs.nl  Wed Dec  3 13:24:36 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 03 Dec 2008 14:24:36 +0100
Subject: Heads up: new soname changing cegui heading towards rawhide
Message-ID: <49368894.1060902@hhs.nl>

Hi All,

A new cegui (0.6.2) is on its way to rawhide, this changes the soname and thus
needs all dependend packages to be rebuild:

[hans at localhost devel]$ repoquery -q --whatrequires --alldeps cegui
chess-0:1.0-21.fc11.x86_64
ember-0:0.5.4-4.fc11.x86_64
ogre-samples-0:1.6.0-1.fc11.x86_64
TnL-0:071111-7.fc10.x86_64
crystalspace-0:1.2.1-1.fc10.x86_64

I will be taking care of all of these myself except for ember.

Regards,

Hans



From mjg at redhat.com  Wed Dec  3 13:21:37 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 3 Dec 2008 13:21:37 +0000
Subject: f10.x86_64: laptop HP: Problem to see all 4Gb of memory
In-Reply-To: <1228302003.5911.192.camel@lesca>
References: <1228302003.5911.192.camel@lesca>
Message-ID: <20081203132137.GA16513@srcf.ucam.org>

On Wed, Dec 03, 2008 at 12:00:03PM +0100, Dario Lesca wrote:

> Now the BIOS show correctly 4Gb of RAM, but Fedora10 x86_64 show only
> 3Gb of RAM (also smolt show 3Gb of RAM):
> > [root at lesca ~]# free
> >              total       used       free     shared    buffers     cached
> > Mem:       3093172    2771984     321188          0       1712    1549504
> > -/+ buffers/cache:    1220768    1872404
> > Swap:      6291448      93716    6197732

You have a 945 chipset. It can only address 4GB of physical address 
space, and some of that address space has to be used to provide access 
to PCI devices. It's common for a gigabyte or so to be reserved for 
that, which means that you get a maximum of 3GB. You'll need a more 
modern motherboard chipset if you want to support more.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From rawhide at fedoraproject.org  Wed Dec  3 13:38:37 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed,  3 Dec 2008 13:38:37 +0000 (UTC)
Subject: rawhide report: 20081203 changes
Message-ID: <20081203133837.4CC721F825E@releng2.fedora.phx.redhat.com>

Compose started at Wed Dec  3 06:01:11 UTC 2008

New package afuse
        An automounter implemented with FUSE
New package eclipse-shelled
        Eclipse Shell script editor
New package ivtv-utils
        Tools for the iTVC15/16 and CX23415/16 driver
New package lzip
        LZMA compressor with integrity checking
New package rubygem-rack
        Common API for connecting web frameworks, web servers and layers of software
New package seahorse
        A GNOME application for managing encryption keys
Removed package gnome-keyring-manager
Updated Packages:

ace-0.0.3-7.fc11
----------------
* Tue Dec  2 17:00:00 2008 Bryan Kearney <bkearney at redhat.com> 0.0.3-7
- Modify the build requires to include the ruby binary

* Tue Dec  2 17:00:00 2008 Bryan Kearney <bkearney at redhat.com> 0.0.3-6
- Modify the build requires to get the sitelibdir value


almanah-0.5.0-1.fc11
--------------------
* Wed Dec  3 17:00:00 2008 Jean-Fran??ois Martin <lokthare at gmail.com> - 0.5.0-1
- Update to the new release


am-utils-6.1.5-12.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Karel Zak <kzak at redhat.com> 5:6.1.5-12
- fix #450754 - Amd does not work with 2.6.25 (thanks to Philippe Troin)


amqp-1.0.722557-1.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0:1.0.722557-1
- Rebased to svn rev 722557


arora-0.4-3.fc11
----------------
* Tue Dec  2 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> - 0.4-3
- owns arora and locale directories (bz#473621)


asymptote-1.54-1.fc11
---------------------
* Tue Dec  2 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.54-1
- 1.54


at-spi-1.25.2-2.fc11
--------------------
* Tue Dec  2 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.25.2-2
- Update to 1.25.2

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.25.1-3
- Rebuild for Python 2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.25.1-2
- Tweak %summary and %description


atk-1.25.2-1.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.25.2-1
- Update to 2.25.2

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.24.0-2
- Tweak %summary and %description


autofs-5.0.4-4
--------------
* Wed Dec  3 17:00:00 2008 Ian Kent <kent at redhat.com> - 5.0.4-4
- fix nested submount expire deadlock.

* Wed Nov 19 17:00:00 2008 Ian Kent <kent at redhat.com> - 5.0.4-3
- fix libxml2 version check for deciding whether to use workaround.


berusky-1.1-10.fc11
-------------------
* Tue Dec  2 17:00:00 2008 Martin Stransky <stransky at redhat.com> 1.1-10
- added patch from #458477 - Berusky aborts at end 
  of intermediate level 18


busybox-1.12.1-2.fc11
---------------------
* Tue Dec  2 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 1:1.12.1-2
- enable selinux in static version of busybox (#462724)


clamav-0.94.2-1.fc11
--------------------
* Tue Dec  2 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> - 0.94.2-1
- Upgrade to 0.94.2 (#474002)


db4-4.7.25-7.fc11
-----------------
* Tue Dec  2 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 4.7.25-7
- remove s390 and s390x from java_arches (#474061)
- BR: tcl-devel for the tclConfig.sh change (#474062)


dovecot-1.1.7-2.fc11
--------------------
* Tue Dec  2 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 1:1.1.7-2
- revert changes from 1:1.1.6-2 and 1:1.1.6-1
- password can be stored in different file readable only for root 
  via !include_try directive

* Tue Dec  2 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 1:1.1.7-1
- update to upstream version 1.1.7


eel2-2.25.1-1.fc11
------------------
* Tue Dec  2 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.25.1-1
- Update to 2.25.1


fatsort-0.9.9.1-1.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Till Maas <opensource at till.name> - 0.9.9.1-1
- Update to new release, that really contains the upstreamed patches

* Tue Dec  2 17:00:00 2008 Till Maas <opensource at till.name> - 0.9.9-1
- Update to new release
- Remove upstreamed patches

* Sat Nov 22 17:00:00 2008 Till Maas <opensource at till.name> - 0.9.8.3-2
- Update summary and description


fcron-3.0.4-3.fc11
------------------

fetchlog-1.2-1.fc11
-------------------
* Tue Dec  2 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 1.2-1
- Updated to new upstream

* Mon Nov 24 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 1.0-11
- Updates summary as per Richard Hughes guidelines


glib2-2.19.2-2.fc11
-------------------
* Tue Dec  2 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.19.2-2
- Rebuild


gtk2-2.14.5-4.fc11
------------------
* Tue Dec  2 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.5-4
- Rebuild for pkg-config provides


gvfs-1.1.1-2.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.1.1-2
- Update file lists to include the dav+sd backend

* Tue Dec  2 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.1.1-1
- Update to 1.1.1

* Mon Dec  1 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.0.3-1
- Update to 1.0.3

* Fri Nov  7 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.0.2-4
- SMB: timestamp setting support (#461505)


heartbeat-2.1.4-1.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 2.1.4-1
- Update to 2.1.4
- Drop upstreamed patch
- Add patch to disable init script by default (#441286)

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.3-4
- Rebuild for Python 2.6


hesiod-3.1.0-14
---------------
* Tue Dec  2 17:00:00 2008 Nalin Dahyabhai <nalin at fedoraproject.org> - 3.1.0-14
- adjust the package summary


ipython-0.9.1-1.fc11
--------------------
* Tue Dec  2 17:00:00 2008 James Bowes <jbowes at redhat.com> 0.9.1-1
- Update to 0.9.1, specfile changes courtesy Greg Swift

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.4-2
- Rebuild for Python 2.6


kazehakase-0.5.6-1.fc11
-----------------------

kde-filesystem-4-21.fc11
------------------------
* Tue Dec  2 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4-21
- sync latest cmake macros
- Add -DCMAKE_VERBOSE_MAKEFILE=ON to %cmake_kde4 (#474053)


kde-plasma-quickaccess-0.7.1-4.fc11
-----------------------------------
* Tue Dec  2 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 0.7.1-4
- build requires
- build problem ugly hack (lkonq) 
- make VERBOSE=1

* Tue Dec  2 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 0.7.1-3
- patched for KDE 4.2 Plasma API


kde-plasma-runcommand-0.7-2.fc11
--------------------------------
* Tue Dec  2 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 0.7-2
- make VERBOSE=1


kdebase-workspace-4.1.80-10.fc11
--------------------------------

kdeedu-4.1.80-7.fc11
--------------------
* Tue Dec  2 17:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 4.1.80-7
- rebuild for gmm 3.1


kdemultimedia-4.1.80-3.fc11
---------------------------
* Fri Nov 28 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.80-3
- dragon documentation disappeared (at least with my mock build), update file
  lists
- add kioslave documentation to file lists

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.80-3
- -devel: drop Req: kdebase-workspace-devel

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast


kdepimlibs-4.1.80-3.fc11
------------------------
* Tue Dec  2 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.80-3
- -devel: Requires: libical-devel


kdeplasma-addons-4.1.80-3.fc11
------------------------------
* Tue Dec  2 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-3
- BR plasma-devel
- add Provides: kde-plasma-lancelot
- fix file list
- BR libkexiv2-devel >= 0.4.0 on F10+

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged
- add Obsoletes: kde-plasma-lancelot

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast


kernel-2.6.28-0.106.rc6.git4.fc11
---------------------------------
* Mon Dec  1 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc6-git4

* Sun Nov 30 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc6-git2

* Mon Nov 24 17:00:00 2008 Jeremy Katz <katzj at redhat.com>
- Add modules.drm file so that we can determine the DRM modules to pull into 
  initrds

* Mon Nov 24 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc6-git1

* Wed Nov 19 17:00:00 2008 Neil Horman <nhorman at redhat.com>
- Enable Garmin gps serial module build (#471824)


kipi-plugins-0.2.0-0.6.beta4.fc11
---------------------------------
* Tue Nov 25 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.2.0-0.6.beta4
- kipi-plugins-0.2.0-beta4

* Tue Nov 25 17:00:00 2008 Luk???? Tinkl <ltinkl at redhat.com> 0.2.0-0.5.beta3
- #472874 - kipi-plugins package is missing kipiplugin.desktop


kphotoalbum-3.2-0.5.20081007svn.fc11
------------------------------------
* Wed Dec  3 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 3.2-0.5.20081007svn
- respin (kdegraphics)
- BR: soprano-devel


libbtctl-0.10.0-8.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Jiri Moskovcak <jmoskovc at redhat.com> 0.10.0-8
- added libtoolize to prep - fixes compile with libtool2.2

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.0-7
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 - Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.0-6
- Rebuild for Python 2.6


liberation-fonts-1.04.93-1.fc11
-------------------------------
* Wed Dec  3 17:00:00 2008 Caius Chance <cchance at redhat.com> - 1.04.93-1.fc11
- Resolves: rhbz#473481
  (Blurriness of Greek letter m (U+03BC) in Liberation Sans Regular.)


libprelude-0.9.21.2-3.fc11
--------------------------
* Tue Dec  2 17:00:00 2008 Steve Grubb <sgrubb at redhat.com> - 0.9.21.2-3
- Disable %check
unset DISPLAY
 target
- Rebuild for Python 2.6


libv4l-0.5.7-1.fc11
-------------------
* Tue Dec  2 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.5.7-1
- New upstream release 0.5.7, fixing rh 473771


lsof-4.81-1.fc11
----------------
* Tue Dec  2 17:00:00 2008 Karel Zak <kzak at redhat.com> 4.81-1
- upgrade to 4.81
  - lsof_4.80-threads.patch - rebased


mercurial-1.1-1.fc11
--------------------
* Tue Dec  2 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 1.1-1
- Update to 1.1


mksh-36-2.fc11
--------------
* Tue Dec  2 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 36-2
- Upstream patch for command hang/high cpu workload (#474115)


muine-0.8.10-2.fc11
-------------------

nagios-3.0.6-1.fc11
-------------------
* Tue Dec  2 17:00:00 2008 Robert M. Albrecht <fedora at romal.de> 3.0.6-1
- Upstream released a new version


nfs-utils-1.1.4-6.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-6
- mount command: remove local getport() implementation
- mount command: Replace clnt_ping() and getport() calls in probe_port()
- mount command: Use nfs_error() instead of perror()
- mount command: Use nfs_pmap_getport() in probe_statd()


nspluginwrapper-1.1.8-2.fc11
----------------------------
* Tue Dec  2 17:00:00 2008 Warren Togami <wtogami at redhat.com> 1.1.8-2
- fix-invalid-RPC-after-NPP_Destroy fixes a crasher


nted-1.4.16-1.fc11
------------------
* Sun Nov 30 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.4.16-1
- Update to upstream's 1.4.16 release.


ntfs-3g-1.5130-1.fc11
---------------------
* Tue Dec  2 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2:1.5130-1
- update to 1.5130


perl-namespace-clean-0.09-1.fc11
--------------------------------
* Tue Dec  2 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.09-1
- update to 0.09
- note BR change from Scope::Guard to B::Hooks::EndOfScope


poker2d-1.6.0-3.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.6.0-3
- Add python2.6 patch
- Add libtool2.2 patch

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.0-2
- Rebuild for Python 2.6


policycoreutils-2.0.60-2.fc11
-----------------------------
* Tue Dec  2 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.60-2
- Fix error checking in restorecond, for inotify_add_watch


python-qpid-0.3.722557-1.fc11
-----------------------------
* Tue Dec  2 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.722557-1
- Rebased to svn rev 722557

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.720585-2
- Rebuild for Python 2.6


python-virtinst-0.400.0-6.fc11
------------------------------
* Tue Dec  2 17:00:00 2008 Cole Robinson <crobinso at redhat.com> - 0.400.0-6.fc11
- Fix printing translated help messages
- Allow using virtio to pxe boot

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.400.0-5
- Rebuild for Python 2.6


rpm-4.6.0-0.rc2.6
-----------------
* Tue Dec  2 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- fix pkg-config provide generation when pc's depend on each other (#473814)


ruby-qpid-0.3.722557-1.fc11
---------------------------
* Tue Dec  2 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.722557-1
- Rebased to svn rev 722557


rubygem-facets-2.5.0-1.fc11
---------------------------
* Tue Dec  2 17:00:00 2008 Jeroen van Meeuwen <j.van.meeuwen at ogd.nl> - 2.5.0-1
- New upstream version


scribus-1.3.5-0.7.12516svn.fc11
-------------------------------
* Tue Dec  2 17:00:00 2008 Dan Hor??k <dan[AT]danny.cz> - 1.3.5-0.7.12516svn
- fix directory ownership in doc subpackage (#474041)

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.5-0.6.12516svn
- Rebuild for Python 2.6


selinux-policy-3.6.1-1.fc11
---------------------------

skychart-3.0.1.5-3.20081026svn.fc11
-----------------------------------
* Mon Dec  1 17:00:00 2008 Lubomir Rintel (Fedora Astronomy) <lkundrak at v3.sk> - 3.0.1.5-3.20081026svn
- Own /usr/share/skychart (#474037)


sqlite-3.6.6.2-2.fc11
---------------------
* Tue Dec  2 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 3.6.6.2-2
- require tcl(abi) in sqlite-tcl subpackage (#474034)
- move tcl extensions to arch-specific location
- enable dependency extraction on the tcl dso
- require pkgconfig in sqlite-devel


stardict-3.0.1-15.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 3.0.1-15
- BR libtool and run libtoolize to fix build with libtool2.
- Add preun scriptlet for GConf2 uninstall rule.
- Build with SMP make flags.
- Install with -p.

* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 3.0.1-14.fc10
- Include /etc/stardict directory


startup-notification-0.9-5.fc11
-------------------------------
* Tue Dec  2 17:00:00 2008 Matthias Clasen <mclasen at redhat.com>
- Rebuild for pkg-config provides


stgit-0.14.3-3.fc11
-------------------
* Tue Dec  2 17:00:00 2008 James Bowes <jbowes at redhat.com> 0.14.3-3
- Try and make the summary text better

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.14.3-2
- Rebuild for Python 2.6


syslog-ng-2.0.10-1.fc11
-----------------------
* Tue Dec  2 17:00:00 2008 Douglas E. Warner <silfreed at silfreed.net> 2.0.10-1
- update to 2.0.10
- fix for CVE-2008-5110


thttpd-2.25b-18.fc11
--------------------
* Tue Dec  2 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 2.25b-18
- Own /var/www in a hack-ish way, but comment it well (#474024).


tig-0.12.1-1.fc11
-----------------
* Tue Dec  2 17:00:00 2008 James Bowes <jbowes at redhat.com> 0.12.1-1
- tig-0.12.1


tomcat6-6.0.18-8.1.fc11
-----------------------
* Tue Dec  2 17:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-8.1
- build for Fedora

* Tue Dec  2 17:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-8
- fix directory ownership

* Thu Nov 13 17:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-7
- add Requires for update-alternatives


txt2tags-2.5-4.fc11
-------------------
* Tue Dec  2 17:00:00 2008 Adam Miller <maxamillion [AT] gmail.com - 2.5-4
- Fixed directory ownership as per bug #473991
- https://bugzilla.redhat.com/show_bug.cgi?id=473991

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.5-3
- Rebuild for Python 2.6


udev-135-1.fc11
---------------
* Tue Dec  2 17:00:00 2008 Harald Hoyer <harald at redhat.com> 135-1
- version 135


ufraw-0.14.1-3.fc11
-------------------
* Tue Dec  2 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 0.14.1-3
- require gimp and cinepaint in the respective subpackages (#474021)


xmoto-0.5.0-1.fc11
------------------
* Mon Dec  1 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> 0.5.0-1
- Update to 0.5.0.


xqilla-2.1.3-0.3.fc11
---------------------
* Tue Dec  2 17:00:00 2008 Milan Zazrivec <mzazrivec at redhat.com 2.1.3-0.3
- fix for bz #473997 - xqilla : Unowned directories


Summary:
Added Packages: 6
Removed Packages: 1
Modified Packages: 73
Broken deps for i386
----------------------------------------------------------
	at-spi-devel-1.25.2-2.fc11.i386 requires pkgconfig(libbonobo-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(libxml-2.0)
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	eel2-devel-2.25.1-1.fc11.i386 requires pkgconfig(libxml-2.0)
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.i386 requires libltdl.so.3
	ettercap-gtk-0.7.3-26.fc10.i386 requires libltdl.so.3
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-data-server-devel-2.25.2-1.fc11.i386 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.i386 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	foobillard-3.0a-8.fc10.i386 requires dejavu-fonts
	freeradius-2.1.1-6.fc10.i386 requires libltdl.so.3
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.i386 requires libplasma.so.2
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libxml++-devel-2.23.2-2.fc11.i386 requires pkgconfig(libxml-2.0)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	muine-devel-0.8.10-2.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-bitstring-2.0.0-5.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.i386 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	poker-network-devel-1.6.0-3.fc11.i386 requires pkgconfig(poker-engine)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.i386 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	ufraw-cinepaint-0.14.1-3.fc11.i386 requires cinepaint(x86-32)
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	at-spi-devel-1.25.2-2.fc11.i386 requires pkgconfig(libbonobo-2.0)
	at-spi-devel-1.25.2-2.fc11.x86_64 requires pkgconfig(libbonobo-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.i386 requires pkgconfig(libxml-2.0)
	compiz-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(libxml-2.0)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	eel2-devel-2.25.1-1.fc11.i386 requires pkgconfig(libxml-2.0)
	eel2-devel-2.25.1-1.fc11.x86_64 requires pkgconfig(libxml-2.0)
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.x86_64 requires libltdl.so.3()(64bit)
	ettercap-gtk-0.7.3-26.fc10.x86_64 requires libltdl.so.3()(64bit)
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	evolution-data-server-devel-2.25.2-1.fc11.i386 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.i386 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	evolution-data-server-devel-2.25.2-1.fc11.x86_64 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.x86_64 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	foobillard-3.0a-8.fc10.x86_64 requires dejavu-fonts
	freeradius-2.1.1-6.fc10.x86_64 requires libltdl.so.3()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	gift-0.11.8.1-10.fc9.x86_64 requires libltdl.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.i386 requires libplasma.so.2
	kde-plasma-lancelot-1.0.3-1.fc10.x86_64 requires libplasma.so.2()(64bit)
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libxml++-devel-2.23.2-2.fc11.i386 requires pkgconfig(libxml-2.0)
	libxml++-devel-2.23.2-2.fc11.x86_64 requires pkgconfig(libxml-2.0)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	muine-devel-0.8.10-2.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	muine-devel-0.8.10-2.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-bitstring-2.0.0-5.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlp5-5.10-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.x86_64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	poker-network-devel-1.6.0-3.fc11.i386 requires pkgconfig(poker-engine)
	poker-network-devel-1.6.0-3.fc11.x86_64 requires pkgconfig(poker-engine)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.x86_64 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	ufraw-cinepaint-0.14.1-3.fc11.x86_64 requires cinepaint(x86-64)
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	at-spi-devel-1.25.2-2.fc11.ppc requires pkgconfig(libbonobo-2.0)
	at-spi-devel-1.25.2-2.fc11.ppc64 requires pkgconfig(libbonobo-2.0)
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	compiz-devel-0.7.8-5.fc11.ppc requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.ppc requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.ppc requires pkgconfig(libxml-2.0)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(libxml-2.0)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	eel2-devel-2.25.1-1.fc11.ppc requires pkgconfig(libxml-2.0)
	eel2-devel-2.25.1-1.fc11.ppc64 requires pkgconfig(libxml-2.0)
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.ppc requires libltdl.so.3
	ettercap-gtk-0.7.3-26.fc10.ppc requires libltdl.so.3
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-data-server-devel-2.25.2-1.fc11.ppc requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.ppc requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	evolution-data-server-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	firstaidkit-plugin-grub-0.2.2-4.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc requires dejavu-fonts
	freeradius-2.1.1-6.fc10.ppc requires libltdl.so.3
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.ppc requires libltdl.so.3
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.ppc requires libplasma.so.2
	kde-plasma-lancelot-1.0.3-1.fc10.ppc64 requires libplasma.so.2()(64bit)
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libxml++-devel-2.23.2-2.fc11.ppc requires pkgconfig(libxml-2.0)
	libxml++-devel-2.23.2-2.fc11.ppc64 requires pkgconfig(libxml-2.0)
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	muine-devel-0.8.10-2.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-bitstring-2.0.0-5.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	poker-network-devel-1.6.0-3.fc11.ppc requires pkgconfig(poker-engine)
	poker-network-devel-1.6.0-3.fc11.ppc64 requires pkgconfig(poker-engine)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.ppc requires python-pygame
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	ufraw-cinepaint-0.14.1-3.fc11.ppc requires cinepaint(ppc-32)
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	appliance-tools-003.9-1.fc10.noarch requires qemu-img
	at-spi-devel-1.25.2-2.fc11.ppc64 requires pkgconfig(libbonobo-2.0)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(xrender)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(xdamage)
	compiz-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(libxml-2.0)
	eel2-devel-2.25.1-1.fc11.ppc64 requires pkgconfig(libxml-2.0)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.ppc64 requires libltdl.so.3()(64bit)
	ettercap-gtk-0.7.3-26.fc10.ppc64 requires libltdl.so.3()(64bit)
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-data-server-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(libxml-2.0)
	evolution-data-server-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(libbonobo-2.0) >= 0:2.20.3
	firstaidkit-plugin-grub-0.2.2-4.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc64 requires dejavu-fonts
	freeradius-2.1.1-6.fc10.ppc64 requires libltdl.so.3()(64bit)
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	kde-plasma-lancelot-1.0.3-1.fc10.ppc64 requires libplasma.so.2()(64bit)
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libxml++-devel-2.23.2-2.fc11.ppc64 requires pkgconfig(libxml-2.0)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-bitstring-2.0.0-5.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	poker-network-devel-1.6.0-3.fc11.ppc64 requires pkgconfig(poker-engine)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.ppc64 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	ufraw-cinepaint-0.14.1-3.fc11.ppc64 requires cinepaint(ppc-64)
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Dec  3 14:13:34 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 03 Dec 2008 23:13:34 +0900
Subject: rpms/libxml2/devel libxml2.spec,1.65,1.66
In-Reply-To: <20081203134419.B08167011D@cvs1.fedora.phx.redhat.com>
References: <20081203134419.B08167011D@cvs1.fedora.phx.redhat.com>
Message-ID: <4936940E.3010107@ioa.s.u-tokyo.ac.jp>

Caolan McNamara wrote, at 12/03/2008 10:44 PM +9:00:
> Author: caolanm
> 
> Update of /cvs/pkgs/rpms/libxml2/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9711
> 
> Modified Files:
> 	libxml2.spec 
> Log Message:
> rebuild to get provides(libxml-2.0) into HEAD rawhide
> 
> 
> Index: libxml2.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/libxml2/devel/libxml2.spec,v
> retrieving revision 1.65
> retrieving revision 1.66
> diff -u -r1.65 -r1.66
> --- libxml2.spec	1 Dec 2008 23:42:58 -0000	1.65
> +++ libxml2.spec	3 Dec 2008 13:43:49 -0000	1.66
> @@ -1,7 +1,7 @@
>  Summary: Library providing XML and HTML support
>  Name: libxml2
>  Version: 2.7.2
> -Release: 4%{?dist}%{?extra_release}
> +Release: 5%{?dist}%{?extra_release}
>  License: MIT
>  Group: Development/Libraries
>  Source: ftp://xmlsoft.org/libxml2/libxml2-%{version}.tar.gz
> @@ -145,6 +145,9 @@
>  %doc doc/python.html
>  
>  %changelog
> +* Wed Dec  3 2008 Caol??n McNamara <caolanm at redhat.com> - 2.7.2-5
> +- rebuild to get provides(libxml-2.0) into HEAD rawhide
> +

Again this causes no effect until bug 473978 is solved.
See:
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00124.html

Regards,
Mamoru



From tmz at pobox.com  Wed Dec  3 14:58:46 2008
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 3 Dec 2008 09:58:46 -0500
Subject: rpms/libxml2/devel libxml2.spec,1.65,1.66
In-Reply-To: <4936940E.3010107@ioa.s.u-tokyo.ac.jp>
References: <20081203134419.B08167011D@cvs1.fedora.phx.redhat.com>
	<4936940E.3010107@ioa.s.u-tokyo.ac.jp>
Message-ID: <20081203145846.GJ20204@inocybe.teonanacatl.org>

Mamoru Tasaka wrote:
> Again this causes no effect until bug 473978 is solved.
> See:
> https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00124.html

It was supposed to be fixed in rpm-4.6.0-0.rc2.6?.  And indeed glib2
was rebuilt yesterday and picked up the proper pkgconfig() provides.
But it doesn't appear that the libxml2 rebuild? has been as fruitful.

So either a) something it still borked or b) I've not had enough sugar
yet today to find and check the right libxml2 build.  Here's hoping
it's b. :)

? https://koji.fedoraproject.org/koji/buildinfo?buildID=72860
* Tue Dec 02 2008 Panu Matilainen <pmatilai at redhat.com>
- fix pkg-config provide generation when pc's depend on each other
  (#473814)

? https://koji.fedoraproject.org/koji/buildinfo?buildID=72995

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anyone who is capable of getting themselves made President should on
no account be allowed to do the job.
    -- Douglas Adams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/0f8fcd68/attachment.sig>

From ed at eh3.com  Wed Dec  3 15:01:10 2008
From: ed at eh3.com (Ed Hill)
Date: Wed, 3 Dec 2008 10:01:10 -0500
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh5j3o$5cp$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
Message-ID: <20081203100110.01427445@localhost.localdomain>

On Wed, 03 Dec 2008 10:22:00 +0100 Kevin Kofler wrote:
> Ralf Corsepius wrote:
> 
> There's an alternative which is:
> * easier to learn,


OK, I see a lot of vitriol on this thread but its an important topic
so I'd like to offer a (hopefully) positive persepective and then ask
about the learning part.  I want a build system that has the following
features:

 required:
 + build for multiple OSes (Linux, some *nix, and an occasional 
   windows build -- where mingw may be sufficient)
 + multiple-language compilation and cross-language linking
   (C/C++, Fortran, MatLAB/Octave MEX, various scripting
   languages, etc.)
 + creation of *both* static and shared libs for C/C++, Fortran,
   etc.
 + good documentation and examples -- where "good" means the docs
   explain what are good strategies/approaches to use for non-
   trivial projects and *why*
 
 desired:
 + allows either "in-tree" or "out-of-tree" builds
 + parallel and/or distributed builds that actually work


So far, my build system experiences have included:

 + Plenty of "homegrown" makefiles (both of my own shameful making 
   and from others) -- have learned the hard lesson that it is
   exceedingly difficult to try to re-implement the flexibility of,
   for instance, the Gnu autotools
 + Gnu autotools -- have used them on-and-off for years and have 
   become somewhat comfortable with them -- have run into many 
   problems (mostly of my own making) but, over time, things keep
   improving and I keep finding (or learning from others) ways to
   better use the tools provided
 + Boost Build (aka bjam) -- this is a Jam implementation that
   was created by the Boost folks and, in my opinion, it has a
   number of serions problems since:
     - the jam language is poorly documented and not easy to 
       grasp -- learning a yet-another new language is just 
       more lost time -- and it seems that you have to keep 
       fighting with the Jam files to get anything accomplished
     - poor support for non-C++ languages
     - error messages are simply awful
     - documentation does a lousy job of explaining how you
       *should* use it for non-trivial projects
 + CMake -- have tried it a bit and have run into problems
   (e.g., multi-job builds failing with frustraing race conditions) 
   with the setups created by others -- but it may be that its not 
   the tool per-se just the use of it
 + have only window-shopped other build systems : Scons, waf, etc.


So, with respect to CMake, I'm mostly sitting on the fence.  I've had a
few less-than-positive experiences with it (have you ever tried to
build VTK from source?) but am not completely turned off by it.  There
is a wonderful tutorial for the autotools:

  http://www.lrde.epita.fr/~adl/autotools.html

but I'm unaware of a similarly helpful (that is, a "this is how you
*ought* to use the tool and here are the main reasons *why*") sort of
tutorial for CMake.

So, what have you folks done to learn about best practices for CMake?

And does CMake have good support for all the needs (esp. the multi- and
cross-language handling) that I listed?

Ed

-- 
Edward H. Hill III, PhD  |  ed at eh3.com  |  http://eh3.com/



From tmz at pobox.com  Wed Dec  3 15:12:29 2008
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 3 Dec 2008 10:12:29 -0500
Subject: rpms/libxml2/devel libxml2.spec,1.65,1.66
In-Reply-To: <20081203145846.GJ20204@inocybe.teonanacatl.org>
References: <20081203134419.B08167011D@cvs1.fedora.phx.redhat.com>
	<4936940E.3010107@ioa.s.u-tokyo.ac.jp>
	<20081203145846.GJ20204@inocybe.teonanacatl.org>
Message-ID: <20081203151229.GK20204@inocybe.teonanacatl.org>

I wrote:
> So either a) something it still borked or b) I've not had enough
> sugar yet today to find and check the right libxml2 build.  Here's
> hoping it's b. :)

Heh, so it was a little of both a and b.  I got straightened out on
irc by Ignacio and Panu. :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
He who knows others is wise; He knows himself is enlightened.
    -- Lao-Tzu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/54806b7f/attachment.sig>

From jarod at redhat.com  Wed Dec  3 15:20:32 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Wed, 03 Dec 2008 10:20:32 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <1228245867.5858.3.camel@localhost.localdomain>
References: <1228245867.5858.3.camel@localhost.localdomain>
Message-ID: <4936A3C0.4050803@redhat.com>

Brian Pepple wrote:
> Hi,
> 
> Please find below the list of topics that are likely to come up in the
> next FESCo meeting that is scheduled for tomorrow, Wednesday at 17:00
> UTC in #fedora-meeting on irc.freenode.org:
> 
> /topic FESCo-Meeting - Final F11 Schedule -
> https://fedoraproject.org/wiki/Releases/11/Schedule - 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.

/topic FESCo meeting -- Secondary Arches: will they ever fly? (aka, wtf 
happened to Fedora ia64, and what can/should we do to resuscitate it).

--jarod



From bpepple at fedoraproject.org  Wed Dec  3 15:39:06 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 03 Dec 2008 10:39:06 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <4936A3C0.4050803@redhat.com>
References: <1228245867.5858.3.camel@localhost.localdomain>
	<4936A3C0.4050803@redhat.com>
Message-ID: <1228318746.2848.2.camel@localhost.localdomain>

On Wed, 2008-12-03 at 10:20 -0500, Jarod Wilson wrote:
> /topic FESCo meeting -- Secondary Arches: will they ever fly? (aka, wtf 
> happened to Fedora ia64, and what can/should we do to resuscitate it).

Added to the schedule.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/8b206a2b/attachment.sig>

From pmatilai at laiskiainen.org  Wed Dec  3 15:43:16 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 3 Dec 2008 17:43:16 +0200 (EET)
Subject: rpms/libxml2/devel libxml2.spec,1.65,1.66
In-Reply-To: <4936940E.3010107@ioa.s.u-tokyo.ac.jp>
References: <20081203134419.B08167011D@cvs1.fedora.phx.redhat.com>
	<4936940E.3010107@ioa.s.u-tokyo.ac.jp>
Message-ID: <alpine.DEB.1.10.0812031734590.22110@gotcha.dreamhost.com>

On Wed, 3 Dec 2008, Mamoru Tasaka wrote:

> Caolan McNamara wrote, at 12/03/2008 10:44 PM +9:00:
>> Author: caolanm
>> 
>> Update of /cvs/pkgs/rpms/libxml2/devel
>> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9711
>> 
>> Modified Files:
>> 	libxml2.spec Log Message:
>> rebuild to get provides(libxml-2.0) into HEAD rawhide
>> 
>> 
>> Index: libxml2.spec
>> ===================================================================
>> RCS file: /cvs/pkgs/rpms/libxml2/devel/libxml2.spec,v
>> retrieving revision 1.65
>> retrieving revision 1.66
>> diff -u -r1.65 -r1.66
>> --- libxml2.spec	1 Dec 2008 23:42:58 -0000	1.65
>> +++ libxml2.spec	3 Dec 2008 13:43:49 -0000	1.66
>> @@ -1,7 +1,7 @@
>>  Summary: Library providing XML and HTML support
>>  Name: libxml2
>>  Version: 2.7.2
>> -Release: 4%{?dist}%{?extra_release}
>> +Release: 5%{?dist}%{?extra_release}
>>  License: MIT
>>  Group: Development/Libraries
>>  Source: ftp://xmlsoft.org/libxml2/libxml2-%{version}.tar.gz
>> @@ -145,6 +145,9 @@
>>  %doc doc/python.html
>>   %changelog
>> +* Wed Dec  3 2008 Caol??????n McNamara <caolanm at redhat.com> - 2.7.2-5
>> +- rebuild to get provides(libxml-2.0) into HEAD rawhide
>> +
>
> Again this causes no effect until bug 473978 is solved.
> See:
> https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00124.html

Well the question is, should rpm-build require everything it can 
extract dependencies from? That would drag in mono and whatnot... and 
rpm-build itself certainly does not require pkg-config to function.

Adding dependency on pkgconfig is no big deal, but the line between what 
should go to rpm-build dependencies and what to buildsys groups is rather 
fuzzy.

 	- Panu -



From fedora at leemhuis.info  Wed Dec  3 15:53:17 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 03 Dec 2008 16:53:17 +0100
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <1228318746.2848.2.camel@localhost.localdomain>
References: <1228245867.5858.3.camel@localhost.localdomain>	<4936A3C0.4050803@redhat.com>
	<1228318746.2848.2.camel@localhost.localdomain>
Message-ID: <4936AB6D.9050002@leemhuis.info>

On 03.12.2008 16:39, Brian Pepple wrote:
> On Wed, 2008-12-03 at 10:20 -0500, Jarod Wilson wrote:
>> /topic FESCo meeting -- Secondary Arches: will they ever fly? (aka, wtf 
>> happened to Fedora ia64, and what can/should we do to resuscitate it).
> Added to the schedule.

Wouldn't it be better to first discuss this on the list first?

Verbose: I'd say most of us will agree that IRC simply sucks when it 
comes to exchange bigger bunches of information. The answer to "wtf 
happened to Fedora ia64" likely is such a bigger bunch. Not to mentioned 
that a lot of readers on this list (which don't want to or can't join 
the meeting) will likely be interested in the answer as well. And they 
might have valuable feedback that might be helpful for FESCo when it 
comes to "what can/should we do to resuscitate it"

CU
knurd



From skvidal at fedoraproject.org  Wed Dec  3 15:54:14 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 3 Dec 2008 10:54:14 -0500 (EST)
Subject: Server SIG - work areas
In-Reply-To: <200812031224.mB3COVpB008672@laptop14.inf.utfsm.cl>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<d9c612bf0812022322v56ec7d5jd107a9848dd88f8@mail.gmail.com>
	<200812031224.mB3COVpB008672@laptop14.inf.utfsm.cl>
Message-ID: <alpine.LFD.2.00.0812031050040.19627@localhost.localdomain>



On Wed, 3 Dec 2008, Horst H. von Brand wrote:

> Christopher Stone <chris.stone at gmail.com> wrote:
>> On Mon, Dec 1, 2008 at 6:02 AM, Dan Hor??k <dan at danny.cz> wrote:
>>> Hello,
>>
>> Hi.
>>
>> There are probably a ton of packages which Require optional desktop
>> dependencies, like gnuplot [1].  Identifying and splitting out the GUI
>> components of these packages is going to be your most difficult hurdle
>> I would guess.
>
> Sorry, but I see little use for gnuplot on a server. And if needed, it will
> have some GUI.
>

amplot which comes in amanda-server uses gnuplot to create reports of your 
backups.


-sv



From jwboyer at gmail.com  Wed Dec  3 16:05:50 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 3 Dec 2008 11:05:50 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <4936AB6D.9050002@leemhuis.info>
References: <1228245867.5858.3.camel@localhost.localdomain>
	<4936A3C0.4050803@redhat.com>
	<1228318746.2848.2.camel@localhost.localdomain>
	<4936AB6D.9050002@leemhuis.info>
Message-ID: <20081203160550.GA5689@yoda.jdub.homelinux.org>

On Wed, Dec 03, 2008 at 04:53:17PM +0100, Thorsten Leemhuis wrote:
> On 03.12.2008 16:39, Brian Pepple wrote:
>> On Wed, 2008-12-03 at 10:20 -0500, Jarod Wilson wrote:
>>> /topic FESCo meeting -- Secondary Arches: will they ever fly? (aka, 
>>> wtf happened to Fedora ia64, and what can/should we do to resuscitate 
>>> it).
>> Added to the schedule.
>
> Wouldn't it be better to first discuss this on the list first?

Here's a brief summary as I know it:

1) Koji still isn't ready.  Dennis has said that he's targeting for
it to be ready by FUDCon

2) ia64 was built using their own koji instance (I think).  I don't
know what happened to it for F10.  There were kernel patches for it
during F10 development, so maybe they are just a bit behind at the
moment.

3) Sparc is still chugging along, but is not complete.

4) I have gotten inquiries about other secondary architectures, such
as soft-float PPC.

Maybe it's time we start a SIG.  We have Sparc, ia64, ARM, and one
or two potential others.  The biggest hurdle is koji at the moment
and hopefully that will be solved soon.  Then we can figure out where
to go from there.

NOTE: The above information is just what I have pieced together over
the past few weeks.  It may or may not be entirely accurate.  If
people know for certain, feel free to comment.

josh



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Dec  3 16:06:08 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 04 Dec 2008 01:06:08 +0900
Subject: rpms/libxml2/devel libxml2.spec,1.65,1.66
In-Reply-To: <alpine.DEB.1.10.0812031734590.22110@gotcha.dreamhost.com>
References: <20081203134419.B08167011D@cvs1.fedora.phx.redhat.com>	<4936940E.3010107@ioa.s.u-tokyo.ac.jp>
	<alpine.DEB.1.10.0812031734590.22110@gotcha.dreamhost.com>
Message-ID: <4936AE70.3090201@ioa.s.u-tokyo.ac.jp>

Panu Matilainen wrote, at 12/04/2008 12:43 AM +9:00:
> Well the question is, should rpm-build require everything it can extract 
> dependencies from? That would drag in mono and whatnot... and rpm-build 
> itself certainly does not require pkg-config to function.
> 
> Adding dependency on pkgconfig is no big deal, but the line between what 
> should go to rpm-build dependencies and what to buildsys groups is 
> rather fuzzy.
> 
>     - Panu -

So this contains packaging guidelines issue
- If FPC says "all packages which creates pkgconfig .pc file must
  have _Build_Requires: pkgconfig", then rpm-build (or buildsys) does not
  have to add pkgconfig dependency

- If FPC says no, then rpm-build or buildsys must have pkgconfig dependency

My current opinition is that rpm-build should have "Requires: pkgconfig"
because this affects even a small package and guideline changes due to this
issue will affect many packages.

Mamoru



From pmatilai at laiskiainen.org  Wed Dec  3 16:11:30 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 3 Dec 2008 18:11:30 +0200 (EET)
Subject: rpms/libxml2/devel libxml2.spec,1.65,1.66
In-Reply-To: <4936AE70.3090201@ioa.s.u-tokyo.ac.jp>
References: <20081203134419.B08167011D@cvs1.fedora.phx.redhat.com>
	<4936940E.3010107@ioa.s.u-tokyo.ac.jp>
	<alpine.DEB.1.10.0812031734590.22110@gotcha.dreamhost.com>
	<4936AE70.3090201@ioa.s.u-tokyo.ac.jp>
Message-ID: <alpine.DEB.1.10.0812031809030.22110@gotcha.dreamhost.com>

On Thu, 4 Dec 2008, Mamoru Tasaka wrote:

> Panu Matilainen wrote, at 12/04/2008 12:43 AM +9:00:
>> Well the question is, should rpm-build require everything it can extract 
>> dependencies from? That would drag in mono and whatnot... and rpm-build 
>> itself certainly does not require pkg-config to function.
>> 
>> Adding dependency on pkgconfig is no big deal, but the line between what 
>> should go to rpm-build dependencies and what to buildsys groups is rather 
>> fuzzy.
>>
>>     - Panu -
>
> So this contains packaging guidelines issue
> - If FPC says "all packages which creates pkgconfig .pc file must
> have _Build_Requires: pkgconfig", then rpm-build (or buildsys) does not
> have to add pkgconfig dependency
>
> - If FPC says no, then rpm-build or buildsys must have pkgconfig dependency
>
> My current opinition is that rpm-build should have "Requires: pkgconfig"
> because this affects even a small package and guideline changes due to this
> issue will affect many packages.

Yup, pkg-config is a bit special in that many packages which provide a 
pkg-config file don't actually require it themselves (for build), causing 
unresolvable dependencies all too easily. Already done and building, will 
be in rawhide in a few minutes.

 	- Panu -



From a.badger at gmail.com  Wed Dec  3 16:12:13 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 03 Dec 2008 08:12:13 -0800
Subject: Status of libtool 2.2.X?
In-Reply-To: <200812030236.43778.konrad@tylerc.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<200812030136.45621.konrad@tylerc.org>	<1228299670.20451.1879.camel@beck.corsepiu.local>
	<200812030236.43778.konrad@tylerc.org>
Message-ID: <4936AFDD.8@gmail.com>

Conrad Meyer wrote:
> On Wednesday 03 December 2008 02:21:10 am Ralf Corsepius wrote:
>> On Wed, 2008-12-03 at 01:36 -0800, Conrad Meyer wrote:
>>> On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote:
>>>> * a crack ridden design (using a central database), reinvention of
>>>> imake, comprising it's design flaws.
>>> Reinvention of build-system-tools-in-general. Like a new version of
>>> autotools (they don't pretend to be backwards compatible).
>> The autotools do not apply a central data base, they keep
>> "configuration" and "installation" as separate jobs. cmake lumps them
>> together.
>>
>> It's a different approach.
> 
> Saves resources on koji, if nothing less.
> 

This should not be a consideration.  We're talking about something that
is used by upstream so koji should never enter the picture.  OTOH, this
could just be a poorly formulated sentence ;-)

-Toshio


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/f8e30db3/attachment.sig>

From lesmikesell at gmail.com  Wed Dec  3 16:15:07 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 03 Dec 2008 10:15:07 -0600
Subject: Server SIG - work areas
In-Reply-To: <49362DD9.9060601@leemhuis.info>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<49362DD9.9060601@leemhuis.info>
Message-ID: <4936B08B.2010506@gmail.com>

Thorsten Leemhuis wrote:

>>  - work on the TUI counterparts of GUI system-config-* tools, should go
>> in hand with the backend/frontend separation
> 
> Just thinking aloud: By "TUI" you mean command line apps with a 
> interactive, ncurses-like interface?
> 
> Are those really worth the work? I for one (and a lot of other linux 
> users I know) either use graphical configuration Tools (with or without 
> remote forwarding) or (if there is no graphical environment or in 
> scripts) simple command line configuration tools (without an interactive 
> interface) -- I doubt a third way in the middle (and a second one for 
> text mode configuration) makes much sense. Improving some of the command 
> line configuration tools (those without an interactive interface) OTOH 
> might.
> 
> But well, maybe that just my odd point of view.

Having x libs installed and running remotely probably isn't a big deal 
for most servers, but it does add a lot more gunk to keep updated. 
However, if there are not text mode alternatives for all of the 
system-config-* tools, all of the magic they do needs to be documented 
to the point that everyone can manage with equivalent edits to the 
underlying config files and snippets under /etc/sysconfig.  That is, it 
should be feasible for someone to manually manage a machine initially 
following such documentation, then later choose to use yum to pull in 
the GUI tools and have them find all of the settings in the right places.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pertusus at free.fr  Wed Dec  3 16:38:35 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 3 Dec 2008 17:38:35 +0100
Subject: Server SIG - work areas
In-Reply-To: <Pine.LNX.4.61.0812031332220.6625@gonzo.dicp.de>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<d9c612bf0812022322v56ec7d5jd107a9848dd88f8@mail.gmail.com>
	<200812031224.mB3COVpB008672@laptop14.inf.utfsm.cl>
	<Pine.LNX.4.61.0812031332220.6625@gonzo.dicp.de>
Message-ID: <20081203163835.GA18067@free.fr>

On Wed, Dec 03, 2008 at 01:34:48PM +0100, Andreas Thienemann wrote:
>
> But there are other unsolved problems: e.g. php-gd pulled in half of the  
> X11 stack for a long time, I think this was partly fixed by now but the  
> dependency chain is still quite long.

Also 'convert' from Imagemagick depends on X (and not only 'display')
which is in my opinion much more problematic than gnuplot. I had a look
and it was not easy to fix, at least until upstream does something.

--
Pat



From dan at danny.cz  Wed Dec  3 16:40:30 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 03 Dec 2008 17:40:30 +0100
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <20081203160550.GA5689@yoda.jdub.homelinux.org>
References: <1228245867.5858.3.camel@localhost.localdomain>
	<4936A3C0.4050803@redhat.com>
	<1228318746.2848.2.camel@localhost.localdomain>
	<4936AB6D.9050002@leemhuis.info>
	<20081203160550.GA5689@yoda.jdub.homelinux.org>
Message-ID: <1228322430.3625.77.camel@eagle.danny.cz>


Josh Boyer p??e v St 03. 12. 2008 v 11:05 -0500:
> On Wed, Dec 03, 2008 at 04:53:17PM +0100, Thorsten Leemhuis wrote:
> > On 03.12.2008 16:39, Brian Pepple wrote:
> >> On Wed, 2008-12-03 at 10:20 -0500, Jarod Wilson wrote:
> >>> /topic FESCo meeting -- Secondary Arches: will they ever fly? (aka, 
> >>> wtf happened to Fedora ia64, and what can/should we do to resuscitate 
> >>> it).
> >> Added to the schedule.
> >
> > Wouldn't it be better to first discuss this on the list first?
> 
> Here's a brief summary as I know it:
> 
> 1) Koji still isn't ready.  Dennis has said that he's targeting for
> it to be ready by FUDCon
> 
> 2) ia64 was built using their own koji instance (I think).  I don't
> know what happened to it for F10.  There were kernel patches for it
> during F10 development, so maybe they are just a bit behind at the
> moment.
> 
> 3) Sparc is still chugging along, but is not complete.
> 
> 4) I have gotten inquiries about other secondary architectures, such
> as soft-float PPC.
> 
> Maybe it's time we start a SIG.  We have Sparc, ia64, ARM, and one
> or two potential others.  The biggest hurdle is koji at the moment
> and hopefully that will be solved soon.  Then we can figure out where
> to go from there.

Work is being done on s390x too.


		Dan




From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec  3 16:42:55 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 03 Dec 2008 17:42:55 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh5ls0$edm$1@ger.gmane.org> (Kevin Kofler's message of "Wed,
	03 Dec 2008 11:09:03 +0100")
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org>
Message-ID: <87y6yxcir4.fsf@fc5.bigo.ensc.de>

Kevin Kofler <kevin.kofler at chello.at> writes:

> * m4's arcane syntax, including considerations like when to quote things
> where, but also just the syntax itself (dnl for comments, [] for quoting
> etc.)

At least, 'm4' *has* quoting rules, while it's always an adventure with
'cmake' to write some non trivial things.  autotool's language is consistent
across its tasks ('make all', 'make install', 'make check', 'make dist'),
while 'cmake' uses different tools with different syntax/quoting rules and
mechanisms for them.  There is so much black magic in 'cmake' that it works
for trivial tasks but it is a nightmare to handle complex things with it.



Enrico



From stickster at gmail.com  Wed Dec  3 17:01:48 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 3 Dec 2008 12:01:48 -0500
Subject: FUDCon F11 Boston
In-Reply-To: <20081201171910.GO18297@localhost.localdomain>
References: <20081201171910.GO18297@localhost.localdomain>
Message-ID: <20081203170148.GK13562@localhost.localdomain>

On Mon, Dec 01, 2008 at 12:19:10PM -0500, Paul W. Frields wrote:
> FUDCon F11 Boston -- News Update!
> =================================
> 
> * All of our location information is confirmed -- we will be holding
>   the conference as predicted, at MIT in the Sloan Building.  There
>   will be plentiful space for hackfests and BarCamp sessions over the
>   course of the weekend.
> 
> * FUDPub will be held at Flat Top Johnny's on Saturday night (January
>   10) from 6:00-10:00pm.
> 
> * The wiki remains open for registration.  Please remember to note
>   your shirt size, whether you prefer vegetarian fare for lunch on
>   Saturday, and any other important information (in the "Comments"
>   section).
> 
> * The hotel group rate is good until DECEMBER 19.  After that, it will
>   be up to the hotel to decide whether or not to extend their offer of
>   $99/night.  So sign up now!
> 
> And here's some further news to sweeten the pot -- the One Laptop Per
> Child and SugarLabs communities will be joining us for FUDCon, to
> address areas of common interest like packaging and building for these
> unique projects, and to talk to Fedora community members about getting
> involved.  This should make FUDCon a very exciting event and I look
> forward to seeing everyone there who can make it!

I apologize for following one announcement with another, but I left
out some helpful links and information that could be useful for
community members who don't follow the wiki or planet feed.[1]

FUDCon F11 Boston will be held all day January 9-11, 2009, at MIT's
Sloan Building as previously noted.  You do not need a Fedora account
to use the wiki page to pre-register for the conference:

http://fedoraproject.org/wiki/FUDCon/FUDConF11

FUDCon, as always, is free of cost and open to anyone to attend.
Pre-registration entitles each attendee to a complimentary gift, lunch
on Saturday, and dinner and a beverage on Sunday.  

Also, please sign up for a BarCamp or hackfest session.  These
sessions can include any topic around which you want to gather people
to collaborate and learn.  Many sessions are not announced until the
event begins, but pre-announcing them gives other community members a
chance to see more reasons why FUDCon is such a worthwhile event for
everyone.

Pre-registration will end on or about December 19th, so sign up today.


= = =
[1] The decongestants aren't helping either. ;-)

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/6c285089/attachment.sig>
-------------- next part --------------
_______________________________________________
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 Dec  3 17:09:09 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 18:09:09 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<200812030136.45621.konrad@tylerc.org>
	<1228299670.20451.1879.camel@beck.corsepiu.local>
Message-ID: <gh6efl$60v$1@ger.gmane.org>

Ralf Corsepius wrote:
> The autotools do not apply a central data base, they keep
> "configuration" and "installation" as separate jobs. cmake lumps them
> together.

Uh no, it doesn't.

CMake:
Configuration: cmake . or cmake ..
Building: make
Installing: make install/fast (or "make install" if you want it to do all
the dependency checks the "make" step already did again like the autotools
always do)

Autotools:
Configuration: ./configure or ../configure
Building: make
Installing: make install

The only extra job the autotools have is the useless "autogenerate and/or
files" (a.k.a. autoreconf) step, which is exactly the one I'm complaining
about.

        Kevin Kofler



From stickster at gmail.com  Wed Dec  3 17:09:26 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 3 Dec 2008 12:09:26 -0500
Subject: FUDCon F11 Boston
In-Reply-To: <20081203170148.GK13562@localhost.localdomain>
References: <20081201171910.GO18297@localhost.localdomain>
	<20081203170148.GK13562@localhost.localdomain>
Message-ID: <20081203170926.GM13562@localhost.localdomain>

On Wed, Dec 03, 2008 at 12:01:48PM -0500, Paul W. Frields wrote:
> http://fedoraproject.org/wiki/FUDCon/FUDConF11
> 
> FUDCon, as always, is free of cost and open to anyone to attend.
> Pre-registration entitles each attendee to a complimentary gift, lunch
> on Saturday, and dinner and a beverage on Sunday.  
                                            ^^^^^^

Ever have one of those days?  This should have read "Saturday night."
Pre-registrants get free lunch during the day on Saturday at BarCamp,
and dinner and a beverage on Saturday night at FUDPub.

Very sorry for the spam, all.

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/7a4b5250/attachment.sig>
-------------- next part --------------
_______________________________________________
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 Dec  3 17:14:05 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 18:14:05 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<200812030136.45621.konrad@tylerc.org>
	<1228299670.20451.1879.camel@beck.corsepiu.local>
	<gh6efl$60v$1@ger.gmane.org>
Message-ID: <gh6eot$60v$3@ger.gmane.org>

Oops, I wrote:
> The only extra job the autotools have is the useless "autogenerate and/or
> files" (a.k.a. autoreconf) step, which is exactly the one I'm complaining
> about.

That should have read "autogenerate and/or *copy* files".

        Kevin Kofler



From kevin.kofler at chello.at  Wed Dec  3 17:13:13 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 18:13:13 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812030136.45621.konrad@tylerc.org>
	<1228299670.20451.1879.camel@beck.corsepiu.local>
	<200812030236.43778.konrad@tylerc.org>
	<1228301740.20451.1934.camel@beck.corsepiu.local>
Message-ID: <gh6en9$60v$2@ger.gmane.org>

Ralf Corsepius wrote:
> It doesn't do so. The only difference is cmake carrying a vendor's
> preferences inside of itself, instead of rpm (from where autotools based
> configurations receive it).

That's not true. Have you ever looked at the %cmake and %cmake_kde4 macros?
How are they different from %configure? By being in cmake resp.
kde-filesystem rather than redhat-rpm-config? That's just a Fedora
packaging decision and it may change in the future, it has nothing to do
with the build systems' design.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Dec  3 17:24:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 18:24:02 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org>
	<200812031124.11838.opensource@till.name>
Message-ID: <gh6fbj$d2a$1@ger.gmane.org>

Till Maas wrote:
> I am only interested to know, when it finished. But this is already taken
> care of by koji. :-)
> Is it possible to disable the progress percentages? It looks to me, that
> it increases the build.log with a lot of lines. Or does it somehow help to
> know at which percentage a build failed?

As far as I know, it can't be disabled. And anyway, yes, knowing how far a
build got before it failed can be useful. And then there's also my habit of
regularly polling the build.log to see how far it already got when I'm
really impatient waiting for a build to finish. ;-)

I'd rather we disable the verbose mode (which unfortunately got just enabled
globally, but all the KDE packages were already using it anyway): that one
spams the log with a lot more lines, it's mostly redundant because the
progress reports already tell what file is being compiled and it also
breaks the color coding in non-mock builds (the verbose lines are in the
default color just as the error/warning messages) and displaces the
errors/warnings out of the terminal buffer way faster than necessary. Not
all RPM builds are with output redirected to a log file! Though all this
may well be a ploy to make non-mock builds utterly useless. ;-)

        Kevin Kofler



From kevin.kofler at chello.at  Wed Dec  3 17:27:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 18:27:59 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812031124.11838.opensource@till.name>
	<1228300274.20451.1893.camel@beck.corsepiu.local>
	<200812031146.18966.opensource@till.name>
Message-ID: <gh6fiv$d2a$2@ger.gmane.org>

Till Maas wrote:
> No, but I also see no colors in the build.log file. :-)

Because colors only work / are used when the output goes to an interactive
terminal. We need a Kate highlighting scheme for cmake-using build.log
files. ;-)

> I do not need any progress report, because I only care when it is
> finished.

I do, because I also care when it _will_ finish. :-)

> Yes, this is already taken care of in %cmake in rawhide, it makes at least
> the compiler flags visible in the make.log.

Yes, unfortunately.

> If you read my complete mail, you can see that I complained about the
> progress percentages, because they fill up the build.log.

A lot less than the verbose spam does.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Dec  3 17:33:43 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 03 Dec 2008 18:33:43 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<20081203100110.01427445@localhost.localdomain>
Message-ID: <gh6ftn$d2a$3@ger.gmane.org>

Ed Hill wrote:
>  + CMake -- have tried it a bit and have run into problems
>    (e.g., multi-job builds failing with frustraing race conditions)
>    with the setups created by others -- but it may be that its not
>    the tool per-se just the use of it

As far as I know, race conditions with parallel make are all due to some
missing dependencies in custom targets. If you use custom targets, you are
responsible for getting the dependencies right, just as in a handwritten
makefile. That's the drawback of custom targets. But they are essential for
extensibility. Automake supports them too (and there too, there are plenty
of packages getting the dependencies wrong). That's neither CMake's nor
Automake's fault.

        Kevin Kofler



From katzj at redhat.com  Wed Dec  3 17:38:05 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 03 Dec 2008 12:38:05 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <1228322430.3625.77.camel@eagle.danny.cz>
References: <1228245867.5858.3.camel@localhost.localdomain>
	<4936A3C0.4050803@redhat.com>
	<1228318746.2848.2.camel@localhost.localdomain>
	<4936AB6D.9050002@leemhuis.info>
	<20081203160550.GA5689@yoda.jdub.homelinux.org>
	<1228322430.3625.77.camel@eagle.danny.cz>
Message-ID: <1228325885.30719.3.camel@aglarond.local>

On Wed, 2008-12-03 at 17:40 +0100, Dan Hor?k wrote:
> Josh Boyer p??e v St 03. 12. 2008 v 11:05 -0500:
> > On Wed, Dec 03, 2008 at 04:53:17PM +0100, Thorsten Leemhuis wrote:
> > > On 03.12.2008 16:39, Brian Pepple wrote:
> > >> On Wed, 2008-12-03 at 10:20 -0500, Jarod Wilson wrote:
> > >>> /topic FESCo meeting -- Secondary Arches: will they ever fly? (aka, 
> > >>> wtf happened to Fedora ia64, and what can/should we do to resuscitate 
> > >>> it).
> > >> Added to the schedule.
> > >
> > > Wouldn't it be better to first discuss this on the list first?
> > 
> > Here's a brief summary as I know it:
[snip]
> > Maybe it's time we start a SIG.  We have Sparc, ia64, ARM, and one
> > or two potential others.  The biggest hurdle is koji at the moment
> > and hopefully that will be solved soon.  Then we can figure out where
> > to go from there.
> 
> Work is being done on s390x too.

Wasn't the idea that each arch should be its own SIG.  And it'd be
really nice to see semi-regular updates from the various arches that are
doing things on progress, either in the form of blog posts, mails to
fedora-devel, smoke signals, carrier pigeons :-)

While I know they're not all dead, status could help show up common
blocking problems and get more people involved in helping to resolve
them

Jeremy



From pertusus at free.fr  Wed Dec  3 18:02:08 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 3 Dec 2008 19:02:08 +0100
Subject: Server SIG - work areas
In-Reply-To: <Pine.LNX.4.61.0812031332220.6625@gonzo.dicp.de>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<d9c612bf0812022322v56ec7d5jd107a9848dd88f8@mail.gmail.com>
	<200812031224.mB3COVpB008672@laptop14.inf.utfsm.cl>
	<Pine.LNX.4.61.0812031332220.6625@gonzo.dicp.de>
Message-ID: <20081203180208.GB18067@free.fr>

On Wed, Dec 03, 2008 at 01:34:48PM +0100, Andreas Thienemann wrote:
>
> But there are other unsolved problems: e.g. php-gd pulled in half of the  
> X11 stack for a long time, I think this was partly fixed by now but the  
> dependency chain is still quite long.

libgd depends on libXpm, I am not sure anything could be done about it.

--
Pat



From ed at eh3.com  Wed Dec  3 18:16:14 2008
From: ed at eh3.com (Ed Hill)
Date: Wed, 3 Dec 2008 13:16:14 -0500
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh6ftn$d2a$3@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<20081203100110.01427445@localhost.localdomain>
	<gh6ftn$d2a$3@ger.gmane.org>
Message-ID: <20081203131614.0ee37d31@localhost.localdomain>

On Wed, 03 Dec 2008 18:33:43 +0100 Kevin Kofler wrote:
> Ed Hill wrote:
> >  + CMake -- have tried it a bit and have run into problems
> >    (e.g., multi-job builds failing with frustraing race conditions)
> >    with the setups created by others -- but it may be that its not
> >    the tool per-se just the use of it
> 
> As far as I know, race conditions with parallel make are all due to
> some missing dependencies in custom targets. If you use custom
> targets, you are responsible for getting the dependencies right, just
> as in a handwritten makefile. That's the drawback of custom targets.
> But they are essential for extensibility. Automake supports them too
> (and there too, there are plenty of packages getting the dependencies
> wrong). That's neither CMake's nor Automake's fault.


Hi Kevin,

Sure, I appreciate the point about poor use of the tools.

But getting back to the meatier issues -- can someone please point me
towards:

 + directions (and examples!) for using CMake for multi-language
   compiles and cross-langage linking (esp. C/C++ and Fortran)
 + creating shared libs for the above
 + manuals (and, if possible, "shining" examples) that describe best
   practices for non-trivial projects

Ed

-- 
Edward H. Hill III, PhD  |  ed at eh3.com  |  http://eh3.com/



From pertusus at free.fr  Wed Dec  3 18:16:49 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 3 Dec 2008 19:16:49 +0100
Subject: looking for inotifywait and similar help
In-Reply-To: <877i6hzmtq.fsf@sheridan.bigo.ensc.de>
References: <20081202233031.GA30159@free.fr>
	<91705d080812022016q7e2bc529t3eb64c9c24ead925@mail.gmail.com>
	<877i6hzmtq.fsf@sheridan.bigo.ensc.de>
Message-ID: <20081203181649.GA1588@free.fr>

On Wed, Dec 03, 2008 at 09:26:25AM +0100, Enrico Scholz wrote:
> 
> Beside the syntax error, there is a race when file was created shortly
> before inotifywait. You have to check whether the file exists *after*
> inotify_add_watch(2) like in
> 
>              https://www.cvg.de/people/ensc/wait-for-file.c

I don't really understand when the race condition could be, but in my
case there is a sleep 30 anyway before launching a command that checks
itself if the file exists, so I think this doesn't apply in my case.

> I filed a request a year ago to include similar functionality into
> inotifytools but this does not seem to implemented yet
> 
>   http://sourceforge.net/mailarchive/message.php?msg_name=lylkdk440g.fsf%40ensc-pc.intern.sigma-chemnitz.de

In both cases /etc is watched. That is something I would have liked to
avoid, because it will cause my script to wake up a lot, compared with
only looking at /etc/cron.d, /etc/crontab and /etc/fcrontab. 

It looks like signalling that a file came into existence without
watching the directory the file is in is not possible with inotify
currently.

--
Pat



From ville.skytta at iki.fi  Wed Dec  3 18:24:20 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 3 Dec 2008 20:24:20 +0200
Subject: Server SIG - work areas
In-Reply-To: <20081203163835.GA18067@free.fr>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<Pine.LNX.4.61.0812031332220.6625@gonzo.dicp.de>
	<20081203163835.GA18067@free.fr>
Message-ID: <200812032024.22332.ville.skytta@iki.fi>

On Wednesday 03 December 2008, Patrice Dumas wrote:
>
> Also 'convert' from Imagemagick depends on X (and not only 'display')
> which is in my opinion much more problematic than gnuplot. I had a look
> and it was not easy to fix, at least until upstream does something.

GraphicsMagick and its "gm convert" is an alternative to that - GraphicsMagick 
is not free of X dependencies either but its complete dependency chain is 
much smaller than ImageMagick's.



From cry_regarder at yahoo.com  Wed Dec  3 18:53:28 2008
From: cry_regarder at yahoo.com (Cry)
Date: Wed, 3 Dec 2008 18:53:28 +0000 (UTC)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
Message-ID: <loom.20081203T184910-257@post.gmane.org>

gallery2 has two new versions and outstanding security bugs.  I have tried
several times to email the maintainer John Berninger with no replies to a few
different addresses.  Is this software dead in fedora? 

https://bugzilla.redhat.com/buglist.cgi?quicksearch=gallery2

It seems that John's last activity was back in June:

http://koji.fedoraproject.org/koji/userinfo?userID=225

Thanks,

Cry





From mike at cchtml.com  Wed Dec  3 18:59:21 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Wed, 03 Dec 2008 12:59:21 -0600
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <loom.20081203T184910-257@post.gmane.org>
References: <loom.20081203T184910-257@post.gmane.org>
Message-ID: <4936D709.5060903@cchtml.com>

-------- Original Message --------
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
From: Cry <cry_regarder at yahoo.com>
To: fedora-devel-list at redhat.com
Date: 12/03/2008 12:53 PM

> gallery2 has two new versions and outstanding security bugs.  I have tried
> several times to email the maintainer John Berninger with no replies to a few
> different addresses.  Is this software dead in fedora? 
> 
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=gallery2
> 
> It seems that John's last activity was back in June:
> 
> http://koji.fedoraproject.org/koji/userinfo?userID=225
> 

He also has outstanding bugs on Bugzilla for Bugzilla.

https://bugzilla.redhat.com/show_bug.cgi?id=466077



From limb at jcomserv.net  Wed Dec  3 19:03:44 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 3 Dec 2008 13:03:44 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <4936D709.5060903@cchtml.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
Message-ID: <dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>


> -------- Original Message --------
> Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
> From: Cry <cry_regarder at yahoo.com>
> To: fedora-devel-list at redhat.com
> Date: 12/03/2008 12:53 PM
>
>> gallery2 has two new versions and outstanding security bugs.  I have
>> tried
>> several times to email the maintainer John Berninger with no replies to
>> a few
>> different addresses.  Is this software dead in fedora?
>>
>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=gallery2
>>
>> It seems that John's last activity was back in June:
>>
>> http://koji.fedoraproject.org/koji/userinfo?userID=225
>>
>
> He also has outstanding bugs on Bugzilla for Bugzilla.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=466077
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
I suggest starting the NRM process:
https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From cry_regarder at yahoo.com  Wed Dec  3 19:04:32 2008
From: cry_regarder at yahoo.com (Cry)
Date: Wed, 3 Dec 2008 19:04:32 +0000 (UTC)
Subject: My (unpleasant) fedora 10 installation experience
References: <4933F7AD.1040904@gmail.com>
	<dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>
	<49340456.7050802@gmail.com>
	<bf967e93f32794940b6560b82c859ae9.squirrel@arekh.dyndns.org>
Message-ID: <loom.20081203T190300-549@post.gmane.org>

Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:


> xorg in Fedora now runs in no-configuration-file mode which means the
> layout preferences have to be read somewhere else.

Which brings in my Fedora 10 install experience.  If you have no xorg.conf You
CAN NOT DUAL HEAD!!!!!  You need to set Virtual big enough.  xrandr is useless
if there isn't a big enough virtual to support the monitor.  The default with no
xorg.conf should be the largest virtual possible.

Cry



From kevin at scrye.com  Wed Dec  3 19:17:36 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 3 Dec 2008 12:17:36 -0700
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081128120926.GA12663@amd.home.annexia.org>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
Message-ID: <20081203121736.0c4586d9@ohm.scrye.com>

On Fri, 28 Nov 2008 12:09:26 +0000
rjones at redhat.com ("Richard W.M. Jones") wrote:

> 
> Just to keep people updated, upstream OCaml made some small but
> significant change to a library which turns out to break lots of
> packages.  So this is going to take some time to get fixed.
> 
> Details here and in the follow-up messages.
> 
> http://caml.inria.fr/pub/ml-archives/caml-list/2008/11/4a13be017ce7f9b70941fe09fbcd9359.en.html

This subject came up at todays FESCo meeting. There continue to be a
bunch of broken dependencies in rawhide on these packages. 

Is there anything we can do to assist you in getting things back in
shape? I'd be happy to fix packages, but I don't know Ocaml, so it
would need to be a clear fix. ;) 

> Rich.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/238a701c/attachment.sig>

From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec  3 19:24:04 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 03 Dec 2008 20:24:04 +0100
Subject: looking for inotifywait and similar help
In-Reply-To: <20081203181649.GA1588@free.fr> (Patrice Dumas's message of "Wed,
	3 Dec 2008 19:16:49 +0100")
References: <20081202233031.GA30159@free.fr>
	<91705d080812022016q7e2bc529t3eb64c9c24ead925@mail.gmail.com>
	<877i6hzmtq.fsf@sheridan.bigo.ensc.de> <20081203181649.GA1588@free.fr>
Message-ID: <871vwp9i5n.fsf@sheridan.bigo.ensc.de>

Patrice Dumas <pertusus at free.fr> writes:

>> Beside the syntax error, there is a race when file was created shortly
>> before inotifywait. You have to check whether the file exists *after*
>> inotify_add_watch(2) like in
>> 
>>              https://www.cvg.de/people/ensc/wait-for-file.c
>
> I don't really understand when the race condition could be,

e.g.

---
d=/tmp/test
test -e $d/file || {
sleep 100
inotifywait -e create $d
}
---

and execute 'touch /tmp/test/file' during the 'sleep 10'.

-->  script will hang forever.


In practice, the 'sleep' is shorter but present.


> In both cases /etc is watched. That is something I would have liked to
> avoid, because it will cause my script to wake up a lot,

1. Why make it a script?  A small C program makes 3 syscalls per new
   file

   | $ strace ./a.out /tmp/foo1.c 100000
   | ...
   | select(4, [3], NULL, NULL, {99987, 966000}) = 1 (in [3], left {99981, 19000})
   | read(3, "\1\0\0\0\0\1\0\0\0\0\0\0\20\0\0\0xxcccvf5\0\0\0\0\0\0\0\0", 1024) = 32
   | lstat("/tmp/foo1.c", 0x7fffc8d46ed0)    = -1 ENOENT (No such file or directory)


2. /etc is not a directory where much file create operations happen


> It looks like signalling that a file came into existence without
> watching the directory the file is in is not possible with inotify
> currently.

No; inotify(7) does not support this operation.




Enrico



From jeff at ocjtech.us  Wed Dec  3 19:27:08 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Wed, 3 Dec 2008 13:27:08 -0600
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081203121736.0c4586d9@ohm.scrye.com>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
Message-ID: <935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>

2008/12/3 Kevin Fenzi <kevin at scrye.com>:
> On Fri, 28 Nov 2008 12:09:26 +0000
> rjones at redhat.com ("Richard W.M. Jones") wrote:
>
>>
>> Just to keep people updated, upstream OCaml made some small but
>> significant change to a library which turns out to break lots of
>> packages.  So this is going to take some time to get fixed.
>>
>> Details here and in the follow-up messages.
>>
>> http://caml.inria.fr/pub/ml-archives/caml-list/2008/11/4a13be017ce7f9b70941fe09fbcd9359.en.html
>
> This subject came up at todays FESCo meeting. There continue to be a
> bunch of broken dependencies in rawhide on these packages.
>
> Is there anything we can do to assist you in getting things back in
> shape? I'd be happy to fix packages, but I don't know Ocaml, so it
> would need to be a clear fix. ;)

Maybe there should be a new tag in Koji for fixing up all of the Ocaml
packages like was was done for Python 2.6 recently (dist-f11-python)
or Perl 5.10 for F-10 (dist-f10-perl).  Is there an easy way to make
packages tagged with dist-f11-ocaml yum installable so that testing
the packages is easier?

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From dpierce at redhat.com  Wed Dec  3 19:30:39 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 3 Dec 2008 14:30:39 -0500
Subject: Runlevels after F10 install
Message-ID: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>

Not sure if this who to report this to or how to view it, but wanted
to share this experience.

I installed F10 x86_64 on a machine for work. I wanted a minimal X11
environment, so I opted to install just WindowMaker and no desktop
environment like Gnome. No errors occurred, install completed
successfully.

On firstboot I was greeted with the text-mode setup utility to
configure firewall, networking, etc. I thought this odd, but went
with it. After completing setup, I was in run level 3. Checking I
realized no display manager were installed, nor was X. So I
installed both. 

Here are the issues. Doing a groupinstall for X did not prompt me 
for or change my default runlevel to 5. So I had to manually edit
/etc/inittab to set it to 5. That's when the other issue popped up:
no services were configured for runlevel 5. Networking, httpd, etc.
all shut down when things booted. X displayed during boot but, when
the system went to runlevel 5, everything else shut down.

Shouldn't installing X make runlevel 5 the default?

And, even if we don't install X, why should't services toggle their
runlevel 5 state?

-- 
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/432d31f5/attachment.sig>

From jkeating at redhat.com  Wed Dec  3 19:43:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 03 Dec 2008 11:43:14 -0800
Subject: Runlevels after F10 install
In-Reply-To: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
Message-ID: <1228333394.31305.28.camel@localhost.localdomain>

On Wed, 2008-12-03 at 14:30 -0500, Darryl L. Pierce wrote:
> Shouldn't installing X make runlevel 5 the default?

No.

> And, even if we don't install X, why should't services toggle their
> runlevel 5 state?

This seems to be the interesting part.  This... shouldn't happen.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/c478ae5c/attachment.sig>

From skvidal at fedoraproject.org  Wed Dec  3 19:46:27 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 3 Dec 2008 14:46:27 -0500 (EST)
Subject: Fedora 10 and YUM
In-Reply-To: <20081128091450.01790757@ludwig-alpha.unil.ch>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
Message-ID: <alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>



On Fri, 28 Nov 2008, Christian Iseli wrote:

> On Fri, 28 Nov 2008 00:42:28 -0500 (EST), Seth Vidal wrote:
>> 1. Do you have any proxies setup?
>
> no
>
>> 2. What are the nameserver entries in /etc/resolv.conf?
>
> Just my home ADSL router (192.168.1.1)
>
> I used dhclient to obtain an IP address, and it also setup
> the /etc/resolv.conf file.
>
> I have another Fedora 8 box connected to the same router, and there are
> no DNS problems there.
> 					C

Did these problems magically go away recently?

-sv



From dpierce at redhat.com  Wed Dec  3 19:49:31 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 3 Dec 2008 14:49:31 -0500
Subject: Runlevels after F10 install
In-Reply-To: <1228333394.31305.28.camel@localhost.localdomain>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
Message-ID: <20081203194931.GD4960@mcpierce-laptop.mcpierce.org>

On Wed, Dec 03, 2008 at 11:43:14AM -0800, Jesse Keating wrote:
> On Wed, 2008-12-03 at 14:30 -0500, Darryl L. Pierce wrote:
> > Shouldn't installing X make runlevel 5 the default?
> 
> No.

That's fine. I wasn't sure how it ought to proceed.

> > And, even if we don't install X, why should't services toggle their
> > runlevel 5 state?
> 
> This seems to be the interesting part.  This... shouldn't happen.

Agreed. I wasn't sure which component owned the services
configuration, so thought I'd float this here before logging a BZ
ticket.

-- 
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/de8c8d41/attachment.sig>

From notting at redhat.com  Wed Dec  3 19:54:47 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 3 Dec 2008 14:54:47 -0500
Subject: Runlevels after F10 install
In-Reply-To: <20081203194931.GD4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<20081203194931.GD4960@mcpierce-laptop.mcpierce.org>
Message-ID: <20081203195447.GA12864@nostromo.devel.redhat.com>

Darryl L. Pierce (dpierce at redhat.com) said: 
> On Wed, Dec 03, 2008 at 11:43:14AM -0800, Jesse Keating wrote:
> > On Wed, 2008-12-03 at 14:30 -0500, Darryl L. Pierce wrote:
> > > Shouldn't installing X make runlevel 5 the default?
> > 
> > No.
> 
> That's fine. I wasn't sure how it ought to proceed.

If you install a desktop, anaconda will modify the default runlevel.
(This may be limited to GNOME or KDE.) Otherwise, we don't touch it.

> > > And, even if we don't install X, why should't services toggle their
> > > runlevel 5 state?
> > 
> > This seems to be the interesting part.  This... shouldn't happen.
> 
> Agreed. I wasn't sure which component owned the services
> configuration, so thought I'd float this here before logging a BZ
> ticket.

Nothing should specifically change for runlevel 5 from the defaults.

Bill



From katzj at redhat.com  Wed Dec  3 20:11:16 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 03 Dec 2008 15:11:16 -0500
Subject: Runlevels after F10 install
In-Reply-To: <20081203195447.GA12864@nostromo.devel.redhat.com>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<20081203194931.GD4960@mcpierce-laptop.mcpierce.org>
	<20081203195447.GA12864@nostromo.devel.redhat.com>
Message-ID: <1228335076.13947.0.camel@aglarond.local>

On Wed, 2008-12-03 at 14:54 -0500, Bill Nottingham wrote:
> Darryl L. Pierce (dpierce at redhat.com) said: 
> > On Wed, Dec 03, 2008 at 11:43:14AM -0800, Jesse Keating wrote:
> > > On Wed, 2008-12-03 at 14:30 -0500, Darryl L. Pierce wrote:
> > > > Shouldn't installing X make runlevel 5 the default?
> > > 
> > > No.
> > 
> > That's fine. I wasn't sure how it ought to proceed.
> 
> If you install a desktop, anaconda will modify the default runlevel.
> (This may be limited to GNOME or KDE.) Otherwise, we don't touch it.

It's based on whether gdm or kdm (kdebase-workspace) are installed

Jeremy



From opensource at till.name  Wed Dec  3 20:20:23 2008
From: opensource at till.name (Till Maas)
Date: Wed, 03 Dec 2008 21:20:23 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh6fbj$d2a$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812031124.11838.opensource@till.name> <gh6fbj$d2a$1@ger.gmane.org>
Message-ID: <200812032120.39907.opensource@till.name>

On Wed December 3 2008, Kevin Kofler wrote:

> I'd rather we disable the verbose mode (which unfortunately got just
> enabled globally, but all the KDE packages were already using it anyway):
> that one spams the log with a lot more lines, it's mostly redundant because
> the progress reports already tell what file is being compiled and it also
> breaks the color coding in non-mock builds (the verbose lines are in the
> default color just as the error/warning messages) and displaces the
> errors/warnings out of the terminal buffer way faster than necessary. Not
> all RPM builds are with output redirected to a log file! Though all this
> may well be a ploy to make non-mock builds utterly useless. ;-)

The problem is, that the non verbose build mode hides, whether or not the 
RPM_OPT_FLAGS are honoured, but it is required to honour them. Maybe cmake 
needs a way to tell it to only show the compiler invocations, but not the 
remaining stuff, that is shown with VERBOSE=1 and not useful.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/fad0617d/attachment.sig>

From jspaleta at gmail.com  Wed Dec  3 20:29:13 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 3 Dec 2008 11:29:13 -0900
Subject: Runlevels after F10 install
In-Reply-To: <1228333394.31305.28.camel@localhost.localdomain>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
Message-ID: <604aa7910812031229y445fd1a8ud4e32947a974b699@mail.gmail.com>

2008/12/3 Jesse Keating <jkeating at redhat.com>:
> This seems to be the interesting part.  This... shouldn't happen.

Is his /etc/event.d/rc5 script not firing?

-jef



From jspaleta at gmail.com  Wed Dec  3 20:27:03 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 3 Dec 2008 11:27:03 -0900
Subject: Runlevels after F10 install
In-Reply-To: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
Message-ID: <604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>

2008/12/3 Darryl L. Pierce <dpierce at redhat.com>:
> And, even if we don't install X, why should't services toggle their
> runlevel 5 state?

Did you manually turn services on for runlevel 3 before editting the inittab?

chkconfig --list  will give a summary of the runlevel activation
settings for each service.

Does chkconfig list the services you are concerned about as being
active for runlevel 5?

-jef



From dpierce at redhat.com  Wed Dec  3 20:35:48 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 3 Dec 2008 15:35:48 -0500
Subject: Runlevels after F10 install
In-Reply-To: <1228335076.13947.0.camel@aglarond.local>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<20081203194931.GD4960@mcpierce-laptop.mcpierce.org>
	<20081203195447.GA12864@nostromo.devel.redhat.com>
	<1228335076.13947.0.camel@aglarond.local>
Message-ID: <20081203203548.GE4960@mcpierce-laptop.mcpierce.org>

On Wed, Dec 03, 2008 at 03:11:16PM -0500, Jeremy Katz wrote:
> > > That's fine. I wasn't sure how it ought to proceed.
> > 
> > If you install a desktop, anaconda will modify the default runlevel.
> > (This may be limited to GNOME or KDE.) Otherwise, we don't touch it.
> 
> It's based on whether gdm or kdm (kdebase-workspace) are installed

So, when I installed gdm after the fact, should it have changed the
runlevel?

-- 
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/b1e4bcef/attachment.sig>

From dpierce at redhat.com  Wed Dec  3 20:37:44 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 3 Dec 2008 15:37:44 -0500
Subject: Runlevels after F10 install
In-Reply-To: <604aa7910812031229y445fd1a8ud4e32947a974b699@mail.gmail.com>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<604aa7910812031229y445fd1a8ud4e32947a974b699@mail.gmail.com>
Message-ID: <20081203203743.GF4960@mcpierce-laptop.mcpierce.org>

On Wed, Dec 03, 2008 at 11:29:13AM -0900, Jeff Spaleta wrote:
> 2008/12/3 Jesse Keating <jkeating at redhat.com>:
> > This seems to be the interesting part.  This... shouldn't happen.
> 
> Is his /etc/event.d/rc5 script not firing?

Services such as network and httpd had "off" as their runlevel 5
setting.

-- 
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/cb7405b1/attachment.sig>

From dpierce at redhat.com  Wed Dec  3 20:38:56 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 3 Dec 2008 15:38:56 -0500
Subject: Runlevels after F10 install
In-Reply-To: <604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
Message-ID: <20081203203856.GG4960@mcpierce-laptop.mcpierce.org>

On Wed, Dec 03, 2008 at 11:27:03AM -0900, Jeff Spaleta wrote:
> 2008/12/3 Darryl L. Pierce <dpierce at redhat.com>:
> > And, even if we don't install X, why should't services toggle their
> > runlevel 5 state?
> 
> Did you manually turn services on for runlevel 3 before editting the inittab?
> 
> chkconfig --list  will give a summary of the runlevel activation
> settings for each service.
> 
> Does chkconfig list the services you are concerned about as being
> active for runlevel 5?

See my other email, but no I didn't turn anything off or on. I only
turned on httpd and network after I saw they were turned off for 5
after installing X.

-- 
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/f47b5683/attachment.sig>

From opensource at till.name  Wed Dec  3 20:42:59 2008
From: opensource at till.name (Till Maas)
Date: Wed, 03 Dec 2008 21:42:59 +0100
Subject: rpms/libxml2/devel libxml2.spec,1.65,1.66
In-Reply-To: <4936AE70.3090201@ioa.s.u-tokyo.ac.jp>
References: <20081203134419.B08167011D@cvs1.fedora.phx.redhat.com>
	<alpine.DEB.1.10.0812031734590.22110@gotcha.dreamhost.com>
	<4936AE70.3090201@ioa.s.u-tokyo.ac.jp>
Message-ID: <200812032143.04834.opensource@till.name>

On Wed December 3 2008, Mamoru Tasaka wrote:

> My current opinition is that rpm-build should have "Requires: pkgconfig"
> because this affects even a small package and guideline changes due to this
> issue will affect many packages.

This does not explain why it should not be in the buildsys-build comps group. 
Or are there any predefined macros in rpm that require pkgconfig? This is the 
only reason I would agree to add Requires: for something directly to 
rpm-build.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/cf2ac231/attachment.sig>

From mike at cchtml.com  Wed Dec  3 20:43:50 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Wed, 03 Dec 2008 14:43:50 -0600
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
References: <loom.20081203T184910-257@post.gmane.org>	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
Message-ID: <4936EF86.5020409@cchtml.com>

-------- Original Message --------
Subject: Re: gallery2 outstanding security bugs -- Abondoned by Berninger?
From: Jon Ciesla <limb at jcomserv.net>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 12/03/2008 01:03 PM

> I suggest starting the NRM process:
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
> 

It has already started. Bugs have been filed. Attempts to contact have 
been made. It's been months with zero contact.

I guess the next step is to ask: who can take up these packages?



From jspaleta at gmail.com  Wed Dec  3 21:13:06 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 3 Dec 2008 12:13:06 -0900
Subject: Runlevels after F10 install
In-Reply-To: <20081203203743.GF4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<604aa7910812031229y445fd1a8ud4e32947a974b699@mail.gmail.com>
	<20081203203743.GF4960@mcpierce-laptop.mcpierce.org>
Message-ID: <604aa7910812031313s50da6f14x99e77f62bb5af5c3@mail.gmail.com>

2008/12/3 Darryl L. Pierce <dpierce at redhat.com>:
> Services such as network and httpd had "off" as their runlevel 5
> setting.

But the problem is..we don't know what the configuration was for
runlevel settings before you started taking local action.  We are
assuming services started out as on for runlevel 5 after your install
into runlevel 3 was completed, To narrow down where to look. you'll
need to try to reproduce this by starting afresh and doing everything
again..watching for which specific action turns off services in
runlevel 5.  Hell you could have tripped over an obscure rpm trigger
or something that calls chkconfig and disables services on package
install.

-jef



From katzj at redhat.com  Wed Dec  3 21:17:17 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 03 Dec 2008 16:17:17 -0500
Subject: Runlevels after F10 install
In-Reply-To: <20081203203548.GE4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<20081203194931.GD4960@mcpierce-laptop.mcpierce.org>
	<20081203195447.GA12864@nostromo.devel.redhat.com>
	<1228335076.13947.0.camel@aglarond.local>
	<20081203203548.GE4960@mcpierce-laptop.mcpierce.org>
Message-ID: <1228339037.13947.5.camel@aglarond.local>

On Wed, 2008-12-03 at 15:35 -0500, Darryl L. Pierce wrote:
> On Wed, Dec 03, 2008 at 03:11:16PM -0500, Jeremy Katz wrote:
> > > > That's fine. I wasn't sure how it ought to proceed.
> > > 
> > > If you install a desktop, anaconda will modify the default runlevel.
> > > (This may be limited to GNOME or KDE.) Otherwise, we don't touch it.
> > 
> > It's based on whether gdm or kdm (kdebase-workspace) are installed
> 
> So, when I installed gdm after the fact, should it have changed the
> runlevel?

No.  It's done by anaconda.  anaconda doesn't do anything after your
system is installed.

Jeremy



From notting at redhat.com  Wed Dec  3 21:19:59 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 3 Dec 2008 16:19:59 -0500
Subject: Runlevels after F10 install
In-Reply-To: <20081203203548.GE4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<20081203194931.GD4960@mcpierce-laptop.mcpierce.org>
	<20081203195447.GA12864@nostromo.devel.redhat.com>
	<1228335076.13947.0.camel@aglarond.local>
	<20081203203548.GE4960@mcpierce-laptop.mcpierce.org>
Message-ID: <20081203211959.GC14354@nostromo.devel.redhat.com>

Darryl L. Pierce (dpierce at redhat.com) said: 
> So, when I installed gdm after the fact, should it have changed the
> runlevel?

No.

Bill



From katzj at redhat.com  Wed Dec  3 21:18:06 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 03 Dec 2008 16:18:06 -0500
Subject: Runlevels after F10 install
In-Reply-To: <20081203203743.GF4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<604aa7910812031229y445fd1a8ud4e32947a974b699@mail.gmail.com>
	<20081203203743.GF4960@mcpierce-laptop.mcpierce.org>
Message-ID: <1228339086.13947.6.camel@aglarond.local>

On Wed, 2008-12-03 at 15:37 -0500, Darryl L. Pierce wrote:
> On Wed, Dec 03, 2008 at 11:29:13AM -0900, Jeff Spaleta wrote:
> > 2008/12/3 Jesse Keating <jkeating at redhat.com>:
> > > This seems to be the interesting part.  This... shouldn't happen.
> > 
> > Is his /etc/event.d/rc5 script not firing?
> 
> Services such as network and httpd had "off" as their runlevel 5
> setting.

Yes, they're off by default.  If you just ran 'chkconfig httpd on' when
you were in runlevel 3, then it only affects runlevel 3.  You have to
explicitly tell chkconfig if you want it to affect other runlevels.
This is the way chkconfig has always worked.

Jeremy



From ajax at redhat.com  Wed Dec  3 21:30:31 2008
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 03 Dec 2008 16:30:31 -0500
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <loom.20081203T190300-549@post.gmane.org>
References: <4933F7AD.1040904@gmail.com>
	<dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>
	<49340456.7050802@gmail.com>
	<bf967e93f32794940b6560b82c859ae9.squirrel@arekh.dyndns.org>
	<loom.20081203T190300-549@post.gmane.org>
Message-ID: <1228339831.14110.279.camel@atropine.boston.devel.redhat.com>

On Wed, 2008-12-03 at 19:04 +0000, Cry wrote:
> Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> 
> 
> > xorg in Fedora now runs in no-configuration-file mode which means the
> > layout preferences have to be read somewhere else.
> 
> Which brings in my Fedora 10 install experience.  If you have no xorg.conf You
> CAN NOT DUAL HEAD!!!!!  You need to set Virtual big enough.  xrandr is useless
> if there isn't a big enough virtual to support the monitor.  The default with no
> xorg.conf should be the largest virtual possible.

No, it shouldn't be, because that burns memory on integrated graphics
machines like Intel, and because it destroys your ability to do 3d on
older cards, and and and.

We do have a heuristic to pick a plausible virtual size based on how
much video memory you have.  It's not perfect, nor can it ever be.
We're hoping for F11 to have it fixed so the screen is dynamically
resizable.

- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/6d549821/attachment.sig>

From pertusus at free.fr  Wed Dec  3 21:32:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 3 Dec 2008 22:32:30 +0100
Subject: looking for inotifywait and similar help
In-Reply-To: <871vwp9i5n.fsf@sheridan.bigo.ensc.de>
References: <20081202233031.GA30159@free.fr>
	<91705d080812022016q7e2bc529t3eb64c9c24ead925@mail.gmail.com>
	<877i6hzmtq.fsf@sheridan.bigo.ensc.de>
	<20081203181649.GA1588@free.fr>
	<871vwp9i5n.fsf@sheridan.bigo.ensc.de>
Message-ID: <20081203213230.GE2650@free.fr>

On Wed, Dec 03, 2008 at 08:24:04PM +0100, Enrico Scholz wrote:
> 
> 
> 1. Why make it a script?  A small C program makes 3 syscalls per new
>    file

Just because it is simpler to do, to debug... But maybe I'll do some C
to include it directly in fcron.

> 2. /etc is not a directory where much file create operations happen

Indeed. I didn't realized that only the file creations were acted upon.

So I'll certainly use your code or use it as a base for something
directly in fcron.

--
Pat



From limb at jcomserv.net  Wed Dec  3 21:27:48 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 3 Dec 2008 15:27:48 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <4936EF86.5020409@cchtml.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
Message-ID: <9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>


> -------- Original Message --------
> Subject: Re: gallery2 outstanding security bugs -- Abondoned by Berninger?
> From: Jon Ciesla <limb at jcomserv.net>
> To: Development discussions related to Fedora
> <fedora-devel-list at redhat.com>
> Date: 12/03/2008 01:03 PM
>
>> I suggest starting the NRM process:
>> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
>>
>
> It has already started. Bugs have been filed. Attempts to contact have
> been made. It's been months with zero contact.
>
> I guess the next step is to ask: who can take up these packages?
>
I could take a crack at gallery2.

-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From jwboyer at gmail.com  Wed Dec  3 21:52:13 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 3 Dec 2008 16:52:13 -0500
Subject: rawhide report: 20081128 changes
In-Reply-To: <935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
Message-ID: <20081203215213.GB5689@yoda.jdub.homelinux.org>

On Wed, Dec 03, 2008 at 01:27:08PM -0600, Jeffrey Ollie wrote:
>2008/12/3 Kevin Fenzi <kevin at scrye.com>:
>> On Fri, 28 Nov 2008 12:09:26 +0000
>> rjones at redhat.com ("Richard W.M. Jones") wrote:
>>
>>>
>>> Just to keep people updated, upstream OCaml made some small but
>>> significant change to a library which turns out to break lots of
>>> packages.  So this is going to take some time to get fixed.
>>>
>>> Details here and in the follow-up messages.
>>>
>>> http://caml.inria.fr/pub/ml-archives/caml-list/2008/11/4a13be017ce7f9b70941fe09fbcd9359.en.html
>>
>> This subject came up at todays FESCo meeting. There continue to be a
>> bunch of broken dependencies in rawhide on these packages.
>>
>> Is there anything we can do to assist you in getting things back in
>> shape? I'd be happy to fix packages, but I don't know Ocaml, so it
>> would need to be a clear fix. ;)
>
>Maybe there should be a new tag in Koji for fixing up all of the Ocaml
>packages like was was done for Python 2.6 recently (dist-f11-python)
>or Perl 5.10 for F-10 (dist-f10-perl).  Is there an easy way to make
>packages tagged with dist-f11-ocaml yum installable so that testing
>the packages is easier?

A separate tag isn't really going to help things, given that the updated
Ocaml is already in rawhide.

josh



From jwboyer at gmail.com  Wed Dec  3 21:54:31 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 3 Dec 2008 16:54:31 -0500
Subject: Plan for tomorrows (20081203) FESCO meeting
In-Reply-To: <1228325885.30719.3.camel@aglarond.local>
References: <1228245867.5858.3.camel@localhost.localdomain>
	<4936A3C0.4050803@redhat.com>
	<1228318746.2848.2.camel@localhost.localdomain>
	<4936AB6D.9050002@leemhuis.info>
	<20081203160550.GA5689@yoda.jdub.homelinux.org>
	<1228322430.3625.77.camel@eagle.danny.cz>
	<1228325885.30719.3.camel@aglarond.local>
Message-ID: <20081203215431.GC5689@yoda.jdub.homelinux.org>

On Wed, Dec 03, 2008 at 12:38:05PM -0500, Jeremy Katz wrote:
>On Wed, 2008-12-03 at 17:40 +0100, Dan Hor?k wrote:
>> Josh Boyer p??e v St 03. 12. 2008 v 11:05 -0500:
>> > On Wed, Dec 03, 2008 at 04:53:17PM +0100, Thorsten Leemhuis wrote:
>> > > On 03.12.2008 16:39, Brian Pepple wrote:
>> > >> On Wed, 2008-12-03 at 10:20 -0500, Jarod Wilson wrote:
>> > >>> /topic FESCo meeting -- Secondary Arches: will they ever fly? (aka, 
>> > >>> wtf happened to Fedora ia64, and what can/should we do to resuscitate 
>> > >>> it).
>> > >> Added to the schedule.
>> > >
>> > > Wouldn't it be better to first discuss this on the list first?
>> > 
>> > Here's a brief summary as I know it:
>[snip]
>> > Maybe it's time we start a SIG.  We have Sparc, ia64, ARM, and one
>> > or two potential others.  The biggest hurdle is koji at the moment
>> > and hopefully that will be solved soon.  Then we can figure out where
>> > to go from there.
>> 
>> Work is being done on s390x too.
>
>Wasn't the idea that each arch should be its own SIG.  And it'd be

Sort of.

>really nice to see semi-regular updates from the various arches that are
>doing things on progress, either in the form of blog posts, mails to
>fedora-devel, smoke signals, carrier pigeons :-)

FESCo agreed on this today as well.  I'll be contacting the various
arch teams and asking them for monthly updates.

>While I know they're not all dead, status could help show up common
>blocking problems and get more people involved in helping to resolve
>them

Right.  And the 'common problems' part is what I wanted to get with the
overall "Secondary Arch SIG".  I was envisioning a simple "have the
Arch team leads meet once in a while to discuss on-goings".  It doesn't
have to be formal.

josh



From stickster at gmail.com  Wed Dec  3 21:23:20 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 3 Dec 2008 16:23:20 -0500
Subject: Board appointment
Message-ID: <20081203212320.GO495@localhost.localdomain>

During this election season, there are two (2) appointed seats and two
(2) community-elected seats open on the Fedora Board.  This cycle,
Bill Nottingham, Karsten Wade, Matt Domsch, and Jef Spaleta are
turning over their seats.  These folks have given very generously of
their time over the last year -- and in some cases years -- and helped
with a great deal of heavy lifting.  Thank you, each and every one;
the community and I are in your debt!

http://fedoraproject.org/wiki/Elections
https://fedoraproject.org/wiki/Board/Elections/Nominations

As you'll see from the URLs above, there is an incredible slate of
worthy candidates up for election, and I'm very excited to see people
who are interested and passionate in helping drive Fedora forward by
helping the Board remove barriers to contribution.  Those barriers get
reduced steadily over time, but there is always more to do.

The elections will begin on 7 December, after a set of town hall
meetings where community members can ask the nominees questions.
Check the general elections wiki page above for the schedule and
details.  We have set these meetings up in response to community
requests and encourage you to attend as many as you like.  You should
also feel free to write to individual nominees directly to ask
questions that are important to you.

The two appointed seats on the Board are nominated by Red Hat and
chosen by the FPL.  One appointment is held back until after the
elections so that the Board's composition can be balanced as needed.
The balance of the appointments are announced before elections.[1]

For this cycle, Chris Aillon will return to the Board as an appointee.
Chris is a long-time Fedora contributor and member of the Red Hat
Desktop team, and among other responsibilities he is the maintainer of
the ever-popular Mozilla Firefox and related packages in Fedora and in
RHEL.  Chris served on the Board previously for approximately a year,
from summer 2007 to summer 2008.[2]  The Board and I welcome him back,
and look forward to working with him again.


= = =
[1] https://fedoraproject.org/wiki/Board/SuccessionPlanning
[2] https://fedoraproject.org/wiki/Board/History

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/016ccfa0/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From jeff at ocjtech.us  Wed Dec  3 21:58:47 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Wed, 3 Dec 2008 15:58:47 -0600
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081203215213.GB5689@yoda.jdub.homelinux.org>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
Message-ID: <935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>

On Wed, Dec 3, 2008 at 3:52 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Wed, Dec 03, 2008 at 01:27:08PM -0600, Jeffrey Ollie wrote:
>>
>>Maybe there should be a new tag in Koji for fixing up all of the Ocaml
>>packages like was was done for Python 2.6 recently (dist-f11-python)
>>or Perl 5.10 for F-10 (dist-f10-perl).  Is there an easy way to make
>>packages tagged with dist-f11-ocaml yum installable so that testing
>>the packages is easier?
>
> A separate tag isn't really going to help things, given that the updated
> Ocaml is already in rawhide.

Unless ocaml in dist-f11 was reverted to a pre-broken state.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From jkeating at redhat.com  Wed Dec  3 22:02:40 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 03 Dec 2008 14:02:40 -0800
Subject: Runlevels after F10 install
In-Reply-To: <20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
Message-ID: <1228341760.31305.34.camel@localhost.localdomain>

On Wed, 2008-12-03 at 15:38 -0500, Darryl L. Pierce wrote:
> 
> See my other email, but no I didn't turn anything off or on. I only
> turned on httpd and network after I saw they were turned off for 5
> after installing X.

Given that we use NetworkManager, and that http is off by default, these
were most likely off for run level 3, as well as 5.  The switch from 3
to have had no effect upon them, they were just plain off.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/fca98854/attachment.sig>

From csnook at redhat.com  Wed Dec  3 22:11:26 2008
From: csnook at redhat.com (Chris Snook)
Date: Wed, 03 Dec 2008 17:11:26 -0500
Subject: Runlevels after F10 install
In-Reply-To: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
Message-ID: <4937040E.2070604@redhat.com>

Darryl L. Pierce wrote:
> Not sure if this who to report this to or how to view it, but wanted
> to share this experience.
> 
> I installed F10 x86_64 on a machine for work. I wanted a minimal X11
> environment, so I opted to install just WindowMaker and no desktop
> environment like Gnome. No errors occurred, install completed
> successfully.
> 
> On firstboot I was greeted with the text-mode setup utility to
> configure firewall, networking, etc. I thought this odd, but went
> with it. After completing setup, I was in run level 3. Checking I
> realized no display manager were installed, nor was X. So I
> installed both. 
> 
> Here are the issues. Doing a groupinstall for X did not prompt me 
> for or change my default runlevel to 5. So I had to manually edit
> /etc/inittab to set it to 5. That's when the other issue popped up:
> no services were configured for runlevel 5. Networking, httpd, etc.
> all shut down when things booted. X displayed during boot but, when
> the system went to runlevel 5, everything else shut down.
> 
> Shouldn't installing X make runlevel 5 the default?
> 
> And, even if we don't install X, why should't services toggle their
> runlevel 5 state?
> 
> 

Very Bad Things happen when packages mess with files they don't own, so it's not 
a bug that installing an X server didn't change your default runlevel.  It's 
also not a bug that WindowMaker didn't pull in a display manager, since 
lightweight window managers are often used remotely on headless servers, which 
we don't want anaconda configuring for runlevel 5 by default.

The services problem is definitely a bug though.

-- Chris



From dpierce at redhat.com  Wed Dec  3 22:39:28 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 3 Dec 2008 17:39:28 -0500
Subject: Runlevels after F10 install
In-Reply-To: <1228341760.31305.34.camel@localhost.localdomain>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
	<1228341760.31305.34.camel@localhost.localdomain>
Message-ID: <20081203223928.GA16131@mcpierce-laptop.mcpierce.org>

On Wed, Dec 03, 2008 at 02:02:40PM -0800, Jesse Keating wrote:
> Given that we use NetworkManager, and that http is off by default, these
> were most likely off for run level 3, as well as 5.  The switch from 3
> to have had no effect upon them, they were just plain off.

Okay, that would explain those being off then. During firstboot I
did tell the system that I wanted network and httpd services
enabled, so that would explain why it set them for runlevel 3.

-- 
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/feeda65c/attachment.sig>

From dpierce at redhat.com  Wed Dec  3 22:42:30 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 3 Dec 2008 17:42:30 -0500
Subject: Runlevels after F10 install
In-Reply-To: <20081203223928.GA16131@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
	<1228341760.31305.34.camel@localhost.localdomain>
	<20081203223928.GA16131@mcpierce-laptop.mcpierce.org>
Message-ID: <20081203224230.GB16131@mcpierce-laptop.mcpierce.org>

On Wed, Dec 03, 2008 at 05:39:28PM -0500, Darryl L. Pierce wrote:
> On Wed, Dec 03, 2008 at 02:02:40PM -0800, Jesse Keating wrote:
> > Given that we use NetworkManager, and that http is off by default, these
> > were most likely off for run level 3, as well as 5.  The switch from 3
> > to have had no effect upon them, they were just plain off.
> 
> Okay, that would explain those being off then. During firstboot I
> did tell the system that I wanted network and httpd services
> enabled, so that would explain why it set them for runlevel 3.

Hit send to early. 

...that would explay why it was set for runlevel 3. Shouldn't it
have also set them for runlevel 5?

-- 
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/00aa6bdf/attachment.sig>

From jkeating at redhat.com  Wed Dec  3 22:56:59 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 03 Dec 2008 14:56:59 -0800
Subject: Runlevels after F10 install
In-Reply-To: <20081203224230.GB16131@mcpierce-laptop.mcpierce.org>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
	<1228341760.31305.34.camel@localhost.localdomain>
	<20081203223928.GA16131@mcpierce-laptop.mcpierce.org>
	<20081203224230.GB16131@mcpierce-laptop.mcpierce.org>
Message-ID: <1228345019.31305.50.camel@localhost.localdomain>

On Wed, 2008-12-03 at 17:42 -0500, Darryl L. Pierce wrote:
> 
> ...that would explay why it was set for runlevel 3. Shouldn't it
> have also set them for runlevel 5?

No.  chkconfig service on will only set it for the current runlevel,
although the man page doesn't make this obvious.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/3cc50c3e/attachment.sig>

From poelstra at redhat.com  Wed Dec  3 23:50:32 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 03 Dec 2008 15:50:32 -0800
Subject: rawhide status page.
In-Reply-To: <20081202210734.GA6778@redhat.com>
References: <20081202210734.GA6778@redhat.com>
Message-ID: <49371B48.7010104@redhat.com>

Dave Jones wrote:
> I'm sure something like this used to exist on the wiki at
> some point, but I'm having trouble finding it.
> 
> I think it would be useful to have a 'rawhide status' page
> on the wiki, updated daily with the latest problems
> be they dependancy failures, or broken installers, or
> broken kernels or whatever.
> 
> The idea being, by checking this page, people can decide
> whether it's worth rsyncing a few hundred MB of packages,
> or whether it's better to sit it out and try again the next day.
> 
> Does this exist already and I've just overlooked it?
> 
> 	Dave
> 

http://wwoods.fedorapeople.org/rawhide.html



From nathanael at gnat.ca  Thu Dec  4 00:14:50 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Wed, 03 Dec 2008 17:14:50 -0700
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <1228339831.14110.279.camel@atropine.boston.devel.redhat.com>
References: <4933F7AD.1040904@gmail.com>	<dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>	<49340456.7050802@gmail.com>	<bf967e93f32794940b6560b82c859ae9.squirrel@arekh.dyndns.org>	<loom.20081203T190300-549@post.gmane.org>
	<1228339831.14110.279.camel@atropine.boston.devel.redhat.com>
Message-ID: <493720FA.3080901@gnat.ca>

Adam Jackson wrote:
> On Wed, 2008-12-03 at 19:04 +0000, Cry wrote:
>> Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
>>
>>
>>> xorg in Fedora now runs in no-configuration-file mode which means the
>>> layout preferences have to be read somewhere else.
>> Which brings in my Fedora 10 install experience.  If you have no xorg.conf You
>> CAN NOT DUAL HEAD!!!!!  You need to set Virtual big enough.  xrandr is useless
>> if there isn't a big enough virtual to support the monitor.  The default with no
>> xorg.conf should be the largest virtual possible.
> 
> No, it shouldn't be, because that burns memory on integrated graphics
> machines like Intel, and because it destroys your ability to do 3d on
> older cards, and and and.

That's some great information. Granted creating the xorg.conf for my 
dual head setup wasn't a pain personally, I wondered why they chose such 
a fb size. I asked on the radeonhd ml with no response. This totally 
answers that question.


-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From dennisml at conversis.de  Thu Dec  4 00:36:27 2008
From: dennisml at conversis.de (Dennis J.)
Date: Thu, 04 Dec 2008 01:36:27 +0100
Subject: Runlevels after F10 install
In-Reply-To: <1228339086.13947.6.camel@aglarond.local>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>	<1228333394.31305.28.camel@localhost.localdomain>	<604aa7910812031229y445fd1a8ud4e32947a974b699@mail.gmail.com>	<20081203203743.GF4960@mcpierce-laptop.mcpierce.org>
	<1228339086.13947.6.camel@aglarond.local>
Message-ID: <4937260B.5040309@conversis.de>

On 12/03/2008 10:18 PM, Jeremy Katz wrote:
> On Wed, 2008-12-03 at 15:37 -0500, Darryl L. Pierce wrote:
>> On Wed, Dec 03, 2008 at 11:29:13AM -0900, Jeff Spaleta wrote:
>>> 2008/12/3 Jesse Keating<jkeating at redhat.com>:
>>>> This seems to be the interesting part.  This... shouldn't happen.
>>> Is his /etc/event.d/rc5 script not firing?
>> Services such as network and httpd had "off" as their runlevel 5
>> setting.
>
> Yes, they're off by default.  If you just ran 'chkconfig httpd on' when
> you were in runlevel 3, then it only affects runlevel 3.  You have to
> explicitly tell chkconfig if you want it to affect other runlevels.
> This is the way chkconfig has always worked.

That's doesn't seem to be right. I've got httpd set to 'on' for runlevels 
2,3,4 and 5. Doing a "chkconfig httpd off" sets *all* runlevels to 'off' 
and then doing a "chkconfig httpd on" sets runlevels 2,3,4 and 5 back to 
on. It behaves like that both on my Desktop running in runlevel 5 (F10) and 
on a server running level 3 (Centos5).

I always believed the 'chkconfig X on' without specifying the runlevels 
would turn on the default runlevel specified in the init script because 
that's the way it seems to behave.

Regards,
   Dennis



From jkeating at redhat.com  Thu Dec  4 00:37:16 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 03 Dec 2008 16:37:16 -0800
Subject: Runlevels after F10 install
In-Reply-To: <4937260B.5040309@conversis.de>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<604aa7910812031229y445fd1a8ud4e32947a974b699@mail.gmail.com>
	<20081203203743.GF4960@mcpierce-laptop.mcpierce.org>
	<1228339086.13947.6.camel@aglarond.local>
	<4937260B.5040309@conversis.de>
Message-ID: <1228351036.31305.52.camel@localhost.localdomain>

On Thu, 2008-12-04 at 01:36 +0100, Dennis J. wrote:
> That's doesn't seem to be right. I've got httpd set to 'on' for runlevels 
> 2,3,4 and 5. Doing a "chkconfig httpd off" sets *all* runlevels to 'off' 
> and then doing a "chkconfig httpd on" sets runlevels 2,3,4 and 5 back to 
> on. It behaves like that both on my Desktop running in runlevel 5 (F10) and 
> on a server running level 3 (Centos5).
> 
> I always believed the 'chkconfig X on' without specifying the runlevels 
> would turn on the default runlevel specified in the init script because 
> that's the way it seems to behave.

Perhaps it's system-config-services-tui which is ran via the text
firstboot which only changes things for the current runlevel.  There is
definitely some disconnect here.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/83aef094/attachment.sig>

From bpepple at fedoraproject.org  Thu Dec  4 00:40:22 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 03 Dec 2008 19:40:22 -0500
Subject: FESCo Meeting Summary for 2008-12-03
Message-ID: <1228351222.3352.6.camel@localhost.localdomain>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Jon Stanley           (jds2001)
* Karsten Hopp          (kick_)
* Kevin Fenzi           (nirik)
* Josh Boyer            (jwb)
* Bill Nottingham       (notting)

=== Members Absent ===
* David Woodhouse       (dwmw2)
* Dennis Gilmore        (dgilmore)

== Summary ==
=== Final Fedora 11 Schedule ===
      * FESCo approved the final version of the F11 schedule proposed by
        rel-eng.  Some important dates:
              * February 25th - Features not testable and nearly
                complete may be pushed to F12
              * April 8th - Features need to be 100% complete, and FESCo
                to make final decisions on whether to keep or defer
                features.
      * https://fedoraproject.org/wiki/Releases/11/Schedule

=== Python 2.6 ===
      * FESCo approved Ignacio Vazquez-Abrams's (ivazquez) request to
        merge the python-2.6 packages built with the dist-f11-python tag
        with Rawhide on Thursday (11/04/08).

=== Misc ===
      * jwb will contact the various Secondary Arches SIGS, and ask for
        monthly status reports.
      * nirik will contact Richard Jones, and see if he could provide
        simple instructions how to fix the OCaml packages, and FESCo
        will recruit some folks to help fix the broken deps.
      * Christoper Stone (XulChris) had a licensing question about one
        of his packages.  FESCo suggested that he contact spot &
        fedora-legal to get a definitive answer.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-12-03.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/782096c0/attachment.sig>

From vonbrand at inf.utfsm.cl  Thu Dec  4 00:46:27 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 03 Dec 2008 21:46:27 -0300
Subject: Runlevels after F10 install
In-Reply-To: <1228345019.31305.50.camel@localhost.localdomain>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
	<1228341760.31305.34.camel@localhost.localdomain>
	<20081203223928.GA16131@mcpierce-laptop.mcpierce.org>
	<20081203224230.GB16131@mcpierce-laptop.mcpierce.org>
	<1228345019.31305.50.camel@localhost.localdomain>
Message-ID: <200812040046.mB40kRTn008312@laptop14.inf.utfsm.cl>

Jesse Keating <jkeating at redhat.com> wrote:
> On Wed, 2008-12-03 at 17:42 -0500, Darryl L. Pierce wrote:
> > 
> > ...that would explay why it was set for runlevel 3. Shouldn't it
> > have also set them for runlevel 5?
> 
> No.  chkconfig service on will only set it for the current runlevel,
> although the man page doesn't make this obvious.

Funny... for instance, /etc/init.d/sendmail contains:

  # chkconfig: 2345 80 30

and AFAIK this has always meant "run in levels 2345, start at 80, shut down
at 20" and I distinctly remember chkconfig on/off creating/axing the
symlinks accordingly.
-- 
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  Thu Dec  4 00:47:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 03 Dec 2008 16:47:33 -0800
Subject: Runlevels after F10 install
In-Reply-To: <200812040046.mB40kRTn008312@laptop14.inf.utfsm.cl>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
	<1228341760.31305.34.camel@localhost.localdomain>
	<20081203223928.GA16131@mcpierce-laptop.mcpierce.org>
	<20081203224230.GB16131@mcpierce-laptop.mcpierce.org>
	<1228345019.31305.50.camel@localhost.localdomain>
	<200812040046.mB40kRTn008312@laptop14.inf.utfsm.cl>
Message-ID: <1228351653.31305.54.camel@localhost.localdomain>

On Wed, 2008-12-03 at 21:46 -0300, Horst H. von Brand wrote:
> > No.  chkconfig service on will only set it for the current runlevel,
> > although the man page doesn't make this obvious.
> 
> Funny... for instance, /etc/init.d/sendmail contains:
> 
>   # chkconfig: 2345 80 30
> 
> and AFAIK this has always meant "run in levels 2345, start at 80, shut down
> at 20" and I distinctly remember chkconfig on/off creating/axing the
> symlinks accordingly.

Yeah, I think this is why the man page didn't show it.  I was going by
Jeremy's info that chkconfig did that, without verifying myself.
Whoops.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081203/585f480b/attachment.sig>

From roland at redhat.com  Wed Dec  3 23:00:49 2008
From: roland at redhat.com (Roland McGrath)
Date: Wed,  3 Dec 2008 15:00:49 -0800 (PST)
Subject: Runlevels after F10 install
In-Reply-To: Jesse Keating's message of  Wednesday,
	3 December 2008 14:56:59 -0800
	<1228345019.31305.50.camel@localhost.localdomain>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
	<1228341760.31305.34.camel@localhost.localdomain>
	<20081203223928.GA16131@mcpierce-laptop.mcpierce.org>
	<20081203224230.GB16131@mcpierce-laptop.mcpierce.org>
	<1228345019.31305.50.camel@localhost.localdomain>
Message-ID: <20081204005203.5417DFC3C5@magilla.sf.frob.com>

> No.  chkconfig service on will only set it for the current runlevel,
> although the man page doesn't make this obvious.

In fact, it's thoroughly non-obvious, counter-intuitive and makes one
wonder what chkconfig is supposed to be good for.



From mw_triad at users.sourceforge.net  Thu Dec  4 02:45:33 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 03 Dec 2008 20:45:33 -0600
Subject: Status of libtool 2.2.X?
In-Reply-To: <1228300274.20451.1893.camel@beck.corsepiu.local>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<1228296680.20451.1794.camel@beck.corsepiu.local>	<gh5ls0$edm$1@ger.gmane.org>
	<200812031124.11838.opensource@till.name>
	<1228300274.20451.1893.camel@beck.corsepiu.local>
Message-ID: <gh7g8d$uk1$1@ger.gmane.org>

Ralf Corsepius wrote:
> As a developer, maintainer and/or packager you normally want to see what
> the tools are doing, e.g. if the compiler has received the correct
> flags, is using the correct libraries etc.

Sure, but I care about that once in a great while. The rest of the time, 
I really have no objection to the terse output cmake generates by 
default. (Remember you *can* get the full output, either by 'make 
VERBOSE=1' or you can ask cmake to just generate verbose makefiles.)

Of course, I like my percentage progress (a LOT, in big projects) also. 
Maybe because I actually watch what my builds are doing as opposed to 
*only* inspecting the log when it finishes. Plus, I challenge you to 
argue that it isn't friendlier for casual end-users :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Adriaan has bin AWOL"
"s/bin/been/g... I spend way too much time with computers."
   -- Stefan Teleman (on IRC)



From mw_triad at users.sourceforge.net  Thu Dec  4 02:50:02 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 03 Dec 2008 20:50:02 -0600
Subject: Status of libtool 2.2.X?
In-Reply-To: <1228296680.20451.1794.camel@beck.corsepiu.local>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<1228190889.5593.2817.camel@beck.corsepiu.local>	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
Message-ID: <gh7ggq$uk1$2@ger.gmane.org>

Ralf Corsepius wrote:
> On Wed, 2008-12-03 at 10:22 +0100, Kevin Kofler wrote:
>> Ralf Corsepius wrote:
>>
>>> On Mon, 2008-12-01 at 22:28 -0500, Jens Petersen wrote:
>>>
>>>> I would add:
>>>>
>>>> * do not start new projects using autotools as far as possible
>>> I would recommend you to stop spreading FUD.
>> What FUD? 
>>
>> There's an alternative which is:
>> * easier to learn,
>> * more portable,
>> * more backwards-compatible (with its own previous versions),
>> * faster,
>> * generating nicer makefiles (progress percentages, color output),
>> * designed in a better way (information is kept in central places instead of
>> being copied into hundreds of projects),
>> * used by more and more software, including big projects like KDE 4.
>>
>> It's called CMake.
> See, all FUD, you simply are spraying hatred against something you don't
> understand or don't want to understand.
> 
> To me, cmake is
> * not easier to learn, just different
> * non-portable/inflexible.
> * overladden with non-helpful gimmicks like progress percentages and
> color output
> * a crack ridden design (using a central database), reinvention of
> imake, comprising it's design flaws.

I'm not going to contribute to the flamewar by commenting on any of the 
above (not in this thread anyway ;-) ), but...

> * a kde proprietary tool.

...this last point (yes, even taking into account your "not useful 
outside of KDE" revision) is just plain wrong and reads like complete 
and utter ignorance of what CMake is. Yes, KDE4 uses it, but saying it 
is "kde proprietary" is just ludicrous.

Personally, I use CMake these days for pretty much every one-off project 
I do (and I'd promote it as the build tool of choice for any new 
project). Why? Because it's dead simple to write a trivial 
CMakeLists.txt that Just Works for basic stuff. For crying out loud, 
"hello, world" is one line! And the dependency graphs don't rely on 
gcc/m4/whatever. I use it for Qt-only apps. I use it for small C/C++ 
projects and I'm working on a port of a large project incorporating C, 
C++ and Java (that needs to build on Windows also, plus a few even more 
esoteric and not-very-UNIX-like platforms).

CMake was not developed by KDE, nor for KDE. KDE is (one of) the most 
visibly FLOSS users of CMake, and *that's all*. It's /very/ useful as a 
general build tool.

Oh, and, autotools is of marginal usefulness outside of GNU. (Maybe 
that's not true /now/, but I'm quite confident it was when autotools was 
young.)

Ok, so I'll throw in my $0.02 anyway...

Autotools needs a POSIX shell... and for development, better have GNU 
gcc, make, sed, awk, m4, bison, probably others... for ANY project of 
non-trivial complexity (maybe even for trivial complexity, since I've 
never tried to develop an auto* project on a non-Linux platform).

Development with CMake needs... CMake. Plus any dependencies specific to 
the project (which is the project's fault, not CMake's, and not a 
problem autotools would solve). CMake also has the huge advantage that, 
if you can /build/ a project, you can also hack on it without additional 
dependencies, which is absolutely not the case with autotools. 
Similarly, there is no extra step you have to add to go from merely 
building to active hacking.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Adriaan has bin AWOL"
"s/bin/been/g... I spend way too much time with computers."
   -- Stefan Teleman (on IRC)



From ghosler at redhat.com  Thu Dec  4 03:00:56 2008
From: ghosler at redhat.com (Gregory Hosler)
Date: Thu, 04 Dec 2008 11:00:56 +0800
Subject: Runlevels after F10 install
In-Reply-To: <20081204005203.5417DFC3C5@magilla.sf.frob.com>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>	<1228341760.31305.34.camel@localhost.localdomain>	<20081203223928.GA16131@mcpierce-laptop.mcpierce.org>	<20081203224230.GB16131@mcpierce-laptop.mcpierce.org>	<1228345019.31305.50.camel@localhost.localdomain>
	<20081204005203.5417DFC3C5@magilla.sf.frob.com>
Message-ID: <493747E8.7090008@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:
>> No.  chkconfig service on will only set it for the current runlevel,

no, this is not true...

	chkconfig cups off

Will result in

	[root at localhost ~]# chkconfig cups off
	[root at localhost ~]# chkconfig cups --list
	cups            0:off   1:off   2:off   3:off   4:off   5:off   6:off

Enabling the service via

	chkconfig cups on

results in:

	[root at localhost ~]# chkconfig cups --list
	cups            0:off   1:off   2:off   3:off   4:off   5:off   6:off
	[root at localhost ~]# chkconfig cups on
	[root at localhost ~]# chkconfig cups --list
	cups            0:off   1:off   2:on    3:on    4:on    5:on    6:off

In other word, if you do NOT specify the run levels to change, chkconfig will,
by default, "on" or "off" runlevels 2,3,4,5

>> although the man page doesn't make this obvious.
>

And in fact, this behaviour *IS* stated in the man page:

	By default, the on and off options affect only runlevels 2,  3,  4,  and
	5,  while reset  and resetpriorities affects all of the runlevels.  The
	--level option may be used to specify which runlevels are affected.

> In fact, it's thoroughly non-obvious, counter-intuitive and makes one
> wonder what chkconfig is supposed to be good for.

Seems pretty clear to me... Perhaps you haven't read the man page?

All the best,

- -Greg

- --
+---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information.
                (from /var/log/Xorg.setup.log)

| Greg Hosler                                   ghosler at redhat.com    |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk3R+YACgkQ404fl/0CV/Rt6QCgpvL7ObTAUA1kodZSAZkG5oay
XjoAniHsGz6X1wOj04vDNFFNKZ62z+iJ
=wE+u
-----END PGP SIGNATURE-----



From kevin.kofler at chello.at  Thu Dec  4 05:13:18 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 04 Dec 2008 06:13:18 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812031124.11838.opensource@till.name>
	<gh6fbj$d2a$1@ger.gmane.org>
	<200812032120.39907.opensource@till.name>
Message-ID: <gh7ote$gb7$1@ger.gmane.org>

Till Maas wrote:
> The problem is, that the non verbose build mode hides, whether or not the
> RPM_OPT_FLAGS are honoured, but it is required to honour them. Maybe cmake
> needs a way to tell it to only show the compiler invocations, but not the
> remaining stuff, that is shown with VERBOSE=1 and not useful.

RPM_OPT_FLAGS are always honored when you use the %cmake or %cmake_kde4
macros, unless the CMakeLists.txt does something really strange to CFLAGS.

And really, checking that the RPM_OPT_FLAGS are used is something that
should be done once during review and then it should just be the case.

        Kevin Kofler



From jonstanley at gmail.com  Thu Dec  4 05:49:06 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 4 Dec 2008 00:49:06 -0500
Subject: Fedora 11 Feature Process reminders
Message-ID: <da159fda0812032149r1ea8d92fx1a73b957022c4f8@mail.gmail.com>

At today's FESCo meeting, the final schedule for Fedora 11 was
approved.  Now  it's time for some reminders about the feature process
for Fedora 11.  We're changing a few things this time around to
hopefully make the whole process run smoother than ever!

First., FESCo will be making decisions regarding dropping incomplete
features at the meeting *2 weeks before* the freeze date, in order to
give rel-eng and QA time to implement whatever contingency plans might
be required prior to the freeze.  For Fedora 11, these dates are:

Alpha freeze: 1/20 - FESCo meeting - 1/8
Beta Freeze:  3/10 - FESCo meeting - 2/25
Final Freeze: 4/14 - FESCo meeting - 4/1

Also, note that feature freeze is on 3/3, a week prior to the Beta
freeze.  This was done in order to provide more time for testing
between feature freeze and beta freeze, and fix any issues that come
up without having to break the beta freeze.

By the time of the Alpha freeze, features must have a defined
specification (i.e. the scope section of the template must be
complete).  This should include criteria of what is required in order
to declare the feature a "success", for example, you're able to adjust
the volume in a variety of ways (name those ways) and that they have
the desired effect for the VolumeControl feature currently scheduled
for F11.

By the time of the beta freeze, features must have a complete test
plan, and be in a testable state.  A test plan is NOT simply "use it
and see if it works". Steps that can be reproduced by someone that has
little  to no knowledge of your feature area, but a basic
understanding of Fedora and the command line, etc. is what's required
here.  Taking the VolumeControl feature, there should be instructions
that tell me what packages need to be installed, what they're expected
to do under various circumstances, and how to make them do those
things.

By final freeze, obviously the feature must be fully implemented and
ready to go out the door.

Also, as feature owners have features that are nearing completion, I
would encourage them to contact either myself or James Laska in order
to schedule a "test day" for that feature.  In the past, these have
been incredibly successful in getting test coverage and exposure for
features that may not otherwise get it.  The earlier in the process
that this can happen, the better.

I will be handling the QA items that are new to this release, John
Poelstra will continue in his role as the overall Feature Wrangler.

All of  this is designed to ensure a high-quality release, and
minimize any schedule slips.

Thanks!
-Jon

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From rc040203 at freenet.de  Thu Dec  4 07:28:58 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 04 Dec 2008 08:28:58 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh7g8d$uk1$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org> <200812031124.11838.opensource@till.name>
	<1228300274.20451.1893.camel@beck.corsepiu.local>
	<gh7g8d$uk1$1@ger.gmane.org>
Message-ID: <1228375738.20451.3604.camel@beck.corsepiu.local>

On Wed, 2008-12-03 at 20:45 -0600, Matthew Woehlke wrote:
> Ralf Corsepius wrote:
> > As a developer, maintainer and/or packager you normally want to see what
> > the tools are doing, e.g. if the compiler has received the correct
> > flags, is using the correct libraries etc.
> 
> Sure, but I care about that once in a great while.
Very likely because your use-cases are trivial.

> Of course, I like my percentage progress (a LOT, in big projects) also.
I am well aware that some people prefer watching progress bars, instead
of watching bugs ... the rationale for doing so has always escaped me.

> Maybe because I actually watch what my builds are doing as opposed to 
> *only* inspecting the log when it finishes. Plus, I challenge you to 
> argue that it isn't friendlier for casual end-users :-).
Please read what I previously wrote. 

I don't deny that cmake is easier to get into in trivial use-cases, but
cmake very soon loose its "initial" advantages when things become a
little less trivial.





From rakesh.pandit at gmail.com  Thu Dec  4 07:41:15 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Thu, 4 Dec 2008 13:11:15 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <20081117235723.1feca5d1@laposte.net>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<20081108234812.6b327e4f@laposte.net>
	<3170f42f0811170622q34247bd6u3dd410ff898c00d6@mail.gmail.com>
	<20081117235723.1feca5d1@laposte.net>
Message-ID: <b401d2530812032341o6c7c34fcwf20f3de92f045089@mail.gmail.com>

2008/11/18 Martin-Gomez Pablo <pablo.martin-gomez at laposte.net>:
> Le Mon, 17 Nov 2008 19:52:15 +0530,
> "Debarshi Ray" <debarshi.ray at gmail.com> a ?crit :
>
[..]
>> Rakesh (CC'ed) had expressed his wish to take up gtksourceviewmm, so
>> hopefully that will also be taken care of.
>>

FI, Vivek (bonii) will be handling this one.

-- 
rakesh



From fedora at camperquake.de  Thu Dec  4 07:47:26 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 4 Dec 2008 08:47:26 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh6fbj$d2a$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org>
	<200812031124.11838.opensource@till.name>
	<gh6fbj$d2a$1@ger.gmane.org>
Message-ID: <20081204084726.3e91d5b3@dhcp03.addix.net>

Hi.

On Wed, 03 Dec 2008 18:24:02 +0100, Kevin Kofler wrote:

> I'd rather we disable the verbose mode (which unfortunately got just
> enabled globally, but all the KDE packages were already using it
> anyway): that one spams the log with a lot more lines,

Who cares? If the build succeeded noone will read it, anyway, and log
files compress quite well.

If the build failed, however, I'd like as much information as possible
telling me what exactly was going on when it failed.

That includes all options to all commands being run, otherwise you
just go around guessing.



From sundaram at fedoraproject.org  Thu Dec  4 08:50:07 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 04 Dec 2008 14:20:07 +0530
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081204084726.3e91d5b3@dhcp03.addix.net>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<1228296680.20451.1794.camel@beck.corsepiu.local>	<gh5ls0$edm$1@ger.gmane.org>	<200812031124.11838.opensource@till.name>	<gh6fbj$d2a$1@ger.gmane.org>
	<20081204084726.3e91d5b3@dhcp03.addix.net>
Message-ID: <493799BF.6090409@fedoraproject.org>

Ralf Ertzinger wrote:
> Hi.
> 
> On Wed, 03 Dec 2008 18:24:02 +0100, Kevin Kofler wrote:
> 
>> I'd rather we disable the verbose mode (which unfortunately got just
>> enabled globally, but all the KDE packages were already using it
>> anyway): that one spams the log with a lot more lines,
> 
> Who cares? If the build succeeded noone will read it, anyway, and log
> files compress quite well.

Even, if the build succeeds, there is always good reasons to read the 
logs. A successful build doesn't always lead to working software. 
Sometimes there are subtle mistakes you can catch early on, by reading 
the build logs each time.

Rahul



From rjones at redhat.com  Thu Dec  4 09:53:32 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 4 Dec 2008 09:53:32 +0000
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081203121736.0c4586d9@ohm.scrye.com>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
Message-ID: <20081204095332.GA9535@thinkpad>

On Wed, Dec 03, 2008 at 12:17:36PM -0700, Kevin Fenzi wrote:
> On Fri, 28 Nov 2008 12:09:26 +0000
> rjones at redhat.com ("Richard W.M. Jones") wrote:
> 
> > 
> > Just to keep people updated, upstream OCaml made some small but
> > significant change to a library which turns out to break lots of
> > packages.  So this is going to take some time to get fixed.
> > 
> > Details here and in the follow-up messages.
> > 
> > http://caml.inria.fr/pub/ml-archives/caml-list/2008/11/4a13be017ce7f9b70941fe09fbcd9359.en.html
> 
> This subject came up at todays FESCo meeting. There continue to be a
> bunch of broken dependencies in rawhide on these packages. 
> 
> Is there anything we can do to assist you in getting things back in
> shape? I'd be happy to fix packages, but I don't know Ocaml, so it
> would need to be a clear fix. ;) 

Basically this week I've been out of the country and had no
opportunity to look at this.  But I know what needs to be fixed, so I
can have a look next week.

Rich.




From opensource at till.name  Thu Dec  4 10:06:39 2008
From: opensource at till.name (Till Maas)
Date: Thu, 04 Dec 2008 11:06:39 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh7ote$gb7$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812032120.39907.opensource@till.name> <gh7ote$gb7$1@ger.gmane.org>
Message-ID: <200812041106.50524.opensource@till.name>

On Thu December 4 2008, Kevin Kofler wrote:
> Till Maas wrote:
> > The problem is, that the non verbose build mode hides, whether or not the
> > RPM_OPT_FLAGS are honoured, but it is required to honour them. Maybe
> > cmake needs a way to tell it to only show the compiler invocations, but
> > not the remaining stuff, that is shown with VERBOSE=1 and not useful.
>
> RPM_OPT_FLAGS are always honored when you use the %cmake or %cmake_kde4
> macros, unless the CMakeLists.txt does something really strange to CFLAGS.
>
> And really, checking that the RPM_OPT_FLAGS are used is something that
> should be done once during review and then it should just be the case.

This would be the case in an ideal world, but I have already seen a project 
that modified their autotools stuff to overwrite the CFLAGS 
unless --enable-maintainermode is passed to %configure (notice the small 
difference to --enable-maintainer-mode). Therefore I expect everything 
strange to happen at upstream. And this will probably also happen with cmake, 
once it is adapted by more projects.

With the complete commandline, it is pretty easy to check every now and then, 
whether the RPM_OPT_FLAGS are honoured. But with cmake, there seems to be 
more lines in between the gcc, than e.g. with autotools, where they often 
align pretty nice in a build.log.

Also does %cmake also make sure that -O3 / -s is not passed to gcc? Also it 
seems imposible to see, whether cmake uses "install -s" to install binaries 
or not.

Can %make maybe modified in a way, that it is possible to use something 
like "rpmbuild --without cmake_verbose" or add something to ones .rpmmacros 
file to enable/disable this for local/mock rebuilds? Then you would have the 
flexibility to get only the color/percentage output for your 
local/interactive builds. Maybe koji can also (be patched to) pass this to 
e.g. scratch builds, so you can have it there, too.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/724d524d/attachment.sig>

From tim at niemueller.de  Thu Dec  4 09:34:40 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Thu, 04 Dec 2008 10:34:40 +0100
Subject: Fedora 10 and YUM
In-Reply-To: <alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
Message-ID: <4937A430.3040109@niemueller.de>

Seth Vidal schrieb:
> 
>> I have another Fedora 8 box connected to the same router, and there are
>> no DNS problems there.
>>                     C
> 
> Did these problems magically go away recently?

Not for me. I had a similar problem yesterday on a "svn up". Trying a
second time immediately afterwards worked. Has happened a few times
since F-10 upgrade.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From rjones at redhat.com  Thu Dec  4 10:35:46 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 4 Dec 2008 10:35:46 +0000
Subject: rawhide report: 20081128 changes
In-Reply-To: <935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
	<935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
Message-ID: <20081204103546.GA10549@thinkpad>

On Wed, Dec 03, 2008 at 03:58:47PM -0600, Jeffrey Ollie wrote:
> On Wed, Dec 3, 2008 at 3:52 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> > On Wed, Dec 03, 2008 at 01:27:08PM -0600, Jeffrey Ollie wrote:
> >>
> >>Maybe there should be a new tag in Koji for fixing up all of the Ocaml
> >>packages like was was done for Python 2.6 recently (dist-f11-python)
> >>or Perl 5.10 for F-10 (dist-f10-perl).  Is there an easy way to make
> >>packages tagged with dist-f11-ocaml yum installable so that testing
> >>the packages is easier?
> >
> > A separate tag isn't really going to help things, given that the updated
> > Ocaml is already in rawhide.
> 
> Unless ocaml in dist-f11 was reverted to a pre-broken state.

Does it really matter though?  This is Rawhide, at the start of a new
cycle, and we've done a major upgrade which was announced in all the
relevant places well before it started.  If people want stable OCaml
they can use Fedora 10.

Rich.



From dtimms at iinet.net.au  Thu Dec  4 10:52:59 2008
From: dtimms at iinet.net.au (David Timms)
Date: Thu, 04 Dec 2008 21:52:59 +1100
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <360f42acea018573951d974f75130677.squirrel@mail.jcomserv.net>
References: <1228091890.19905.5.camel@localhost.localdomain>	<200811301640.37888.konrad@tylerc.org>	<20081201101456.GA18568@thinkpad>	<ufa1vwrwrf3.fsf@epithumia.math.uh.edu>
	<360f42acea018573951d974f75130677.squirrel@mail.jcomserv.net>
Message-ID: <4937B68B.8050006@iinet.net.au>

Jon Ciesla wrote:
>>>>>>> "RWMJ" == Richard W M Jones <rjones at redhat.com> writes:
>> RWMJ> On Sun, Nov 30, 2008 at 04:40:37PM -0800, Conrad Meyer wrote:
>>>> Any count of the number of outstanding reviews?
>> RWMJ> This page shows all bugs in the 'Package Review' component (8104
>> RWMJ> in total),
>> Why not just look at http://fedoraproject.org/PackageReviewStatus/ ?
Would be good to have a breakdown without the "Merge Review"s, perhaps 
it wouldn't look so bad then ;-)

What is the plan with Merge Reviews anyway ? Is there a long term goal ?
Can they only be done by certain people (I noticed that at least they 
are not suggested for beginner Packagers wanting to get sponsored) ?

DaveT



From dominik at greysector.net  Thu Dec  4 12:08:30 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 4 Dec 2008 13:08:30 +0100
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <1228091890.19905.5.camel@localhost.localdomain>
References: <1228091890.19905.5.camel@localhost.localdomain>
Message-ID: <20081204120830.GA2890@mokona.greysector.net>

On Monday, 01 December 2008 at 01:38, Brian Pepple wrote:
[...]

Subject: Re: Package Review Stats for the week ending November 23, 2007
                                                                   ^^^^
Shouldn't this be 2008?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jwboyer at gmail.com  Thu Dec  4 12:27:12 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 4 Dec 2008 07:27:12 -0500
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081204103546.GA10549@thinkpad>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
	<935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
	<20081204103546.GA10549@thinkpad>
Message-ID: <20081204122712.GA2339@yoda.jdub.homelinux.org>

On Thu, Dec 04, 2008 at 10:35:46AM +0000, Richard W.M. Jones wrote:
>On Wed, Dec 03, 2008 at 03:58:47PM -0600, Jeffrey Ollie wrote:
>> On Wed, Dec 3, 2008 at 3:52 PM, Josh Boyer <jwboyer at gmail.com> wrote:
>> > On Wed, Dec 03, 2008 at 01:27:08PM -0600, Jeffrey Ollie wrote:
>> >>
>> >>Maybe there should be a new tag in Koji for fixing up all of the Ocaml
>> >>packages like was was done for Python 2.6 recently (dist-f11-python)
>> >>or Perl 5.10 for F-10 (dist-f10-perl).  Is there an easy way to make
>> >>packages tagged with dist-f11-ocaml yum installable so that testing
>> >>the packages is easier?
>> >
>> > A separate tag isn't really going to help things, given that the updated
>> > Ocaml is already in rawhide.
>> 
>> Unless ocaml in dist-f11 was reverted to a pre-broken state.
>
>Does it really matter though?  This is Rawhide, at the start of a new
>cycle, and we've done a major upgrade which was announced in all the
>relevant places well before it started.  If people want stable OCaml
>they can use Fedora 10.

It's more about not flooding the rawhide reports with a sea of OCaml
broken dep emails.  That decreases readability for others looking for
things they can fix.  (Aside from the primary concern of just wanting
to get OCaml fixed too.)

In the future, a dist-f11-ocaml (or similar) tag would be great for
things like this.  You can introduce the new OCaml there fixup the
majority of packages, and then bring it into rawhide.  This was done
in part for python 2.6.

josh



From rjones at redhat.com  Thu Dec  4 12:34:54 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 4 Dec 2008 12:34:54 +0000
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081204122712.GA2339@yoda.jdub.homelinux.org>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
	<935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
	<20081204103546.GA10549@thinkpad>
	<20081204122712.GA2339@yoda.jdub.homelinux.org>
Message-ID: <20081204123454.GA10672@thinkpad>

On Thu, Dec 04, 2008 at 07:27:12AM -0500, Josh Boyer wrote:
> It's more about not flooding the rawhide reports with a sea of OCaml
> broken dep emails.  That decreases readability for others looking for
> things they can fix.  (Aside from the primary concern of just wanting
> to get OCaml fixed too.)

Isn't it redundant for the rawhide report to show more than one broken
package dependency anyway?  Certainly if the deps that are broken come
from the same package ...

Anyway, I'm rebuilding some now.

Rich.



From valent.turkovic at gmail.com  Thu Dec  4 12:38:07 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 4 Dec 2008 13:38:07 +0100
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <9008cd5d0812010600g33d35d1cn6e9f2f7c3a32b888@mail.gmail.com>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
	<4931518D.8090706@leemhuis.info>
	<64b14b300811290642h730cdbf1kac8170b443acc99@mail.gmail.com>
	<4931566B.8040006@leemhuis.info> <4931660C.6080802@sbcglobal.net>
	<64b14b300811290823k43f49fefkcef46c1526285553@mail.gmail.com>
	<64b14b300812010540t44578261jd8146b26612ac273@mail.gmail.com>
	<9008cd5d0812010600g33d35d1cn6e9f2f7c3a32b888@mail.gmail.com>
Message-ID: <64b14b300812040438x23cb735flcef40869e85eb418@mail.gmail.com>

On Mon, Dec 1, 2008 at 3:00 PM, Andras Simon <szajmi at gmail.com> wrote:
> On 12/1/08, Valent Turkovic <valent.turkovic at gmail.com> wrote:
>
>> After updates I tested wireless againg with ath5k module and now it
>> works perfectly. Really, really strange...
>
> Does it also work after suspend/resume?
>
> Andras

No it doesn't. Have you posted a bug report? If you have please share
the link with me so I can also provide feedback to it if needed.

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 dpierce at redhat.com  Thu Dec  4 12:57:16 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Thu, 4 Dec 2008 07:57:16 -0500
Subject: Runlevels after F10 install
In-Reply-To: <1228345019.31305.50.camel@localhost.localdomain>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
	<1228341760.31305.34.camel@localhost.localdomain>
	<20081203223928.GA16131@mcpierce-laptop.mcpierce.org>
	<20081203224230.GB16131@mcpierce-laptop.mcpierce.org>
	<1228345019.31305.50.camel@localhost.localdomain>
Message-ID: <20081204125716.GB4803@mcpierce-laptop.rdu.redhat.com>

On Wed, Dec 03, 2008 at 02:56:59PM -0800, Jesse Keating wrote:
> No.  chkconfig service on will only set it for the current runlevel,
> although the man page doesn't make this obvious.

http://pastebin.com/m2b2a6027

Other runlevels are affected even though I didn't specify any.

-- 
Darryl L. Pierce, Sr. Software Engineer
Red Hat, Inc. - http://www.redhat.com/
oVirt - Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/ad2b5ec2/attachment.sig>

From rawhide at fedoraproject.org  Thu Dec  4 13:10:28 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu,  4 Dec 2008 13:10:28 +0000 (UTC)
Subject: rawhide report: 20081204 changes
Message-ID: <20081204131029.2206D1F825E@releng2.fedora.phx.redhat.com>

Compose started at Thu Dec  4 06:01:04 UTC 2008

New package deco
        Extractor for various archive file formats
New package deco-archive
        Extraction scripts for various archive formats for use of deco
New package eclipse-eclemma
        Java code coverage tool plugin for Eclipse
New package grib_api
        ECMWF encoding/decoding GRIB software
New package partimage
        Partition imaging utility, much like Ghost
New package perl-Satcon
        Framework for configuration files
New package xfburn
        Simple CD burning tool for Xfce
Removed package evolution-webcal
Removed package kde-plasma-lancelot
Updated Packages:

CCfits-2.1-1.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> 2.1-1
- New upstream source
- Rebuilt needed to fix bz #474087


TnL-071111-8.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 071111-8
- Rebuild for new cegui


at-3.1.10-27.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 3.1.10-27
- 464393 add script into pm-utils, because daemon wasn't taking all jobs 
	after suspend/hibernate


avant-window-navigator-0.2.6-12.fc11
------------------------------------
* Thu Dec  4 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 0.2.6-12
- Add patch to fix metacity sticky bug, #469032

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.6-11
- Rebuild for Python 2.6


bind-9.6.0-0.5.rc1.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.5.rc1
- 9.6.0rc1 release
- patches merged
  - bind-9.2.0rc3-varrun.patch
  - bind-95-sdlz-include.patch
  - bind-96-libxml2.patch
- fixed rare use-after-free problem in host utility (#452060)
- enabled chase of DNSSEC signature chains in dig

* Mon Dec  1 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.4.1.b1
- improved sample config file (#473586)


bug-buddy-2.25.2-2.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.2-2
- Update to 2.25.2

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.1-2
- Tweak %summary and %description


cegui-0.6.2-1.fc11
------------------
* Wed Dec  3 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.6.2-1
- New upstream release 0.6.2


cheese-2.25.2-1.fc11
--------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 2.25.2-1
- Update to 2.25.2

* Fri Nov 21 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 2.25.1-4
- Better URL


chess-1.0-22.fc11
-----------------

comix-4.0.0-1.fc11
------------------
* Thu Dec  4 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 4.0.0-1
- 4.0.0

* Mon Dec  1 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 4.0-0.2.rc1
- 4.0.0 rc1
- Update ja.po

* Fri Oct  3 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 4.0-0.1.svn199_trunk
- 4.0 branch, rev 199


compizconfig-backend-gconf-0.7.8-1.fc11
---------------------------------------
* Thu Dec  4 17:00:00 2008 Mohd Izhar Firdaus Ismail <mohd.izhar.firdaus at gmail.com> 0.7.8-1
- update to 0.7.8


compizconfig-backend-kconfig-0.7.8-1.fc11
-----------------------------------------
* Thu Dec  4 17:00:00 2008 Mohd Izhar Firdaus Ismail <mohd.izhar.firdaus at gmail.com> 0.7.8-1
- update to 0.7.8


compizconfig-python-0.7.8-1.fc11
--------------------------------
* Mon Dec  1 17:00:00 2008 Mohd Izhar Firdaus Ismail <mohd.izhar.firdaus at gmail.com> 0.7.8-1
- update to 0.7.8

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.6-2
- Rebuild for Python 2.6


coreutils-7.0-5.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 7.0-5
- fix info documentation for expr command as well(#474434)

* Thu Dec  4 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 7.0-4
- fixed syntax error w/ "expr" command using negative
  string/integer as first (i.e expr -125) - due to
  complexity of changes used diff against upstream git-head
  (#474434)
- enable total-awk test again (and skip it when df not working)


crystalspace-1.2.1-3.fc11
-------------------------
* Wed Dec  3 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.2.1-3
- Rebuild for new cegui

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.1-2
- Rebuild for Python 2.6


cstream-2.7.5-1.fc11
--------------------

ctrlproxy-3.0.7-3.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Bernie Innocenti <bernie at codewiz.org> 3.0.7-3
- Patch for upstream bug http://bugs.bitlbee.org/ctrlproxy/ticket/202

* Tue Sep  2 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 3.0.7-2
- Include /usr/include/ctrlproxy-3.0 directory


duel3-0.1-0.6.20060225.fc11
---------------------------
* Wed Dec  3 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.1-0.6.20060225
- Fix a buffer overflow crash (bz 473374)


eel2-2.25.1-2.fc11
------------------
* Wed Dec  3 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.25.1-2
- Rebuild for pkg-config provides


elfinfo-1.1-4.fc11
------------------
* Wed Dec  3 17:00:00 2008 Parag Nemade <panemade at gmail.com>- 1.1-4
- Add patches from "Michael Schwendt" to fix CFLAGS and Makefile

* Wed Dec  3 17:00:00 2008 Parag Nemade <panemade at gmail.com>- 1.1-3
- Remove CFLAGS as its faling to build

* Wed Dec  3 17:00:00 2008 Parag Nemade <panemade at gmail.com>- 1.1-2
- bump release

* Wed Dec  3 17:00:00 2008 Parag Nemade <panemade at gmail.com>- 1.1-1
- Update to upstream version 1.1


ember-0.5.4-5.fc11
------------------
* Wed Dec  3 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.4-5
- Removed program name from description
- Rebuild for new CEGUI


eog-2.25.2-1.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-5
- Better URL

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-4
- Tweak %summary and %description


evince-2.25.2-2.fc11
--------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.2-2
- Update to 2.25.2

* Fri Nov 21 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.1-5
- Better URL

* Fri Nov 21 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.1-4
- Tweak %summary and %description


fetchmail-6.3.9-1.fc11
----------------------
* Wed Dec  3 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 6.3.9-1
- Update to fetchmail-6.3.9


freeradius-2.1.1-8.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 John Dennis <jdennis at redhat.com> - 2.1.1-8
- add --with-system-libtool to configure as a workaround for
undefined reference to lt__PROGRAM__LTX_preloaded_symbols

* Mon Dec  1 17:00:00 2008 John Dennis <jdennis at redhat.com> - 2.1.1-7
- add readline-devel BuildRequires

* Mon Dec  1 17:00:00 2008 John Dennis <jdennis at redhat.com> - 2.1.1-7
- add obsoletes tag for dialupadmin subpackages which were removed

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.1-4
- Rebuild for Python 2.6


ganyremote-5.4.2-1.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.4.2-1
- Fix detection of activity of bluetooth service


gmp-4.2.4-2.fc11
----------------
* Wed Dec  3 17:00:00 2008 Stepan Kasal <skasal at redhat.com> 4.2.4-2
- Run full autoreconf, add automake to BuildRequires.


gnome-commander-1.2.8-0.1.svn2330_trunk.fc11
--------------------------------------------
* Thu Dec  4 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2330
- Add patch to compile with libtool 2.2


gnome-games-2.25.2-1.fc11
-------------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.2-1
- Update to 2.25.2

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:2.25.1-4
- Rebuild for Python 2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.1-3
- Better URL
- Tweak description


gnome-menus-2.25.2-2.fc11
-------------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.25.2-2
- Update to 2.25.2

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.24.1-2
- Rebuild for Python 2.6


gnome-themes-2.25.2-1.fc11
--------------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-3
- Improve description


gok-2.25.2-1.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2


gtk2-engines-2.17.1-1.fc11
--------------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.17.1-1
- Update to 2.17.1


hunspell-en-0.20081202-1.fc11
-----------------------------
* Tue Dec  2 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081202-1
- latest version


java-1.6.0-openjdk-1.6.0.0-7.b13.fc11
-------------------------------------
* Tue Dec  2 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-7.b13
- Updated pkgversion to include release and arch.
- Set runtests to 1.
- Updated icedteasnapshot.
- Resolves: rhbz#468484
- Resolves: rhbz#472862
- Resolves: rhbz#472234
- Resolves: rhbz#472233
- Resolves: rhbz#472231
- Resolves: rhbz#472228
- Resolves: rhbz#472224
- Resolves: rhbz#472218
- Resolves: rhbz#472213
- Resolves: rhbz#472212
- Resolves: rhbz#472211
- Resolves: rhbz#472209
- Resolves: rhbz#472208
- Resolves: rhbz#472206
- Resolves: rhbz#472201

* Tue Dec  2 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-7.b13
- Set runtests to 0.


javacc-4.1-0.2.fc11
-------------------
* Wed Dec  3 17:00:00 2008 Matt Wringe <mwringe at redhat.com> - 0:4.1-0.2
- Update to remove packaged jars in source tar
- Build with bootstrap jar so that required java source 
  files get generated

* Wed Oct 22 18:00:00 2008 Jerry James <loganjerry at gmail.com> - 0:4.1-0.1
- Update to 4.1
- Also ship the jjrun script
- Own the appropriate gcj directory
- Minor spec file changes to comply with latest Fedora guidelines
- Include the top-level index.html file in the manual


javasqlite-20081006-3.fc11
--------------------------
* Wed Dec  3 17:00:00 2008 Colin Walters <walters at verbum.org> - 20081006-3
- Add a link in /usr/share/java to correspond with other jars.
  Someday we'll have a real module system.


kanyremote-5.4.1-1.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.4.1-1
- Fix detection of activity of bluetooth service


kdeaccessibility-4.1.80-2.fc11
------------------------------
* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- remove duplicated BR on cmake, it's already done in kdelibs-devel

* Wed Nov 19 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 1:4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast


kdeadmin-4.1.80-2.fc11
----------------------
* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- get rid of duplicated BRs

* Wed Nov 19 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 7:4.1.80-1
- 4.1.80
- BR cmake 2.6
- BR python-devel
- make install/fast

* Tue Nov 11 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.3-1
- 4.1.3


koffice-1.9.98.2-3.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1:1.0.98.2-3
- Conflicts with oxygen-icon-theme-4.1.80 (#474268)

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:1.9.98.2-2
- Rebuild for Python 2.6


libIDL-0.8.12-1.fc11
--------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.8.12-1
- Update to 0.8.12


libXdamage-1.1.1-5.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1.1.1-5
- rebuild to get provides pkgconfig(xdamage)


libXi-1.2.0-1.fc11
------------------
* Wed Dec  3 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.2.0-1
- libXi 1.2.0


libXrender-0.9.4-4.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.9.4-4
- rebuild to get provides pkgconfig(xrender)


libbonobo-2.24.0-3.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 2.24.0-3
- rebuild to get new rpm provides of pkgconfig(libbonobo-2.0)


libchewing-0.3.2-0.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 0.3.2-0
- Upstream update to 0.3.2.


libgweather-2.25.2-2.fc11
-------------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.25.2-2
- Update to 2.25.2


libspectre-0.2.2-1.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.2.2-1
- Update to 0.2.2


libtool-2.2.6-2.fc11
--------------------
* Wed Dec  3 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 2.2.6-2
- add Requires: sed  (Ignacio Vazquez-Abrams)


libxml2-2.7.2-6.fc11
--------------------
* Wed Dec  3 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 2.7.2-6
- AutoProvides requires BuildRequires pkgconfig

* Wed Dec  3 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 2.7.2-5
- rebuild to get provides(libxml-2.0) into HEAD rawhide

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.7.2-4
- Rebuild for pkgconfig logic

* Fri Nov 28 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.7.2-3
- Rebuild for Python 2.6


linuxdoc-tools-0.9.56-1.fc11
----------------------------
* Wed Dec  3 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 0.9-56-1
- Used latest upstream version 0.9.56,
  removed already applied patches


monafont-2.90-5.fc11.1
----------------------
* Wed Dec  3 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rebuild for new VLGothic


muine-0.8.10-3.fc11
-------------------
* Wed Dec  3 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 0.8.10-3
- Add patch to fix gstreamer critical bug, see gnome bz #562901


ogre-1.6.0-2.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.6.0-2
- Rebuild for new cegui


orca-2.25.2-1.fc11
------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.25.1-3
- Rebuild for Python 2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-2
- Tweak description


pdns-2.9.22-1.rc2.fc11
----------------------
* Wed Dec  3 17:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.9.22-1.rc2
- Upstream releasd new release candidate
- Drop patches which are upstreamed


perl-Class-Accessor-Grouped-0.08002-1.fc11
------------------------------------------
* Tue Dec  2 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.08002-1
- update to 0.08002


plymouth-0.6.0-1.fc11
---------------------
* Wed Dec  3 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-1
- Update to 0.6.0

* Sat Nov 22 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0.6.0-0.2008.11.17.3.1
- Strip %name from %summary


pyodbc-2.1.1-1.fc11
-------------------
* Wed Dec  3 17:00:00 2008 Ray Van Dolson <rayvd at fedoraproject.org> - 2.1.1-1
- New upstream version and homepage


rhythmbox-0.11.6-16.6086.fc11
-----------------------------
* Tue Dec  2 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-16-r6086
- Update to rev 6086
- Add libmusicbrainz3 support


rpm-4.6.0-0.rc2.8
-----------------
* Wed Dec  3 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- make rpm-build require pkgconfig (#473978)

* Wed Dec  3 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 4.6.0-0.rc2.8
- python 2.6 rebuild again


selinux-policy-3.6.1-4.fc11
---------------------------
* Wed Dec  3 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-4
- Cleanup policy

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.6.1-2
- Rebuild for Python 2.6


sendmail-8.14.3-2.fc11
----------------------
* Wed Dec  3 17:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> 8.14.3-2
- add NM dispatcher script (#451575)
- print warning on service start when sendmail-cf is required (#447148)
- replace Makefile with shell script to avoid dependency on make (#467841)
- fix multiarch conflicts (#343161)
- preserve timestamps on config files
- gzip RELEASE_NOTES
- defuzz patches
- drop gcc2690 patch


star-1.5a89-1.fc11
------------------
* Wed Dec  3 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 1.5a89-1
- update to latest upstream release


tcltls-1.6-2.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Sander Hoentjen <sander at hoentjen.eu> - 1.6-2
- Add requires on tcl


tecnoballz-0.92-5.fc11
----------------------
* Wed Dec  3 17:00:00 2008 Andrea Musuruane <musuruan at gmail.com> 0.92-5
- fix unowned directory (BZ #473980)


tkdnd-1.0a2-12.fc11
-------------------
* Wed Dec  3 17:00:00 2008 Sander Hoentjen <sander at hoentjen.eu> - 1.0a2-12
- Add missing requires on libXft

* Wed Dec  3 17:00:00 2008 Sander Hoentjen <sander at hoentjen.eu> - 1.0a2-11
- Add requires on tcl


tomboy-0.13.1-4.fc11
--------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.13.1-4
- Update to 0.13.1

* Sat Nov 22 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.12.0-6
- Better URL
- Tweak %description


xorg-x11-drv-synaptics-0.99.1-2.fc11
------------------------------------
* Thu Dec  4 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 0.99.1-2
- 10-synaptics.fdi: if something has capabilities input.touchpad match it.
  Don't bother about product names.

* Mon Nov 24 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com>
- Fix up summary and description, provide list of supported models.


xorg-x11-proto-devel-7.4-8.fc11
-------------------------------
* Wed Dec  3 17:00:00 2008 Adam Jackson <ajax at redhat.com> 7.4-8
- inputproto 1.5.0


ypbind-1.20.4-11.fc11
---------------------
* Wed Dec  3 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 3:1.20.4-11
- Fix verbose option man page entry
- Add description of port option to man page
  Resolves: #474184


Summary:
Added Packages: 7
Removed Packages: 2
Modified Packages: 72
Broken deps for i386
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.i386 requires libltdl.so.3
	ettercap-gtk-0.7.3-26.fc10.i386 requires libltdl.so.3
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	foobillard-3.0a-8.fc10.i386 requires dejavu-fonts
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	gok-devel-2.25.2-1.fc11.i386 requires pkgconfig(cspi-1.0)
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-bitstring-2.0.0-5.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.i386 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.i386 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	poker-network-devel-1.6.0-3.fc11.i386 requires pkgconfig(poker-engine)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.i386 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	tomboy-0.13.1-4.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	ufraw-cinepaint-0.14.1-3.fc11.i386 requires cinepaint(x86-32)
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.x86_64 requires libltdl.so.3()(64bit)
	ettercap-gtk-0.7.3-26.fc10.x86_64 requires libltdl.so.3()(64bit)
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	foobillard-3.0a-8.fc10.x86_64 requires dejavu-fonts
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	gift-0.11.8.1-10.fc9.x86_64 requires libltdl.so.3()(64bit)
	gok-devel-2.25.2-1.fc11.i386 requires pkgconfig(cspi-1.0)
	gok-devel-2.25.2-1.fc11.x86_64 requires pkgconfig(cspi-1.0)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	muine-devel-0.8.10-3.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-bitstring-2.0.0-5.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlp5-5.10-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.x86_64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	poker-network-devel-1.6.0-3.fc11.i386 requires pkgconfig(poker-engine)
	poker-network-devel-1.6.0-3.fc11.x86_64 requires pkgconfig(poker-engine)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.x86_64 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	tomboy-0.13.1-4.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	ufraw-cinepaint-0.14.1-3.fc11.x86_64 requires cinepaint(x86-64)
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.ppc requires libltdl.so.3
	ettercap-gtk-0.7.3-26.fc10.ppc requires libltdl.so.3
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	firstaidkit-plugin-grub-0.2.2-4.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc requires dejavu-fonts
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.ppc requires libltdl.so.3
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gok-devel-2.25.2-1.fc11.ppc requires pkgconfig(cspi-1.0)
	gok-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(cspi-1.0)
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	muine-devel-0.8.10-3.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-bitstring-2.0.0-5.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	poker-network-devel-1.6.0-3.fc11.ppc requires pkgconfig(poker-engine)
	poker-network-devel-1.6.0-3.fc11.ppc64 requires pkgconfig(poker-engine)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.ppc requires python-pygame
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	tomboy-0.13.1-4.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	ufraw-cinepaint-0.14.1-3.fc11.ppc requires cinepaint(ppc-32)
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	appliance-tools-003.9-1.fc10.noarch requires qemu-img
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	ettercap-0.7.3-26.fc10.ppc64 requires libltdl.so.3()(64bit)
	ettercap-gtk-0.7.3-26.fc10.ppc64 requires libltdl.so.3()(64bit)
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	firstaidkit-plugin-grub-0.2.2-4.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc64 requires dejavu-fonts
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gok-devel-2.25.2-1.fc11.ppc64 requires pkgconfig(cspi-1.0)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Raw) = 0:69af96aa68a96126bd4effa1f62b2b3b
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-bitstring-2.0.0-5.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Graphics) = 0:628a353c50569abf64b91abe6edf1b24
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlp5-5.10-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-csv-1.1.7-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-gsl-0.6.0-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-lacaml-4.3.3-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Event) = 0:eed3f9e28d19dc881a67c9170fab2cba
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-lwt-1.1.0-2.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(MoreLabels) = 0:e32b0a5e5d53192fe9f7543989261ae8
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(StdLabels) = 0:afc5c70a95593ab1b2f875fcfe758714
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mysql-1.0.4-3.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-newt-0.9-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-openin-20070524-4.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-res-3.0.0-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0+beta1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-zip-1.03-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	olpc-utils-0.89-5.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	poker-network-devel-1.6.0-3.fc11.ppc64 requires pkgconfig(poker-engine)
	python-dbsprockets-0.5-0.2.dev.r411.fc11.noarch requires python-sqlalchemy >= 0:0.5
	python-rabbyt-0.8.2-4.fc9.ppc64 requires python-pygame
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	ufraw-cinepaint-0.14.1-3.fc11.ppc64 requires cinepaint(ppc-64)
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From skvidal at fedoraproject.org  Thu Dec  4 13:41:47 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 4 Dec 2008 08:41:47 -0500 (EST)
Subject: Fedora 10 and YUM
In-Reply-To: <4937A430.3040109@niemueller.de>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
Message-ID: <alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>



On Thu, 4 Dec 2008, Tim Niemueller wrote:

> Seth Vidal schrieb:
>>
>>> I have another Fedora 8 box connected to the same router, and there are
>>> no DNS problems there.
>>>                     C
>>
>> Did these problems magically go away recently?
>
> Not for me. I had a similar problem yesterday on a "svn up". Trying a
> second time immediately afterwards worked. Has happened a few times
> since F-10 upgrade.
>

What does 'svn up' have to do with yum?

-sv



From mark.bidewell at alumni.clemson.edu  Thu Dec  4 13:48:57 2008
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Thu, 4 Dec 2008 08:48:57 -0500
Subject: Fedora 10 and YUM
In-Reply-To: <alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
Message-ID: <bfdeacfa0812040548x546b1975w7992c0d19d1e9fc9@mail.gmail.com>

On Thu, Dec 4, 2008 at 8:41 AM, Seth Vidal <skvidal at fedoraproject.org>wrote:

>
>
> On Thu, 4 Dec 2008, Tim Niemueller wrote:
>
>  Seth Vidal schrieb:
>>
>>>
>>>  I have another Fedora 8 box connected to the same router, and there are
>>>> no DNS problems there.
>>>>                    C
>>>>
>>>
>>> Did these problems magically go away recently?
>>>
>>
>> Not for me. I had a similar problem yesterday on a "svn up". Trying a
>> second time immediately afterwards worked. Has happened a few times
>> since F-10 upgrade.
>>
>>
> What does 'svn up' have to do with yum?
>
> -sv
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

After using F10 for a longer time, I believe that the issue might be a more
general DNS issue than just YUM.  I have been getting more failed lookups
under F10 than under Windows or F9.

Mark Bidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/541144a2/attachment.htm>

From gary at mlbassoc.com  Thu Dec  4 13:54:46 2008
From: gary at mlbassoc.com (Gary Thomas)
Date: Thu, 04 Dec 2008 06:54:46 -0700
Subject: Fedora 10 and YUM
In-Reply-To: <bfdeacfa0812040548x546b1975w7992c0d19d1e9fc9@mail.gmail.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>	<20081128091450.01790757@ludwig-alpha.unil.ch>	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>	<4937A430.3040109@niemueller.de>	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
	<bfdeacfa0812040548x546b1975w7992c0d19d1e9fc9@mail.gmail.com>
Message-ID: <4937E126.9040106@mlbassoc.com>

Mark Bidewell wrote:
> 
> 
> On Thu, Dec 4, 2008 at 8:41 AM, Seth Vidal <skvidal at fedoraproject.org
> <mailto:skvidal at fedoraproject.org>> wrote:
> 
> 
> 
>     On Thu, 4 Dec 2008, Tim Niemueller wrote:
> 
>         Seth Vidal schrieb:
> 
> 
>                 I have another Fedora 8 box connected to the same
>                 router, and there are
>                 no DNS problems there.
>                                    C
> 
> 
>             Did these problems magically go away recently?
> 
> 
>         Not for me. I had a similar problem yesterday on a "svn up".
>         Trying a
>         second time immediately afterwards worked. Has happened a few times
>         since F-10 upgrade.
> 
> 
>     What does 'svn up' have to do with yum?
> 
>     -sv
> 
> 
>     -- 
>     fedora-devel-list mailing list
>     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
> After using F10 for a longer time, I believe that the issue might be a
> more general DNS issue than just YUM.  I have been getting more failed
> lookups under F10 than under Windows or F9.

I noticed this as well.  I just updated my WiFi-only laptop (full install)
to Fedora 10.  Doing something as simple as 'yum update' now fails with
tons of DNS lookup failures.  Very odd because I'm using a repository mirror
(baseurl) to a machine in the next room :-(  Retries give similar, but different,
failures.





-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



From tim at niemueller.de  Thu Dec  4 14:08:24 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Thu, 04 Dec 2008 15:08:24 +0100
Subject: Fedora 10 and YUM
In-Reply-To: <alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
Message-ID: <4937E458.3000106@niemueller.de>

Seth Vidal schrieb:
> 
> What does 'svn up' have to do with yum?

I think not yum is the problem but there is a more general problem
related to DNS lookups. As a specialty I'm using nss-mdns. But on
F-8/F-9 this has never been a problem, so I suspect this is not what is
causing the problem, especially because others have the same problem and
I don't think nss-mdns is installed on many machines.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From camilo at mesias.co.uk  Thu Dec  4 14:44:16 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Thu, 4 Dec 2008 14:44:16 +0000
Subject: Fedora 10 and YUM
In-Reply-To: <4937E126.9040106@mlbassoc.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
	<bfdeacfa0812040548x546b1975w7992c0d19d1e9fc9@mail.gmail.com>
	<4937E126.9040106@mlbassoc.com>
Message-ID: <d551e0e20812040644p555a3b0u2c55c24d619fbe1d@mail.gmail.com>

FYI many ISPs seem to have DNS problems from time to time. I have
taken to running tshark to watch what is going on:

tshark -i any -f 'port 53'

For many people the DNS server will be a proxy on the local router,
but it's perfectly valid to edit new entries into /etc/resolv.conf to
use external DNS servers (eg. OpenDNS). This can confirm that problems
relate to the 'default' DNS setup.

OT but I have a reasonably fast ADSL2+ connection that often suffers
slow DNS (multiple seconds for a lookup).

-Cam



From notting at redhat.com  Thu Dec  4 14:50:06 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 4 Dec 2008 09:50:06 -0500
Subject: Fedora 11 Feature Process reminders
In-Reply-To: <da159fda0812032149r1ea8d92fx1a73b957022c4f8@mail.gmail.com>
References: <da159fda0812032149r1ea8d92fx1a73b957022c4f8@mail.gmail.com>
Message-ID: <20081204145006.GA24907@nostromo.devel.redhat.com>

Jon Stanley (jonstanley at gmail.com) said: 
> At today's FESCo meeting, the final schedule for Fedora 11 was
> approved.  Now  it's time for some reminders about the feature process
> for Fedora 11.  We're changing a few things this time around to
> hopefully make the whole process run smoother than ever!
> 
> First., FESCo will be making decisions regarding dropping incomplete
> features at the meeting *2 weeks before* the freeze date, in order to
> give rel-eng and QA time to implement whatever contingency plans might
> be required prior to the freeze.  For Fedora 11, these dates are:
> 
> Alpha freeze: 1/20 - FESCo meeting - 1/8
> Beta Freeze:  3/10 - FESCo meeting - 2/25
> Final Freeze: 4/14 - FESCo meeting - 4/1

According to the meeting log, it's one week before the freeze date,
and these dates are 1/14, 2/25, and 4/8. (The beta one is one week
before feature freeze, which is one week before the actual beta freeze.)

Bill



From jonathan.underwood at gmail.com  Thu Dec  4 14:46:08 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 4 Dec 2008 14:46:08 +0000
Subject: Fedora 10 and YUM
In-Reply-To: <4937E458.3000106@niemueller.de>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
	<4937E458.3000106@niemueller.de>
Message-ID: <645d17210812040646h3f6514ddj281eaa2038e5bd0@mail.gmail.com>

2008/12/4 Tim Niemueller <tim at niemueller.de>:
> Seth Vidal schrieb:
>>
>> What does 'svn up' have to do with yum?
>
> I think not yum is the problem but there is a more general problem
> related to DNS lookups. As a specialty I'm using nss-mdns. But on
> F-8/F-9 this has never been a problem, so I suspect this is not what is
> causing the problem, especially because others have the same problem and
> I don't think nss-mdns is installed on many machines.

This could well all be due to this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=459756



From mark.bidewell at alumni.clemson.edu  Thu Dec  4 15:16:48 2008
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Thu, 4 Dec 2008 10:16:48 -0500
Subject: Fedora 10 and YUM
In-Reply-To: <645d17210812040646h3f6514ddj281eaa2038e5bd0@mail.gmail.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
	<4937E458.3000106@niemueller.de>
	<645d17210812040646h3f6514ddj281eaa2038e5bd0@mail.gmail.com>
Message-ID: <bfdeacfa0812040716m4d28e71bxe82c618cf8ea0cbf@mail.gmail.com>

On Thu, Dec 4, 2008 at 9:46 AM, Jonathan Underwood <
jonathan.underwood at gmail.com> wrote:

> 2008/12/4 Tim Niemueller <tim at niemueller.de>:
> > Seth Vidal schrieb:
> >>
> >> What does 'svn up' have to do with yum?
> >
> > I think not yum is the problem but there is a more general problem
> > related to DNS lookups. As a specialty I'm using nss-mdns. But on
> > F-8/F-9 this has never been a problem, so I suspect this is not what is
> > causing the problem, especially because others have the same problem and
> > I don't think nss-mdns is installed on many machines.
>
> This could well all be due to this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=459756
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Thanks.  that sounds likely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/bbaec67f/attachment.htm>

From geoff at programmer-monk.net  Thu Dec  4 15:28:11 2008
From: geoff at programmer-monk.net (Geoff Reedy)
Date: Thu, 4 Dec 2008 10:28:11 -0500
Subject: Fedora 10 and YUM
In-Reply-To: <bfdeacfa0812040548x546b1975w7992c0d19d1e9fc9@mail.gmail.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
	<bfdeacfa0812040548x546b1975w7992c0d19d1e9fc9@mail.gmail.com>
Message-ID: <20081204152811.GA11313@programmer-monk.net>

I'm seeing this as well, seems to be in BZ 459756 and 471450. It seems
as though at least some DNS servers get confused by the parallel AAAA
and A queries and only respond to one of them. The worst part is that
the nature of the problem will make it hard to update to a fixed
implementation. I think this particular issue is worth a mention in
Bugs/F10Common because it seems to be relatively wide spread (seems to
be impacting comcast users reliably).



From notting at redhat.com  Thu Dec  4 13:57:24 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 4 Dec 2008 08:57:24 -0500
Subject: Runlevels after F10 install
In-Reply-To: <4937260B.5040309@conversis.de>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<1228333394.31305.28.camel@localhost.localdomain>
	<604aa7910812031229y445fd1a8ud4e32947a974b699@mail.gmail.com>
	<20081203203743.GF4960@mcpierce-laptop.mcpierce.org>
	<1228339086.13947.6.camel@aglarond.local>
	<4937260B.5040309@conversis.de>
Message-ID: <20081204135724.GA23386@nostromo.devel.redhat.com>

Dennis J. (dennisml at conversis.de) said: 
> That's doesn't seem to be right. I've got httpd set to 'on' for runlevels 
> 2,3,4 and 5. Doing a "chkconfig httpd off" sets *all* runlevels to 'off'  
> and then doing a "chkconfig httpd on" sets runlevels 2,3,4 and 5 back to  
> on. It behaves like that both on my Desktop running in runlevel 5 (F10) 
> and on a server running level 3 (Centos5).
>
> I always believed the 'chkconfig X on' without specifying the runlevels  
> would turn on the default runlevel specified in the init script because  
> that's the way it seems to behave.

'on' and 'off' affect 2/3/4/5 if you don't specify a level otherwise. See
the man page.

Bill



From notting at redhat.com  Thu Dec  4 13:58:49 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 4 Dec 2008 08:58:49 -0500
Subject: Runlevels after F10 install
In-Reply-To: <200812040046.mB40kRTn008312@laptop14.inf.utfsm.cl>
References: <20081203193037.GA4960@mcpierce-laptop.mcpierce.org>
	<604aa7910812031227j3fcff55ax8fffb6eae658bae@mail.gmail.com>
	<20081203203856.GG4960@mcpierce-laptop.mcpierce.org>
	<1228341760.31305.34.camel@localhost.localdomain>
	<20081203223928.GA16131@mcpierce-laptop.mcpierce.org>
	<20081203224230.GB16131@mcpierce-laptop.mcpierce.org>
	<1228345019.31305.50.camel@localhost.localdomain>
	<200812040046.mB40kRTn008312@laptop14.inf.utfsm.cl>
Message-ID: <20081204135849.GB23386@nostromo.devel.redhat.com>

Horst H. von Brand (vonbrand at inf.utfsm.cl) said: 
> Funny... for instance, /etc/init.d/sendmail contains:
> 
>   # chkconfig: 2345 80 30
> 
> and AFAIK this has always meant "run in levels 2345, start at 80, shut down
> at 20" and I distinctly remember chkconfig on/off creating/axing the
> symlinks accordingly.

Default levels in the initscript are used by 'chkconfig --add', not
'chkconfig [--level XYZ] on/off'

Bill



From jonstanley at gmail.com  Thu Dec  4 15:52:52 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 4 Dec 2008 10:52:52 -0500
Subject: Fedora 11 Feature Process reminders
In-Reply-To: <20081204145006.GA24907@nostromo.devel.redhat.com>
References: <da159fda0812032149r1ea8d92fx1a73b957022c4f8@mail.gmail.com>
	<20081204145006.GA24907@nostromo.devel.redhat.com>
Message-ID: <da159fda0812040752t21bbf79cie1b806deb2519b97@mail.gmail.com>

On Thu, Dec 4, 2008 at 9:50 AM, Bill Nottingham <notting at redhat.com> wrote:

> According to the meeting log, it's one week before the freeze date,
> and these dates are 1/14, 2/25, and 4/8. (The beta one is one week
> before feature freeze, which is one week before the actual beta freeze.)

Sorry, amendment sent to f-d-a.  Thanks for the catch!



From fedora at camperquake.de  Thu Dec  4 15:54:53 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 4 Dec 2008 16:54:53 +0100
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <1228339831.14110.279.camel@atropine.boston.devel.redhat.com>
References: <4933F7AD.1040904@gmail.com>
	<dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>
	<49340456.7050802@gmail.com>
	<bf967e93f32794940b6560b82c859ae9.squirrel@arekh.dyndns.org>
	<loom.20081203T190300-549@post.gmane.org>
	<1228339831.14110.279.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081204165453.1000b24d@dhcp03.addix.net>

Hi.

On Wed, 03 Dec 2008 16:30:31 -0500, Adam Jackson wrote:

> We do have a heuristic to pick a plausible virtual size based on how
> much video memory you have.  It's not perfect, nor can it ever be.

'Have' as in 'we have a plan', or 'have' as in 'it's in the F10/rawhide
drivers already'?



From rayvd at bludgeon.org  Thu Dec  4 17:00:29 2008
From: rayvd at bludgeon.org (Ray Van Dolson)
Date: Thu, 4 Dec 2008 09:00:29 -0800
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
Message-ID: <20081204170029.GA5553@bludgeon.org>

On Wed, Dec 03, 2008 at 03:27:48PM -0600, Jon Ciesla wrote:
> 
> >> I suggest starting the NRM process:
> >> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
> >>
> >
> > It has already started. Bugs have been filed. Attempts to contact have
> > been made. It's been months with zero contact.
> >
> > I guess the next step is to ask: who can take up these packages?
> >
> I could take a crack at gallery2.

Are you able to maintain an EPEL version as well?  At least for EL-5.

Ray



From jonstanley at gmail.com  Thu Dec  4 15:49:02 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 4 Dec 2008 10:49:02 -0500
Subject: Updates to dates in the Fedora 11 Feature process
Message-ID: <da159fda0812040749n207e68benf4a320050c91c24@mail.gmail.com>

I inadvertently got the dates wrong in my previous e-mail, thanks Bill
Nottingham for pointing that out! It was late when I composed it, and
I have a "green" brain that goes into power-save mode after midnight
:).

Here are the real ones:

Alpja Freeze - 1/20 - FESCo meeting 1/14
Feature Freeze - 3/3 - FESCo meeting 2/25
Final Freeze - 4/14 - FESCo meeting 4/8

Apologies for the spam.

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From a.badger at gmail.com  Thu Dec  4 17:07:47 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 04 Dec 2008 09:07:47 -0800
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh7ggq$uk1$2@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<1228190889.5593.2817.camel@beck.corsepiu.local>	<gh5j3o$5cp$1@ger.gmane.org>	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh7ggq$uk1$2@ger.gmane.org>
Message-ID: <49380E63.9010801@gmail.com>

Matthew Woehlke wrote:
> Ralf Corsepius wrote:
>> On Wed, 2008-12-03 at 10:22 +0100, Kevin Kofler wrote:
>>> Ralf Corsepius wrote:
>>>
>>>> On Mon, 2008-12-01 at 22:28 -0500, Jens Petersen wrote:
>>>>
>>>>> I would add:
>>>>>
>>>>> * do not start new projects using autotools as far as possible
>>>> I would recommend you to stop spreading FUD.
>>> What FUD?
>>> There's an alternative which is:
>>> * easier to learn,
>>> * more portable,
>>> * more backwards-compatible (with its own previous versions),
>>> * faster,
>>> * generating nicer makefiles (progress percentages, color output),
>>> * designed in a better way (information is kept in central places
>>> instead of
>>> being copied into hundreds of projects),
>>> * used by more and more software, including big projects like KDE 4.
>>>
>>> It's called CMake.
>> See, all FUD, you simply are spraying hatred against something you don't
>> understand or don't want to understand.
>>
>> To me, cmake is
>> * not easier to learn, just different
>> * non-portable/inflexible.
>> * overladden with non-helpful gimmicks like progress percentages and
>> color output
>> * a crack ridden design (using a central database), reinvention of
>> imake, comprising it's design flaws.
> 
> I'm not going to contribute to the flamewar by commenting on any of the
> above (not in this thread anyway ;-) ), but...
> 
>> * a kde proprietary tool.
> 
> ...this last point (yes, even taking into account your "not useful
> outside of KDE" revision) is just plain wrong and reads like complete
> and utter ignorance of what CMake is. Yes, KDE4 uses it, but saying it
> is "kde proprietary" is just ludicrous.
> 
> Personally, I use CMake these days for pretty much every one-off project
> I do (and I'd promote it as the build tool of choice for any new
> project). Why? Because it's dead simple to write a trivial
> CMakeLists.txt that Just Works for basic stuff. For crying out loud,
> "hello, world" is one line! And the dependency graphs don't rely on
> gcc/m4/whatever. I use it for Qt-only apps. I use it for small C/C++
> projects and I'm working on a port of a large project incorporating C,
> C++ and Java (that needs to build on Windows also, plus a few even more
> esoteric and not-very-UNIX-like platforms).
> 
> CMake was not developed by KDE, nor for KDE. KDE is (one of) the most
> visibly FLOSS users of CMake, and *that's all*. It's /very/ useful as a
> general build tool.
> 
> Oh, and, autotools is of marginal usefulness outside of GNU. (Maybe
> that's not true /now/, but I'm quite confident it was when autotools was
> young.)
> 
> Ok, so I'll throw in my $0.02 anyway...
> 
> Autotools needs a POSIX shell... and for development, better have GNU
> gcc, make, sed, awk, m4, bison, probably others... for ANY project of
> non-trivial complexity (maybe even for trivial complexity, since I've
> never tried to develop an auto* project on a non-Linux platform).
> 
POSIX shell certainly.  gcc and GNU make definitely not.  Being able to
build when gcc and GNU make is not present is one of the reasons that
the autotools were created.

GNU m4 should only be required when the developer is modifying
configure.ac, not when the user is building. GNU sed, awk, and bison I'm
a little fuzzy in my memory but I don't believe the GNU versions are
required.  Better to ask an autotools guru about that, though.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/a53a8fef/attachment.sig>

From limb at jcomserv.net  Thu Dec  4 17:16:38 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 4 Dec 2008 11:16:38 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <20081204170029.GA5553@bludgeon.org>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
Message-ID: <205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>


> On Wed, Dec 03, 2008 at 03:27:48PM -0600, Jon Ciesla wrote:
>>
>> >> I suggest starting the NRM process:
>> >> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
>> >>
>> >
>> > It has already started. Bugs have been filed. Attempts to contact have
>> > been made. It's been months with zero contact.
>> >
>> > I guess the next step is to ask: who can take up these packages?
>> >
>> I could take a crack at gallery2.
>
> Are you able to maintain an EPEL version as well?  At least for EL-5.

Yes, I already do for Drupal and a few other PHP apps.

> Ray
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From jkeating at redhat.com  Thu Dec  4 17:27:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 04 Dec 2008 09:27:06 -0800
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081204123454.GA10672@thinkpad>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
	<935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
	<20081204103546.GA10549@thinkpad>
	<20081204122712.GA2339@yoda.jdub.homelinux.org>
	<20081204123454.GA10672@thinkpad>
Message-ID: <1228411626.3275.14.camel@localhost.localdomain>

On Thu, 2008-12-04 at 12:34 +0000, Richard W.M. Jones wrote:
> 
> Isn't it redundant for the rawhide report to show more than one broken
> package dependency anyway?  Certainly if the deps that are broken come
> from the same package ...

Each broken dep may be from a different cause, and fixing one won't
necessarily fix the other.

Basically FESCo has noticed that the broken deps have dragged on a few
days, and wanted to offer a hand in fixing them up.  That's kind of part
of FESCo's responsibility, to help out where help is needed.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/0aaf5871/attachment.sig>

From mark.bidewell at alumni.clemson.edu  Thu Dec  4 17:34:51 2008
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Thu, 4 Dec 2008 12:34:51 -0500
Subject: Fedora 10 and YUM
In-Reply-To: <20081204152811.GA11313@programmer-monk.net>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
	<bfdeacfa0812040548x546b1975w7992c0d19d1e9fc9@mail.gmail.com>
	<20081204152811.GA11313@programmer-monk.net>
Message-ID: <bfdeacfa0812040934rc8061ednbfd7034ff779404a@mail.gmail.com>

On Thu, Dec 4, 2008 at 10:28 AM, Geoff Reedy <geoff at programmer-monk.net>wrote:

> I'm seeing this as well, seems to be in BZ 459756 and 471450. It seems
> as though at least some DNS servers get confused by the parallel AAAA
> and A queries and only respond to one of them. The worst part is that
> the nature of the problem will make it hard to update to a fixed
> implementation. I think this particular issue is worth a mention in
> Bugs/F10Common because it seems to be relatively wide spread (seems to
> be impacting comcast users reliably).
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Interesting data point as I am also a Comcast user.  Also, even though it
would appear that we have narrowed down the cause, it case it is relevant,
here is my router configuration:

Buffalo WHR-G125 running DD-WRT v24-sp1.

Mark Bidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/e0e67916/attachment.htm>

From opensource at till.name  Thu Dec  4 18:16:54 2008
From: opensource at till.name (Till Maas)
Date: Thu, 04 Dec 2008 19:16:54 +0100
Subject: Updates to dates in the Fedora 11 Feature process
In-Reply-To: <da159fda0812040749n207e68benf4a320050c91c24@mail.gmail.com>
References: <da159fda0812040749n207e68benf4a320050c91c24@mail.gmail.com>
Message-ID: <200812041917.03694.opensource@till.name>

On Thu December 4 2008, Jon Stanley wrote:

> Here are the real ones:
>
> Alpja Freeze - 1/20 - FESCo meeting 1/14
> Feature Freeze - 3/3 - FESCo meeting 2/25
> Final Freeze - 4/14 - FESCo meeting 4/8

Would you please write the dates next time in iso/international notation:

Alpha Freeze - 2008-01-20 - FESCo meeting 2008-01-14
Feature Freeze - 2008-03-03 - FESCo meeting 2008-02-25
Final Freeze - 2008-04-14 - FESCo meeting 2008-04-08

Thanks,
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/e5470baa/attachment.sig>

From rjones at redhat.com  Thu Dec  4 18:18:08 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 4 Dec 2008 18:18:08 +0000
Subject: rawhide report: 20081128 changes
In-Reply-To: <1228411626.3275.14.camel@localhost.localdomain>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
	<935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
	<20081204103546.GA10549@thinkpad>
	<20081204122712.GA2339@yoda.jdub.homelinux.org>
	<20081204123454.GA10672@thinkpad>
	<1228411626.3275.14.camel@localhost.localdomain>
Message-ID: <20081204181808.GB10672@thinkpad>

On Thu, Dec 04, 2008 at 09:27:06AM -0800, Jesse Keating wrote:
> Basically FESCo has noticed that the broken deps have dragged on a few
> days, and wanted to offer a hand in fixing them up.  That's kind of part
> of FESCo's responsibility, to help out where help is needed.

Yes, I appreciate it.  I'm building the packages now.  It's a serial
process because of the dependencies between packages.

I'm using tsort(1) to get a build ordering, and some scripting to kick
off the builds one after another.  One problem is that there seems to
be no good way to find out from Koji when it rebuilds its repository
(so that I can kick off a build that depends on a previous build).

Rich.



From skvidal at fedoraproject.org  Thu Dec  4 18:21:17 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 4 Dec 2008 13:21:17 -0500 (EST)
Subject: Updates to dates in the Fedora 11 Feature process
In-Reply-To: <200812041917.03694.opensource@till.name>
References: <da159fda0812040749n207e68benf4a320050c91c24@mail.gmail.com>
	<200812041917.03694.opensource@till.name>
Message-ID: <alpine.LFD.2.00.0812041320390.27394@localhost.localdomain>



On Thu, 4 Dec 2008, Till Maas wrote:

> On Thu December 4 2008, Jon Stanley wrote:
>
>> Here are the real ones:
>>
>> Alpja Freeze - 1/20 - FESCo meeting 1/14
>> Feature Freeze - 3/3 - FESCo meeting 2/25
>> Final Freeze - 4/14 - FESCo meeting 4/8
>
> Would you please write the dates next time in iso/international notation:
>
> Alpha Freeze - 2008-01-20 - FESCo meeting 2008-01-14
> Feature Freeze - 2008-03-03 - FESCo meeting 2008-02-25
> Final Freeze - 2008-04-14 - FESCo meeting 2008-04-08

does iso/international notation mean '1 year ago'? b/c I'm pretty sure the 
freezes are not for a 2008. :)

-sv



From jeff at ocjtech.us  Thu Dec  4 18:27:29 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Thu, 4 Dec 2008 12:27:29 -0600
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081204181808.GB10672@thinkpad>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
	<935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
	<20081204103546.GA10549@thinkpad>
	<20081204122712.GA2339@yoda.jdub.homelinux.org>
	<20081204123454.GA10672@thinkpad>
	<1228411626.3275.14.camel@localhost.localdomain>
	<20081204181808.GB10672@thinkpad>
Message-ID: <935ead450812041027h6dbd6d9fs5e6a7b125f030323@mail.gmail.com>

On Thu, Dec 4, 2008 at 12:18 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
> One problem is that there seems to
> be no good way to find out from Koji when it rebuilds its repository
> (so that I can kick off a build that depends on a previous build).

'koji wait-repo dist-f11' should do what you want.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From jkeating at redhat.com  Thu Dec  4 18:27:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 04 Dec 2008 10:27:35 -0800
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081204181808.GB10672@thinkpad>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
	<20081128120926.GA12663@amd.home.annexia.org>
	<20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
	<935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
	<20081204103546.GA10549@thinkpad>
	<20081204122712.GA2339@yoda.jdub.homelinux.org>
	<20081204123454.GA10672@thinkpad>
	<1228411626.3275.14.camel@localhost.localdomain>
	<20081204181808.GB10672@thinkpad>
Message-ID: <1228415255.3275.18.camel@localhost.localdomain>

On Thu, 2008-12-04 at 18:18 +0000, Richard W.M. Jones wrote:
> 
> Yes, I appreciate it.  I'm building the packages now.  It's a serial
> process because of the dependencies between packages.
> 
> I'm using tsort(1) to get a build ordering, and some scripting to kick
> off the builds one after another.  One problem is that there seems to
> be no good way to find out from Koji when it rebuilds its repository
> (so that I can kick off a build that depends on a previous build).

You want to use chain-build

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/2aa14d26/attachment.sig>

From ajax at redhat.com  Thu Dec  4 18:01:22 2008
From: ajax at redhat.com (Adam Jackson)
Date: Thu, 04 Dec 2008 13:01:22 -0500
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <20081204165453.1000b24d@dhcp03.addix.net>
References: <4933F7AD.1040904@gmail.com>
	<dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>
	<49340456.7050802@gmail.com>
	<bf967e93f32794940b6560b82c859ae9.squirrel@arekh.dyndns.org>
	<loom.20081203T190300-549@post.gmane.org>
	<1228339831.14110.279.camel@atropine.boston.devel.redhat.com>
	<20081204165453.1000b24d@dhcp03.addix.net>
Message-ID: <1228413682.14110.282.camel@atropine.boston.devel.redhat.com>

On Thu, 2008-12-04 at 16:54 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Wed, 03 Dec 2008 16:30:31 -0500, Adam Jackson wrote:
> 
> > We do have a heuristic to pick a plausible virtual size based on how
> > much video memory you have.  It's not perfect, nor can it ever be.
> 
> 'Have' as in 'we have a plan', or 'have' as in 'it's in the F10/rawhide
> drivers already'?

The latter.

- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/f436d028/attachment.sig>

From rjones at redhat.com  Thu Dec  4 18:49:16 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 4 Dec 2008 18:49:16 +0000
Subject: rawhide report: 20081128 changes
In-Reply-To: <1228415255.3275.18.camel@localhost.localdomain>
References: <20081203121736.0c4586d9@ohm.scrye.com>
	<935ead450812031127g495583c3of2a7d34c1a589fa6@mail.gmail.com>
	<20081203215213.GB5689@yoda.jdub.homelinux.org>
	<935ead450812031358o4e645458t3c4528cf7628557e@mail.gmail.com>
	<20081204103546.GA10549@thinkpad>
	<20081204122712.GA2339@yoda.jdub.homelinux.org>
	<20081204123454.GA10672@thinkpad>
	<1228411626.3275.14.camel@localhost.localdomain>
	<20081204181808.GB10672@thinkpad>
	<1228415255.3275.18.camel@localhost.localdomain>
Message-ID: <20081204184916.GA15902@thinkpad>

On Thu, Dec 04, 2008 at 10:27:35AM -0800, Jesse Keating wrote:
> On Thu, 2008-12-04 at 18:18 +0000, Richard W.M. Jones wrote:
> > 
> > Yes, I appreciate it.  I'm building the packages now.  It's a serial
> > process because of the dependencies between packages.
> > 
> > I'm using tsort(1) to get a build ordering, and some scripting to kick
> > off the builds one after another.  One problem is that there seems to
> > be no good way to find out from Koji when it rebuilds its repository
> > (so that I can kick off a build that depends on a previous build).
> 
> You want to use chain-build

I've never managed to get chain-build to do anything useful.  But I
just reread the documentation[1] so I'll have another go with it.

Rich.

[1] http://fedoraproject.org/wiki/Koji/UsingKoji#Chained_builds



From tibbs at math.uh.edu  Thu Dec  4 18:44:49 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 04 Dec 2008 12:44:49 -0600
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <4937B68B.8050006@iinet.net.au>
References: <1228091890.19905.5.camel@localhost.localdomain>
	<200811301640.37888.konrad@tylerc.org>
	<20081201101456.GA18568@thinkpad>
	<ufa1vwrwrf3.fsf@epithumia.math.uh.edu>
	<360f42acea018573951d974f75130677.squirrel@mail.jcomserv.net>
	<4937B68B.8050006@iinet.net.au>
Message-ID: <ufa3ah3hja6.fsf@epithumia.math.uh.edu>

>>>>> "DT" == David Timms <dtimms at iinet.net.au> writes:

DT> What is the plan with Merge Reviews anyway ?

To process them as any other review.

DT> Is there a long term goal ?

To have them all reviewed.

DT> Can they only be done by certain people (I noticed that at least
DT> they are not suggested for beginner Packagers wanting to get
DT> sponsored) ?

Anyone who is sponsored can do package reviews.  People who are not
sponsored are welcome to make comments, but they cannot set the
flags.  This is no different than any other review ticket.

Separating out the merge reviews would only serve to focus less
reviewer time on them.  I personally tend to spend my time on the
non-merge reviews as those have a eager person attached to them who
would obviously like their package to be in the distro, but I try to
do an occasional merge review and there's no reason that someone else
couldn't have other priorities.

 - J<



From fedora at camperquake.de  Thu Dec  4 19:11:13 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 4 Dec 2008 20:11:13 +0100
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <1228413682.14110.282.camel@atropine.boston.devel.redhat.com>
References: <4933F7AD.1040904@gmail.com>
	<dd55f09e5e37b66cb57c3a7e90b85dd2.squirrel@arekh.dyndns.org>
	<49340456.7050802@gmail.com>
	<bf967e93f32794940b6560b82c859ae9.squirrel@arekh.dyndns.org>
	<loom.20081203T190300-549@post.gmane.org>
	<1228339831.14110.279.camel@atropine.boston.devel.redhat.com>
	<20081204165453.1000b24d@dhcp03.addix.net>
	<1228413682.14110.282.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081204201113.51e481a1@lain.camperquake.de>

Hi.

On Thu, 04 Dec 2008 13:01:22 -0500, Adam Jackson wrote

> > 'Have' as in 'we have a plan', or 'have' as in 'it's in the
> > F10/rawhide drivers already'?
> 
> The latter.

Well, then I wonder how well that works. I have a 945GM with 3GB of
RAM sitting besides it and a 1024x768 display, and my maximum xrandr
size is 1024x1024.

Is there something I have to do in order to use all that RAM?



From tibbs at math.uh.edu  Thu Dec  4 19:26:13 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 04 Dec 2008 13:26:13 -0600
Subject: Package Review Stats for the week ending November 23, 2007
In-Reply-To: <ufa3ah3hja6.fsf@epithumia.math.uh.edu>
References: <1228091890.19905.5.camel@localhost.localdomain>
	<200811301640.37888.konrad@tylerc.org>
	<20081201101456.GA18568@thinkpad>
	<ufa1vwrwrf3.fsf@epithumia.math.uh.edu>
	<360f42acea018573951d974f75130677.squirrel@mail.jcomserv.net>
	<4937B68B.8050006@iinet.net.au>
	<ufa3ah3hja6.fsf@epithumia.math.uh.edu>
Message-ID: <ufatz9jg2sq.fsf@epithumia.math.uh.edu>

I intended to add that FESCo targeted a list of merge reviews to get
done before F9; obviously those didn't get done, but there are some
tough packages like gcc and kernel on the list.  The tracker bug is
https://bugzilla.redhat.com/show_bug.cgi?id=426387

Folks are certainly welcome to pick off some of the tickets not yet
assigned from that list, or to go through and ping the ones that seem
to have stalled out.

It also occurred to me that the whole merge review list could use some
gardening, to make sure the current package owners are at least CC'd
on the tickets.  It is often the case that the traffic just isn't
getting to the person responsible for those packages.  Anyone at all
can do this; the simplest way seems to be to run an IRC client, open a
ticket with zodbot and ask it ".whoowns blah".

 - J<



From opensource at till.name  Thu Dec  4 19:46:02 2008
From: opensource at till.name (Till Maas)
Date: Thu, 04 Dec 2008 20:46:02 +0100
Subject: My (unpleasant) fedora 10 installation experience
In-Reply-To: <20081204201113.51e481a1@lain.camperquake.de>
References: <4933F7AD.1040904@gmail.com>
	<1228413682.14110.282.camel@atropine.boston.devel.redhat.com>
	<20081204201113.51e481a1@lain.camperquake.de>
Message-ID: <200812042046.09973.opensource@till.name>

On Thu December 4 2008, Ralf Ertzinger wrote:

> Well, then I wonder how well that works. I have a 945GM with 3GB of
> RAM sitting besides it and a 1024x768 display, and my maximum xrandr
> size is 1024x1024.
>
> Is there something I have to do in order to use all that RAM?

There may be a bios option to specify how much RAM you want to assign to the 
graphics adapter or whether it should be done automatically or dynamically.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/368e0e10/attachment.sig>

From mclasen at redhat.com  Thu Dec  4 19:47:36 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 04 Dec 2008 14:47:36 -0500
Subject: gmime soname bump
Message-ID: <1228420056.3402.4.camel@localhost.localdomain>

I'm building gmime-2.4.3, which changes the libgmime soname to
libgmime-2.4.so.2.



From mw_triad at users.sourceforge.net  Thu Dec  4 20:29:40 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 04 Dec 2008 14:29:40 -0600
Subject: Status of libtool 2.2.X?
In-Reply-To: <1228375738.20451.3604.camel@beck.corsepiu.local>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<1228296680.20451.1794.camel@beck.corsepiu.local>	<gh5ls0$edm$1@ger.gmane.org>
	<200812031124.11838.opensource@till.name>	<1228300274.20451.1893.camel@beck.corsepiu.local>	<gh7g8d$uk1$1@ger.gmane.org>
	<1228375738.20451.3604.camel@beck.corsepiu.local>
Message-ID: <gh9ejl$vsm$1@ger.gmane.org>

Ralf Corsepius wrote:
> On Wed, 2008-12-03 at 20:45 -0600, Matthew Woehlke wrote:
>> Ralf Corsepius wrote:
>>> As a developer, maintainer and/or packager you normally want to see what
>>> the tools are doing, e.g. if the compiler has received the correct
>>> flags, is using the correct libraries etc.
>> Sure, but I care about that once in a great while.
> Very likely because your use-cases are trivial.

No. Rather, I don't change my build flags every build, and therefore 
don't need to verify them constantly. VERBOSE is only needed when the 
buildsystem is first created or when it is changed. (Besides that it is 
only needed in special circumstances or when you don't trust the build 
system.)

>> Of course, I like my percentage progress (a LOT, in big projects) also.
> I am well aware that some people prefer watching progress bars, instead
> of watching bugs ... the rationale for doing so has always escaped me.

That's... uncalled for. And unwarranted.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)



From forum at ru.bir.ru  Thu Dec  4 20:37:20 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Thu, 04 Dec 2008 23:37:20 +0300
Subject: How to pack cron jobs?
In-Reply-To: <20081202202346.GA6090@free.fr>
References: <46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>	<ggsd7q$5tn$1@ger.gmane.org>
	<20081130142237.GA16722@free.fr>	<ggujhc$68k$1@ger.gmane.org>
	<20081130210724.GA2649@free.fr>	<ggv8d5$539$1@ger.gmane.org>
	<20081201083229.GA2735@free.fr>	<gh1grb$v31$1@ger.gmane.org>
	<20081201205847.GB2796@free.fr>	<gh44ph$5v8$1@ger.gmane.org>
	<20081202202346.GA6090@free.fr>
Message-ID: <gh9f21$1t5$1@ger.gmane.org>

Patrice Dumas ?????:
> On Tue, Dec 02, 2008 at 11:11:29PM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>> May be, may be.
>> But return to initial my question - how I should pack cron jobs  
>> correctly? If crons independent from crontab, directories layout also  
>> depend from cron variant...
>> May be I must "Require /etc/cron.d" directly in my rpm?
> 
> Indeed.
> 
> Now if you rely on cron.hourly and so on and so forth, maybe you should
> require crontabs.
I do not rely to /etc/cron.hourly or etc and for what I could require 
crontab if I need /etc/cron.d what is not them?

>And crontabs could depend on /etc/cron.d.
Indeed? For what, if crontab is not uses it?

> --
> Pat
> 



From mw_triad at users.sourceforge.net  Thu Dec  4 20:40:05 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 04 Dec 2008 14:40:05 -0600
Subject: Status of libtool 2.2.X?
In-Reply-To: <49380E63.9010801@gmail.com>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<1228190889.5593.2817.camel@beck.corsepiu.local>	<gh5j3o$5cp$1@ger.gmane.org>	<1228296680.20451.1794.camel@beck.corsepiu.local>	<gh7ggq$uk1$2@ger.gmane.org>
	<49380E63.9010801@gmail.com>
Message-ID: <gh9f75$28a$1@ger.gmane.org>

Toshio Kuratomi wrote:
> Matthew Woehlke wrote:
>> Autotools needs a POSIX shell... and for development, better have GNU
>> gcc, make, sed, awk, m4, bison, probably others... for ANY project of
>> non-trivial complexity (maybe even for trivial complexity, since I've
>> never tried to develop an auto* project on a non-Linux platform).
>
> POSIX shell certainly.  gcc and GNU make definitely not. 

How are dependencies calculated?

> GNU m4 should only be required when the developer is modifying
> configure.ac, not when the user is building.

...which was one of my points. With autotools, the dependencies for 
actual development are more than for building, thereby increasing the 
difficulty of transitioning from user to developer. With CMake, it's 
often possible to require nothing but CMake and the necessary compilers 
(and a make tool, which doesn't need to be GNU), but regardless, once 
you have the *build* prerequisites there is nothing additional needed to 
move from being a mere consumer to more active participation.

> GNU sed, awk, and bison I'm
> a little fuzzy in my memory but I don't believe the GNU versions are
> required.  Better to ask an autotools guru about that, though.

Ideally, no, but I'm pretty sure I've run into the odd problem where 
some package doesn't build correctly in the absence of one of these 
(besides which you need /some/ version of sed and/or awk much of the 
time). Since CMake can in many instances replace the need for these, 
it's one less area of potential bugs, and for systems that don't already 
have sed/awk/etc (e.g. Windows, or other non-UNIX-like platforms), 
needing only CMake vs. needing sh, sed, awk, etc is fewer dependencies.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)



From limb at jcomserv.net  Thu Dec  4 20:46:30 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 4 Dec 2008 14:46:30 -0600 (CST)
Subject: Topic filter added for Fedora 10
In-Reply-To: <1228420449.3275.20.camel@localhost.localdomain>
References: <1228420449.3275.20.camel@localhost.localdomain>
Message-ID: <744c7f7adb9444aaf28779589fd9ccb1.squirrel@mail.jcomserv.net>


> Subject says it all.

Added to what?

> --
> Jesse Keating
> Fedora -- Freedom?? is a feature!
> identi.ca: http://identi.ca/jkeating
> _______________________________________________
> Fedora-package-announce mailing list
> Fedora-package-announce at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-package-announce
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From pertusus at free.fr  Thu Dec  4 20:48:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 4 Dec 2008 21:48:30 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh9f75$28a$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh7ggq$uk1$2@ger.gmane.org> <49380E63.9010801@gmail.com>
	<gh9f75$28a$1@ger.gmane.org>
Message-ID: <20081204204830.GB2761@free.fr>

On Thu, Dec 04, 2008 at 02:40:05PM -0600, Matthew Woehlke wrote:
>
> have sed/awk/etc (e.g. Windows, or other non-UNIX-like platforms),  
> needing only CMake vs. needing sh, sed, awk, etc is fewer dependencies.

sh, sed and awk are POSIX, and indeed Windows is not POSIX, but most
other platforms are, not only UNIX (and GNU is not UNIX). Cmake is not 
covered by any standard (that I know about).

--
Pat



From forum at ru.bir.ru  Thu Dec  4 20:50:39 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Thu, 04 Dec 2008 23:50:39 +0300
Subject: looking for inotifywait and similar help
In-Reply-To: <20081203181649.GA1588@free.fr>
References: <20081202233031.GA30159@free.fr>	<91705d080812022016q7e2bc529t3eb64c9c24ead925@mail.gmail.com>	<877i6hzmtq.fsf@sheridan.bigo.ensc.de>
	<20081203181649.GA1588@free.fr>
Message-ID: <gh9fr0$1t5$2@ger.gmane.org>

Patrice Dumas wrote:
> In both cases /etc is watched. That is something I would have liked to
> avoid, because it will cause my script to wake up a lot, compared with
> only looking at /etc/cron.d, /etc/crontab and /etc/fcrontab. 
> 
> It looks like signalling that a file came into existence without
> watching the directory the file is in is not possible with inotify
> currently.
> 
May be initialy check this file is exists, and if not just create 
(touch) empty if not? If we create new empty files, it is not add any 
job, but allow watch modify of it.

> --
> Pat
> 



From cweyl at alumni.drew.edu  Thu Dec  4 20:54:26 2008
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Thu, 4 Dec 2008 12:54:26 -0800
Subject: Fedora 11 Feature Process reminders
In-Reply-To: <da159fda0812032149r1ea8d92fx1a73b957022c4f8@mail.gmail.com>
References: <da159fda0812032149r1ea8d92fx1a73b957022c4f8@mail.gmail.com>
Message-ID: <7dd7ab490812041254v3d91adbai35b55ea29b0ca093@mail.gmail.com>

On Wed, Dec 3, 2008 at 9:49 PM, Jon Stanley <jonstanley at gmail.com> wrote:
>
> At today's FESCo meeting, the final schedule for Fedora 11 was
> approved.  Now  it's time for some reminders about the feature process
> for Fedora 11.  We're changing a few things this time around to
> hopefully make the whole process run smoother than ever!
>
> First., FESCo will be making decisions regarding dropping incomplete
> features at the meeting *2 weeks before* the freeze date, in order to
> give rel-eng and QA time to implement whatever contingency plans might
> be required prior to the freeze.  For Fedora 11, these dates are:

Silly question, but are there any deadlines for submitting features to
FESCo for F-11?

                        -Chris
--
Chris Weyl
Ex astris, scientia



From pertusus at free.fr  Thu Dec  4 20:57:19 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 4 Dec 2008 21:57:19 +0100
Subject: looking for inotifywait and similar help
In-Reply-To: <gh9fr0$1t5$2@ger.gmane.org>
References: <20081202233031.GA30159@free.fr>
	<91705d080812022016q7e2bc529t3eb64c9c24ead925@mail.gmail.com>
	<877i6hzmtq.fsf@sheridan.bigo.ensc.de>
	<20081203181649.GA1588@free.fr> <gh9fr0$1t5$2@ger.gmane.org>
Message-ID: <20081204205719.GC2761@free.fr>

On Thu, Dec 04, 2008 at 11:50:39PM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>>
> May be initialy check this file is exists, and if not just create  
> (touch) empty if not? If we create new empty files, it is not add any  
> job, but allow watch modify of it.

I'd prefer not to create even empty files that are part of other
packages. I will solve that by doing a specific C program to watch both
files modifications and creation.

--
Pat



From jkeating at redhat.com  Thu Dec  4 21:10:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 04 Dec 2008 13:10:32 -0800
Subject: Topic filter added for Fedora 10
In-Reply-To: <744c7f7adb9444aaf28779589fd9ccb1.squirrel@mail.jcomserv.net>
References: <1228420449.3275.20.camel@localhost.localdomain>
	<744c7f7adb9444aaf28779589fd9ccb1.squirrel@mail.jcomserv.net>
Message-ID: <1228425032.3275.25.camel@localhost.localdomain>

On Thu, 2008-12-04 at 14:46 -0600, Jon Ciesla wrote:
> Added to what?

Added to the topic filter list for the fedora-package-announce list.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/307bfba5/attachment.sig>

From paul-fedora at saturnine.org.uk  Thu Dec  4 21:17:35 2008
From: paul-fedora at saturnine.org.uk (Paul Black)
Date: Thu, 4 Dec 2008 21:17:35 +0000
Subject: Topic filter added for Fedora 10
In-Reply-To: <1228425032.3275.25.camel@localhost.localdomain>
References: <1228420449.3275.20.camel@localhost.localdomain>
	<744c7f7adb9444aaf28779589fd9ccb1.squirrel@mail.jcomserv.net>
	<1228425032.3275.25.camel@localhost.localdomain>
Message-ID: <a9274eb10812041317r5f6c405dr27bed62179cb9291@mail.gmail.com>

2008/12/4 Jesse Keating wrote:
> On Thu, 2008-12-04 at 14:46 -0600, Jon Ciesla wrote:
>> Added to what?
>
> Added to the topic filter list for the fedora-package-announce list.

And much appreciated it is too.

Cheers

-- 
Paul



From pertusus at free.fr  Thu Dec  4 21:58:53 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 4 Dec 2008 22:58:53 +0100
Subject: How to pack cron jobs?
In-Reply-To: <gh9f21$1t5$1@ger.gmane.org>
References: <20081130142237.GA16722@free.fr> <ggujhc$68k$1@ger.gmane.org>
	<20081130210724.GA2649@free.fr> <ggv8d5$539$1@ger.gmane.org>
	<20081201083229.GA2735@free.fr> <gh1grb$v31$1@ger.gmane.org>
	<20081201205847.GB2796@free.fr> <gh44ph$5v8$1@ger.gmane.org>
	<20081202202346.GA6090@free.fr> <gh9f21$1t5$1@ger.gmane.org>
Message-ID: <20081204215853.GD2761@free.fr>

On Thu, Dec 04, 2008 at 11:37:20PM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> Patrice Dumas ?????:
>> On Tue, Dec 02, 2008 at 11:11:29PM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>>> May be, may be.
>>> But return to initial my question - how I should pack cron jobs   
>>> correctly? If crons independent from crontab, directories layout also 
>>>  depend from cron variant...
>>> May be I must "Require /etc/cron.d" directly in my rpm?
>>
>> Indeed.
>>
>> Now if you rely on cron.hourly and so on and so forth, maybe you should
>> require crontabs.
> I do not rely to /etc/cron.hourly or etc and for what I could require  
> crontab if I need /etc/cron.d what is not them?

If indeed you don't need /etc/cron.hourly or etc, but rather
/etc/cron.d, you'd better require /etc/cron.d.

>> And crontabs could depend on /etc/cron.d.
> Indeed? For what, if crontab is not uses it?

To make sure that crontabs brings in a scheduler.

--
Pat



From mw_triad at users.sourceforge.net  Thu Dec  4 22:03:22 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 04 Dec 2008 16:03:22 -0600
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081204204830.GB2761@free.fr>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<1228190889.5593.2817.camel@beck.corsepiu.local>	<gh5j3o$5cp$1@ger.gmane.org>	<1228296680.20451.1794.camel@beck.corsepiu.local>	<gh7ggq$uk1$2@ger.gmane.org>
	<49380E63.9010801@gmail.com>	<gh9f75$28a$1@ger.gmane.org>
	<20081204204830.GB2761@free.fr>
Message-ID: <gh9k3g$kp1$1@ger.gmane.org>

Patrice Dumas wrote:
> Cmake is not  covered by any standard (that I know about).

What's your point? Is the autotools suite "covered by a standard"?

Autotools is theoretically portable to any POSIX system. In reality, 
since most systems have bugs and idiosyncrasies, porting to a totally 
new platform is going to involve some work.

CMake is theoretically portable to any system with a C++ compiler.

Let's do some score-keeping:

Mainstream POSIX systems:
- CMake: already works
- autotools: already works
Winner: tie

New POSIX systems:
- CMake: has to deal with idiosyncrasies in the compiler and possibly make.
- autotools: has to deal with idiosyncrasies in the compiler, shell, 
sed/awk/m4/etc, and possibly make.
Winner: CMake

Non-POSIX systems:
- CMake: have to find the compiler and understand how to use it, have to 
understand a make system to generate "makefiles" (or an equivalent).
- autotools: not going to happen :-).
Winner: CMake

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)



From poelstra at redhat.com  Thu Dec  4 23:09:18 2008
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 04 Dec 2008 15:09:18 -0800
Subject: Fedora 11 Feature Process reminders
In-Reply-To: <7dd7ab490812041254v3d91adbai35b55ea29b0ca093@mail.gmail.com>
References: <da159fda0812032149r1ea8d92fx1a73b957022c4f8@mail.gmail.com>
	<7dd7ab490812041254v3d91adbai35b55ea29b0ca093@mail.gmail.com>
Message-ID: <4938631E.3050605@redhat.com>

Chris Weyl wrote:
> On Wed, Dec 3, 2008 at 9:49 PM, Jon Stanley <jonstanley at gmail.com> wrote:
>> At today's FESCo meeting, the final schedule for Fedora 11 was
>> approved.  Now  it's time for some reminders about the feature process
>> for Fedora 11.  We're changing a few things this time around to
>> hopefully make the whole process run smoother than ever!
>>
>> First., FESCo will be making decisions regarding dropping incomplete
>> features at the meeting *2 weeks before* the freeze date, in order to
>> give rel-eng and QA time to implement whatever contingency plans might
>> be required prior to the freeze.  For Fedora 11, these dates are:
> 
> Silly question, but are there any deadlines for submitting features to
> FESCo for F-11?
> 

Feature Freeze

https://fedoraproject.org/wiki/Features/Policy/Milestones

John



From pertusus at free.fr  Thu Dec  4 23:13:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 00:13:20 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh9k3g$kp1$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh7ggq$uk1$2@ger.gmane.org> <49380E63.9010801@gmail.com>
	<gh9f75$28a$1@ger.gmane.org> <20081204204830.GB2761@free.fr>
	<gh9k3g$kp1$1@ger.gmane.org>
Message-ID: <20081204231320.GE2761@free.fr>

On Thu, Dec 04, 2008 at 04:03:22PM -0600, Matthew Woehlke wrote:
> Patrice Dumas wrote:
>> Cmake is not  covered by any standard (that I know about).
>
> What's your point? Is the autotools suite "covered by a standard"?

Not at all. But although cmake may not be installed on a POSIX system
all that is required by ./configure should.

I don't mean that cmake is more nor less portable. But vendor cmake may
not be more portable than POSIX tools.

> Autotools is theoretically portable to any POSIX system. In reality,  
> since most systems have bugs and idiosyncrasies, porting to a totally  
> new platform is going to involve some work.

> CMake is theoretically portable to any system with a C++ compiler.

You mean a specific cmake. But a vendor cmake may be different, with its
own set of idiosyncrasies. Looks like you are not compared the same set
of tools. GNU POSIX utilities don't have specific idiosyncrasies.

> Let's do some score-keeping:

I won't comment on that there are too many things that are not clearly
defined, and, honestly I don't caare. I don't favor cmake or the
autotools. My point is that you are comparing different things. 

On one hand you have an upstream cmake rebuild on different platforms. 
On the other thre are different vendor POSIX utilities that may be
rebuilt or in binary form that may not share the same source (and you 
may not even have the source).

A fair comparison would be a comparison between, say, GNU POSIX
utilities and standard cmake.

--
Pat



From lists at ebourne.me.uk  Thu Dec  4 23:33:47 2008
From: lists at ebourne.me.uk (Martin Ebourne)
Date: Thu, 4 Dec 2008 23:33:47 +0000 (UTC)
Subject: keyfile plugin as new install default for NetworkManager in F11?
Message-ID: <pan.2008.12.04.23.33.46@ebourne.me.uk>

Fedora is currently using the ifcfg plugin for NetworkManager that stores 
system wide network settings in the old network scripts format. This is 
clearly useful when upgrading a machine with a working configuration from 
an old Fedora release. However the legacy format makes it difficult to 
understand the settings and restricts the functionality somewhat.

NetworkManager also includes an alternative system wide settings plugin 
called keyfile. This stores system wide connections in ini format files 
in the /etc/NetworkManager/system-connections directory. These are a lot 
easier to understand and read, and provide much better functionality (eg. 
system wide WPA is trivial), and most importantly of all provides a much 
more user friendly and consistent GUI giving an excellent user experience.

I switched to keyfile with the Fedora 9 release since ifcfg was not 
working for WPA. Back then it was necessary to write the config files by 
hand which took quite some figuring out. With Fedora 10 it's now as 
simple as configure the network in NetworkManager in the usual way, then 
just tick the 'Available to all users' box in the NetworkManager edit 
settings dialogue.

Are there any plans to switch to keyfile as the default for new installs 
with Fedora 11? It would seem sensible to leave ifcfg for upgrades, 
perhaps with an easy way to automatically switch to keyfile if desired.

Cheers,
Martin

PS. These two very minor bugs in F10 are all that separates keyfile from 
an excellent user experience for me, on several different machines:
https://bugzilla.redhat.com/show_bug.cgi?id=465633
https://bugzilla.redhat.com/show_bug.cgi?id=471734



From mw_triad at users.sourceforge.net  Fri Dec  5 00:09:57 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 04 Dec 2008 18:09:57 -0600
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081204231320.GE2761@free.fr>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>	<1228190889.5593.2817.camel@beck.corsepiu.local>	<gh5j3o$5cp$1@ger.gmane.org>	<1228296680.20451.1794.camel@beck.corsepiu.local>	<gh7ggq$uk1$2@ger.gmane.org>
	<49380E63.9010801@gmail.com>	<gh9f75$28a$1@ger.gmane.org>
	<20081204204830.GB2761@free.fr>	<gh9k3g$kp1$1@ger.gmane.org>
	<20081204231320.GE2761@free.fr>
Message-ID: <gh9rgl$ddb$1@ger.gmane.org>

Patrice Dumas wrote:
> On Thu, Dec 04, 2008 at 04:03:22PM -0600, Matthew Woehlke wrote:
>> Patrice Dumas wrote:
>>> Cmake is not  covered by any standard (that I know about).
>> What's your point? Is the autotools suite "covered by a standard"?
> 
> Not at all. But although cmake may not be installed on a POSIX system
> all that is required by ./configure should.
> 
> I don't mean that cmake is more nor less portable. But vendor cmake may
> not be more portable than POSIX tools.

What "vendor CMake"? Right now there is only one CMake (and unlike 
autotools, it does a fair job of allowing projects using CMake to work 
with CMake versions other than the one used by the developers). I don't 
expect to see third-party flavors of CMake (the way you see various 
vendor versions of e.g. sed, which have no relation to each other 
besides the degree to which they implement the POSIX spec for such tool).

I can't help but notice that you are ignoring that having CMake provides 
you with the ability to make changes to the application, where autotools 
fails miserably at this.

>> Autotools is theoretically portable to any POSIX system. In reality,  
>> since most systems have bugs and idiosyncrasies, porting to a totally  
>> new platform is going to involve some work.
> 
>> CMake is theoretically portable to any system with a C++ compiler.
> 
> You mean a specific cmake. But a vendor cmake may be different, with its
> own set of idiosyncrasies.

Again, *what* "vendor cmake"? There is no such thing.

> Looks like you are not compared the same set
> of tools. GNU POSIX utilities don't have specific idiosyncrasies.

Sure they don't. That's why if I write a script for GNU sh (a.k.a. bash) 
it runs perfectly on every other vendor's shell (and every other version 
of bash). Likewise for make, sed, awk, etc.

>> Let's do some score-keeping:
> 
> I won't comment on that there are too many things that are not clearly
> defined, and, honestly I don't caare. I don't favor cmake or the
> autotools. My point is that you are comparing different things. 

I think that's the very point I'm trying to make. Autotools has a slight 
advantage of (debatably) lower build requirements, but very onerous 
development requirements. CMake, by being a proper build system rather 
than an ever-changing collective mess that tries to make a build system 
unnecessary, has a slightly greater minimum cost to build CMake-based 
software versus the best-case for autotools-based software, but that 
cost provides an entire spectrum of utility that 'configure' does not, 
whereas the autotools cost to get comparable functionality is much, much 
higher.

> A fair comparison would be a comparison between, say, GNU POSIX
> utilities and standard cmake.

Actually, that's the comparison I /was/ making.

Cost of porting the entire autotools sphagetti bowl: something like a 
half dozen tools, and good luck getting them to work on non-UNIX-like 
systems.

Cost of porting CMake: on POSIX platforms, about the same as autotools 
or better, and unlike autotools, doable for non-UNIX-like platforms.

...and when you're done, I fail to see that autotools provides anything 
to justify that extra effort. Especially since being able to generate a 
build system that works without installing anything (the only point I 
can see as even being worth arguing where autotools is "better") is not 
guaranteed.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)



From ivazqueznet at gmail.com  Fri Dec  5 00:03:31 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 04 Dec 2008 19:03:31 -0500
Subject: Python 2.6 now in Rawhide; breakage to follow
Message-ID: <1228435411.29612.142.camel@ignacio.lan>

Python 2.6 is now in Rawhide and ready to be battle-tested. Tools up to
yum and system-config-* work, with some DeprecationWarnings;
higher-level tools are still being worked on.

It will still be a few weeks before all the problems are ironed out.
Anyone that has any problems with porting code, just let me know and
I'll help out.

Some packages are also going to need changes for missing dependencies,
especially for a missing python(abi) requirement. Bugs will be filed as
problems are found.

Thanks for your patience in this time of transition.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081204/f07ef96b/attachment.sig>
-------------- next part --------------
_______________________________________________
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  Fri Dec  5 00:35:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 05 Dec 2008 01:35:47 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org>
	<200812031124.11838.opensource@till.name>
	<1228300274.20451.1893.camel@beck.corsepiu.local>
	<gh7g8d$uk1$1@ger.gmane.org>
	<1228375738.20451.3604.camel@beck.corsepiu.local>
Message-ID: <gh9t13$grs$1@ger.gmane.org>

Ralf Corsepius wrote:
> I am well aware that some people prefer watching progress bars, instead
> of watching bugs

The progress output doesn't hide the errors or warnings, which are the
actual bugs in the code.

Getting the build flags right is something you do once (in the context of
Fedora, when you first submit the package for review) and then you're done
with it.

        Kevin Kofler



From markg85 at gmail.com  Fri Dec  5 00:48:09 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 5 Dec 2008 01:48:09 +0100
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
Message-ID: <6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>

On Sun, Nov 30, 2008 at 2:04 AM, Mark <markg85 at gmail.com> wrote:
> Hey,
>
> There is a bug report for it here:
> https://bugzilla.redhat.com/show_bug.cgi?id=470266
>
> That's there since just a few weeks but the issue itself is in
> bugzilla several times and known for years now.
> And i wonder what the status is with this. If it's so hard to get it
> working then please just destroy the entire option to have a logout
> sound in gnome at the first place. A feature that is in but broken is
> kinda ugly.
>
> And perhaps this info helps. When pulseaudio wasn't in gnome the
> logout sound did work, but was already screwed! it just played a part
> of the logout sound before getting cut off.
>
> I hope anyone can give me some status on this bug. I really hope it
> can be fixed for F11.
>
> Thanx,
> Mark

Is there really no interest for this long standing bug?



From kevin.kofler at chello.at  Fri Dec  5 00:52:04 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 05 Dec 2008 01:52:04 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<200812032120.39907.opensource@till.name>
	<gh7ote$gb7$1@ger.gmane.org>
	<200812041106.50524.opensource@till.name>
Message-ID: <gh9tvk$jpn$1@ger.gmane.org>

Till Maas wrote:
> Also does %cmake also make sure that -O3 / -s is not passed to gcc? Also
> it seems imposible to see, whether cmake uses "install -s" to install
> binaries or not.

CMake doesn't use the install binary at all, it creates a CMake script with
the installations to perform and runs cmake -P with that script. So there
are no command invocations to show. I'm not sure whether that even supports
stripping, I've yet to see a CMake-using program which tries to strip on
install.

But to be sure, just look at the contents of the -debuginfo package, you'll
see immediately when it is invalid (it will be empty or almost empty). If
there's useful debuginfo, the files haven't been stripped.

As for -O3, that's not necessarily a problem, I'd be more worried about
things like -fno-stack-protector (i.e. "Listen crackers, this code is so
full of buffer overflows that it doesn't work at all with buffer overflow
protection, and so I helpfully disabled it for you, have fun!" ;-) ).

> Can %make maybe modified in a way, that it is possible to use something
> like "rpmbuild --without cmake_verbose" or add something to ones
> .rpmmacros file to enable/disable this for local/mock rebuilds?

That (but in %cmake and %cmake_kde4, not %make) sounds like a good idea.

        Kevin Kofler



From pertusus at free.fr  Fri Dec  5 01:09:42 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 02:09:42 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh9rgl$ddb$1@ger.gmane.org>
References: <1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh7ggq$uk1$2@ger.gmane.org> <49380E63.9010801@gmail.com>
	<gh9f75$28a$1@ger.gmane.org> <20081204204830.GB2761@free.fr>
	<gh9k3g$kp1$1@ger.gmane.org> <20081204231320.GE2761@free.fr>
	<gh9rgl$ddb$1@ger.gmane.org>
Message-ID: <20081205010942.GF2761@free.fr>

On Thu, Dec 04, 2008 at 06:09:57PM -0600, Matthew Woehlke wrote:
>
> expect to see third-party flavors of CMake (the way you see various  
> vendor versions of e.g. sed, which have no relation to each other  
> besides the degree to which they implement the POSIX spec for such tool).

Why so? There could be a solaris cmake, an IRIX cmake, an HP-UX cmake...

> Again, *what* "vendor cmake"? There is no such thing.

There could be. Why are there vendor sh, sed and awk?

> Cost of porting CMake: on POSIX platforms, about the same as autotools  
> or better, and unlike autotools, doable for non-UNIX-like platforms.

All the GNU POSIX utilities are portable and have been ported on many
platforms. 

I don't know exactly where to check, but I guess that there were even VMS 
versions of GNU sed, awk and so on, and also apollo versions and so on.

--
Pat



From chris.stone at gmail.com  Fri Dec  5 01:35:34 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 4 Dec 2008 17:35:34 -0800
Subject: apache user is unable to resolve IP addresses in F10
Message-ID: <d9c612bf0812041735p2e5a370apb0b5c5f4edd4d85d@mail.gmail.com>

The following PHP code is not working in F10:

<?php
$fp = fsockopen ("redhat.com", 80, $errno, $errstr, 30);
if (!$fp) echo "$errstr ($errno)<br>\n";
else { echo "worked"; fclose($fp); }
?>

Result: php_network_getaddresses: getaddrinfo failed: Name or service
not known (0)

Adding redhat.com's IP to my /etc/hosts gets it to work, but obviously
this is not the correct solution to the problem.

Can anyone else here reproduce this on their F10 web servers?  Or am I
all alone?

NOTE:  I get same results in both Permissive and Enforcing selinux modes.

This was working in F9, it just started happening when I upgraded.



From rc040203 at freenet.de  Fri Dec  5 01:50:33 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 05 Dec 2008 02:50:33 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh9t13$grs$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org> <200812031124.11838.opensource@till.name>
	<1228300274.20451.1893.camel@beck.corsepiu.local>
	<gh7g8d$uk1$1@ger.gmane.org>
	<1228375738.20451.3604.camel@beck.corsepiu.local>
	<gh9t13$grs$1@ger.gmane.org>
Message-ID: <1228441833.26691.1784.camel@beck.corsepiu.local>

On Fri, 2008-12-05 at 01:35 +0100, Kevin Kofler wrote:
> Ralf Corsepius wrote:
> > I am well aware that some people prefer watching progress bars, instead
> > of watching bugs
> 
> The progress output doesn't hide the errors or warnings, which are the
> actual bugs in the code.
It hides the bugs which doesn't trigger errors or warning.

> Getting the build flags right is something you do once (in the context of
> Fedora, when you first submit the package for review) and then you're done
> with it.
Not true. Packages move, packages change, dependencies change, tools
change, ... 



From notting at redhat.com  Fri Dec  5 02:02:30 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 4 Dec 2008 21:02:30 -0500
Subject: keyfile plugin as new install default for NetworkManager in F11?
In-Reply-To: <pan.2008.12.04.23.33.46@ebourne.me.uk>
References: <pan.2008.12.04.23.33.46@ebourne.me.uk>
Message-ID: <20081205020230.GA4447@nostromo.devel.redhat.com>

Martin Ebourne (lists at ebourne.me.uk) said: 
> Are there any plans to switch to keyfile as the default for new installs 
> with Fedora 11? It would seem sensible to leave ifcfg for upgrades, 
> perhaps with an easy way to automatically switch to keyfile if desired.

We're still discussing what to do. The migration story is not good right
now for keyfile.

Bill



From mike at cchtml.com  Fri Dec  5 02:31:41 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 04 Dec 2008 20:31:41 -0600
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
	<6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
Message-ID: <4938928D.5020603@cchtml.com>

Mark wrote:
>
> Is there really no interest for this long standing bug?
>
>   
I'd help you, but I hate system sounds. It shouldn't be that hard to 
follow the source or setup some debugging? Start with where the sound is 
emitted and go backwards.

Good luck.



From mclasen at redhat.com  Fri Dec  5 02:55:47 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 04 Dec 2008 21:55:47 -0500
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <4938928D.5020603@cchtml.com>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
	<6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
	<4938928D.5020603@cchtml.com>
Message-ID: <1228445747.19595.4.camel@localhost.localdomain>

On Thu, 2008-12-04 at 20:31 -0600, Michael Cronenworth wrote:
> Mark wrote:
> >
> > Is there really no interest for this long standing bug?
> >
> >   
> I'd help you, but I hate system sounds. It shouldn't be that hard to 
> follow the source or setup some debugging? Start with where the sound is 
> emitted and go backwards.


There is no need for debugging, the problem is well understood. 
We install /usr/share/gnome/shutdown/libcanberra-logout-sound.sh, but 
there is nothing in gnome-session that does anything  with that script.
It should be easy enough to come up with a basic implementation of
logout actions, if someone is really interested in fixing this bug.






From jon at fedoraunity.org  Fri Dec  5 04:00:46 2008
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Thu, 04 Dec 2008 21:00:46 -0700
Subject: apache user is unable to resolve IP addresses in F10
In-Reply-To: <d9c612bf0812041735p2e5a370apb0b5c5f4edd4d85d@mail.gmail.com>
References: <d9c612bf0812041735p2e5a370apb0b5c5f4edd4d85d@mail.gmail.com>
Message-ID: <4938A76E.2010705@fedoraunity.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Stone wrote:
> Result: php_network_getaddresses: getaddrinfo failed: Name or service
> not known (0)

See this bug and please report this is also affecting php:
https://bugzilla.redhat.com/show_bug.cgi?id=459756


- --
Jonathan Steffan
daMaestro
Fedora Unity - http://fedoraunity.org/
GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk4pzoACgkQrRJs5w2Gr1l+rQCg5eNdEQHvQjOE8VnIlhouVi2C
6HYAoJENo/oklkHMosLwg5bz5aPgZznJ
=9XOi
-----END PGP SIGNATURE-----



From jon at fedoraunity.org  Fri Dec  5 04:00:00 2008
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Thu, 04 Dec 2008 21:00:00 -0700
Subject: apache user is unable to resolve IP addresses in F10
In-Reply-To: <d9c612bf0812041735p2e5a370apb0b5c5f4edd4d85d@mail.gmail.com>
References: <d9c612bf0812041735p2e5a370apb0b5c5f4edd4d85d@mail.gmail.com>
Message-ID: <4938A740.40801@fedoraunity.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Stone wrote:
> Result: php_network_getaddresses: getaddrinfo failed: Name or service
> not known (0)

See this bug and please report this is also affecting php:
https://bugzilla.redhat.com/show_bug.cgi?id=459756


- --
Jonathan Steffan
daMaestro
Fedora Unity - http://fedoraunity.org/
GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk4pzoACgkQrRJs5w2Gr1l+rQCg5eNdEQHvQjOE8VnIlhouVi2C
6HYAoJENo/oklkHMosLwg5bz5aPgZznJ
=9XOi
-----END PGP SIGNATURE-----



From poelstra at redhat.com  Fri Dec  5 04:38:18 2008
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 04 Dec 2008 20:38:18 -0800
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <20081126144415.GC2780@free.fr>
References: <20081116160839.GC2933@free.fr>	<da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>	<20081118191939.GB2610@free.fr>	<20081123151541.5332b42c@ohm.scrye.com>	<981da310811231519i58b2f9b8t68c31ab769aff8d1@mail.gmail.com>
	<20081126144415.GC2780@free.fr>
Message-ID: <4938B03A.9010209@redhat.com>

Patrice Dumas wrote:
> On Sun, Nov 23, 2008 at 03:19:00PM -0800, Brennan Ashton wrote:
>> The only part of our housekeeping page that seems to be policy is the
>> EOL, was there another area that you were wanting in there as well?
> 
> I think that the use of FutureFeature should be in the policy. And also
> the part about 'Tracker (Blocker) Bugs'. 
> 
> Maybe something along:
> 
> When a fedora version is released, all the bugs entered against rawhide
> are rebased against that version, except for those having the 'FutureFeature'
> keyword.
> 
> And for the tracker bugs, simply a redirection to the corresponding 
> Tracker (Blocker) Bugs section of HouseKeeping.
> --

I added a bullet about Trackers.  FutureFeature was already there.
https://fedoraproject.org/wiki/BugZappers/HouseKeeping#Rawhide_Bugs_Excluded_From_Rebase



From jamundso at gmail.com  Fri Dec  5 05:12:11 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Thu, 4 Dec 2008 23:12:11 -0600
Subject: Status of libtool 2.2.X?
In-Reply-To: <1228441833.26691.1784.camel@beck.corsepiu.local>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh5ls0$edm$1@ger.gmane.org> <200812031124.11838.opensource@till.name>
	<1228300274.20451.1893.camel@beck.corsepiu.local>
	<gh7g8d$uk1$1@ger.gmane.org>
	<1228375738.20451.3604.camel@beck.corsepiu.local>
	<gh9t13$grs$1@ger.gmane.org>
	<1228441833.26691.1784.camel@beck.corsepiu.local>
Message-ID: <6d06ce20812042112w428d8df6y8c79bd6e713130b2@mail.gmail.com>

At some point, somebody wrote:
> some stuff.

Come to a conclusion here. Please.

jerry

-- 
Store in cool, dry place. Rotate stock.



From pjones at redhat.com  Fri Dec  5 05:28:44 2008
From: pjones at redhat.com (Peter Jones)
Date: Fri, 05 Dec 2008 00:28:44 -0500
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <49385677.8090701@redhat.com>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
Message-ID: <4938BC0C.5070701@redhat.com>

Responding to the correct mailing list for this discussion.  Cc:ing the other one.

Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> John Dennis wrote:
>> I've had my fill of autotool problems (especially libtool)
> 
> Don't throw in libtool with the rest.  libtool was available in the
> spirit of the auto tools only in its very first version (which of those
> reading this only Jim and Tom will know).  Then came the windows and
> HP-SUX idiots and ruined it.  I've for the longest time said libtool
> should not be used (and I don't do it in my code).  In the worst case a
> simple Linux-only replacement for libtool should be used.

I agree that a Linux-only replacement for libtool should be used, if at all.  So 
why isn't there one available in Fedora that deps on "libtool" will pick by default?

-- 
   Peter



From behdad at behdad.org  Fri Dec  5 05:41:43 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Fri, 05 Dec 2008 00:41:43 -0500
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <4938BC0C.5070701@redhat.com>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com>
Message-ID: <4938BF17.4000909@behdad.org>

Peter Jones wrote:
> Responding to the correct mailing list for this discussion.  Cc:ing the
> other one.
> 
> Ulrich Drepper wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> John Dennis wrote:
>>> I've had my fill of autotool problems (especially libtool)
>>
>> Don't throw in libtool with the rest.  libtool was available in the
>> spirit of the auto tools only in its very first version (which of those
>> reading this only Jim and Tom will know).  Then came the windows and
>> HP-SUX idiots and ruined it.  I've for the longest time said libtool
>> should not be used (and I don't do it in my code).  In the worst case a
>> simple Linux-only replacement for libtool should be used.
> 
> I agree that a Linux-only replacement for libtool should be used, if at
> all.  So why isn't there one available in Fedora that deps on "libtool"
> will pick by default?

There's one, called dolt.  Problem is, packages ship with generated files so
they won't pick it up unless you want to do the 'autoconf; libtoolize;
automake; ...' at build time, which breaks more stuff than it fixes.  dolt is
not fully transparent.  One needs to add one line to configure.ac, but that
can be worked around if we wanted to.

behdad



From rc040203 at freenet.de  Fri Dec  5 05:52:25 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 05 Dec 2008 06:52:25 +0100
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <4938BC0C.5070701@redhat.com>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com>
Message-ID: <1228456345.26691.2083.camel@beck.corsepiu.local>

On Fri, 2008-12-05 at 00:28 -0500, Peter Jones wrote:
> Responding to the correct mailing list for this discussion.  Cc:ing the other one.
> 
> Ulrich Drepper wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > John Dennis wrote:
> >> I've had my fill of autotool problems (especially libtool)
> > 
> > Don't throw in libtool with the rest.  libtool was available in the
> > spirit of the auto tools only in its very first version (which of those
> > reading this only Jim and Tom will know).

Right, ... and libtool-2 is a completely different beast once again. 

Future will tell if it improves or worsens the situation. 
It definitely cleans up part of the mess older libtools suffered from.

> I agree that a Linux-only replacement for libtool should be used, if at all.  So 
> why isn't there one available in Fedora that deps on "libtool" will pick by default?

Such a tool would widely contradict libtools purposes (portability). 

I.e. such a tool will only help "linux-only packages" and package for
which portability to other OS is of minor interest (such as glibc).

Ralf









From rc040203 at freenet.de  Fri Dec  5 05:54:39 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 05 Dec 2008 06:54:39 +0100
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <4938BF17.4000909@behdad.org>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com>  <4938BF17.4000909@behdad.org>
Message-ID: <1228456479.26691.2085.camel@beck.corsepiu.local>

On Fri, 2008-12-05 at 00:41 -0500, Behdad Esfahbod wrote:
> Peter Jones wrote:
> > Responding to the correct mailing list for this discussion.  Cc:ing the
> > other one.
> > 
> > Ulrich Drepper wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> John Dennis wrote:
> >>> I've had my fill of autotool problems (especially libtool)
> >>
> >> Don't throw in libtool with the rest.  libtool was available in the
> >> spirit of the auto tools only in its very first version (which of those
> >> reading this only Jim and Tom will know).  Then came the windows and
> >> HP-SUX idiots and ruined it.  I've for the longest time said libtool
> >> should not be used (and I don't do it in my code).  In the worst case a
> >> simple Linux-only replacement for libtool should be used.
> > 
> > I agree that a Linux-only replacement for libtool should be used, if at
> > all.  So why isn't there one available in Fedora that deps on "libtool"
> > will pick by default?
> 
> There's one, called dolt.  Problem is, packages ship with generated files so
> they won't pick it up unless you want to do the 'autoconf; libtoolize;
> automake; ...' 
=> It's an alternative to developers, not an alternative "at
build-time".

> at build time, which breaks more stuff than it fixes.  dolt is
> not fully transparent.  One needs to add one line to configure.ac, but that
> can be worked around if we wanted to.





From pertusus at free.fr  Fri Dec  5 08:41:29 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 09:41:29 +0100
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <4938B03A.9010209@redhat.com>
References: <20081116160839.GC2933@free.fr>
	<da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
	<20081118191939.GB2610@free.fr>
	<20081123151541.5332b42c@ohm.scrye.com>
	<981da310811231519i58b2f9b8t68c31ab769aff8d1@mail.gmail.com>
	<20081126144415.GC2780@free.fr> <4938B03A.9010209@redhat.com>
Message-ID: <20081205084129.GA2699@free.fr>

On Thu, Dec 04, 2008 at 08:38:18PM -0800, John Poelstra wrote:
>
> I added a bullet about Trackers.  FutureFeature was already there.
> https://fedoraproject.org/wiki/BugZappers/HouseKeeping#Rawhide_Bugs_Excluded_From_Rebase

That was not my point. My point is that these are Policy,, and should be
linked from th ePolicy section. Otherwise packagers who are not invloved
in bug triaging will never know about it (well they'll know because it
hits them, but they won't knwo that it is a policy).

--
Pat



From berrange at redhat.com  Fri Dec  5 09:25:41 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 5 Dec 2008 09:25:41 +0000
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <4938BC0C.5070701@redhat.com>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com>
Message-ID: <20081205092541.GA24974@redhat.com>

On Fri, Dec 05, 2008 at 12:28:44AM -0500, Peter Jones wrote:
> Ulrich Drepper wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >John Dennis wrote:
> >>I've had my fill of autotool problems (especially libtool)
> >
> >Don't throw in libtool with the rest.  libtool was available in the
> >spirit of the auto tools only in its very first version (which of those
> >reading this only Jim and Tom will know).  Then came the windows and
> >HP-SUX idiots and ruined it.  I've for the longest time said libtool
> >should not be used (and I don't do it in my code).  In the worst case a
> >simple Linux-only replacement for libtool should be used.
> 
> I agree that a Linux-only replacement for libtool should be used, if at 
> all.  So why isn't there one available in Fedora that deps on "libtool" 
> will pick by default?

A Linux only replacement is of minimal interest to large majority of
libs in Fedora which are portable across multiple OS. Very few libs
are  truely Linux only

Daniel
-- 
|: Red Hat, Engineering, London   -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 kzak at redhat.com  Fri Dec  5 09:53:29 2008
From: kzak at redhat.com (Karel Zak)
Date: Fri, 5 Dec 2008 10:53:29 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <gh9f75$28a$1@ger.gmane.org>
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh7ggq$uk1$2@ger.gmane.org> <49380E63.9010801@gmail.com>
	<gh9f75$28a$1@ger.gmane.org>
Message-ID: <20081205095329.GA2971@nb.net.home>

On Thu, Dec 04, 2008 at 02:40:05PM -0600, Matthew Woehlke wrote:
> needing only CMake vs. needing sh, sed, awk, etc is fewer dependencies.

 "The Right Tool For The Job" ... autotools use already implemented
 tools (POSIX sed, awk, sh, ..) rather than duplicate functionality &
 code. The dependences are price that we pay for this excellent UNIX
 idea.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From pertusus at free.fr  Fri Dec  5 09:53:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 10:53:34 +0100
Subject: starting a service if a subpackage is installed
Message-ID: <20081205095334.GB17710@free.fr>

Hello,

I'd like to have a way to start fcron automatically, but only if a
subpackage is installed. I have (locally) implemented the following:

The initscripts are started automatically, but they do:

 [ -e /etc/sysconfig/fcron ] && . /etc/sysconfig/fcron
 case "$1" in
  start)
        if [ "z$FCROND_STARTUP" = 'z' ]; then
           exit 6
        fi

So if $FCROND_STARTUP is not set they won't start. Then I have package
that only contains /etc/sysconfig/fcron, called fcron-startup, with, in
/etc/sysconfig/fcron:

FCROND_STARTUP=1


This seemed like a good idea to me, however when there is no
/etc/sysconfig/fcron, /etc/init.d/fcron start is just silent.

Another possibility would be to put the initscripts in a separate
package and have them started automatically, but I preferred having them
in the main package but switched on and off.


Thoughts?

--
Pat



From peter at thecodergeek.com  Fri Dec  5 10:21:31 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Fri, 05 Dec 2008 02:21:31 -0800
Subject: License Addition: Deluge (CC-BY-SA Tango images)
Message-ID: <1228472491.9341.370.camel@localhost.localdomain>

Hi, all.

I just committed a version bump to the devel branch for Deluge 1.0.6
(with an F-10 sync on my TODO list for tomorrow) which includes some
images from the Tango project in the directory
"deluge/ui/webui/static/images/tango" of the unpacked tarball. (These
are installed to their final destination of the same directory tree
under %python_sitearch during the build process.) These images are under
the Creative Commons Attribution Share-Alike license, version 2.5.

The rest of the package is unchanged in terms of licensing; this is
merely an *addition* to the licenses for its data.

Please feel free to yell or scream, etc., if any issues arise because of
this. :)

Thanks and Regards.
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/abcecfc4/attachment.sig>

From rjones at redhat.com  Fri Dec  5 10:25:22 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 5 Dec 2008 10:25:22 +0000
Subject: ANNOUNCE: New smock supports Koji chain building
Message-ID: <20081205102522.GA18476@thinkpad>


I've just modified smock so that it can be used to work out a build
order suitable for chain building (in Koji), with maximum parallelism.
Just use smock in the normal way, but add the '--chain' option.

For example:

  smock.pl --arch=i386 --distro=fedora-10 --chain ocaml*/devel/*.src.rpm

prints ...

  make chain-build CHAIN="ocaml : ocaml-perl4caml ocaml-lablgl ocaml-findlib ocaml-cryptokit ocaml-camlp5 ocaml-camlidl : ocaml-lablgtk ocaml-SDL ocamldsort ocaml-zip ocaml-xml-light ocaml-ulex ocaml-type-conv ocaml-ssl ocaml-sqlite ocaml-res ocaml-postgresql ocaml-pcre ocaml-pa-monad ocaml-ounit ocaml-openin ocaml-omake ocaml-ocamlgraph ocaml-mysql ocaml-libvirt ocaml-lacaml ocaml-json-static ocaml-gsl ocaml-fileutils ocaml-facile ocaml-extlib ocaml-expat ocaml-deriving ocaml-dbus ocaml-curses ocaml-curl ocaml-camomile ocaml-calendar ocaml-bitstring ocaml-bisect ocaml-augeas ocaml-newt : ocaml-camlimages ocaml-cairo ocaml-sexplib ocaml-lwt ocaml-ocamlnet ocaml-mikmatch ocaml-cmigrep ocaml-reins ocaml-csv ocaml-gettext : ocaml-xmlrpc-light ocaml-pxp ocaml-json-wheel ocaml-pgocaml "

To get the latest version of smock, do:

  hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel

and it is in the smock/ subdirectory.

Rich.



From rjones at redhat.com  Fri Dec  5 10:29:03 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 5 Dec 2008 10:29:03 +0000
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <4938BC0C.5070701@redhat.com>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com>
Message-ID: <20081205102903.GB18476@thinkpad>

On Fri, Dec 05, 2008 at 12:28:44AM -0500, Peter Jones wrote:
> Responding to the correct mailing list for this discussion.  Cc:ing the other one.
>
> Ulrich Drepper wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> John Dennis wrote:
>>> I've had my fill of autotool problems (especially libtool)
>>
>> Don't throw in libtool with the rest.  libtool was available in the
>> spirit of the auto tools only in its very first version (which of those
>> reading this only Jim and Tom will know).  Then came the windows and
>> HP-SUX idiots and ruined it.  I've for the longest time said libtool
>> should not be used (and I don't do it in my code).  In the worst case a
>> simple Linux-only replacement for libtool should be used.
>
> I agree that a Linux-only replacement for libtool should be used, if at 
> all.  So why isn't there one available in Fedora that deps on "libtool" 
> will pick by default?

No one has explained yet how these packages that don't use libtool
will work when cross-compiling to Windows (or on HP-SUX / all the
other platforms that have different ways to make shared libraries).

Really: use libtool, it helps.

Rich.



From atkac at redhat.com  Fri Dec  5 11:13:13 2008
From: atkac at redhat.com (Adam Tkac)
Date: Fri, 5 Dec 2008 12:13:13 +0100
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <4938BC0C.5070701@redhat.com>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com>
Message-ID: <20081205111313.GA3036@evileye.atkac.englab.brq.redhat.com>

On Fri, Dec 05, 2008 at 12:28:44AM -0500, Peter Jones wrote:
> Responding to the correct mailing list for this discussion.  Cc:ing the other one.
>
> Ulrich Drepper wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> John Dennis wrote:
>>> I've had my fill of autotool problems (especially libtool)
>>
>> Don't throw in libtool with the rest.  libtool was available in the
>> spirit of the auto tools only in its very first version (which of those
>> reading this only Jim and Tom will know).  Then came the windows and
>> HP-SUX idiots and ruined it.  I've for the longest time said libtool
>> should not be used (and I don't do it in my code).  In the worst case a
>> simple Linux-only replacement for libtool should be used.
>

Could I ask you how are you building shared librares from one source
for multiple platforms? I need, for example, to compile and run shared
library on Linux, AIX, HP-UX and Solaris. Do you know what tool is
better than libtool?

Adam

-- 
Adam Tkac, Red Hat, Inc.



From nicu_fedora at nicubunu.ro  Fri Dec  5 11:17:14 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 05 Dec 2008 13:17:14 +0200
Subject: License Addition: Deluge (CC-BY-SA Tango images)
In-Reply-To: <1228472491.9341.370.camel@localhost.localdomain>
References: <1228472491.9341.370.camel@localhost.localdomain>
Message-ID: <49390DBA.4060604@nicubunu.ro>

Peter Gordon wrote:
> I just committed a version bump to the devel branch for Deluge 1.0.6
> (with an F-10 sync on my TODO list for tomorrow) which includes some
> images from the Tango project in the directory
> "deluge/ui/webui/static/images/tango" of the unpacked tarball. (These
> are installed to their final destination of the same directory tree
> under %python_sitearch during the build process.) These images are under
> the Creative Commons Attribution Share-Alike license, version 2.5.
> 
> The rest of the package is unchanged in terms of licensing; this is
> merely an *addition* to the licenses for its data.

I am surprised to learn the Tango people haven't managed to finish the 
move from CC-BY-SA to PD, as it was announced a long time ago:
http://lists.freedesktop.org/archives/tango-artists/2008-July/001821.html

-- 
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  Fri Dec  5 14:23:02 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri,  5 Dec 2008 14:23:02 +0000 (UTC)
Subject: rawhide report: 20081205 changes
Message-ID: <20081205142302.3E6C71F825E@releng2.fedora.phx.redhat.com>

Compose started at Fri Dec  5 06:01:06 UTC 2008

New package dfu-util
        USB Device Firmware Upgrade tool
New package globalplatform
        Library for access to OP 2.0.1 and GP 2.1.1 conforming smart cards
New package gpshell
        Manage applets on GlobalPlatform and OpenPlatform smart cards
New package kopete-cryptography
        Encrypts and signs messages in Kopete using the OpenPGP
New package libiphone
        Library for connecting to Apple iPhone and iPod touch
New package m4ri
        Linear Algebra over F_2
New package nocpulse-common
        NOCpulse common
New package robodoc
        Extract documentation from source code
New package vim-perl-support
        Perl-IDE for VIM
Removed package libdhcp
Updated Packages:

Ajaxterm-0.10-6.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10-6
- Rebuild for Python 2.6


Cython-0.10.2-2.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.2-2
- Rebuild for Python 2.6


Django-1.0-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-2
- Rebuild for Python 2.6


HippoDraw-1.21.1-6.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.21.1-6
- Rebuild for Python 2.6

* Sat Jun  7 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.21.1-5
- add sparc64 to multilib conditional


Io-language-20071010-7.fc11
---------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 20071010-7
- Rebuild for Python 2.6


Miro-1.2.8-1.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.2.8-1
- Update to latest upstream (1.2.8)
- Rebuild for Python 2.6


MySQL-python-1.2.2-8.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.2-8
- Rebuild for Python 2.6


OpenIPMI-2.0.14-7.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.14-7
- Rebuild for Python 2.6

* Thu Oct 30 18:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-6
- removed static libraries from the -devel subpackage
- fixed openipmigui.desktop file


PackageKit-0.3.11-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.11-2
- Rebuild for Python 2.6


PyAmanith-0.3.35-5.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.35-5
- Rebuild for Python 2.6


PyKDE-3.16.2-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.16.2-2
- Rebuild for Python 2.6


PyOpenGL-3.0.0-0.10.b6.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.0.0-0.9.b6
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.0.0-0.10.b6
- Fix locations for Python 2.6


PyQt-3.17.6-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.17.6-2
- Rebuild for Python 2.6


PyQt4-4.4.4-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.4.4-2
- Rebuild for Python 2.6


PyRTF-0.45-8.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.45-8
- Rebuild for Python 2.6


PySBIG-0.04-3.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.04-3
- Rebuild for Python 2.6


PySolFC-1.1-7.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-7
- Rebuild for Python 2.6


PyX-0.10-5.fc11
---------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10-5
- Rebuild for Python 2.6


PyXML-0.8.4-11
--------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.4-11
- Rebuild for Python 2.6


PyYAML-3.06-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.06-2
- Rebuild for Python 2.6


Pyrex-0.9.8.4-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0:0.9.8.4-2
- Rebuild for Python 2.6


PythonCAD-0.1.36-4.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.36-4
- Rebuild for Python 2.6


PythonCard-0.8.2-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.2-3
- Rebuild for Python 2.6

* Wed Oct 29 18:00:00 2008 Matt Domsch <mdomsch at fedoraproject.org> - 0.8.2-2
- use python_sitelib not sitearch (BZ#464959)
- don't package the build dir


R2spec-2.5.1-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.5.1-2
- Rebuild for Python 2.6


SOAPpy-0.11.6-8.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.6-8
- Rebuild for Python 2.6


TurboGears-1.0.7-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.7-3
- Rebuild for Python 2.6


VLGothic-fonts-20081203-1.fc11
------------------------------
* Thu Dec  4 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 20081203-1
- update to 20081203 release.
- clean up spec file.
- changed the priority prefix for fontconfig to 66 according to Fontconfig packaging tips.


adonthell-0.3.5-0.4.fc11
------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.5-0.4
- Rebuild for Python 2.6


alacarte-0.11.6-6.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.6-6
- Rebuild for Python 2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.11.6-5
- Tweak %summary and %description


aldrin-0.11-7.fc11
------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11-7
- Rebuild for Python 2.6


anaconda-11.4.1.58-2
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 11.4.1.58-2
- Rebuild for Python 2.6


ant-1.7.1-8.2.fc11
------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0:1.7.1-8.2
- Rebuild for Python 2.6


appliance-tools-004-2.fc11
--------------------------
* Mon Dec  1 17:00:00 2008 David Huff <dhuff at redhat.com> -004-2
- changed form ExclusiveArch to EcludeArch to fix broken deps

* Mon Dec  1 17:00:00 2008 David Huff <dhuff at redhat.com> - 004
- bumped version for rebuild for Python 2.6
- Allow the user to pass in --version and --release command line paramneters (bkearney)
- Patches to integrate ec2 conversion into the adk (bkeareny)
- Allow the appliance-creator to use remote urls with the new image tools (bkearney)


apt-0.5.15lorg3.94-5.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.15lorg3.94-5
- Rebuild for Python 2.6


aqbanking-3.7.2-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.7.2-2
- Rebuild for Python 2.6


archmage-0.1.9-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.9-4
- Rebuild for Python 2.6


at-spi-1.25.2-3.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.25.2-3
- Rebuild for Python 2.6


aubio-0.3.2-5.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.2-5
- Rebuild for Python 2.6


audio-convert-mod-3.45.4-2.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.45.4-2
- Rebuild for Python 2.6


audit-1.7.9-1.fc11.1
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.7.9-1.1
- Rebuild for Python 2.6


audit-viewer-0.4-2.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4-2
- Rebuild for Python 2.6


authconfig-5.4.5-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 5.4.5-2
- Rebuild for Python 2.6


autobuild-applet-1.0.3-8.fc11
-----------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.3-8
- Rebuild for Python 2.6


avahi-0.6.22-13.fc11
--------------------
* Wed Dec  3 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.22-13
- Fix libtool errors

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.22-12
- Rebuild for Python 2.6


avant-window-navigator-0.2.6-13.fc11
------------------------------------

babel-0.9.4-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.4-2
- Rebuild for Python 2.6


babl-0.0.22-2.fc11
------------------
* Tue Sep  2 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.0.22-2
- Include /usr/include/babl-0.0 directory


bash-3.2-30.fc11
----------------
* Thu Dec  4 17:00:00 2008 Roman Rakus <rrakus at redhat.com> - 3.2-30
- Added check for `command_not_found_handler' shell function
  Resolves: #432579


basket-1.0.3.1-4.fc11
---------------------
* Thu Dec  4 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.0.3.1-4
- fix ->F-10+ upgrade path
- Cannot configure basket, kcm_basket.la missing (#474425)
- drop needless Requires: hicolor-icon-theme

* Sat Nov 15 17:00:00 2008 Christopher D. Stover <quantumburnz at hotmail.com> 1.0.3.1-3
- resolved kontact broken dependency


bcel-5.2-5.1.fc11
-----------------
* Thu Dec  4 17:00:00 2008 Permaine Cheung <pcheung at redhat.com> 0:5.2-5.1
- Do not install poms in /usr/share/maven2/default_poms


bcfg2-0.9.6-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.6-2
- Rebuild for Python 2.6


bibus-1.4.3.1-1.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4.3-2
- Rebuild for Python 2.6

* Mon Dec  1 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.4.3.1-1
- Updating to new upstream (1.4.3.1)
- Adds support for OpenOffice 3.x
- Add patch to fix broken Makefile and desktop file
- Cleanup .spec


bitbake-1.8.10-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.8.10-2
- Rebuild for Python 2.6


bittorrent-4.4.0-8.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.4.0-8
- Rebuild for Python 2.6


blender-2.48a-5.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.48a-5
- Rebuild for Python 2.6


blogtk-1.1-10.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-10
- Rebuild for Python 2.6


bodhi-0.5.5-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.5-2
- Rebuild for Python 2.6


booty-0.107-2.fc11
------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.107-2
- Rebuild for Python 2.6


bpython-0.7.0-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.0-2
- Rebuild for Python 2.6


buildbot-0.7.7-3.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.7-3
- Rebuild for Python 2.6


bzr-1.9-2.fc11
--------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.9-2
- Rebuild for Python 2.6


bzrtools-1.9.1-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.9.1-2
- Rebuild for Python 2.6


catfish-0.3.2-1.fc11.1
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.2-1.1
- Rebuild for Python 2.6


ccsm-0.7.6-4.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.6-4
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.6-3
- Rebuild for Python 2.6


cel-1.2-5.fc11
--------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2-5
- Rebuild for Python 2.6


centerim-4.22.6-0.2.20080705git.fc11
------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:4.22.6-0.2.20080705git
- Rebuild for Python 2.6


chkconfig-1.3.40-1
------------------
* Fri Dec  5 17:00:00 2008 Bill Nottingham <notting at redhat.com> 1.3.40-1
- fix some overflows. (#176944)
- add --type parameter to specify either xinetd or sysv services.
  (#467863, <mschmidt at redhat.com>
- do a permissions check before add/remove/on/off/resetpriorities. (#450254)
- parse Short-Description correctly (#441813, <peter_e at gmx.net>)

* Thu Dec  4 17:00:00 2008 Bill Nottingham <notting at redhat.com> 1.3.39-1
- fail if dependencies fail on add/remove in LSB mode (#474223)


chm2pdf-0.9.1-5.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.1-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.1-4
- Rebuild for Python 2.6


cinepaint-0.22.1-9.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.22.1-9
- Rebuild for Python 2.6

* Thu Oct  9 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.22.1-8
- add sparc64 to the list of 64 bit arches for python site arch


clearsilver-0.10.5-5.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.5-5
- Rebuild for Python 2.6


clive-1.0.2-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.2-2
- Rebuild for Python 2.6

* Sun Nov  2 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> 1.0.2-1
- Rebuild for 1.0.2


cluster-2.99.12-2.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.99.12-2
- Rebuild for Python 2.6


codeina-0.10.1-10.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.1-10
- Rebuild for Python 2.6


comedilib-0.8.1-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.1-2
- Rebuild for Python 2.6


comix-4.0.0-1.fc11.1
--------------------

compiz-0.7.8-6.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.7.8-6
- Bugfixes from git head:
	compiz-0.7.8-decoration-placement.patch (RH #218561)
	compiz-0.7.8-fullscreen-top.patch
- Fall back to metacity if GLX_tfp is not present (RH #457816)
- Don't allow command line passed (config) plugins to be unloaded


compizconfig-python-0.7.8-2.fc11
--------------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.8-2
- Rebuild for Python 2.6


conduit-0.3.15-3.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.15-3
- Rebuild for Python 2.6


control-center-2.25.2-4.fc11
----------------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-4
- Update to 2.25.2

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-6
- Tweak %summary and %description


coriander-2.0.0-0.9.rc6.fc11
----------------------------
* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.0.0-0.9.rc6
- Include directory /usr/share/pixmaps/coriander


cracklib-2.8.13-2
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.8.13-2
- Rebuild for Python 2.6


createrepo-0.9.6-4.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.6-4
- Rebuild for Python 2.6


crossfire-1.11.0-2.fc11
-----------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.11.0-2
- Rebuild for Python 2.6


crystalspace-1.2.1-4.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.1-4
- Rebuild for Python 2.6


cvs2svn-2.1.1-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.1-2
- Rebuild for Python 2.6


cwiid-0.6.00-10.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.00-10
- Rebuild for Python 2.6


cycle-0.3.1-7.fc11
------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.1-7
- Rebuild for Python 2.6


d-feet-0.1.8-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.8-2
- Rebuild for Python 2.6


dblatex-0.2.9-3.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.9-3
- Rebuild for Python 2.6


dbus-glib-0.78-1.fc11
---------------------
* Thu Dec  4 17:00:00 2008 Colin Walters <walters at verbum.org> - 0.78-1
- New upstream release, drop upstreamed patches


dbus-python-0.83.0-4.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.83.0-4
- Rebuild for Python 2.6


dbxml-2.4.16-0.2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4.16-0.2
- Rebuild for Python 2.6


decibel-audio-player-0.11-2.fc11
--------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11-2
- Rebuild for Python 2.6


deluge-1.0.5-3.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.5-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.5-2
- Rebuild for Python 2.6


denyhosts-2.6-16.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.6-16
- Rebuild for Python 2.6

* Thu Nov 13 17:00:00 2008 Jason L Tibbitts III <tibbs at math.uh.edu> - 2.6-15
- Tweak default config file and add info to README.Fedora asking folks not to
  use sync and to report bugs upstream if they do.

* Fri Nov  7 17:00:00 2008 Jason L Tibbitts III <tibbs at math.uh.edu> - 2.6-14
- Add patch from upstream to fix command line --sync.


deskbar-applet-2.25.1-5.fc11
----------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.25.1-5
- Rebuild for Python 2.6


dhcp-4.0.0-32.fc11
------------------
* Wed Dec  3 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 12:4.0.0-32
- Enable LDAP/SSL support in dhcpd (#467740)
- Do not calculate a prefix for an address we did not receive (#473885)
- Removed libdhcp4client because libdhcp has been removed from Fedora

* Wed Oct 29 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 12:4.0.0-31
- Use O_CLOEXEC in open(2) calls and "e" mode in fopen(3) calls, build
  with -D_GNU_SOURCE so we pick up O_CLOEXEC (#468984)
- Add missing prototype for validate_port() in common/inet.c


dhcpv6-1.1.0-1.fc11
-------------------
* Thu Dec  4 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 1.1.0-1
- Upgrade to dhcpv6-1.1.0, changes include:
      Correct DUID time generation and save server DUID
      Match DUID LLT between client and server
      Do not let dhcp6c ignore IAID option in config file
      Use MAC address in DUID calculation
      In dhcp6s, do not SIGSEGV if link is not in config file
      Use <sys/queue.h> only if we have it
      Let dhcp6c get new address when moving links
      Removal of libdhcp6client since libdhcp has been removed


dia-0.96.1-9.fc11
-----------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:0.96.1-9
- Rebuild for Python 2.6

* Fri Oct 31 18:00:00 2008 Caol??n McNamara <caolanm at redhat.com> 1:0.96.1-8
- kill the ".la"s


dogtail-0.6.90-2.401.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.90-2.401
- Rebuild for Python 2.6


dot2tex-2.7.0-5.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.7.0-5
- Rebuild for Python 2.6


driconf-0.9.1-10.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.1-9
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.1-10
- Fix locations for Python 2.6


drpython-3.11.0-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:3.11.0-3
- Rebuild for Python 2.6


dstat-0.6.9-2.fc11
------------------
* Thu Dec  4 17:00:00 2008 Zdenek Prikryl <zprikryl at redhat.com> - 0.6.9-1
- Updated to 0.6.9
- Fixed dbus module patch again

* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.9-2
- Rebuild for Python 2.6

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.8-2
- Rebuild for Python 2.6


edsadmin-1.0-4.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-4
- Rebuild for Python 2.6


ekg-1.8-0.2.rc1.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.8-0.2.rc1
- Rebuild for Python 2.6


ekg2-0.2-0.5.rc1.fc11
---------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-0.5.rc1
- Rebuild for Python 2.6


emacs-22.3-2.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:22.3-2
- Rebuild for Python 2.6


emesene-1.0.1-4.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1-4
- Rebuild for Python 2.6


empathy-2.24.1-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.24.1-4
- Rebuild for Python 2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-2
- Tweak %description

* Thu Nov 20 17:00:00 2008 Peter Gordon <peter at thecodergeek.com>
- Fix Source0 URL.


enemies-of-carlotta-1.2.4-3.fc11
--------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.4-3
- Rebuild for Python 2.6

* Fri Aug 24 18:00:00 2007 Ralf Ertzinger <ralf at skytale.net> 1.2.4-2
- Clarify License: tag


epiphany-2.24.1-5.fc11
----------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.24.1-5
- Rebuild for Python 2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-4
- Tweak description


epydoc-3.0.1-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.0.1-2
- Rebuild for Python 2.6


epylog-1.0.3-8.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.3-8
- Rebuild for Python 2.6


eric-4.2.3-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.2.3-2
- Rebuild for Python 2.6


esc-1.0.1-12.fc11
-----------------
* Sat Nov  8 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.0.1-12
- Include lots of missing directories (#233833) and mark
  recursively included directories in files list with a trailing slash.


ettercap-0.7.3-27.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.7.3-27
- rebuild for dependencies


evolution-2.25.2-1.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.2-1.fc11
- Update to 2.25.2
- Bump eds_version to 2.25.2.


evolution-data-server-2.25.2-2.fc11
-----------------------------------
* Thu Dec  4 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25-2-2.fc11
- Rebuild due to recent pkg-config breakage.


exaile-0.2.14-2.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.14-2
- Rebuild for Python 2.6


exim-4.69-8.fc11
----------------
* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 4.69-8
- Include unowned directories.


exo-0.3.4-4.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.4-4
- Rebuild for Python 2.6


expendable-0.0.7-2.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.7-2
- Rebuild for Python 2.6


f-spot-0.5.0.3-5.fc11
---------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.5.0.3-5
- Update to 0.5.0.3

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.4.4-8
- Better URL
- Tweak %description

* Tue Oct 28 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com.com> - 0.4.4-7
- Run desktop-file-validate against desktop files


fail2ban-0.8.3-17.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.3-17
- Rebuild for Python 2.6


fedora-business-cards-0.2.2-2.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-2
- Rebuild for Python 2.6


fftw-3.2-1.fc11
---------------
* Thu Dec  4 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 3.2-1
- Bump to 3.2.


file-4.26-6.fc11
----------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.26-6
- Rebuild for Python 2.6

* Thu Dec  4 17:00:00 2008 Daniel Novotny <dnovotny at redhat.com> - 4.26-5
- fix #470811 - Spurious perl auto-requires

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.26-4
- Rebuild for Python 2.6


filezilla-3.1.6-1.fc11
----------------------
* Thu Dec  4 17:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.6-1
- Update to 3.1.6


firmware-addon-dell-1.4.8-2.fc11.1
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4.8-2.1
- Rebuild for Python 2.6


firmware-tools-1.5.6-2.fc11.1
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.6-2.1
- Rebuild for Python 2.6


firstaidkit-0.2.2-5.fc11
------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-5
- Rebuild for Python 2.6


firstboot-1.103-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.103-2
- Rebuild for Python 2.6

* Tue Nov  4 17:00:00 2008 Chris Lumens <clumens at redhat.com> 1.103-1
- Try another way of waiting for X to terminate (#469501).


flagpoll-0.9.1-3.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.1-3
- Rebuild for Python 2.6


flumotion-0.4.2-7.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.2-7
- Rebuild for Python 2.6

* Sun Nov 23 17:00:00 2008 Thomas Vander Stichele <thomas at apestaart dot org>
- 0.4.2-6
- updated summary and description
- not rebuilt yet


fluxstyle-1.0.1-6.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1-6
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1-5
- Rebuild for Python 2.6


fontforge-20080927-2.fc11
-------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 20080927-2
- Rebuild for Python 2.6


fonttools-2.2-3.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2-2
- Rebuild for Python 2.6


fontypython-0.3.6-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.6-2
- Rebuild for Python 2.6


foobillard-3.0a-9
-----------------
* Thu Dec  4 17:00:00 2008 Miloslav Trma?? <mitr at volny.cz> - 3.0a-9
- Use a more specific dejavu-fonts requirement
  Resolves: #473554


foomatic-3.0.2-68.fc11
----------------------
* Wed Dec  3 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 3.0.2-68
- Updated db-hpijs to 20081124.
- Updated db to 20081124.
- Updated filters to 3.0-20081124.
- Updated db-engine to 3.0-20081124.
- Better build root.
- Fixed summary.


freeciv-2.1.8-1.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 2.1.8-1
- Update to 2.1.8.


fuse-gmailfs-0.8.0-2.fc11
-------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.0-2
- Rebuild for Python 2.6


fuse-python-0.2-9.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-9
- Rebuild for Python 2.6


fusion-icon-0.1.0-0.5.5e2dc9git.fc11
------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.0-0.5.5e2dc9git
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.0-0.4.5e2dc9git
- Rebuild for Python 2.6


fwbackups-1.43.2-4.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.43.2-4
- Rebuild for Python 2.6


fwfstab-0.03-3.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.03-3
- Rebuild for Python 2.6


gajim-0.11.4-7.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.4-7
- Rebuild for Python 2.6


galternatives-0.13.4-6.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.13.4-6
- Rebuild for Python 2.6


gamin-0.1.10-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.10-2
- Rebuild for Python 2.6


garmin-sync-0.3-2.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-2
- Rebuild for Python 2.6


gazpacho-0.7.2-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.2-4
- Rebuild for Python 2.6


gcompris-8.4.8-2.fc11
---------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 8.4.8-2
- Rebuild for Python 2.6


gdeskcal-1.01-3.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.01-3
- Rebuild for Python 2.6


gdesklets-goodweather-0.31-2.fc11
---------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.31-2
- Rebuild for Python 2.6


gdevilspie-0.31-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.31-3
- Rebuild for Python 2.6


gdm-2.25.1-2.fc11
-----------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1:2.25.1-2
- Update to 2.25.1


gedit-2.25.2-2.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com>
- Update to 2.25.2

* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com>
- Rebuild for Python 2.6

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:2.24.1-4
- Rebuild for Python 2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.1-3
- Better URL

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.1-2
- Improve %summmary and %description


geos-3.0.1-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.0.1-2
- Rebuild for Python 2.6


gerbv-2.1.0-3.fc11
------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.1.0-3
- Include unowned headers directory.


getmail-4.8.4-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.8.4-2
- Rebuild for Python 2.6


gfeed-2.5.0-4.fc11
------------------
* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.5.0-4
- Include /usr/share/gfeed


gflags-0.9-7.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9-7
- Rebuild for Python 2.6


gimp-2.6.3-3.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2:2.6.3-3
- Rebuild for Python 2.6


gitosis-0.2-7.20080825git.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-7.20080825git
- Rebuild for Python 2.6


gjots2-2.3.8-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.3.8-2
- Rebuild for Python 2.6


glump-0.9.11-5.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.11-5
- Rebuild for Python 2.6


gmime-2.4.3-2.fc11
------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.4.3-2
- Update to 2.4.3

* Fri Oct 24 18:00:00 2008 Xavier Lamien <lxtnow at gmail.com> - 2.2.23-2
- Fix Strong name check.

* Mon Sep 15 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.2.23-1
- Update to 2.2.23
- Drop static libraries from -devel


gnofract4d-3.9-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.9-2
- Rebuild for Python 2.6


gnome-applet-jalali-calendar-1.6.5-4.fc11
-----------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.5-4
- Rebuild for Python 2.6


gnome-applet-music-2.4.2-2.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4.2-2
- Rebuild for Python 2.6


gnome-applet-timer-2.0.1-6.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.1-6
- Rebuild for Python 2.6

* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 2.0.1-5
- include %_libdir/timer-applet directory


gnome-applets-2.25.1-4.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:2.25.1-4
- Rebuild for Python 2.6

* Sat Nov 22 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.1-4
- Improve description


gnome-commander-1.2.8-0.1.svn2330_trunk.fc11.1
----------------------------------------------

gnome-desktop-2.25.2-3.fc11
---------------------------
* Thu Dec  4 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-3
- Rebase fade-in patch to latest from upstream report

* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-2
- Update to 2.25.2


gnome-doc-utils-0.14.0-4.fc11
-----------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.14.0-4
- Rebuild for Python 2.6


gnome-games-2.25.2-2.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.2-2
- Rebuild for Python 2.6


gnome-hearts-0.3-2.fc11
-----------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-2
- Rebuild for Python 2.6


gnome-lirc-properties-0.3.1-2.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.1-2
- Rebuild for Python 2.6


gnome-menus-2.25.2-3.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.25.2-3
- Rebuild for Python 2.6


gnome-python2-2.22.3-2.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.22.3-2
- Rebuild for Python 2.6


gnome-python2-desktop-2.24.0-5.fc11
-----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.24.0-5
- Rebuild for Python 2.6


gnome-python2-extras-2.19.1-25.fc11
-----------------------------------
* Wed Dec  3 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.19.1-25
- Fudge the gecko versioning

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.19.1-24
- Rebuild for Python 2.6


gnome-schedule-2.0.2-2.fc11
---------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.2-2
- Rebuild for Python 2.6


gnome-screensaver-2.25.1-2.fc11
-------------------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-2
- Update to 2.25.1


gnome-session-2.25.2-2.fc11
---------------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.2-2
- Update to 2.25.2

* Tue Nov 25 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-5
- Spec file cleanups


gnome-specimen-0.3-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-3
- Rebuild for Python 2.6


gnomecatalog-0.3.4-4.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.4-4
- Rebuild for Python 2.6


gnubg-0.9.0.1-2.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:0.9.0.1-2
- Rebuild for Python 2.6


gnue-common-0.6.9-5.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.9-5
- Rebuild for Python 2.6


gnuradio-3.1.2-3.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.1.2-3
- Rebuild for Python 2.6


gnutls-2.6.2-1.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> 2.6.2-1
- upgrade to a new upstream version


gourmet-0.13.4-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.13.4-4
- Rebuild for Python 2.6


gpixpod-0.6.2-4.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.2-4
- Rebuild for Python 2.6


gpodder-0.13.1-2.1.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> - 0.13.1-2.1
- Source Fix

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.13.1-2
- Rebuild for Python 2.6

* Wed Nov 12 17:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> 0.13.1-1
- Update to 0.13.1


gpsd-2.37-3.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.37-3
- Rebuild for Python 2.6


gquilt-0.20-4.fc11
------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.20-4
- Rebuild for Python 2.6


gramps-3.0.3-1.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.0.3-1
- Rebuild for Python 2.6


grass-6.3.0-7.fc11
------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 6.3.0-7
- Rebuild for Python 2.6


gresistor-0.0.1-14.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.1-14
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.1-13
- Rebuild for Python 2.6


gst-inspector-0.3-6.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-6
- Rebuild for Python 2.6


gstreamer-python-0.10.12-2.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.12-2
- Rebuild for Python 2.6


gtk-recordmydesktop-0.3.7.2-3.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.7.2-3
- Rebuild for Python 2.6


gtk-vnc-0.3.7-4.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.7-4
- Rebuild for Python 2.6


gtkglextmm-1.2.0-8.fc11
-----------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.2.0-8
- Include unowned doc directories in -devel pkg.
- post/postun: execute ldconfig directly


gtkpod-0.99.12-4.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.99.12-4
- Rebuild for Python 2.6


guake-0.3.1-5.fc11
------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.1-5
- Rebuild for Python 2.6


gwibber-0.7.1-2.134bzr.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.1-2.134bzr
- Rebuild for Python 2.6


halberd-0.2.2-4.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-4
- Rebuild for Python 2.6


hamlib-1.2.7-3.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.7-3
- Rebuild for Python 2.6


heartbeat-2.1.4-2.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.4-2
- Rebuild for Python 2.6


hellanzb-0.13-7.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.13-7
- Rebuild for Python 2.6


hgsvn-0.1.6-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.6-2
- Rebuild for Python 2.6


hippo-canvas-0.3.0-4.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.0-4
- Rebuild for Python 2.6


honeyd-1.5c-6.fc11
------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5c-6
- Rebuild for Python 2.6


hotssh-0.2.5-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.5-2
- Rebuild for Python 2.6


hotwire-0.721-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.721-2
- Rebuild for Python 2.6


hplip-2.8.7-4.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.8.7-4
- Rebuild for Python 2.6


ht2html-2.0-8.fc11
------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0-8
- Rebuild for Python 2.6


hwbrowser-0.42-2.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.42-2
- Rebuild for Python 2.6


ibus-0.1.1.20081023-3.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1.20081023-3
- Rebuild for Python 2.6


ibus-anthy-0.1.1.20080912-2.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1.20080912-2
- Rebuild for Python 2.6


ibus-chewing-0.1.1.20081023-2.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1.20081023-2
- Rebuild for Python 2.6


ibus-hangul-0.1.1.20081023-2.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1.20081023-2
- Rebuild for Python 2.6


ibus-m17n-0.1.1.20081013-4.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1.20081013-4
- Rebuild for Python 2.6


ibus-pinyin-0.1.1.20081004-2.fc11
---------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1.20081004-2
- Rebuild for Python 2.6


ibus-table-0.1.1.20081014-3.fc11
--------------------------------

ice-3.3.0-9.fc11
----------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.3.0-9
- Rebuild for Python 2.6

* Thu Dec  4 17:00:00 2008 <mefoster at gmail.com> - 3.3.0-8
- Add all accumulated upstream patches

* Thu Dec  4 17:00:00 2008 <mefoster at gmail.com> - 3.3.0-7
- (Tiny) patch to support Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.3.0-6
- Rebuild for Python 2.6


ikiwiki-2.70-2.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.70-2
- Rebuild for Python 2.6


inkscape-0.46-8.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.46-8
- Rebuild for Python 2.6


inn-2.4.5-6.fc11
----------------

iotop-0.2.1-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-2
- Rebuild for Python 2.6


iproute-2.6.27-1.fc11
---------------------
* Thu Dec  4 17:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> - 2.6.27-1
- aead support was included into upstream version
- patch for moving libs is now deprecated
- update to 2.6.27


ipython-0.9.1-2.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.1-2
- Rebuild for Python 2.6


isomd5sum-1.0.4-4.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:1.0.4-4
- Rebuild for Python 2.6


istanbul-0.2.2-8.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-8
- Rebuild for Python 2.6


itaka-0.2.1-4.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-4
- Rebuild for Python 2.6


jabberpy-0.5-0.18.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-0.18
- Rebuild for Python 2.6


jabbim-0.4.3-4.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.3-4
- Rebuild for Python 2.6


java-1.5.0-gcj-1.5.0.0-24.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.0.0-24
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.0.0-23
- Rebuild for Python 2.6


jbrout-0.2.201-3.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.201-3
- Rebuild for Python 2.6


jokosher-1.0-0.4.20081012svn.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-0.4.20081012svn
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-0.3.20081012svn
- Rebuild for Python 2.6


jython-2.2.1-2.1.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2.1-2.1
- Rebuild for Python 2.6

* Thu Jul 31 18:00:00 2008 Andrew Overholt <overholt at redhat.com> 2.2.1-1.1
- Fix version since we're on 2.2.1 final


k3d-0.6.7.0-8.fc11
------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.7.0-8
- Rebuild for Python 2.6


kchmviewer-4.0-1.fc11
---------------------
* Thu Dec  4 17:00:00 2008 Patrice Dumas <pertusus at free.fr> 4.0-1
- update to 4.0


kde-filesystem-4-22.fc11
------------------------
* Thu Dec  4 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4-22
- (re)add -DCMAKE_SKIP_RPATH:BOOL=ON


kdeaccessibility-4.1.80-4.fc11
------------------------------
* Thu Dec  4 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.or> 4.1.80-3
- drop (Build)Requires: kdebase-workspace(-devel)
- BR: plasma-devel
- better, versioned Obsoletes: kdeaccessibility-devel ...

* Thu Dec  4 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-4
- rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)


kdeadmin-4.1.80-4.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.80-3
- drop Requires: kdebase-workspace

* Thu Dec  4 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-4
- rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)


kdeartwork-4.1.80-3.fc11
------------------------

kdebase-workspace-4.1.80-12.fc11
--------------------------------
* Fri Dec  5 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-12
- move libplasma_applet-system-monitor.so from -devel to -libs (not a symlink)

* Fri Dec  5 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-11
- drop devel symlink (parallel -devel) hacks, not needed anymore in this package


kdebindings-4.1.80-5.fc11
-------------------------

kdeedu-4.1.80-9.fc11
--------------------
* Fri Dec  5 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-9
- rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)

* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.1.80-8
- Rebuild for Python 2.6


kdegames-4.1.80-4.fc11
----------------------
* Fri Dec  5 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 6:4.1.80-4
- rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)

* Thu Dec  4 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 6:4.1.80-3
- add missing BR qca2-devel (for ksirk)
- add killbots, kapman and bomber to the description

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> 6:4.1.80-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast
- drop _default_patch_fuzz 2


kdelibs3-3.5.10-2.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 3.5.10-2
- omit libkscreensaver (F9+)


kdenetwork-4.1.80-6.fc11
------------------------
* Thu Dec  4 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 7:4.1.80-6
- rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)

* Thu Dec  4 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 7:4.1.80-5
- add missing BR meanwhile-devel (#474592)
- add missing BR ortp-devel and speex-devel (for Jingle protocol)


kdetoys-4.1.80-4.fc11
---------------------
* Thu Dec  4 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-4
- clean up BRs
- fix file list

* Tue Nov 25 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-3
- remove kworldclock from description (dropped in 4.2, replaced by a plasmoid
  using marble, which is part of kdeedu)
- remove bogus BR qimageblitz-devel (was already unneeded in 4.1)

* Thu Nov 20 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- merged

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 7:4.1.72-1
- 4.1.80
- BR cmake >= 2.6.2
- make install/fast


kdeutils-4.1.80-4.fc11
----------------------

kdevelop-3.5.3-2.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 9:3.5.3-2
- Rebuild for Python 2.6


kernel-2.6.28-0.110.rc7.git3.fc11
---------------------------------
* Thu Dec  4 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
- linux-2.6-utrace.patch updates

* Thu Dec  4 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
- 2.6.28-rc7-git3

* Tue Dec  2 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc7-git1


kexec-tools-2.0.0-7.fc11
------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.0-7
- Rebuild for Python 2.6


kflickr-0.9.1-3.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.9.1-3
- Include unowned directories.


kgrab-0.1.1-12.fc11
-------------------
* Fri Dec  5 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1.1-12
- rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)

* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.1.1-11
- Include /usr/share/kde4/apps/kgrab directory.


kipi-plugins-0.2.0-0.7.beta4.fc11
---------------------------------
* Thu Dec  4 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.2.0-0.7.beta4
- rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)


kmobiletools-0.4.3.3-6.fc11
---------------------------
* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.4.3.3-6
- include /usr/share/apps/kmobiletools directory

* Wed May 21 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.4.3.3-5
- fix license tag


koan-1.2.6-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.6-2
- Rebuild for Python 2.6


kodos-2.4.9-6.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4.9-6
- Rebuild for Python 2.6


koffice-1.9.98.2-4.fc11
-----------------------
* Thu Dec  4 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 1:1.9.98.2-4
- Rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)


koji-1.2.6-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.6-2
- Rebuild for Python 2.6


kphotobymail-0.4.1-5.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.1-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.1-4
- Rebuild for Python 2.6


kudzu-1.2.85-2
--------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.85-2
- Rebuild for Python 2.6


labyrinth-0.4.0-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.0-3
- Rebuild for Python 2.6

* Thu Nov 20 17:00:00 2008 Peter Gordon <peter at thecodergeek.com>
- Fix Source0 URL.


lazarus-0.9.26-3.fc11
---------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.9.26-3
- Include /etc/lazarus directory.

* Wed Oct 29 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 0.9.26-2
- Fix path to the source tree


lcms-1.17-8.fc11
----------------
* Thu Dec  4 17:00:00 2008 kwizart < kwizart at gmail.com > - 1.17-8
- Fix autoreconf and missing auxiliary files.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.17-7
- Rebuild for Python 2.6


libbeagle-0.3.5-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.5-3
- Rebuild for Python 2.6

* Sun May  4 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.3.5-2
- Fix source url


libbtctl-0.10.0-9.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0.10.0-9
- Rebuld for Python 2.6


libconcord-0.20-6.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.20-6
- Rebuild for Python 2.6


libgpod-0.6.0-9.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-9
- Rebuild for Python 2.6

* Thu Oct  2 18:00:00 2008 Todd Zullinger <tmz at pobox.com> - 0.6.0-8
- The -devel package should require gtk2-devel as well
- Add gdk-pixbuf-2.0 to the pkg-config file requirements


libgsf-1.14.10-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.14.10-2
- Rebuild for Python 2.6


libhocr-0.10.17-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.17-2
- Rebuild for Python 2.6


libieee1284-0.2.11-4.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 0.2.11-4
- Rebuild for Python 2.6


libiptcdata-1.0.2-4.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.2-4
- Rebuild for Python 2.6

* Thu May 29 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.2-3
- fix license tag


liblicense-0.8-3
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8-3
- Rebuild for Python 2.6

* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.8-2
- Include unowned directories
- Add missing defattr to sub-packages


libpar2-0.2-7.fc11
------------------
* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.2-7
- Include %_libdir/libpar2 directory


libprelude-0.9.21.2-4.fc11
--------------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.9.21.2-4
- Include /usr/include/libpreludecpp directory.


libpreludedb-0.9.15.1-2.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.15.1-2
- Rebuild for Python 2.6


libpst-0.6.23-1.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Carl Byington <carl at five-ten-sg.com> - 0.6.23-1
- bump version to avoid cvs tagging mistake in fedora


librapi-0.11.1-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.1-2
- Rebuild for Python 2.6


librtfcomp-1.1-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-4
- Rebuild for Python 2.6


libscigraphica-2.1.1-9.fc11
---------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.1-9
- Rebuild for Python 2.6


libselinux-2.0.76-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.76-2
- Rebuild for Python 2.6


libsemanage-2.0.30-2.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.30-2
- Rebuild for Python 2.6

* Thu Dec  4 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 2.0.30-1
* Add semanage_mls_enabled() interface from Stephen Smalley.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.29-2
- Rebuild for Python 2.6


libsvm-2.88-3.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.88-3
- Rebuild for Python 2.6


libuser-0.56.9-2
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.56.9-2
- Rebuild for Python 2.6


libvirt-0.5.1-1.fc11
--------------------
* Fri Dec  5 17:00:00 2008 Daniel Veillard <veillard at redhat.com> - 0.5.1-1.fc11
- upstream release 0.5.1
- mostly bugfixes e.g #473071
- some driver improvments

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.0-2
- Rebuild for Python 2.6


libwfut-0.2.1-3.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-3
- Rebuild for Python 2.6


libxml2-2.7.2-7.fc11
--------------------

libxslt-1.1.24-3.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 1.1.24-3
- Rebuild for Python 2.6


lilypond-2.11.57-2.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.11.57-2
- Rebuild for Python 2.6


livecd-tools-019-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 019-2
- Rebuild for Python 2.6


liveusb-creator-3.0-3.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.0-3
- Rebuild for Python 2.6


londonlaw-0.2.1-5.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-4
- Rebuild for Python 2.6


luma-2.4-4.fc11
---------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4-4
- Rebuild for Python 2.6


lybniz-1.3.2-3.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.2-3
- Rebuild for Python 2.6


lyx-1.6.0-2.fc11
----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.0-2
- Rebuild for Python 2.6


m2crypto-0.19.1-3
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.19.1-3
- Rebuild for Python 2.6


magicor-1.1-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-2
- Rebuild for Python 2.6


mailman-2.1.11-5.fc11
---------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3:2.1.11-5
- Rebuild for Python 2.6

* Wed Oct 29 18:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 3:2.1.11-4
fix #460820 - msg_footer gets its trailing spaces trimmed


man-pages-cs-0.17.20080113-4.fc11
---------------------------------
* Thu Dec  4 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 0.17.20080113-4
- update another part of coreutils man-pages (patches are from Kamil Dudka)


mapserver-5.2.0-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 5.2.0-2
- Rebuild for Python 2.6


mash-0.4.2-4.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.2-4
- Rebuild for Python 2.6


maxima-5.17.0-1.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 5.17.0-1
- maxima-5.17.0


mc-4.6.2-8.pre1.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 4.6.2-8.pre1
- fix a couple of UTF-8 related display bugs (#464708),
  thanks to Rafa?? Mu??y??o


mediascrapper-0.1-4.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-4
- Rebuild for Python 2.6


meld-1.2.1-2.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.1-2
- Rebuild for Python 2.6


mercurial-1.1-2.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-2
- Rebuild for Python 2.6


metacity-2.25.34-1.fc11
-----------------------
* Wed Dec  3 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.34-1
- Update to 2.25.34


metakit-2.4.9.7-6.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4.9.7-6
- Rebuild for Python 2.6


metamonitor-0.4.5-6.fc11
------------------------
* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.4.5-6
- include unowned directories


mftrace-1.2.15-2.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.15-2
- Rebuild for Python 2.6


mirage-0.9.3-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.3-2
- Rebuild for Python 2.6


mirrormanager-1.2.6-2.fc11
--------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.6-2
- Rebuild for Python 2.6


mkinitrd-6.0.73-2.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Peter Jones <pjones at redhat.com> - 6.0.73-1
- Use scsi_wait_scan on scsi devices instead of stabilized (#470628)

* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 6.0.73-2
- Rebuild for Python 2.6

* Wed Dec  3 17:00:00 2008 Peter Jones <pjones at redhat.com> - 6.0.72-1
- loadDrivers before plytmouth --show-splash (wtogami)
- Ignore missing module groups specified in --with-avail (wtogami)
- Use libnl and dhclient instead of libdhcp (dcantrell)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 6.0.71-2
- Rebuild for Python 2.6


mock-0.9.13-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.13-2
- Rebuild for Python 2.6


mod_python-3.3.1-9
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.3.1-9
- Rebuild for Python 2.6


mod_wsgi-2.3-2.fc11
-------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.3-2
- Rebuild for Python 2.6

* Tue Oct 28 18:00:00 2008 Luke Macken <lmacken at redhat.com> 2.3-1
- Update to 2.3


moin-1.6.3-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.3-2
- Rebuild for Python 2.6


moin-latex-0-0.20051127.4.fc11
------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0-0.20051127.4
- Rebuild for Python 2.6

* Fri May 23 18:00:00 2008 Jon Stanley <jonstanley at gmail.com> - 0-0.20051126.4
- Fix license tag


monafont-2.90-5.fc11.2
----------------------
* Fri Dec  5 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rebuild for new VLGothic


mousetweaks-2.25.2-1.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2


museek+-0.2-0.1.20081126svn1027.fc11
------------------------------------
* Sun Nov 30 17:00:00 2008 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.2-0.1.20081126svn1027
- Updated to 0.2 SVN snapshot
- Split the package into several parts

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.13-4
- Rebuild for Python 2.6


mx-3.1.1-3.fc11
---------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.1.1-3
- Rebuild for Python 2.6


mypaint-0.5.1-3.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.1-3
- Rebuild for Python 2.6


nautilus-2.25.1-3.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.25.1-3
- Fix BuildRequires

* Thu Dec  4 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.25.1-2
- Rediff the XDS patch

* Tue Dec  2 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.25.1-1
- Update to 2.25.1

* Wed Nov 26 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.24.2-1
- Update to 2.24.2

* Fri Nov 21 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-5
- Better URL
- Tweak %description


ncl-5.0.0-14.fc11
-----------------
* Thu Dec  4 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 5.0.0-14
- Actually apply udunits patch

* Thu Nov 27 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 5.0.0-13
- Enable udunits support add use system udunits.dat


newt-0.52.10-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.52.10-2
- Rebuild for Python 2.6


nginx-0.6.33-2.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.6.33-2
- Fix inclusion of /usr/share/nginx tree => no unowned directories.


nmap-4.68-4.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2:4.68-4
- Rebuild for Python 2.6


notify-python-0.1.1-5.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1-5
- Rebuild for Python 2.6


nspr-4.7.3-3.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.7.3-3
- Rebuild for pkgconfig


ntfs-config-1.0.1-4.fc11
------------------------
* Fri Dec  5 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.0.1-4
- Patch to compile with Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1-3
- Rebuild for Python 2.6


numpy-1.2.0-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.0-2
- Rebuild for Python 2.6


nxt_python-0.7-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7-4
- Rebuild for Python 2.6


obexftp-0.23-0.3.alpha.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.23-0.3.alpha
- Rebuild for Python 2.6


obmenu-1.0-7.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-7
- Rebuild for Python 2.6


ocaml-3.11.0-1.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.11.0-1
- Official release of 3.11.0.

* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.11.0-0.6.rc1
- Fixed sources file.

* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.11.0-0.5.rc1
- New upstream version 3.11.0+rc1.


ocaml-SDL-0.7.2-16.fc11
-----------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.7.2-16
- Rebuild.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.7.2-15
- Rebuild for OCaml 3.11.0


ocaml-augeas-0.4-3.fc11
-----------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.4-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-bisect-1.0-0.3.alpha.fc11
-------------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0-0.3.alpha
- Rebuild for OCaml 3.11.0+rc1.


ocaml-bitstring-2.0.0-6.fc11
----------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.0.0-6
- Rebuild.


ocaml-cairo-1.2.0.cvs20080301-5.fc11
------------------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0.cvs20080301-5
- Rebuild.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0.cvs20080301-4
- Rebuild for OCaml 3.11.0


ocaml-calendar-2.0.4-3.fc11
---------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.0.4-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-camlidl-1.05-7.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.05-7
- Rebuild for OCaml 3.11.0 release.


ocaml-camlimages-3.0.1-4.fc11
-----------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.0.1-4
- Rebuild.

* Mon Nov  3 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.0.1-3
- +BR gtk2-devel.
- +BR ocaml-x11.

* Mon Nov  3 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.0.1-1
- Home page moved (fixes rhbz 468158).
- New upstream version 3.0.1 and multiple build fixes for this.
- License is really LGPLv2 with the OCaml linking exception.
- Removed the DESTDIR patch.
- Build tiff support.
- Run it through rpmlint and fix all problems.


ocaml-camlp5-5.10-2.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 5.10-2
- Rebuild for OCaml 3.11.0+rc1.


ocaml-camomile-0.7.1-9.fc11
---------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.7.1-9
- Rebuild for OCaml 3.11.0+rc1.


ocaml-cryptokit-1.3-7.fc11
--------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.3-7
- Rebuild for OCaml 3.11.0+rc1.


ocaml-csv-1.1.7-3.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1.7-3
- Rebuild.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1.7-2
- Rebuild for OCaml 3.11.0


ocaml-curl-0.5.0-3.fc11
-----------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.5.0-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-curses-1.0.3-3.fc11
-------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.3-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-dbus-0.07-3.fc11
----------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.07-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-expat-0.9.1-14.fc11
-------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9.1-14
- Rebuild for OCaml 3.11.0+rc1.


ocaml-extlib-1.5.1-5.fc11
-------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.5.1-5
- Rebuild for OCaml 3.11.0+rc1.


ocaml-facile-1.1-7.fc11
-----------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1-7
- Rebuild for OCaml 3.11.0+rc1.


ocaml-fileutils-0.3.0-8.fc11
----------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.3.0-8
- Rebuild for OCaml 3.11.0+rc1.


ocaml-findlib-1.2.3-5.fc11
--------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.3-5
- Change to camlp4/META means that this package really depends on
  the latest OCaml compiler.

* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.3-4
- camlp4/META: camlp4.lib should depend on dynlink.

* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.3-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-gsl-0.6.0-5.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.6.0-5
- Rebuild.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.6.0-4
- Rebuild for OCaml 3.11.0


ocaml-json-static-0.9.6-7.fc11
------------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9.6-7
- Rebuild for OCaml 3.11.0+rc1.


ocaml-lablgl-1.03-6.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.03-6
- Rebuild for OCaml 3.11.0+rc1.


ocaml-lablgtk-2.10.1-7.fc11
---------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.10.1-7
- Rebuild for OCaml 3.11.0+rc1.


ocaml-lacaml-4.6.8-2.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 4.6.8-2
- Rebuild.

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 4.6.8-1
- New upstream version 4.6.8.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 4.3.3-2
- Rebuild for OCaml 3.11.0


ocaml-libvirt-0.4.4.2-3.fc11
----------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.4.4.2-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-lwt-1.1.0-3.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1.0-3
- Rebuild.


ocaml-mysql-1.0.4-5.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.4-5
- Rebuild for OCaml 3.11.0+rc1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.4-4
- Rebuild for OCaml 3.11.0


ocaml-newt-0.9-4.fc11
---------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9-4
- Rebuild for OCaml 3.11.0+rc1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9-3
- Rebuild for OCaml 3.11.0


ocaml-openin-20070524-6.fc11
----------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 20070524-6
- Rebuild for OCaml 3.11.0+rc1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 20070524-5
- Rebuild for OCaml 3.11.0


ocaml-ounit-1.0.3-3.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.3-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-pcre-5.15.0-3.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 5.15.0-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-perl4caml-0.9.5-7.fc11
----------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9.5-7
- Rebuild for OCaml 3.11.0+rc1.


ocaml-postgresql-1.9.2-3.fc11
-----------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.9.2-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-res-3.0.0-2.fc11
----------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.0.0-2
- Rebuild for OCaml 3.11.0+rc1.


ocaml-sqlite-1.2.0-4.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0-4
- Rebuild for OCaml 3.11.0.

* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-ssl-0.4.2-12.fc11
-----------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.4.2-12
- Rebuild for OCaml 3.11.0+rc1.


ocaml-type-conv-1.6.4-3.fc11
----------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.6.4-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-ulex-1.1-5.fc11
---------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1-5
- Rebuild for OCaml 3.11.0+rc1.


ocaml-xml-light-2.2.cvs20070817-10.fc11
---------------------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.2.cvs20070817-10
- Rebuild for OCaml 3.11.0+rc1.


ocaml-zip-1.03-6.fc11
---------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.03-6
- Rebuild for OCaml 3.11.0+rc1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.03-5
- Rebuild for OCaml 3.11.0


ocamldsort-0.14.4-4.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.14.4-4
- Rebuild for OCaml 3.11.0+rc1.


ocfs2-tools-1.3.9-9.20080221git.fc11
------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.9-9.20080221git
- Rebuild for Python 2.6


oddjob-0.29.1-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.29.1-2
- Rebuild for Python 2.6


odfpy-0.8-2.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8-2
- Rebuild for Python 2.6


offlineimap-6.0.0-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 6.0.0-2
- Rebuild for Python 2.6


oggconvert-0.3.2-4.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.2-4
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.2-3
- Rebuild for Python 2.6


online-desktop-0.3.2-2.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.2-2
- Rebuild for Python 2.6


openbabel-2.2.0-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2.0-2
- Rebuild for Python 2.6


openlierox-0.57-0.11.beta8.fc11
-------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.57-0.11.beta8
- Rebuild for Python 2.6


openmsx-0.6.3-5.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.3-5
- Rebuild for Python 2.6


openser-1.3.3-3.fc11
--------------------

orca-2.25.2-2.fc11
------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-2
- Rebuild for Python 2.6


p0rn-comfort-0.0.4-6.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.0.4-6
- Rebuild to fix unowned directory (#233894).


pAgenda-3.2-3.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.2-3
- Rebuild for Python 2.6


paraview-3.4.0-2.fc11
---------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.4.0-2
- Rebuild for Python 2.6


pcapdiff-0.1-4.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-4
- Rebuild for Python 2.6


pcapy-0.10.5-4.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.5-4
- Rebuild for Python 2.6


perl-Module-Install-0.77-1.fc11
-------------------------------
* Thu Dec  4 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.77-1
- update to 0.77


pessulus-2.23.1-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.23.1-3
- Rebuild for Python 2.6


php-xmpphp-0.1-0.3.beta_r50.fc11
--------------------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.1-0.3.beta_r50
- Include unowned directories.


picard-0.10-3.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10-3
- Rebuild for Python 2.6


pida-0.5.1-8.fc11
-----------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.1-8
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.1-7
- Rebuild for Python 2.6


pigment-python-0.3.8-2.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.8-2
- Rebuild for Python 2.6


pitivi-0.11.2.2-2.fc11
----------------------
* Thu Dec  4 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.2.2-2
- Upload the sources

* Thu Dec  4 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.2.2-1
- Update to 0.11.2.2

* Sat Nov 29 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.2-2
- Rebuild for Python 2.6


plague-0.4.5.7-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.5.7-2
- Rebuild for Python 2.6

* Wed Nov  5 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.4.5.7-1
- update to 0.4.5.7 (Python 2.4 fix and optional POSIX lockfile support)


planet-2.0-7.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0-7
- Rebuild for Python 2.6


planner-0.14.3-8.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.14.3-8
- Rebuild for Python 2.6


pmpu-0.2-2.fc11
---------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-2
- Rebuild for Python 2.6


pnp4nagios-0.4.12-2.fc11
------------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.4.12-2
- Include /usr/libexec/pnp4nagios directory.


poker-engine-1.2.0-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.0-2
- Rebuild for Python 2.6


poker-network-1.6.0-3.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.0-3
- Rebuild for Python 2.6


poker2d-1.6.0-3.fc11.1
----------------------
* Tue Dec  2 17:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.6.0-3.1
- Release bump for dist-f11-python build


poker3d-1.1.36-13.fc11
----------------------
* Tue Dec  2 17:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.1.36-13
- Add python26 patch

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.36-12
- Rebuild for Python 2.6


policycoreutils-2.0.60-3.fc11
-----------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.60-3
- Rebuild for Python 2.6


postgresql-8.3.5-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 8.3.5-2
- Rebuild for Python 2.6


postgresql-ip4r-1.03-2.fc11
---------------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 1.03-2
- Include unowned doc directory.


postgresql-pgpool-II-2.1-2.fc11
-------------------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 2.1-2
- Include /usr/share/pgpool-II directory.


postr-0.12.2-3.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.12.2-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.12.2-2
- Rebuild for Python 2.6


prelude-notify-0.9-0.2.20080814svn10860.fc11
--------------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9-0.2.20080814svn10860
- Rebuild for Python 2.6


presto-0.1.3-5.fc11
-------------------
* Tue Sep  2 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.1.3-5
- Include unowned directories


preupgrade-1.0.0-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.0-2
- Rebuild for Python 2.6


printoxx-1.7-2.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.7-2
- Include unowned /usr/share/printoxx/locales directory.


procps-3.2.7-22.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 3.2.7-22
- fix #472783 vmstat -p <partition name> not working
- extended diskstat parameters to unsigned long to avoid overflow


psiconv-0.9.8-2.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.9.8-2
- Include unowned /etc/psiconv directory.
- Add missing defattr to -devel pkg.


pssh-1.4.0-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4.0-2
- Rebuild for Python 2.6


pungi-2.0.9-1.fc11
------------------
* Thu Dec  4 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 2.0.9-1
- Fix for python-2.6 ('default' is no longer a valid config section)
- Fix splitting srpms


pure-ftpd-1.0.21-17.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.21-17
- Rebuild for Python 2.6


puritan-0.4-3.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4-3
- Rebuild for Python 2.6


pyOpenSSL-0.7-3.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7-3
- Rebuild for Python 2.6


pyPdf-1.12-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.12-2
- Rebuild for Python 2.6


pybackpack-0.5.6-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.6-2
- Rebuild for Python 2.6


pybliographer-1.2.12-2.fc11
---------------------------

pybluez-0.15-3.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.15-3
- Rebuild for Python 2.6


pycairo-1.4.12-5.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4.12-5
- Rebuild for Python 2.6


pychart-1.39-8.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.39-8
- Rebuild for Python 2.6


pychecker-0.8.17-7.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.17-7
- Rebuild for Python 2.6

* Wed Nov  5 17:00:00 2008 Daniel Mach <dmach at redhat.com> - 0.8.17-6
- Add dist tag
- Package .egg-info file only on Fedora >= 9
- Use python_sitelib instead of hardcoded paths


pychess-0.8.2-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.2-2
- Rebuild for Python 2.6


pyclutter-0.8.0-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.0-2
- Rebuild for Python 2.6


pydot-1.0.2-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.2-2
- Rebuild for Python 2.6


pyephem-3.7.2.3-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.7.2.3-3
- Rebuild for Python 2.6


pyevent-0.3-4.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-4
- Rebuild for Python 2.6


pyexiv2-0.1.2-5.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.2-5
- Rebuild for Python 2.6


pyfits-1.3-4.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3-4
- Rebuild for Python 2.6


pyflakes-0.2.1-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-4
- Rebuild for Python 2.6


pyflowtools-0.3.4-3.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.4-3
- Rebuild for Python 2.6


pyfribidi-0.6.0-6.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-6
- Rebuild for Python 2.6


pygame-1.8.1-3.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.8.1-3
- Rebuild for Python 2.6


pygobject2-2.15.4-4.fc11
------------------------
* Sat Nov 29 17:00:00 2008 - Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.15.4-4
- Rebuild for Python 2.6


pygoocanvas-0.10.0-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.0-3
- Rebuild for Python 2.6


pygpgme-0.1-9.fc11
------------------
* Fri Nov 28 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-9
- Rebuild for Python 2.6


pygsl-0.9.3-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.3-2
- Rebuild for Python 2.6


pygtk2-2.13.0-3.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.13.0-3
- Rebuild for Python 2.6


pygtkglext-1.1.0-5.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.0-5
- Rebuild for Python 2.6


pygtksourceview-2.4.0-2.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4.0-2
- Rebuild for Python 2.6


pyicq-t-0.8-7.b.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8-7.b
- Rebuild for Python 2.6


pyjigdo-0.3.0-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.0-2
- Rebuild for Python 2.6


pyke-0.5-2.fc11
---------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-2
- Rebuild for Python 2.6


pykickstart-1.47-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.47-2
- Rebuild for Python 2.6


pylibacl-0.2.2-5.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-5
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-4
- Rebuild for Python 2.6


pylint-0.14.0-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.14.0-2
- Rebuild for Python 2.6


pymetar-0.14-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.14-2
- Rebuild for Python 2.6


pymol-1.1-14.20081015svn3468.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-14.20081015svn3468
- Rebuild for Python 2.6

* Thu Oct 30 18:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.1-13-20081015svn3468
- Fixed vendor flag per kkofler.


pymsn-0.3.3-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.3-2
- Rebuild for Python 2.6


pymssql-0.8.0-3.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.0-3
- Rebuild for Python 2.6


pyodbc-2.1.1-2.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.1-2
- Rebuild for Python 2.6


pyorbit-2.24.0-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.24.0-2
- Rebuild for Python 2.6


pypar2-1.4-3.fc11
-----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4-3
- Rebuild for Python 2.6


pyparsing-1.5.0-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.0-3
- Rebuild for Python 2.6


pyparted-1.8.9-6.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.8.9-6
- Rebuild for Python 2.6


pypoker-eval-135.0-3.fc11.1
---------------------------

pypop-0.7.0-3.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.0-3
- Rebuild for Python 2.6


pyrenamer-0.6.0-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-2
- Rebuild for Python 2.6

* Wed Oct  1 18:00:00 2008 Jean-Fran??ois Martin <lokthare at gmail.com> 0.6.0-1
- Update to new upstream release


pyroom-0.3.1.1-5.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.1.1-5
- Rebuild for Python 2.6


pyscript-0.6.1-3.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.1-3
- Rebuild for Python 2.6


pyserial-2.2-7.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2-7
- Rebuild for Python 2.6


pystatgrab-0.5-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-4
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-3
- Rebuild for Python 2.6


pysvn-1.6.2-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.2-2
- Rebuild for Python 2.6

* Tue Oct 28 18:00:00 2008 Caitlyn O'Hanna <ravenoak at virtualxistenz.com> - 1.6.2-1
- Upstream to 1.6.2, upstream provided some build fixes to remove patches
-   (Thanks Barry!).  Re-enabled testing with provided patch to fix whitespace


python-2.6-1.fc11
-----------------
* Fri Nov 28 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.6-1
- Update to 2.6


python-4Suite-XML-1.0.2-5.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.2-5
- Rebuild for Python 2.6


python-BeautifulSoup-3.0.7a-3.fc11
----------------------------------
* Thu Dec  4 17:00:00 2008 kwizart < kwizart at gmail.com > - 3.0.7a-3
- ReTag

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.0.7a-2
- Rebuild for Python 2.6

* Wed Oct 15 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.0.7a-1
- Update to 3.0.7a


python-CDDB-1.4-4.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4-4
- Rebuild for Python 2.6


python-Coherence-0.5.8-2.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.8-2
- Rebuild for Python 2.6


python-GeoIP-1.2.2-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.2-2
- Rebuild for Python 2.6


python-HTMLgen-2.2.2-11.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2.2-11
- Rebuild for Python 2.6


python-IPy-0.62-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.62-2
- Rebuild for Python 2.6


python-Levenshtein-0.10.1-7.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.1-7
- Rebuild for Python 2.6

* Tue Oct 21 18:00:00 2008 Dwayne Bailey <dwayne at translate.org.za> - 0.10.1-6
- Comments about location of source files
- Update genextdoc.py to v1.5


python-TestGears-0.2-8.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-8
- Rebuild for Python 2.6


python-TurboMail-2.1-5.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1-5
- Rebuild for Python 2.6

* Tue Sep  2 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 2.1-4
- Include unowned directory.


python-ZSI-2.0-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0-4
- Rebuild for Python 2.6


python-adns-1.2.1-4.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.1-4
- Rebuild for Python 2.6

* Wed May 21 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.2.1-3
- fix license tag


python-alsa-1.0.17-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.17-2
- Rebuild for Python 2.6


python-alsaaudio-0.3-3.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-3
- Rebuild for Python 2.6

* Fri Oct 17 18:00:00 2008 kwizart < kwizart at gmail.com > - 0.3-2
- Rebuild for F-10


python-amara-1.2.0.2-3.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.0.2-3
- Rebuild for Python 2.6


python-augeas-0.3.0-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.0-2
- Rebuild for Python 2.6


python-basemap-0.99-6.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.99-6
- Rebuild for Python 2.6


python-beaker-1.0.3-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.3-2
- Rebuild for Python 2.6


python-bibtex-1.2.4-5.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.4-5
- Rebuild for Python 2.6


python-biopython-1.49-1.fc11
----------------------------
* Mon Dec  1 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.49-1
- Update to latest upstream (1.49) uses numpy and new API for psycopg2
- [Build]Requires python-numeric -> numpy 
- [Build]Requires python-psycopg -> python-psycopg2
- Remove interactive question hack, no longer needed

* Sun Nov 30 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.48-3
- Temporarily disable python-psycopg dependency until it is rebuilt
  for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.48-2
- Rebuild for Python 2.6


python-bugzilla-0.4-0.rc4.fc11.1
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4-0.rc4.1
- Rebuild for Python 2.6


python-cerealizer-0.6-4.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6-4
- Rebuild for Python 2.6


python-cheetah-2.0.1-4.fc11
---------------------------
* Mon Dec  1 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 2.0.1-4
- Fix cheetah enough that it will pass its unittests on python-2.6.  This has
  actually been broken since py-2.5 and this fix is only a workaround.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.1-3
- Rebuild for Python 2.6


python-cherrypy-3.1.1-1.fc11
----------------------------
* Mon Dec  1 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 3.1.1-1
- Update to 3.1.1
- Fix python-2.6 build errors
- Make test code non-interactive via cmdline switch
- Refresh the no test and tutorial patch

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.0.3-3
- Rebuild for Python 2.6


python-cherrypy2-2.3.0-7.fc11
-----------------------------

python-cherrytemplate-1.0.0-8.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.0-8
- Rebuild for Python 2.6


python-chm-0.8.4-5.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.4-5
- Rebuild for Python 2.6


python-cjson-1.0.5-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.5-2
- Rebuild for Python 2.6


python-clientform-0.2.7-3.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.7-3
- Rebuild for Python 2.6


python-configobj-4.5.3-3.fc11
-----------------------------
* Mon Dec  1 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 4.5.3-3
- Upload Source file so this actually builds.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.5.3-2
- Rebuild for Python 2.6

* Sat Jun 28 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 4.5.3-1
- Update to 4.5.3


python-cpio-0.1-7.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-7
- Rebuild for Python 2.6


python-crypto-2.0.1-14.1
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.1-14.1
- Rebuild for Python 2.6


python-cssutils-0.9.5.1-4.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.5.1-4
- Rebuild for Python 2.6


python-daap-0.7.1-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.1-2
- Rebuild for Python 2.6


python-dateutil-1.4-3.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4-3
- Rebuild for Python 2.6


python-dbsprockets-0.5-0.3.dev.r411.fc11
----------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-0.3.dev.r411
- Rebuild for Python 2.6


python-decorator-2.2.0-2.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2.0-2
- Rebuild for Python 2.6


python-decoratortools-1.7-2.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.7-2
- Rebuild for Python 2.6


python-demjson-1.3-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3-3
- Rebuild for Python 2.6


python-dialog-2.7-9.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.7-9
- Rebuild for Python 2.6


python-dictclient-1.0.1-2.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1-2
- Rebuild for Python 2.6


python-dns-1.6.0-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.0-3
- Rebuild for Python 2.6


python-docs-2.6-1.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.6-1
- Update to 2.6


python-docutils-0.5-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-2
- Rebuild for Python 2.6


python-dotconf-0.2.1-8.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-8
- Rebuild for Python 2.6


python-dtopt-0.1-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-3
- Rebuild for Python 2.6


python-durus-3.5-8.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.5-8
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.5-7
- Rebuild for Python 2.6


python-elixir-0.6.1-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.1-2
- Rebuild for Python 2.6


python-enchant-1.3.1-3.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.1-3
- Rebuild for Python 2.6


python-enum-0.4.3-4.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.3-4
- Rebuild for Python 2.6


python-ethtool-0.3-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-3
- Rebuild for Python 2.6


python-exif-1.0.8-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.8-2
- Rebuild for Python 2.6


python-eyed3-0.6.16-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.16-2
- Rebuild for Python 2.6


python-fedora-0.3.8-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.8-2
- Rebuild for Python 2.6


python-feedcache-1.3-3.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3-3
- Rebuild for Python 2.6


python-feedparser-4.1-5.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.1-5
- Rebuild for Python 2.6


python-flickrapi-1.1-5.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-5
- Rebuild for Python 2.6


python-flup-1.0-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-3
- Rebuild for Python 2.6


python-formencode-1.0.1-3.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1-3
- Rebuild for Python 2.6


python-fpconst-0.7.3-4.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.3-4
- Rebuild for Python 2.6


python-gammu-0.27-3.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.27-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.27-2
- Rebuild for Python 2.6


python-gasp-0.2.0beta1-2.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.0beta1-2
- Rebuild for Python 2.6


python-gdata-1.2.3-2.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.3-2
- Rebuild for Python 2.6

* Thu Dec  4 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.2.3-1
- Update to 1.2.3

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.2-2
- Rebuild for Python 2.6


python-genshi-0.5.1-3.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.5.1-3
- Rebuild for Python 2.6


python-goopy-0.1-6.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-6
- Rebuild for Python 2.6

* Sat Jan 19 17:00:00 2008 Peter Jones <pjones at redhat.com> - 0.1-5
- Rebuild for broken deps.


python-html2text-2.34-2.1
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.34-2.1
- Rebuild for Python 2.6


python-httplib2-0.4.0-2.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.0-2
- Rebuild for Python 2.6


python-id3-1.2-13.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2-13
- Rebuild for Python 2.6


python-imaging-1.1.6-13.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.6-13
- Rebuild for Python 2.6


python-iniparse-0.2.3-5.fc11
----------------------------
* Fri Nov 28 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.3-5
- Rebuild for Python 2.6

* Tue Jan  8 17:00:00 2008 Tim Lauridsen <timlau at fedoraproject.org> - 0.2.3-4
- own the %{_docdir}/python-iniparse-0.2.3 directory


python-inotify-0.8.0-4.r.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.0-4.r
- Rebuild for Python 2.6


python-irclib-0.4.6-7.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.6-7
- Rebuild for Python 2.6


python-isprelink-0.1.2-6.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.2-6
- Rebuild for Python 2.6


python-jinja-1.2-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2-2
- Rebuild for Python 2.6


python-jinja2-2.0-3.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0-3
- Rebuild for Python 2.6


python-json-3.4-5.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.4-5
- Rebuild for Python 2.6


python-kaa-base-0.4.0-2.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.0-2
- Rebuild for Python 2.6


python-kaa-imlib2-0.2.3-3.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.3-3
- Rebuild for Python 2.6


python-kaa-metadata-0.7.3-2.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.3-2
- Rebuild for Python 2.6


python-kerberos-1.1-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-2
- Rebuild for Python 2.6


python-kid-0.9.6-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.6-3
- Rebuild for Python 2.6


python-kiwi-1.9.22-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.9.22-2
- Rebuild for Python 2.6


python-krbV-1.0.13-8.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.13-8
- Rebuild for Python 2.6


python-ldap-2.3.5-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0:2.3.5-2
- Rebuild for Python 2.6


python-lirc-0.0.5-8
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.5-8
- Rebuild for Python 2.6


python-logilab-astng-0.17.2-2.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.17.2-2
- Rebuild for Python 2.6


python-logilab-common-0.32.0-2.fc11
-----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.32.0-2
- Rebuild for Python 2.6


python-louie-1.1-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-3
- Rebuild for Python 2.6


python-lxml-2.2-0.3.alpha1.fc11
-------------------------------
* Fri Nov 28 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.2-0.3.alpha1
- Rebuild for Python 2.6


python-lzo-1.08-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.08-3
- Rebuild for Python 2.6


python-mako-0.1.10-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.10-3
- Rebuild for Python 2.6


python-markdown-1.7-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.7-2
- Rebuild for Python 2.6


python-markdown2-1.0.1.11-2.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1.11-2
- Rebuild for Python 2.6


python-matplotlib-0.98.3-2.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.98.3-2
- Rebuild for Python 2.6

* Wed Aug  6 18:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> - 0.98.3-1
- Latest upstream release


python-mecab-0.97-1.fc11.1
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.97-1.1
- Rebuild for Python 2.6


python-mechanize-0.1.6-0.3.b.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.6-0.3.b
- Rebuild for Python 2.6


python-meld3-0.6.4-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.4-2
- Rebuild for Python 2.6


python-memcached-1.43-3.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.43-3
- Rebuild for Python 2.6


python-metar-1.3.0-4.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.0-4
- Rebuild for Python 2.6


python-migrate-0.4.5-4.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.5-4
- Rebuild for Python 2.6


python-minihallib-0.1.10-2.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.10-2
- Rebuild for Python 2.6


python-mpd-0.2.0-4.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.0-4
- Rebuild for Python 2.6


python-musicbrainz2-0.6.0-3.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-3
- Rebuild for Python 2.6


python-mutagen-1.13-3.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.13-3
- Rebuild for Python 2.6


python-mwlib-0.8.5-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.5-3
- Rebuild for Python 2.6


python-myghty-1.1-7.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-7
- Rebuild for Python 2.6


python-netaddr-0.5.2-2.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.2-2
- Rebuild for Python 2.6


python-nltk-0.9.2-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:0.9.2-2
- Rebuild for Python 2.6


python-nose-0.10.4-1.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.4-1
- Update to 0.10.4 to fix 2.6 issues

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.3-2
- Rebuild for Python 2.6


python-nss-0.1-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-2
- Rebuild for Python 2.6


python-numarray-1.5.2-7.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.2-7
- Rebuild for Python 2.6


python-numdisplay-1.4-3.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4-3
- Rebuild for Python 2.6


python-numeric-24.2-12.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 24.2-12
- Rebuild for Python 2.6


python-ogg-1.3-10
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3-10
- Rebuild for Python 2.6


python-openhpi-1.1-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-2
- Rebuild for Python 2.6


python-paramiko-1.7.4-3.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.7.4-3
- Rebuild for Python 2.6


python-paste-1.7.1-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.7.1-2
- Rebuild for Python 2.6


python-paste-deploy-1.3.2-2.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.2-2
- Rebuild for Python 2.6


python-paste-script-1.6.3-4.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.3-4
- Rebuild for Python 2.6


python-paver-0.8.1-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.1-3
- Rebuild for Python 2.6


python-peak-rules-0.5a1.dev-4.2582.fc11
---------------------------------------
* Tue Dec  2 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 0.5a1.dev-4.2582
- Update patch for some more doctest fixing under py2.6.

* Tue Dec  2 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 0.5a1.dev-3.2582
- Update to latest development snapshot
- Enable test suite
- Patch so doctests pass

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5a1.dev-2.2581
- Rebuild for Python 2.6


python-peak-util-addons-0.6-2.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6-2
- Rebuild for Python 2.6


python-peak-util-assembler-0.5-2.fc11
-------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-2
- Rebuild for Python 2.6


python-peak-util-extremes-1.1-2.fc11
------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-2
- Rebuild for Python 2.6


python-peak-util-symbols-1.0-2.fc11
-----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-2
- Rebuild for Python 2.6


python-pgsql-0.9.7-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.7-2
- Rebuild for Python 2.6


python-ply-2.5-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.5-2
- Rebuild for Python 2.6


python-pmw-1.3.2-6.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.2-6
- Rebuild for Python 2.6


python-pp-1.5.6-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.6-2
- Rebuild for Python 2.6


python-prioritized-methods-0.2.1-3.fc11
---------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-3
- Rebuild for Python 2.6


python-protocols-1.0-0.10.a0dev_r2302.fc11
------------------------------------------
* Tue Dec  2 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 1.0-0.10.a0dev_r2302
- Enable the test suite
- Add a requirement on python-decoratortools

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-0.9.a0dev_r2302
- Rebuild for Python 2.6


python-psyco-1.5.1-12.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.1-12
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.1-11
- Rebuild for Python 2.6


python-psycopg2-2.0.8-2.fc11
----------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.8-2
- Rebuild for Python 2.6


python-pyasn1-0.0.8a-2.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.8a-2
- Rebuild for Python 2.6


python-pyblock-0.32-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.32-2
- Rebuild for Python 2.6


python-pycurl-7.18.2-2.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 7.18.2-2
- Rebuild for Python 2.6


python-pydns-2.3.3-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.3.3-2
- Rebuild for Python 2.6


python-pygments-1.0-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-2
- Rebuild for Python 2.6


python-pylons-0.9.6.2-2.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.6.2-2
- Rebuild for Python 2.6


python-pysctp-0.3.1-4.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.1-4
- Rebuild for Python 2.6


python-pyspf-2.0.5-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.5-2
- Rebuild for Python 2.6


python-qpid-0.3.722557-2.fc11
-----------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.722557-2
- Rebuild for Python 2.6


python-quixote-2.4-10.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4-9
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4-10
- Fix locations for Python 2.6


python-rabbyt-0.8.2-7.fc11
--------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.2-7
- Really fix locations this time

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.2-6
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.2-5
- Rebuild for Python 2.6


python-reportlab-2.1-4.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1-4
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1-3
- Rebuild for Python 2.6


python-repoze-tm2-1.0-0.2.a3.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-0.2.a3
- Rebuild for Python 2.6


python-routes-1.8-3.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.8-3
- Rebuild for Python 2.6


python-ruledispatch-0.5a0-0.13.svnr2306.fc11
--------------------------------------------
* Tue Dec  2 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 0.5a0-0.12.svnr2306
- Enable test suite.

* Tue Dec  2 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5a0-0.12.svnr2306
- Add patch to change "as" to "asnew"

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5a0-0.11.svnr2306
- Rebuild for Python 2.6


python-schedutils-0.2-3.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-3
- Rebuild for Python 2.6


python-setuptools-0.6c9-2.fc11
------------------------------
* Fri Nov 28 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6c9-2
- Rebuild for Python 2.6

* Sun Nov 23 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 0.6c9-1
- Update to 0.6c9
- Small fixes to URL, summary and description


python-sexy-0.1.9-7.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.9-7
- Rebuild for Python 2.6


python-simplejson-2.0.3-3.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.3-3
- Rebuild for Python 2.6


python-simpletal-4.1-9.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.1-9
- Rebuild for Python 2.6


python-simpy-1.9.1-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.9.1-2
- Rebuild for Python 2.6


python-slip-0.1.15-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.15-2
- Rebuild for Python 2.6


python-smbpasswd-1.0.1-9.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1-9
- Rebuild for Python 2.6


python-sphinx-0.5-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-2
- Rebuild for Python 2.6


python-sqlalchemy-0.5.0-0.1.rc4.fc11
------------------------------------
* Mon Dec  1 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 0.5-0.1.rc4
- Update to 0.5.0rc4 which works with the new pysqlite
- And update test cases to work with the new pysqlite

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.7-2
- Rebuild for Python 2.6


python-sqlite2-2.3.3-5.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:2.3.3-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:2.3.3-4
- Rebuild for Python 2.6


python-sqlobject-0.10.2-2.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.2-2
- Rebuild for Python 2.6


python-suds-0.3.3-2.fc11
------------------------
* Thu Dec  4 17:00:00 2008 jortel <jortel at redhat.com> - 0.3.3-2
- Rebuild for Python 2.6

* Thu Dec  4 17:00:00 2008 jortel <jortel at redhat.com> - 0.3.3-1
- No longer installs (tests) package.
- Implements API-3 proposal
    Pluggable transport
    Keyword method arguments
    Baisc http authentication in default transport
- Add namespace prefix normalization in soap message.
- Better soap message pruning of empty nodes.
- Fixed Tickets: #51 - #60.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.2-2
- Rebuild for Python 2.6


python-tag-0.94.1-3.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.94.1-3
- Rebuild for Python 2.6

* Tue Aug 12 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.94.1-2
- Rebuild against new boost.


python-telepathy-0.15.3-2.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.15.3-2
- Rebuild for Python 2.6


python-tempita-0.2-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-3
- Rebuild for Python 2.6


python-textile-2.0.11-5.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.11-5
- Rebuild for Python 2.6


python-tftpy-0.4.6-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.6-2
- Rebuild for Python 2.6


python-tgexpandingformwidget-0.1.3-6.fc11
-----------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.3-6
- Rebuild for Python 2.6


python-tgfastdata-0.9a6-8.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9a6-8
- Rebuild for Python 2.6


python-tidy-0.2-5.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-5
- Rebuild for Python 2.6


python-toscawidgets-0.9.3-2.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.3-2
- Rebuild for Python 2.6


python-tpg-3.1.2-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.1.2-3
- Rebuild for Python 2.6


python-transaction-1.0-0.2.a1.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-0.2.a1
- Rebuild for Python 2.6


python-turbocheetah-1.0-3.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-3
- Rebuild for Python 2.6


python-turbojson-1.2.1-3.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.1-3
- Rebuild for Python 2.6


python-turbokid-1.0.4-2.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.4-2
- Rebuild for Python 2.6


python-tw-forms-0.9.2-2.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.2-2
- Rebuild for Python 2.6


python-twisted-conch-0.8.0-6.fc11
---------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.0-6
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.0-5
- Rebuild for Python 2.6


python-twisted-core-2.5.0-6.fc11
--------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.5.0-6
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.5.0-5
- Rebuild for Python 2.6


python-twisted-lore-0.3.0-3.fc11
--------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.0-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.0-2
- Rebuild for Python 2.6


python-twisted-mail-0.4.0-6.fc11
--------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.0-6
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.0-5
- Rebuild for Python 2.6


python-twisted-names-0.4.0-5.fc11
---------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.0-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.0-4
- Rebuild for Python 2.6


python-twisted-news-0.3.0-5.fc11
--------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.0-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.0-4
- Rebuild for Python 2.6


python-twisted-runner-0.2.0-8.fc11
----------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.0-8
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.0-7
- Rebuild for Python 2.6


python-twisted-web-0.7.0-5.fc11
-------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.0-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.0-4
- Rebuild for Python 2.6


python-twisted-words-0.5.0-5.fc11
---------------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.0-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.0-4
- Rebuild for Python 2.6


python-twitter-0.5-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-2
- Rebuild for Python 2.6


python-twyt-0.8.5-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.8.5-2
- Rebuild for Python 2.6


python-urlgrabber-3.0.0-11.fc11
-------------------------------
* Fri Nov 28 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 3.0.0-11
- Rebuild for Python 2.6


python-virtinst-0.400.0-7.fc11
------------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.400.0-7
- Rebuild for Python 2.6


python-virtkey-0.50-4.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.50-4
- Rebuild for Python 2.6


python-virtualenv-1.3.1-4.fc11
------------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.1-4
- Rebuild for Python 2.6


python-vobject-0.7.1-3.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.1-3
- Rebuild for Python 2.6


python-vorbis-1.5-0.5.a
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5-0.5.a
- Rebuild for Python 2.6


python-webhelpers-0.3.4-3.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.4-3
- Rebuild for Python 2.6


python-webob-0.9.3-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.3-3
- Rebuild for Python 2.6


python-webtest-1.0-4.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-4
- Rebuild for Python 2.6


python-which-1.1.0-4.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.0-4
- Rebuild for Python 2.6


python-wikimarkup-1.01-4.005svn.fc11
------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.01-4.005svn
- Rebuild for Python 2.6


python-wsgiproxy-0.1-2.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-2
- Rebuild for Python 2.6


python-xlib-0.14-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.14-3
- Rebuild for Python 2.6


python-xlrd-0.6.1-7.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.1-7
- Rebuild for Python 2.6


python-xmltramp-2.17-4.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.17-4
- Rebuild for Python 2.6


python-xmpp-0.4.1-4.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.1-4
- Rebuild for Python 2.6


python-yenc-0.3-5.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-5
- Rebuild for Python 2.6


python-zope-interface-3.5.0-2.fc11
----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.5.0-2
- Rebuild for Python 2.6


python-zope-sqlalchemy-0.3-2.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3-2
- Rebuild for Python 2.6


pytrainer-1.6.0.5-4.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.0.5-4
- Rebuild for Python 2.6


pytz-2008i-4.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2008i-4
- Rebuild for Python 2.6


pyusb-0.4.1-3.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.1-3
- Rebuild for Python 2.6


pyvnc2swf-0.9.3-5.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.3-5
- Rebuild for Python 2.6


pyxattr-0.2.2-4.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-4
- Rebuild for Python 2.6


pyxdg-0.16-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.16-2
- Rebuild for Python 2.6


pyxf86config-0.3.37-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.37-2
- Rebuild for Python 2.6


pyxmms-2.06-9.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.06-9
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.06-8
- Rebuild for Python 2.6


pyzor-0.4.0-14.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.0-14
- Rebuild for Python 2.6

* Thu Aug 14 18:00:00 2008 Jason L Tibbitts III <tibbs at math.uh.edu> - 0.4.0-13
- Fix failing build too.

* Thu Aug 14 18:00:00 2008 Jason L Tibbitts III <tibbs at math.uh.edu> - 0.4.0-12
- Fix license tag.


qct-1.5-7.fc11
--------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5-7
- Rebuild for Python 2.6


qscintilla-2.3.2-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.3.2-2
- Rebuild for Python 2.6


qt-recordmydesktop-0.3.7.2-3.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.7.2-3
- Rebuild for Python 2.6


quodlibet-1.0-5.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-5
- Rebuild for Python 2.6


rb_libtorrent-0.13.1-5.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.13.1-5
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.13.1-4
- Rebuild for Python 2.6

* Thu Nov 20 17:00:00 2008 Peter Gordon <peter at thecodergeek.com>
- Update Source0 URL, for now.


rdiff-backup-1.2.1-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.1-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.1-2
- Rebuild for Python 2.6


referencer-1.1.5-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.5-3
- Rebuild for Python 2.6


repoman-0.9-6.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9-6
- Rebuild for Python 2.6


revisor-2.1.3-2.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.3-2
- Rebuild for Python 2.6


rhpl-0.218-2
------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.218-2
- Rebuild for Python 2.6


rhpxl-1.9-4.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.9-4
- Rebuild for Python 2.6


rhythmbox-0.11.6-18.6086.fc11
-----------------------------

rkward-0.5.0b-11.fc11
---------------------
* Fri Dec  5 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.5.0b-11
- Rebuild for fixed kde-filesystem (macros.kde4) (get rid of rpaths)

* Sun Nov 30 17:00:00 2008 pingou <pingou -AT- pingoured.fr> 0.5.0b-10
- Own directory rkward -- #473660

* Wed Oct 29 18:00:00 2008 pingou <pingou -AT- pingoured.fr> 0.5.0b-9
- Move the sed to prep

* Wed Oct 29 18:00:00 2008 pingou <pingou -AT- pingoured.fr> 0.5.0b-8
- Rebuild for R 2.8.0 
- Remove the Rdevices.h which make the build failed


roundup-1.4.6-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4.6-2
- Rebuild for Python 2.6


roxterm-1.13.0-1.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Sebastian Vahl <fedora at deadbabylon.de> - 1.13.0-1
- new upstream version: 1.13.0


rpm-4.6.0-0.rc2.9
-----------------

rpmlint-0.85-3.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.85-3
- Rebuild for Python 2.6


rpmrebuild-2.2.2-2.fc11
-----------------------
* Thu Dec  4 17:00:00 2008 Anderson Silva <ansilva at redhat.com> 2.2.2-2
- Fix package ownership of locale directories.


rrdtool-1.3.4-5.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.4-5
- Rebuild for Python 2.6


rubber-1.1-3.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-3
- Rebuild for Python 2.6


s3cmd-0.9.8.4-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.8.4-2
- Rebuild for Python 2.6


sabayon-2.22.1-2.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.22.1-2
- Rebuild for Python 2.6


sbcl-1.0.23-1.fc11
------------------
* Mon Dec  1 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0.23-1
- sbcl-1.0.23


scim-python-0.1.13rc1-4.fc11
----------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.13rc1-4
- Rebuild for Python 2.6


scipy-0.7.0-0.1.b1.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Jef Spaleta <jspaleta at fedoraproject.org> - 0.7.0-0.1.b1
- Update to latest beta which lists python 2.6 support


scons-1.0.0-2.d20080826.fc11
----------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.0-2.d20080826
- Rebuild for Python 2.6


scribes-0.3.3.3-3.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.3.3-3
- Rebuild for Python 2.6


scribus-1.3.5-0.8.12516svn.fc11
-------------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.5-0.8.12516svn
- Rebuild for Python 2.6


sectool-0.9.1-7
---------------
* Thu Dec  4 17:00:00 2008 Jakub Hrozek <jhrozek at redhat.com> - 0.9.1-7
- apply mbarabas' manpage patch


seedit-2.2.0-4.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2.0-4
- Rebuild for Python 2.6


selinux-policy-3.6.1-6.fc11
---------------------------
* Thu Dec  4 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-6
- Allow iptables to talk to terminals

* Thu Dec  4 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-5
- Allow iptables to talk to terminals


serpentine-0.9-3.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9-3
- Rebuild for Python 2.6


setools-3.3.5-5.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.3.5-5
- Rebuild for Python 2.6


setroubleshoot-2.0.12-2.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.12-2
- Rebuild for Python 2.6


setroubleshoot-plugins-2.0.11-2.fc11
------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.11-2
- Rebuild for Python 2.6

* Wed Nov  5 17:00:00 2008 <dwalsh at redhat.com> - 2.0.11-1
- Fix catchall_booleans
- Fix priority on samba plugins


sip-4.7.9-2.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.7.9-2
- Rebuild for Python 2.6


sk2py-0.1-2.fc11
----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-2
- Rebuild for Python 2.6


smart-1.1-57.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1-57
- Rebuild for Python 2.6


smolt-1.2-2.fc11
----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2-2
- Rebuild for Python 2.6

* Sun Nov 30 17:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.2-1
- Upstream released new version

* Fri Nov 21 17:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.1.1.1-10
- Fix for bug 472101


solfege-3.10.4-2.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.10.4-2
- Rebuild for Python 2.6


sonata-1.5.2-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.2-2
- Rebuild for Python 2.6


sos-1.8-3.fc11
--------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.8-3
- Rebuild for Python 2.6


spambayes-1.0.4-6.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.4-6
- Rebuild for Python 2.6


specto-0.2.2-4.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-4
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.2-3
- Rebuild for Python 2.6


speech-dispatcher-0.6.6-20.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.6-20
- Rebuild for Python 2.6

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.6.6-19
- Fix Patch0:/%patch mismatch.


sqlite-3.6.6.2-3.fc11
---------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 3.6.6.2-3
- Rebuild for pkg-config provides


squirrelmail-1.4.17-1.fc11
--------------------------
* Thu Dec  4 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 1.4.17-1
- update to 1.4.17 (fixes CVE-2008-2379)


stgit-0.14.3-4.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.14.3-4
- Rebuild for Python 2.6


straw-0.27-15.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.27-15
- Rebuild for Python 2.6


streamtuner-0.99.99-26.fc11
---------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.99.99-26
- Rebuild for Python 2.6


subversion-1.5.4-4
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.4-4
- Rebuild for Python 2.6


sugar-0.83.3-4.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.83.3-4
- Rebuild for Python 2.6


sugar-base-0.83.1-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.83.1-2
- Rebuild for Python 2.6


sugar-datastore-0.83.0-2.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.83.0-2
- Rebuild for Python 2.6


sugar-presence-service-0.83.1-4.fc11
------------------------------------
* Thu Dec  4 17:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.1-3
- Add patch for network manager 0.7

* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.83.1-4
- Rebuild for Python 2.6

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.83.1-2
- Rebuild for Python 2.6


supervisor-2.1-6.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1-6
- Rebuild for Python 2.6


supybot-0.83.3-8.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.83.3-8
- Rebuild for Python 2.6


svnmailer-1.0.8-7.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.8-7
- Rebuild for Python 2.6


swig-1.3.36-2.fc11
------------------
* Thu Dec  4 17:00:00 2008 Adam Tkac <atkac redhat com> 1.3.36-2
- #470811 is fixed => dropped workaround


switchdesk-4.0.9-3.fc11.1
-------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.0.9-3.1
- Rebuild for Python 2.6


sympy-0.6.3-1.fc11
------------------
* Thu Dec  4 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 0.6.3-1
- Bump to 0.6.3, supports python 2.6.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.2-3
- Rebuild for Python 2.6


synce-kpm-0.11.2-0.2.svn3491.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.2-0.2.svn3491
- Rebuild for Python 2.6


synce-sync-engine-0.11.1-3.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.1-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.1-2
- Rebuild for Python 2.6


system-config-bind-4.0.11-5.fc11
--------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.0.11-5
- Rebuild for Python 2.6


system-config-boot-0.3.0-3.fc11
-------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.0-3
- Rebuild for Python 2.6


system-config-cluster-1.0.53-3
------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.53-3
- Rebuild for Python 2.6


system-config-display-1.1.1-2.fc11
----------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.1-2
- Rebuild for Python 2.6


system-config-firewall-1.2.13-3.fc11
------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.13-3
- Rebuild for Python 2.6


system-config-kdump-1.0.14-3.fc11
---------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.14-3
- Rebuild for Python 2.6


system-config-keyboard-1.2.15-6.fc11
------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.15-6
- Rebuild for Python 2.6


system-config-kickstart-2.7.19-2.fc11
-------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.7.19-2
- Rebuild for Python 2.6


system-config-language-1.3.2-4.fc11
-----------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.2-4
- Rebuild for Python 2.6


system-config-lvm-1.1.4-4.1.fc11
--------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.4-4.1
- Rebuild for Python 2.6


system-config-netboot-0.1.45.3-2.fc11
-------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.45.3-2
- Rebuild for Python 2.6

* Tue Sep 16 18:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> - 0.1.45.3-1
- Fixes icon reference (#bz457715)
- Fixes replacing custom msgs (#bz459383)
- Config noreplace for config files
- Upstream URL updated


system-config-network-1.5.93-3.fc11
-----------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.93-3
- Rebuild for Python 2.6


system-config-nfs-1.3.41-2.fc11
-------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.41-2
- Rebuild for Python 2.6


system-config-printer-1.0.11-3.fc11
-----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.11-3
- Rebuild for Python 2.6

* Fri Nov 28 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.11-2
- Updated pycups to 1.9.44.


system-config-rootpassword-1.99.4-3.fc11
----------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.99.4-3
- Rebuild for Python 2.6


system-config-samba-1.2.67-2.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.67-2
- Rebuild for Python 2.6


system-config-services-0.99.28-2.fc11
-------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.99.28-2
- Rebuild for Python 2.6


system-config-users-1.2.81-2.fc11
---------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.81-2
- Rebuild for Python 2.6


system-config-vsftpd-0.5.1-2.fc11
---------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.1-2
- Rebuild for Python 2.6


system-switch-displaymanager-1.2-3.fc11
---------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2-3
- Rebuild for Python 2.6


system-switch-java-1.1.4-2.fc11
-------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.4-2
- Rebuild for Python 2.6


system-switch-mail-0.5.26-4
---------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.26-4
- Rebuild for Python 2.6


tailor-0.9.35-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.35-2
- Rebuild for Python 2.6


taskcoach-0.69.1-3.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.69.1-3
- Rebuild for Python 2.6


taskjuggler-2.4.1-4.fc11
------------------------
* Thu Dec  4 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 2.4.1-4
- install taskjuggler documentation in docdir and do own
  that dir (#47600) , removed trailing spaces in spec file


telepathy-butterfly-0.3.2-2.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.2-2
- Rebuild for Python 2.6


tellico-1.3.4-3.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.3.4-3
- Rebuild for Python 2.6


testoob-1.13-6.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.13-6
- Rebuild for Python 2.6


textflow-0.2.3.2-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.3.2-2
- Rebuild for Python 2.6


tmda-1.1.12-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.12-2
- Rebuild for Python 2.6


tomboy-0.13.1-5.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.13.1-5
- Rebuild against new gmime


tomoe-0.6.0-8.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-8
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-7
- Rebuild for Python 2.6


totem-2.24.3-3.fc11
-------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.24.3-3
- Rebuild for Python 2.6

* Sat Nov 22 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.3-2
- Tweak %descriptions


totem-pl-parser-2.24.2-3.fc11
-----------------------------
* Fri Dec  5 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.24.2-3
- Rebuild against newer libcamel.


trac-0.11.2.1-4.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.2.1-4
- Rebuild for Python 2.6

* Fri Nov 28 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.2.1-3
- Add dependency on python-pygments
- Rebuild for Python 2.6


trac-bazaar-plugin-0.2-8.20080925bzr49.fc11
-------------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-8.20080925bzr49
- Rebuild for Python 2.6


trac-doxygen-plugin-0.4-0.4.r2892.fc11
--------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4-0.4.r2892
- Rebuild for Python 2.6


trac-git-plugin-0.0.1-7.20070705svn1536.fc11
--------------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.1-7.20070705svn1536
- Rebuild for Python 2.6


trac-iniadmin-plugin-0.1-3.20071126svn2824.fc11
-----------------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-3.20071126svn2824
- Rebuild for Python 2.6


trac-mercurial-plugin-0.10.0.2-5.20070705svn5798.fc11
-----------------------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10.0.2-5.20070705svn5798
- Rebuild for Python 2.6


trac-monotone-plugin-0.0.14-2.20080208mtnb4dd178b.fc11
------------------------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.14-2.20080208mtnb4dd178b
- Rebuild for Python 2.6


trac-spamfilter-plugin-0.2.1-0.3.20080603svn6990.fc11
-----------------------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.1-0.3.20080603svn6990
- Rebuild for Python 2.6


trac-ticketdelete-plugin-1.1.4-2.20071126svn2825.fc11
-----------------------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.4-2.20071126svn2825
- Rebuild for Python 2.6


trac-webadmin-0.1.2-0.4.dev_r4429.fc11
--------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.2-0.4.dev_r4429
- Rebuild for Python 2.6


trac-xmlrpc-plugin-0.1-0.4.r2892.fc11
-------------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1-0.4.r2892
- Rebuild for Python 2.6


transbot-0.2-4.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2-4
- Rebuild for Python 2.6


translate-toolkit-1.2.0-4.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.0-4
- Rebuild for Python 2.6


translation-filter-0.0.2-3.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.2-3
- Rebuild for Python 2.6


tre-0.7.5-6.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.7.5-6
- Rebuild for Python 2.6


twitux-0.65-2.fc11
------------------
* Fri Dec  5 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.65-2
- Add patch to fix notification popup menu.


txt2tags-2.5-5.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.5-5
- Rebuild for Python 2.6


uniconvertor-1.1.3-3.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.3-3
- Rebuild for Python 2.6


vegastrike-0.5.0-6.fc11
-----------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.0-6
- Rebuild for Python 2.6


veusz-1.2-4.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2-4
- Rebuild for Python 2.6


viewmtn-0.10-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.10-2
- Rebuild for Python 2.6


viewvc-1.1.0-0.beta1.1.fc11.1
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.0-0.beta1.1.1
- Rebuild for Python 2.6


vim-7.2.060-2.fc11
------------------
* Thu Dec  4 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 7.2.060-2
- Rebuild for new python.


vips-7.14.5-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 7.14.5-2
- Rebuild for Python 2.6


virt-manager-0.6.0-6.fc11
-------------------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.0-6
- Rebuild for Python 2.6


vte-0.19.1-2.fc11
-----------------
* Thu Dec  4 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.19.1-2
- Rebuild for Python 2.6


vtk-5.0.4-26.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 5.0.4-26
- Rebuild for Python 2.6


waf-1.4.4-2.fc11
----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4.4-2
- Rebuild for Python 2.6


wallpapoz-0.4.1-7.svn87_trunk.fc11.1
------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.1-7.svn87_trunk.1
- Rebuild for Python 2.6


wastesedge-0.3.4-0.10.fc11
--------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.4-0.10
- Rebuild for Python 2.6


weechat-0.2.6-6.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.6-6
- Rebuild for Python 2.6


wesnoth-1.4.6-3.fc11
--------------------

widelands-0-0.13.Build13.fc11
-----------------------------
* Thu Dec  4 17:00:00 2008 Karol Trzcionka <karlikt at gmail.com> - 0-0.13.Build13
- Update to Build13


winpdb-1.4.2-2.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.4.2-2
- Rebuild for Python 2.6


wireshark-1.1.1-0.pre1.fc11.1
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.1-0.pre1.1
- Rebuild for Python 2.6


wuja-0.0.8-5.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.8-5
- Rebuild for Python 2.6


wxGTK-2.8.9-3.fc11
------------------
* Tue Nov  4 17:00:00 2008 Dan Hor??k <dan[at]danny.cz> - 2.8.9-3
- remove support for bakefiles, fixes directory ownership (#474594)

* Tue Nov  4 17:00:00 2008 Dan Horak <dan[at]danny.cz> - 2.8.9-2
- drop all the Obsoletes/Provides used for upgrading from the wxGTK 2.6 era
- drop using of x11libdir pointing to X11R6
- create media subpackage for more precise package dependencies


wxPython-2.8.9.1-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.8.9.1-2
- Rebuild for Python 2.6


xcb-proto-1.2-3.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2-3
- Rebuild for Python 2.6


xchat-2.8.6-4.fc11
------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:2.8.6-4
- Rebuild for Python 2.6


xchat-gnome-0.24.1-2.fc11
-------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.24.1-2
- Rebuild for Python 2.6


xemacs-packages-extra-20070427-4.fc11
-------------------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 20070427-4
- Rebuild for Python 2.6


xen-3.3.0-1.fc11.1
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.3.0-1.1
- Rebuild for Python 2.6


xesam-tools-0.6.1-2.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.1-2
- Rebuild for Python 2.6


xorg-x11-drv-ati-6.9.0-61.fc10
------------------------------
* Tue Dec  2 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-61
- radeon-modeset.patch: fix some DFS issues on r5xx - better fix for rs4xx

* Sun Nov 30 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-60
- radeon-6.9.0-posting-fix.patch - add fix to post the second GPU properly


xorg-x11-drv-synaptics-0.99.2-1.fc11
------------------------------------

xpilot-ng-4.7.2-15.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.7.2-15
- Rebuild for Python 2.6


xulrunner-1.9.0.4-1.fc11
------------------------

xxdiff-3.2-9.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.2-9
- Rebuild for Python 2.6


yum-3.2.20-6.fc11
-----------------
* Thu Dec  4 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 3.2.20-6
- Add patch from upstream to fix cases where obsoletes are disabled. (jantill)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.2.20-5
- Rebuild for Python 2.6


yum-arch-2.2.2-4.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2.2-4
- Rebuild for Python 2.6


yum-metadata-parser-1.1.2-11.fc11
---------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 1.1.2-11
- Rebuild for Python 2.6


yum-presto-0.4.5-2.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.5-2
- Rebuild for Python 2.6


yumex-2.0.5-4.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.5-4
- Rebuild for Python 2.6


zabbix-1.6.1-1.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-1
- Fix BZ#474593 by adding a requires.

* Wed Nov  5 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-1
- Update to 1.6.1


zeroinstall-injector-0.34-2.fc11
--------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.34-2
- Rebuild for Python 2.6


Summary:
Added Packages: 9
Removed Packages: 1
Modified Packages: 852
Broken deps for i386
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.i386 requires libpython2.5.so.1.0
	ScientificPython-qt-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	avahi-ui-sharp-0.6.22-13.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	beagle-0.3.8-14.fc11.i386 requires mono(gmime-sharp) = 0:2.2.0.0
	beagle-evolution-0.3.8-14.fc11.i386 requires mono(gmime-sharp) = 0:2.2.0.0
	beagle-thunderbird-0.3.8-14.fc11.i386 requires mono(gmime-sharp) = 0:2.2.0.0
	beecrypt-python-4.1.2-17.fc10.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	cyphesis-0.5.17-1.fc11.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	duplicity-0.4.12-2.fc10.i386 requires python(abi) = 0:2.5
	duplicity-0.4.12-2.fc10.i386 requires libpython2.5.so.1.0
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	freeradius-python-2.1.1-8.fc11.i386 requires libpython2.5.so.1.0
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ganglia-gmond-python-3.1.1-1.fc10.i386 requires libpython2.5.so.1.0
	gdal-python-1.5.3-1.fc10.i386 requires python(abi) = 0:2.5
	gdal-python-1.5.3-1.fc10.i386 requires libpython2.5.so.1.0
	gdl-0.9-0.rc1.4.fc10.i386 requires libpython2.5.so.1.0
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	gimmie-0.2.8-2.fc9.i386 requires python(abi) = 0:2.5
	glipper-1.0-4.fc10.i386 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.i386 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.i386 requires libpython2.5.so.1.0
	gnome-bluetooth-libs-0.11.0-5.fc10.i386 requires python(abi) = 0:2.5
	gnome-packagekit-0.3.11-1.fc11.i386 requires python(abi) = 0:2.5
	gnome-python2-gtkmozembed-2.19.1-25.fc11.i386 requires gecko-libs = 0:1.9.0.2
	1:gnumeric-1.8.2-4.fc10.i386 requires libpython2.5.so.1.0
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	graphviz-python-2.20.3-1.fc11.i386 requires python(abi) = 0:2.5
	gtkglextmm-devel-1.2.0-8.fc11.i386 requires pkgconfig(gdkglext-1.0)
	guidance-power-manager-4.1.3-1.fc10.i386 requires python(abi) = 0:2.5
	guidance-power-manager-4.1.3-1.fc10.i386 requires libpython2.5.so.1.0
	hamster-applet-2.24.2-2.fc11.i386 requires python(abi) = 0:2.5
	hulahop-0.4.6-4.fc10.i386 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	liblicense-devel-0.8-3.i386 requires pkgconfig(raptor)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libprelude-python-0.9.21.2-4.fc11.i386 requires python(abi) = 0:2.5
	libprelude-python-0.9.21.2-4.fc11.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	libscigraphica-devel-2.1.1-9.fc11.i386 requires pkgconfig(gtkextra-2.0)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	listen-0.5-19.fc10.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mkinitrd-6.0.73-2.fc11.i386 requires libdhcp-1.99.so.1
	mkinitrd-6.0.73-2.fc11.i386 requires libdhcp6client-1.0.so.2
	mkinitrd-6.0.73-2.fc11.i386 requires libdhcp4client-4.0.so.0
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nash-6.0.73-2.fc11.i386 requires libdhcp6client
	nash-6.0.73-2.fc11.i386 requires libdhcp
	nash-6.0.73-2.fc11.i386 requires libdhcp4client
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	ocaml-SDL-0.7.2-16.fc11.i386 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-bitstring-2.0.0-6.fc11.i386 requires ocaml(Camlp4) = 0:d7e5152f31e867ec87eb7b384dc9c109
	ocaml-camlimages-3.0.1-4.fc11.i386 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-gettext-0.3.2-4.fc11.i386 requires ocaml(Camlp4) = 0:d7e5152f31e867ec87eb7b384dc9c109
	ocaml-gsl-0.6.0-5.fc11.i386 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.i386 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Csv) = 0:ae0aaf6ac1a19f8dfc45722e1b9f6616
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.i386 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.i386 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	olpc-utils-0.89-5.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-5.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.i386 requires python(abi) = 0:2.5
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.i386 requires libpython2.5.so.1.0
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pexpect-2.3-1.fc9.noarch requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-gui-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	plplot-5.9.0-2.svn8985.fc11.i386 requires python(abi) = 0:2.5
	plplot-5.9.0-2.svn8985.fc11.i386 requires libpython2.5.so.1.0
	plplot-gnome-5.9.0-2.svn8985.fc11.i386 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	prewikka-0.9.14-1.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyabiword-0.6.1-3.fc10.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-GnuPGInterface-0.3.2-3.fc9.noarch requires python(abi) = 0:2.5
	python-boto-1.2a-1.fc10.noarch requires python(abi) = 0:2.5
	python-brlapi-0.5.2-1.fc10.i386 requires libpython2.5.so.1.0
	python-brlapi-0.5.2-1.fc10.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rdflib-2.4.0-7.fc10.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-tunepimp-0.5.3-11.fc9.i386 requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pywebkitgtk-1.0.1-2.fc10.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.705289-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	revelation-0.4.11-5.1.i386 requires python(abi) = 0:2.5
	rpy-1.0.3-4.fc10.i386 requires libpython2.5.so.1.0
	rpy-1.0.3-4.fc10.i386 requires python(abi) = 0:2.5
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	scigraphica-2.1.0-6.fc9.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.i386 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13
	xapian-bindings-python-1.0.8-1.fc10.i386 requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ScientificPython-qt-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.x86_64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.x86_64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	avahi-ui-sharp-0.6.22-13.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	beagle-0.3.8-14.fc11.x86_64 requires mono(gmime-sharp) = 0:2.2.0.0
	beagle-evolution-0.3.8-14.fc11.x86_64 requires mono(gmime-sharp) = 0:2.2.0.0
	beagle-thunderbird-0.3.8-14.fc11.x86_64 requires mono(gmime-sharp) = 0:2.2.0.0
	beecrypt-python-4.1.2-17.fc10.x86_64 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	cyphesis-0.5.17-1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	duplicity-0.4.12-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	duplicity-0.4.12-2.fc10.x86_64 requires python(abi) = 0:2.5
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	freeradius-python-2.1.1-8.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ganglia-gmond-python-3.1.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	gdal-python-1.5.3-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	gdal-python-1.5.3-1.fc10.x86_64 requires python(abi) = 0:2.5
	gdl-0.9-0.rc1.4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.i386 requires libltdl.so.3
	gift-0.11.8.1-10.fc9.x86_64 requires libltdl.so.3()(64bit)
	gimmie-0.2.8-2.fc9.x86_64 requires python(abi) = 0:2.5
	glipper-1.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.i386 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.i386 requires libpython2.5.so.1.0
	glom-1.6.17-1.fc10.x86_64 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	gnome-bluetooth-libs-0.11.0-5.fc10.i386 requires python(abi) = 0:2.5
	gnome-bluetooth-libs-0.11.0-5.fc10.x86_64 requires python(abi) = 0:2.5
	gnome-packagekit-0.3.11-1.fc11.x86_64 requires python(abi) = 0:2.5
	gnome-python2-gtkmozembed-2.19.1-25.fc11.x86_64 requires gecko-libs = 0:1.9.0.2
	1:gnumeric-1.8.2-4.fc10.i386 requires libpython2.5.so.1.0
	1:gnumeric-1.8.2-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	graphviz-python-2.20.3-1.fc11.x86_64 requires python(abi) = 0:2.5
	gtkglextmm-devel-1.2.0-8.fc11.i386 requires pkgconfig(gdkglext-1.0)
	gtkglextmm-devel-1.2.0-8.fc11.x86_64 requires pkgconfig(gdkglext-1.0)
	guidance-power-manager-4.1.3-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	guidance-power-manager-4.1.3-1.fc10.x86_64 requires python(abi) = 0:2.5
	hamster-applet-2.24.2-2.fc11.x86_64 requires python(abi) = 0:2.5
	hulahop-0.4.6-4.fc10.x86_64 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
	liblicense-devel-0.8-3.i386 requires pkgconfig(raptor)
	liblicense-devel-0.8-3.x86_64 requires pkgconfig(raptor)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libprelude-python-0.9.21.2-4.fc11.x86_64 requires python(abi) = 0:2.5
	libprelude-python-0.9.21.2-4.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	libscigraphica-devel-2.1.1-9.fc11.i386 requires pkgconfig(gtkextra-2.0)
	libscigraphica-devel-2.1.1-9.fc11.x86_64 requires pkgconfig(gtkextra-2.0)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.x86_64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	listen-0.5-19.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mkinitrd-6.0.73-2.fc11.x86_64 requires libdhcp-1.99.so.1()(64bit)
	mkinitrd-6.0.73-2.fc11.x86_64 requires libdhcp6client-1.0.so.2()(64bit)
	mkinitrd-6.0.73-2.fc11.x86_64 requires libdhcp4client-4.0.so.0()(64bit)
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	muine-devel-0.8.10-3.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nash-6.0.73-2.fc11.i386 requires libdhcp6client
	nash-6.0.73-2.fc11.i386 requires libdhcp
	nash-6.0.73-2.fc11.i386 requires libdhcp4client
	nash-6.0.73-2.fc11.x86_64 requires libdhcp6client
	nash-6.0.73-2.fc11.x86_64 requires libdhcp
	nash-6.0.73-2.fc11.x86_64 requires libdhcp4client
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	ocaml-SDL-0.7.2-16.fc11.x86_64 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-bitstring-2.0.0-6.fc11.x86_64 requires ocaml(Camlp4) = 0:d7e5152f31e867ec87eb7b384dc9c109
	ocaml-camlimages-3.0.1-4.fc11.x86_64 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cil-1.3.6-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-gettext-0.3.2-4.fc11.x86_64 requires ocaml(Camlp4) = 0:d7e5152f31e867ec87eb7b384dc9c109
	ocaml-gsl-0.6.0-5.fc11.x86_64 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.x86_64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Csv) = 0:ae0aaf6ac1a19f8dfc45722e1b9f6616
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_import) = 0:0134ca95282ef6821081c0c11802cea0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.x86_64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	olpc-utils-0.89-5.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-5.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.x86_64 requires python(abi) = 0:2.5
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pexpect-2.3-1.fc9.noarch requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	plplot-5.9.0-2.svn8985.fc11.x86_64 requires python(abi) = 0:2.5
	plplot-5.9.0-2.svn8985.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	plplot-gnome-5.9.0-2.svn8985.fc11.i386 requires python(abi) = 0:2.5
	plplot-gnome-5.9.0-2.svn8985.fc11.x86_64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	prewikka-0.9.14-1.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyabiword-0.6.1-3.fc10.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-GnuPGInterface-0.3.2-3.fc9.noarch requires python(abi) = 0:2.5
	python-boto-1.2a-1.fc10.noarch requires python(abi) = 0:2.5
	python-brlapi-0.5.2-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-brlapi-0.5.2-1.fc10.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-tunepimp-0.5.3-11.fc9.x86_64 requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pywebkitgtk-1.0.1-2.fc10.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.705289-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.705289-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	revelation-0.4.11-5.1.x86_64 requires python(abi) = 0:2.5
	rpy-1.0.3-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	rpy-1.0.3-4.fc10.x86_64 requires python(abi) = 0:2.5
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	scigraphica-2.1.0-6.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.x86_64 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)
	xapian-bindings-python-1.0.8-1.fc10.x86_64 requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.ppc requires libpython2.5.so.1.0
	ScientificPython-qt-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	avahi-ui-sharp-0.6.22-13.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	beagle-0.3.8-14.fc11.ppc requires mono(gmime-sharp) = 0:2.2.0.0
	beagle-evolution-0.3.8-14.fc11.ppc requires mono(gmime-sharp) = 0:2.2.0.0
	beagle-thunderbird-0.3.8-14.fc11.ppc requires mono(gmime-sharp) = 0:2.2.0.0
	beecrypt-python-4.1.2-17.fc10.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Utf8) = 0:9a93366d1857172893046538c18877ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Ulexing) = 0:62a01a8adf79f2414335ce113929c046
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	cduce-0.5.2.1-9.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	cyphesis-0.5.17-1.fc11.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	duplicity-0.4.12-2.fc10.ppc requires python(abi) = 0:2.5
	duplicity-0.4.12-2.fc10.ppc requires libpython2.5.so.1.0
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	freeradius-python-2.1.1-8.fc11.ppc requires libpython2.5.so.1.0
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ganglia-gmond-python-3.1.1-1.fc10.ppc requires libpython2.5.so.1.0
	gdal-python-1.5.3-1.fc10.ppc requires libpython2.5.so.1.0
	gdal-python-1.5.3-1.fc10.ppc requires python(abi) = 0:2.5
	gdl-0.9-0.rc1.4.fc10.ppc requires libpython2.5.so.1.0
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gift-0.11.8.1-10.fc9.ppc requires libltdl.so.3
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gimmie-0.2.8-2.fc9.ppc requires python(abi) = 0:2.5
	glipper-1.0-4.fc10.ppc requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.ppc requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.ppc requires libpython2.5.so.1.0
	glom-1.6.17-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	glom-1.6.17-1.fc10.ppc64 requires python(abi) = 0:2.5
	gnome-bluetooth-libs-0.11.0-5.fc10.ppc requires python(abi) = 0:2.5
	gnome-bluetooth-libs-0.11.0-5.fc10.ppc64 requires python(abi) = 0:2.5
	gnome-packagekit-0.3.11-1.fc11.ppc requires python(abi) = 0:2.5
	gnome-python2-gtkmozembed-2.19.1-25.fc11.ppc requires gecko-libs = 0:1.9.0.2
	1:gnumeric-1.8.2-4.fc10.ppc requires libpython2.5.so.1.0
	1:gnumeric-1.8.2-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	graphviz-python-2.20.3-1.fc11.ppc requires python(abi) = 0:2.5
	gtkglextmm-devel-1.2.0-8.fc11.ppc requires pkgconfig(gdkglext-1.0)
	gtkglextmm-devel-1.2.0-8.fc11.ppc64 requires pkgconfig(gdkglext-1.0)
	guidance-power-manager-4.1.3-1.fc10.ppc requires python(abi) = 0:2.5
	guidance-power-manager-4.1.3-1.fc10.ppc requires libpython2.5.so.1.0
	hamster-applet-2.24.2-2.fc11.ppc requires python(abi) = 0:2.5
	hulahop-0.4.6-4.fc10.ppc requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	liblicense-devel-0.8-3.ppc requires pkgconfig(raptor)
	liblicense-devel-0.8-3.ppc64 requires pkgconfig(raptor)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libprelude-python-0.9.21.2-4.fc11.ppc requires python(abi) = 0:2.5
	libprelude-python-0.9.21.2-4.fc11.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libscigraphica-devel-2.1.1-9.fc11.ppc requires pkgconfig(gtkextra-2.0)
	libscigraphica-devel-2.1.1-9.fc11.ppc64 requires pkgconfig(gtkextra-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	listen-0.5-19.fc10.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mkinitrd-6.0.73-2.fc11.ppc requires libdhcp-1.99.so.1
	mkinitrd-6.0.73-2.fc11.ppc requires libdhcp6client-1.0.so.2
	mkinitrd-6.0.73-2.fc11.ppc requires libdhcp4client-4.0.so.0
	muine-devel-0.8.10-3.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nash-6.0.73-2.fc11.ppc requires libdhcp6client
	nash-6.0.73-2.fc11.ppc requires libdhcp
	nash-6.0.73-2.fc11.ppc requires libdhcp4client
	nash-6.0.73-2.fc11.ppc64 requires libdhcp6client
	nash-6.0.73-2.fc11.ppc64 requires libdhcp
	nash-6.0.73-2.fc11.ppc64 requires libdhcp4client
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	ocaml-SDL-0.7.2-16.fc11.ppc requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-bitstring-2.0.0-6.fc11.ppc requires ocaml(Camlp4) = 0:d7e5152f31e867ec87eb7b384dc9c109
	ocaml-camlimages-3.0.1-4.fc11.ppc requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-gettext-0.3.2-4.fc11.ppc requires ocaml(Camlp4) = 0:d7e5152f31e867ec87eb7b384dc9c109
	ocaml-gsl-0.6.0-5.fc11.ppc requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Csv) = 0:ae0aaf6ac1a19f8dfc45722e1b9f6616
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pxp-1.2.0test2-3.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	olpc-utils-0.89-5.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-5.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.ppc requires python(abi) = 0:2.5
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.ppc requires libpython2.5.so.1.0
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pexpect-2.3-1.fc9.noarch requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	plplot-5.9.0-2.svn8985.fc11.ppc requires python(abi) = 0:2.5
	plplot-5.9.0-2.svn8985.fc11.ppc requires libpython2.5.so.1.0
	plplot-gnome-5.9.0-2.svn8985.fc11.ppc requires python(abi) = 0:2.5
	plplot-gnome-5.9.0-2.svn8985.fc11.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	prewikka-0.9.14-1.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyabiword-0.6.1-3.fc10.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-GnuPGInterface-0.3.2-3.fc9.noarch requires python(abi) = 0:2.5
	python-boto-1.2a-1.fc10.noarch requires python(abi) = 0:2.5
	python-brlapi-0.5.2-1.fc10.ppc requires libpython2.5.so.1.0
	python-brlapi-0.5.2-1.fc10.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-tunepimp-0.5.3-11.fc9.ppc requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pywebkitgtk-1.0.1-2.fc10.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	revelation-0.4.11-5.1.ppc requires python(abi) = 0:2.5
	rpy-1.0.3-4.fc10.ppc requires libpython2.5.so.1.0
	rpy-1.0.3-4.fc10.ppc requires python(abi) = 0:2.5
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	scigraphica-2.1.0-6.fc9.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.ppc requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13
	xapian-bindings-python-1.0.8-1.fc10.ppc requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ScientificPython-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	ScientificPython-qt-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	beecrypt-python-4.1.2-17.fc10.ppc64 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	cyphesis-0.5.17-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	duplicity-0.4.12-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	duplicity-0.4.12-2.fc10.ppc64 requires python(abi) = 0:2.5
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	freeradius-python-2.1.1-8.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ganglia-gmond-python-3.1.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gdal-python-1.5.3-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gdal-python-1.5.3-1.fc10.ppc64 requires python(abi) = 0:2.5
	gdl-0.9-0.rc1.4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gimmie-0.2.8-2.fc9.ppc64 requires python(abi) = 0:2.5
	glipper-1.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	glom-1.6.17-1.fc10.ppc64 requires python(abi) = 0:2.5
	gnome-bluetooth-libs-0.11.0-5.fc10.ppc64 requires python(abi) = 0:2.5
	gnome-packagekit-0.3.11-1.fc11.ppc64 requires python(abi) = 0:2.5
	gnome-python2-gtkmozembed-2.19.1-25.fc11.ppc64 requires gecko-libs = 0:1.9.0.2
	1:gnumeric-1.8.2-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	graphviz-python-2.20.3-1.fc11.ppc64 requires python(abi) = 0:2.5
	gtkglextmm-devel-1.2.0-8.fc11.ppc64 requires pkgconfig(gdkglext-1.0)
	guidance-power-manager-4.1.3-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	guidance-power-manager-4.1.3-1.fc10.ppc64 requires python(abi) = 0:2.5
	hamster-applet-2.24.2-2.fc11.ppc64 requires python(abi) = 0:2.5
	hulahop-0.4.6-4.fc10.ppc64 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	liblicense-devel-0.8-3.ppc64 requires pkgconfig(raptor)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libprelude-python-0.9.21.2-4.fc11.ppc64 requires python(abi) = 0:2.5
	libprelude-python-0.9.21.2-4.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libscigraphica-devel-2.1.1-9.fc11.ppc64 requires pkgconfig(gtkextra-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	listen-0.5-19.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mkinitrd-6.0.73-2.fc11.ppc64 requires libdhcp-1.99.so.1()(64bit)
	mkinitrd-6.0.73-2.fc11.ppc64 requires libdhcp6client-1.0.so.2()(64bit)
	mkinitrd-6.0.73-2.fc11.ppc64 requires libdhcp4client-4.0.so.0()(64bit)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nash-6.0.73-2.fc11.ppc64 requires libdhcp6client
	nash-6.0.73-2.fc11.ppc64 requires libdhcp
	nash-6.0.73-2.fc11.ppc64 requires libdhcp4client
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	ocaml-SDL-0.7.2-16.fc11.ppc64 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-bitstring-2.0.0-6.fc11.ppc64 requires ocaml(Camlp4) = 0:d7e5152f31e867ec87eb7b384dc9c109
	ocaml-camlimages-3.0.1-4.fc11.ppc64 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-gettext-0.3.2-4.fc11.ppc64 requires ocaml(Camlp4) = 0:d7e5152f31e867ec87eb7b384dc9c109
	ocaml-gsl-0.6.0-5.fc11.ppc64 requires ocaml(Gc) = 0:8085fbcf44309957e64bbd3332be7fff
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-json-wheel-1.0.4-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-mikmatch-1.0.0-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlgraph-0.99c-2.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GData) = 0:cf8a65e92eec6538a65ff69a7c7ab62b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gtk) = 0:0d6f4ec0bf1a7b2e5e41286f20c3c5ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GDraw) = 0:de5e7d153111cf2106f02ce7333bd650
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Types) = 0:df897aed3fc89c2129322c17067857b8
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gpointer) = 0:72eda5d9f0d59b5972aa22fcecf67daa
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gdk) = 0:4cac9e9df9320b71cd77db9bff9f1b91
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Env) = 0:6d0215253b3fde95601c34944cacb607
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Path) = 0:d8bc8e7163bac3a9a0a93f1cb07092d1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ident) = 0:ba1acc56fc179d27bd55278cbc2abf40
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Weak) = 0:6d509339939dea165d9dfd44d8a6a035
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Oo) = 0:d1fd8eab2c1fb52f42b20d2c4fa47731
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GPango) = 0:c3e2d4654a26d85b0800cfa7d17f76d0
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GObj) = 0:53dd7a4179f73c3626b38ea930595387
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Ssl) = 0:324220f216777300ec27ca4377a7572a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Longident) = 0:46fb8aad4fb2c12a0f301b02d8139f07
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkSignal) = 0:513bc46de3006ac18ee73bbe252bbaf6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gobject) = 0:c0ecf32dba4d98abfabf69278beb91f5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Consistbl) = 0:47f9cdffda6ba2de99c8e9f0c0c1b34d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkEvent) = 0:7bbe2249f0e29f2f646affd9314e938d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GtkStock) = 0:f647e114242729fbdcd203cc5c09cb59
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gc) = 0:3c11fc69ccb4eb611e4cf313a52c3a2d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Location) = 0:eed044ad1204a633caad97bdd9048f8c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Thread) = 0:4d689a17935ae01464f9b634e77c2e6f
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Primitive) = 0:43a2770aed8fbcc536ab39d717fe9a7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Genlex) = 0:d4f22baa55ba132f6cc3bf2ec6671ffd
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Gaux) = 0:1f8c3af1ec44d0b19146161a687dd947
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Mutex) = 0:855af44384a5465360efe6e8bff546ab
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GdkPixbuf) = 0:a5ff570e45ecdc9c9213f393f8d57f2b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-2.2.9-7.fc10.ppc64 requires ocaml(GMain) = 0:28826dd38aa448cf7aad65bf99740f3a
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-ocamlnet-nethttpd-2.2.9-7.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pa-monad-1.2.0-5.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Str) = 0:56bb7ee61b2da83d42394686e3558fe4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Option) = 0:77e72c890789e19a0e7444e00377d171
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Calendar) = 0:bf2d533aa4bba61b1d373c5d237d52f0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Digest) = 0:a5dd2d89492338578de12105e88c803f
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Enum) = 0:c16e527384c2b6d71d8b19582503f5f1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Csv) = 0:ae0aaf6ac1a19f8dfc45722e1b9f6616
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Pcre) = 0:9cf03a45728e3cf29272c957775befee
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtString) = 0:a3a294a12ef901b2e812ef847ce8c233
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(ExtList) = 0:f0f729e9c5635a8010fc862a9c31fed4
	ocaml-pgocaml-1.1-4.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Random) = 0:9936935480b36bcbc716ee513f37876c
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Map) = 0:dedde7683d54ae7db1eb97cc868dd047
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-reins-0.1a-2.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Set) = 0:7da14e671a035f12386ace3890018ef3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nat) = 0:0ea20dd1cc4533fd519b5542a89feb87
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Num) = 0:cfa2705c9c6d6f5a56b83f91fc630d2a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Stack) = 0:132c3f280681fcc39900477f79c7096b
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Int64) = 0:f8f7e2e4c0667ead94596040b12e732d
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Ratio) = 0:7067125cce206dd2bbe93918ba7bdfe9
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Char) = 0:e98bc9c9e918a84b3c1a5a122d42fac1
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_import) = 0:b41a1895cf301f0c8e37e5462feb4dc7
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4) = 0:1e46a133b8062d1571640f7fa36f32c4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Bigarray) = 0:e881a834bafaaa24bc612d94119cc0f5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Filename) = 0:633a1e7f590ff5e95124293dbef3b476
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Pa_type_conv) = 0:dbb7b8444ffb4d658cbf9b40bc73a870
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	ocaml-sexplib-4.0.1-1.fc10.ppc64 requires ocaml(Big_int) = 0:992d682669507b99e689b5a2188c0b9a
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(runtime) = 0:3.10.2
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printexc) = 0:82717999a586ede6925c0aa18d6562ac
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Xml) = 0:06113979902326aeb173e83414f141d7
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Int32) = 0:711321870c949bd3bbdd092d9bae92e4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(List) = 0:da1ce9168f0408ff26158af757456948
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Sys) = 0:0da495f5a80f31899139359805318f28
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Scanf) = 0:03364fa23e007821f9d76a0f078ed6d6
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Lazy) = 0:8a4b5e7f0bdc6316df9264fd73cde981
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(CamlinternalOO) = 0:6d0d5b328d6db88f403ca4393b4abd38
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Arg) = 0:03e86a4154064ea900dc32c05f53e364
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Buffer) = 0:f6cef633ea14963b84b79c4095c63dc3
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Hashtbl) = 0:083f2c94b44ff4e0b3220aaea6a783b4
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Format) = 0:35fe566f7a37d8991a5c822bd1463949
	ocaml-xmlrpc-light-0.6-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	olpc-utils-0.89-5.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-5.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.ppc64 requires python(abi) = 0:2.5
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pexpect-2.3-1.fc9.noarch requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	plplot-5.9.0-2.svn8985.fc11.ppc64 requires python(abi) = 0:2.5
	plplot-5.9.0-2.svn8985.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	plplot-gnome-5.9.0-2.svn8985.fc11.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	prewikka-0.9.14-1.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyabiword-0.6.1-3.fc10.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-GnuPGInterface-0.3.2-3.fc9.noarch requires python(abi) = 0:2.5
	python-boto-1.2a-1.fc10.noarch requires python(abi) = 0:2.5
	python-brlapi-0.5.2-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-brlapi-0.5.2-1.fc10.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-tunepimp-0.5.3-11.fc9.ppc64 requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	pywebkitgtk-1.0.1-2.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	revelation-0.4.11-5.1.ppc64 requires python(abi) = 0:2.5
	rpy-1.0.3-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	rpy-1.0.3-4.fc10.ppc64 requires python(abi) = 0:2.5
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	scigraphica-2.1.0-6.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.ppc64 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)
	xapian-bindings-python-1.0.8-1.fc10.ppc64 requires python(abi) = 0:2.5





From mark.bidewell at alumni.clemson.edu  Fri Dec  5 14:24:20 2008
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Fri, 5 Dec 2008 09:24:20 -0500
Subject: Fedora 10 and YUM
In-Reply-To: <645d17210812040646h3f6514ddj281eaa2038e5bd0@mail.gmail.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
	<4937E458.3000106@niemueller.de>
	<645d17210812040646h3f6514ddj281eaa2038e5bd0@mail.gmail.com>
Message-ID: <bfdeacfa0812050624l3185dd5pf9fdb3d7fb829b11@mail.gmail.com>

On Thu, Dec 4, 2008 at 9:46 AM, Jonathan Underwood <
jonathan.underwood at gmail.com> wrote:

> 2008/12/4 Tim Niemueller <tim at niemueller.de>:
> > Seth Vidal schrieb:
> >>
> >> What does 'svn up' have to do with yum?
> >
> > I think not yum is the problem but there is a more general problem
> > related to DNS lookups. As a specialty I'm using nss-mdns. But on
> > F-8/F-9 this has never been a problem, so I suspect this is not what is
> > causing the problem, especially because others have the same problem and
> > I don't think nss-mdns is installed on many machines.
>
> This could well all be due to this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=459756
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


I noticed that the thread mentions running DNSmasq as a proxy on an F10
system as a workaround.  I am running DNSmasq on my router as part of
DD-WRT.  should this have the same effect?

Mark Bidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/b60b838b/attachment.htm>

From notting at redhat.com  Fri Dec  5 13:54:22 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 5 Dec 2008 08:54:22 -0500
Subject: starting a service if a subpackage is installed
In-Reply-To: <20081205095334.GB17710@free.fr>
References: <20081205095334.GB17710@free.fr>
Message-ID: <20081205135422.GA11026@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> I'd like to have a way to start fcron automatically, but only if a
> subpackage is installed. I have (locally) implemented the following:
> 
> The initscripts are started automatically, but they do:
> 
>  [ -e /etc/sysconfig/fcron ] && . /etc/sysconfig/fcron
>  case "$1" in
>   start)
>         if [ "z$FCROND_STARTUP" = 'z' ]; then
>            exit 6
>         fi
> 
> So if $FCROND_STARTUP is not set they won't start. Then I have package
> that only contains /etc/sysconfig/fcron, called fcron-startup, with, in
> /etc/sysconfig/fcron:
> 
> FCROND_STARTUP=1

Just rely on admin configuration, like is done for every other
service.

Bill



From mdehaan at redhat.com  Fri Dec  5 14:42:43 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 05 Dec 2008 09:42:43 -0500
Subject: The looming Python 3(000) monster
Message-ID: <49393DE3.1080707@redhat.com>


We're just now dealing with Python 2.6, but over on the radar is perhaps 
one of the most incompatible upgrades to the language we've seen in 
Python 3.  I personally haven't tried it yet, but it /aims/ to be 
incompatble, which is perhaps one of the most glaring signs a language 
designer has lost it that I've seen.

http://docs.python.org/3.0/whatsnew/3.0.html

This isn't a huge problem to those who are only developing on the latest 
Fedora, per-se (other than getting over the initial hump), but it's 
pretty bad for someone who wants to keep a single codebase across EL 4 
(Python 2.3) and up, which I think a lot of us do.   That gets to be 
darn impossible and we have to double our involvement with code because 
we essentially have to maintain a differently-compatible fork for each 
project.

(NOTE: this requires the viewpoint that not everyone care just about the 
latest Fedora, which might be controversial... but to me, the latest 
Fedora is what I'll run as my dev environment but not everyone can 
upgrade -- and many folks are also running EL and EPEL deserves our full 
support and consideration)

So, what of plans?

Are we looking at also carrying on with packaging 2.N indefinitely when 
we do decide to carry 3, because as I know it, the code changes to make 
something Python 3 compatible will be severe and that's a big item for 
any release, and will probably result in some undiscovered bugs even 
after the initial ports (if applied).

I haven't seen /anything/ regarding a compatibility mode for 
/usr/bin/python, and I'd hate to have to develop a non-core library that 
allows for functions that work the same way on both versions and use 
that instead.  That would be heinous.

Short of porting everything over to Ruby, oCaml, or 
enterprise-Fortran.NET#4000, any ideas on planning for this?

--Michael



From limb at jcomserv.net  Fri Dec  5 14:49:26 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 5 Dec 2008 08:49:26 -0600 (CST)
Subject: The looming Python 3(000) monster
In-Reply-To: <49393DE3.1080707@redhat.com>
References: <49393DE3.1080707@redhat.com>
Message-ID: <e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>


>
> We're just now dealing with Python 2.6, but over on the radar is perhaps
> one of the most incompatible upgrades to the language we've seen in
> Python 3.  I personally haven't tried it yet, but it /aims/ to be
> incompatble, which is perhaps one of the most glaring signs a language
> designer has lost it that I've seen.
>
> http://docs.python.org/3.0/whatsnew/3.0.html
>
> This isn't a huge problem to those who are only developing on the latest
> Fedora, per-se (other than getting over the initial hump), but it's
> pretty bad for someone who wants to keep a single codebase across EL 4
> (Python 2.3) and up, which I think a lot of us do.   That gets to be
> darn impossible and we have to double our involvement with code because
> we essentially have to maintain a differently-compatible fork for each
> project.
>
> (NOTE: this requires the viewpoint that not everyone care just about the
> latest Fedora, which might be controversial... but to me, the latest
> Fedora is what I'll run as my dev environment but not everyone can
> upgrade -- and many folks are also running EL and EPEL deserves our full
> support and consideration)
>
> So, what of plans?
>
> Are we looking at also carrying on with packaging 2.N indefinitely when
> we do decide to carry 3, because as I know it, the code changes to make
> something Python 3 compatible will be severe and that's a big item for
> any release, and will probably result in some undiscovered bugs even
> after the initial ports (if applied).
>
> I haven't seen /anything/ regarding a compatibility mode for
> /usr/bin/python, and I'd hate to have to develop a non-core library that
> allows for functions that work the same way on both versions and use
> that instead.  That would be heinous.
>
> Short of porting everything over to Ruby, oCaml, or
> enterprise-Fortran.NET#4000, any ideas on planning for this?

Well, this:

http://docs.python.org/3.0/library/2to3.html#to3-reference

should be helpful.  The work being done on 2.6 now is an excellent first
step.

Other than that, I think we'll have to treat it like any other major
change, such as gcc-4.3, etc.

It's gonna hurt, and obviously we'll need a compat-python26, but I think
we'll be able to port things over, and have them either use Python3k or
compat- as needed.  Not sure when we'd be completely cut over, but I'd
love to see 2.6 the default in F11, which I believe is the plan, and Py3k
in the not too distant future*, F12.

> --Michael
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

* or maybe next Sunday A.D. :)

-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From mdehaan at redhat.com  Fri Dec  5 14:54:17 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 05 Dec 2008 09:54:17 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
Message-ID: <49394099.4040205@redhat.com>

Jon Ciesla wrote:
>> We're just now dealing with Python 2.6, but over on the radar is perhaps
>> one of the most incompatible upgrades to the language we've seen in
>> Python 3.  I personally haven't tried it yet, but it /aims/ to be
>> incompatble, which is perhaps one of the most glaring signs a language
>> designer has lost it that I've seen.
>>
>> http://docs.python.org/3.0/whatsnew/3.0.html
>>
>> This isn't a huge problem to those who are only developing on the latest
>> Fedora, per-se (other than getting over the initial hump), but it's
>> pretty bad for someone who wants to keep a single codebase across EL 4
>> (Python 2.3) and up, which I think a lot of us do.   That gets to be
>> darn impossible and we have to double our involvement with code because
>> we essentially have to maintain a differently-compatible fork for each
>> project.
>>
>> (NOTE: this requires the viewpoint that not everyone care just about the
>> latest Fedora, which might be controversial... but to me, the latest
>> Fedora is what I'll run as my dev environment but not everyone can
>> upgrade -- and many folks are also running EL and EPEL deserves our full
>> support and consideration)
>>
>> So, what of plans?
>>
>> Are we looking at also carrying on with packaging 2.N indefinitely when
>> we do decide to carry 3, because as I know it, the code changes to make
>> something Python 3 compatible will be severe and that's a big item for
>> any release, and will probably result in some undiscovered bugs even
>> after the initial ports (if applied).
>>
>> I haven't seen /anything/ regarding a compatibility mode for
>> /usr/bin/python, and I'd hate to have to develop a non-core library that
>> allows for functions that work the same way on both versions and use
>> that instead.  That would be heinous.
>>
>> Short of porting everything over to Ruby, oCaml, or
>> enterprise-Fortran.NET#4000, any ideas on planning for this?
>>     
>
> Well, this:
>
> http://docs.python.org/3.0/library/2to3.html#to3-reference
>
> should be helpful.  The work being done on 2.6 now is an excellent first
> step.
>
> Other than that, I think we'll have to treat it like any other major
> change, such as gcc-4.3, etc.
>
> It's gonna hurt, and obviously we'll need a compat-python26, but I think
> we'll be able to port things over, and have them either use Python3k or
> compat- as needed.  Not sure when we'd be completely cut over, but I'd
> love to see 2.6 the default in F11, which I believe is the plan, and Py3k
> in the not too distant future*, F12.
>
>   
>> --Michael
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>>     
>
> * or maybe next Sunday A.D. :)
>
>   
You're suggesting running 2.3 at each build time?  I hope we can trust 
it that much and it knows how to automatically port all possibilities.

Otherwise we get into a fork situation.   The initial switchover does 
not concern me so much as a dual maintaince problem.

A new gcc didn't really require that I stop using print() in the source, 
it was mostly a build thing, no?

--Michael



From abu_hurayrah at hidayahonline.org  Fri Dec  5 14:52:45 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Fri, 05 Dec 2008 16:52:45 +0200
Subject: The looming Python 3(000) monster
In-Reply-To: <49393DE3.1080707@redhat.com>
References: <49393DE3.1080707@redhat.com>
Message-ID: <1228488785.3386.18.camel@beta>

On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
> We're just now dealing with Python 2.6, but over on the radar is perhaps 
> one of the most incompatible upgrades to the language we've seen in 
> Python 3.  I personally haven't tried it yet, but it /aims/ to be 
> incompatble, which is perhaps one of the most glaring signs a language 
> designer has lost it that I've seen.
> 
> http://docs.python.org/3.0/whatsnew/3.0.html
> 
> This isn't a huge problem to those who are only developing on the latest 
> Fedora, per-se (other than getting over the initial hump), but it's 
> pretty bad for someone who wants to keep a single codebase across EL 4 
> (Python 2.3) and up, which I think a lot of us do.   That gets to be 
> darn impossible and we have to double our involvement with code because 
> we essentially have to maintain a differently-compatible fork for each 
> project.
> 
> (NOTE: this requires the viewpoint that not everyone care just about the 
> latest Fedora, which might be controversial... but to me, the latest 
> Fedora is what I'll run as my dev environment but not everyone can 
> upgrade -- and many folks are also running EL and EPEL deserves our full 
> support and consideration)
> 
> So, what of plans?
> 
> Are we looking at also carrying on with packaging 2.N indefinitely when 
> we do decide to carry 3, because as I know it, the code changes to make 
> something Python 3 compatible will be severe and that's a big item for 
> any release, and will probably result in some undiscovered bugs even 
> after the initial ports (if applied).
> 
> I haven't seen /anything/ regarding a compatibility mode for 
> /usr/bin/python, and I'd hate to have to develop a non-core library that 
> allows for functions that work the same way on both versions and use 
> that instead.  That would be heinous.
> 
> Short of porting everything over to Ruby, oCaml, or 
> enterprise-Fortran.NET#4000, any ideas on planning for this?
> 
> --Michael
> 
I'm not a Python developer, but I have been reading with a lot of
interest the upgrade in Fedora to 2.6 as well as the release of this new
dynamic programming language named "Python 3000".  It seems that the
prevailing wisdom, which fits with the scenario you have mentioned, is
to make everything work now with 2.6, and then the 2to3 utility will
make the move to 3000 much easier, if not painless.

Of course, again, not being Pythonic myself, this all sounds good to me,
but the devilish details are not apparent either.



From mdehaan at redhat.com  Fri Dec  5 14:56:39 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 05 Dec 2008 09:56:39 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
Message-ID: <49394127.3050108@redhat.com>


> Well, this:
>
> http://docs.python.org/3.0/library/2to3.html#to3-reference
>
>
>   
>   

Here's the problem:

"""
Sometimes 2to3 will find a place in your source code that needs to be 
changed, but 2to3 cannot fix automatically. In this case, 2to3 will 
print a warning beneath the diff for a file. You should address the 
warning in order to have compliant 3.x code.
"""

So it means we can't dual maintain code easily between two 
branches/versions.

Something to try out now, for sure, though, I'd think ... so we can 
anticipate what may happen.   Though trying this out without having 
Python 3.X built versions of all the libraries any given app might need 
to complete it's tests yet is going to be slightly fun.

--Michael





From ivazqueznet at gmail.com  Fri Dec  5 14:57:32 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 05 Dec 2008 09:57:32 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <49393DE3.1080707@redhat.com>
References: <49393DE3.1080707@redhat.com>
Message-ID: <1228489052.29612.158.camel@ignacio.lan>

On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
> Short of porting everything over to Ruby, oCaml, or 
> enterprise-Fortran.NET#4000, any ideas on planning for this?

I think we should continue on to 2.7 and 2.8; this will give us the time
we need to bring the compatibility versions into EL and inch us closer
to Python 3000.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/eb406c1f/attachment.sig>

From mcepl at redhat.com  Fri Dec  5 14:51:24 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 05 Dec 2008 15:51:24 +0100
Subject: The looming Python 3(000) monster
References: <49393DE3.1080707@redhat.com>
Message-ID: <corn06xveo.ln2@ppp1053.in.ipex.cz>

On 2008-12-05, 14:42 GMT, Michael DeHaan wrote:
> I personally haven't tried it yet, but it /aims/ to be 
> incompatble, which is perhaps one of the most glaring signs 
> a language designer has lost it that I've seen.

Guido was preparing on this incompatibility for years, so unless 
you were sleeping you should not be surprised.

> but it's pretty bad for someone who wants to keep a single 
> codebase across EL 4 (Python 2.3) and up, which I think a lot 
> of us do.

The party line is that you should develop against python 2.6 
(which doesn't block you from being compatible with Python 2.3) 
and then conversion from 2.6 to 3.* would be guaranteed to be 
done just with a script.

Mat?j



From limb at jcomserv.net  Fri Dec  5 15:07:58 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 5 Dec 2008 09:07:58 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
Message-ID: <f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>


>
>> On Wed, Dec 03, 2008 at 03:27:48PM -0600, Jon Ciesla wrote:
>>>
>>> >> I suggest starting the NRM process:
>>> >> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
>>> >>
>>> >
>>> > It has already started. Bugs have been filed. Attempts to contact
>>> have
>>> > been made. It's been months with zero contact.
>>> >
>>> > I guess the next step is to ask: who can take up these packages?
>>> >
>>> I could take a crack at gallery2.
>>
>> Are you able to maintain an EPEL version as well?  At least for EL-5.
>
> Yes, I already do for Drupal and a few other PHP apps.

I think I've got an updated version of gallery2 ready.  When will the NRM
process complete and the packages orphaned? It's somewhat academic as I'm
a provenpackager, I just don't want to step on any toes.

>> Ray
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
>
> --
> in your fear, speak only peace
> in your fear, speak only love
>
> -d. bowie
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From rjones at redhat.com  Fri Dec  5 15:09:38 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 5 Dec 2008 15:09:38 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <49393DE3.1080707@redhat.com>
References: <49393DE3.1080707@redhat.com>
Message-ID: <20081205150938.GA4142@thinkpad>

For Windows cross-compilation of Python libraries, we decided that
Python 2.x's build system is crazy, so we would only support Python 3
from the beginning.  The reason is so that we can get build system
patches upstream easily without having to maintain patches against all
the different branches (ie. against 2.5, 2.6, 3.0, devel).

So if you want your Python program to work with the Fedora MinGW
cross-compiler, you'd better try it out with the 'python -3' option
and fix any deprecated bits.

Rich.

... Or take the opportunity to jump to a safe language .. we've
already got an OCaml cross-compiler.



From berrange at redhat.com  Fri Dec  5 15:09:49 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 5 Dec 2008 15:09:49 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <49393DE3.1080707@redhat.com>
References: <49393DE3.1080707@redhat.com>
Message-ID: <20081205150949.GD4290@redhat.com>

On Fri, Dec 05, 2008 at 09:42:43AM -0500, Michael DeHaan wrote:
> 
> We're just now dealing with Python 2.6, but over on the radar is perhaps 
> one of the most incompatible upgrades to the language we've seen in 
> Python 3.  I personally haven't tried it yet, but it /aims/ to be 
> incompatble, which is perhaps one of the most glaring signs a language 
> designer has lost it that I've seen.
> 
> http://docs.python.org/3.0/whatsnew/3.0.html
> 
> This isn't a huge problem to those who are only developing on the latest 
> Fedora, per-se (other than getting over the initial hump), but it's 
> pretty bad for someone who wants to keep a single codebase across EL 4 
> (Python 2.3) and up, which I think a lot of us do.   That gets to be 
> darn impossible and we have to double our involvement with code because 
> we essentially have to maintain a differently-compatible fork for each 
> project.
> 
> (NOTE: this requires the viewpoint that not everyone care just about the 
> latest Fedora, which might be controversial... but to me, the latest 
> Fedora is what I'll run as my dev environment but not everyone can 
> upgrade -- and many folks are also running EL and EPEL deserves our full 
> support and consideration)
> 
> So, what of plans?
> 
> Are we looking at also carrying on with packaging 2.N indefinitely when 
> we do decide to carry 3, because as I know it, the code changes to make 
> something Python 3 compatible will be severe and that's a big item for 
> any release, and will probably result in some undiscovered bugs even 
> after the initial ports (if applied).
> 
> I haven't seen /anything/ regarding a compatibility mode for 
> /usr/bin/python, and I'd hate to have to develop a non-core library that 
> allows for functions that work the same way on both versions and use 
> that instead.  That would be heinous.

IMHO the only viable option is to maintain both python 2.x and 3.x
in parallel. It is essentially a brand new language which just
happens to share the same base name. Like Perl 5 & Perl 6.

It is going to be a very long time before every upstream for all our
python bits support 3.x syntax and we don't want to have to undertake
the work to re-write them all ourselves.

The delibrate break of syntax is going to cause a major PITA for
upstream projects because there's no way they can stop shipping
2.x compatible code just because some people want to use 3.x. So
every upstream pretty much has to now maintain two sets of python
bindings :-(

Daniel
-- 
|: Red Hat, Engineering, London   -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 rjones at redhat.com  Fri Dec  5 15:11:34 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 5 Dec 2008 15:11:34 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <49394127.3050108@redhat.com>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<49394127.3050108@redhat.com>
Message-ID: <20081205151134.GB4142@thinkpad>

On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
> So it means we can't dual maintain code easily between two  
> branches/versions.

Isn't it the case that you can use 3.x features in 2.6, using the
'from future import ...' syntax?

http://www.python.org/dev/peps/pep-0236/

Rich.



From notting at redhat.com  Fri Dec  5 15:13:05 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 5 Dec 2008 10:13:05 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <1228489052.29612.158.camel@ignacio.lan>
References: <49393DE3.1080707@redhat.com>
	<1228489052.29612.158.camel@ignacio.lan>
Message-ID: <20081205151305.GA13097@nostromo.devel.redhat.com>

Ignacio Vazquez-Abrams (ivazqueznet at gmail.com) said: 
> On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
> > Short of porting everything over to Ruby, oCaml, or 
> > enterprise-Fortran.NET#4000, any ideas on planning for this?
> 
> I think we should continue on to 2.7 and 2.8; this will give us the time
> we need to bring the compatibility versions into EL and inch us closer
> to Python 3000.

Only one version of EL, though. It's not like RHEL 4/5 are going
to move to new python.

Bill



From james at fedoraproject.org  Fri Dec  5 15:14:38 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 05 Dec 2008 10:14:38 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
Message-ID: <1228490078.26618.163.camel@code.and.org>

On Fri, 2008-12-05 at 08:49 -0600, Jon Ciesla wrote:
> >
> > We're just now dealing with Python 2.6, but over on the radar is perhaps
> > one of the most incompatible upgrades to the language we've seen in
> > Python 3.  I personally haven't tried it yet, but it /aims/ to be
> > incompatble, which is perhaps one of the most glaring signs a language
> > designer has lost it that I've seen.
> >
> > http://docs.python.org/3.0/whatsnew/3.0.html
> >
> > This isn't a huge problem to those who are only developing on the latest
> > Fedora, per-se (other than getting over the initial hump), but it's
> > pretty bad for someone who wants to keep a single codebase across EL 4
> > (Python 2.3) and up, which I think a lot of us do.   That gets to be
> > darn impossible and we have to double our involvement with code because
> > we essentially have to maintain a differently-compatible fork for each
> > project.
> >
> > (NOTE: this requires the viewpoint that not everyone care just about the
> > latest Fedora, which might be controversial... but to me, the latest
> > Fedora is what I'll run as my dev environment but not everyone can
> > upgrade -- and many folks are also running EL and EPEL deserves our full
> > support and consideration)
> >
> > So, what of plans?

 There is no real plan atm.

> > Are we looking at also carrying on with packaging 2.N indefinitely when
> > we do decide to carry 3, because as I know it, the code changes to make
> > something Python 3 compatible will be severe and that's a big item for
> > any release, and will probably result in some undiscovered bugs even
> > after the initial ports (if applied).
> >
> > I haven't seen /anything/ regarding a compatibility mode for
> > /usr/bin/python, and I'd hate to have to develop a non-core library that
> > allows for functions that work the same way on both versions and use
> > that instead.  That would be heinous.
> >
> > Short of porting everything over to Ruby, oCaml, or
> > enterprise-Fortran.NET#4000, any ideas on planning for this?
> 
> Well, this:
> 
> http://docs.python.org/3.0/library/2to3.html#to3-reference
> 
> should be helpful.  The work being done on 2.6 now is an excellent first
> step.
> 
> Other than that, I think we'll have to treat it like any other major
> change, such as gcc-4.3, etc.
> 
> It's gonna hurt, and obviously we'll need a compat-python26, but I think
> we'll be able to port things over, and have them either use Python3k or
> compat- as needed.

 It has been requested for us to do dual installs of python multiple
times now, and in each case it was voted down.
 Because with GCC, we just have a second GCC, but with python we need a
second version of every module that uses it. Imagine if a second GCC
required a second version of every package that required a shared
library.

 We also have _much less_ resources dedicated to python than we do GCC.
 My guess is that if a second python is proposed for py3k, it'll get
voted down again.

 Add onto that the fact that lots of python code is going to break in
3.0, and the fact that 3.0 seems utterly broken wrt. unicode, from bits
I've heard.
 Then there's the fact that for the next 6-12 months people will want to
be developing things that still work with python-2.4.* (as that's what
is in RHEL-5/CentOS-5).

>   Not sure when we'd be completely cut over, but I'd
> love to see 2.6 the default in F11, which I believe is the plan, and Py3k
> in the not too distant future*, F12.

 hahaha, I'll put money on python3k not being the default in Fedora 12.
Hell, I'll even put some money on it not being the default in Fedora 14,
at this point.

 My personal opinion is that we stay with 2.6.* for as long as possible,
giving everyone time to dual port and the problems to be found/fixed and
then it "should be easy" to have it as a feature and move for one
release.

 But I'll point out that Ignacio Vazquez-Abrams did _all_ the work for
2.6 in Fedora 11 ... so feel free to take this as just my opinion.

-- 
James Antill <james at fedoraproject.org>
Fedora



From jamatos at fc.up.pt  Fri Dec  5 15:14:25 2008
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Fri, 5 Dec 2008 15:14:25 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <corn06xveo.ln2@ppp1053.in.ipex.cz>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
Message-ID: <200812051514.25261.jamatos@fc.up.pt>

On Friday 05 December 2008 14:51:24 Matej Cepl wrote:
> On 2008-12-05, 14:42 GMT, Michael DeHaan wrote:
> > I personally haven't tried it yet, but it /aims/ to be
> > incompatble, which is perhaps one of the most glaring signs
> > a language designer has lost it that I've seen.
>
> Guido was preparing on this incompatibility for years, so unless
> you were sleeping you should not be surprised.

For more than 9 years and it intends to fix some inconsistencies that had 
grown with the language for more than 18 years (python was initially released 
in 1989).

The plan was well laid there are plans to ease the upgrade.

If you (Michael) wish we can consider in a sense that python 2 and python are 
two different (although closed related) languages.

-- 
Jos? Ab?lio



From notting at redhat.com  Fri Dec  5 15:18:18 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 5 Dec 2008 10:18:18 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205150938.GA4142@thinkpad>
References: <49393DE3.1080707@redhat.com> <20081205150938.GA4142@thinkpad>
Message-ID: <20081205151818.GA13246@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
> So if you want your Python program to work with the Fedora MinGW
> cross-compiler, you'd better try it out with the 'python -3' option
> and fix any deprecated bits.
> 
> Rich.
> 
> ... Or take the opportunity to jump to a safe language .. we've
> already got an OCaml cross-compiler.

Yes, let's move to something 'safer', which doesn't have ABI compatibility
ANYWHERE. That makes perfect sense.

Bill



From berrange at redhat.com  Fri Dec  5 15:19:02 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 5 Dec 2008 15:19:02 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205151134.GB4142@thinkpad>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<49394127.3050108@redhat.com> <20081205151134.GB4142@thinkpad>
Message-ID: <20081205151902.GE4290@redhat.com>

On Fri, Dec 05, 2008 at 03:11:34PM +0000, Richard W.M. Jones wrote:
> On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
> > So it means we can't dual maintain code easily between two  
> > branches/versions.
> 
> Isn't it the case that you can use 3.x features in 2.6, using the
> 'from future import ...' syntax?

Which isn't much help if python 2.3, 2.4 and 2.5 don't support
'from future import' and you care about shipping stuff that works
on the 99% of deployed Linux boxes today which don't have 2.6
let alone 3.0.


Daniel
-- 
|: Red Hat, Engineering, London   -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 katzj at redhat.com  Fri Dec  5 15:28:02 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 05 Dec 2008 10:28:02 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <49393DE3.1080707@redhat.com>
References: <49393DE3.1080707@redhat.com>
Message-ID: <1228490882.9414.10.camel@aglarond.local>

On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
> We're just now dealing with Python 2.6, but over on the radar is perhaps 
> one of the most incompatible upgrades to the language we've seen in 
> Python 3.  
[snip]
> So, what of plans?

You do realize that this thread has occurred multiple times now? :)  

> Are we looking at also carrying on with packaging 2.N indefinitely when 
> we do decide to carry 3, because as I know it, the code changes to make 
> something Python 3 compatible will be severe and that's a big item for 
> any release, and will probably result in some undiscovered bugs even 
> after the initial ports (if applied).

Carrying multiple versions of python becomes pretty infeasible very
quickly.  It's easy enough to package just python itself, but any
non-trivial user is going to require modules also.  So how do you decide
which modules to bring in, how to handle the fact that they may have
moved on to python 3 only, etc.  It's a big huge mess.

We'll likely stick with 2.x for a while and watch as python3 matures and
fix things up as we can against 2.6+.  Once there seems to be a critical
mass or compelling reason, we'll get to have a flag day.  Yes it will
hurt.  And for those who also develop things for older distros, yes,
they'll probably need to fork off an old-python or whatever branch and
probably only do bugfixes for some of those distros.  But this is no
different from apache 1.x -> 2.x, anyone doing kernel development, or a
number of other cases that have occurred over the years.

Jeremy



From james at fedoraproject.org  Fri Dec  5 15:32:19 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 05 Dec 2008 10:32:19 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205150949.GD4290@redhat.com>
References: <49393DE3.1080707@redhat.com> <20081205150949.GD4290@redhat.com>
Message-ID: <1228491139.26618.171.camel@code.and.org>

On Fri, 2008-12-05 at 15:09 +0000, Daniel P. Berrange wrote:

> IMHO the only viable option is to maintain both python 2.x and 3.x
> in parallel. It is essentially a brand new language which just
> happens to share the same base name. Like Perl 5 & Perl 6.

 It's much less like Perl-5/Perl-6, IMO, but even if you convince FESCo
of this mental contortion and you have dual sets of _every_ python
module. The API is very similar and uses the same shared library
name ... so what do you do about all the C programs that link with
libpython?

repoquery --whatrequires 'libpython2.5.so.*'

...are you going to offer two versions of rhythmbox?

-- 
James Antill <james at fedoraproject.org>
Fedora



From limb at jcomserv.net  Fri Dec  5 15:42:00 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 5 Dec 2008 09:42:00 -0600 (CST)
Subject: The looming Python 3(000) monster
In-Reply-To: <49394099.4040205@redhat.com>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<49394099.4040205@redhat.com>
Message-ID: <6e8c3ce317dc2a9861d06f27648114a5.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>>> We're just now dealing with Python 2.6, but over on the radar is
>>> perhaps
>>> one of the most incompatible upgrades to the language we've seen in
>>> Python 3.  I personally haven't tried it yet, but it /aims/ to be
>>> incompatble, which is perhaps one of the most glaring signs a language
>>> designer has lost it that I've seen.
>>>
>>> http://docs.python.org/3.0/whatsnew/3.0.html
>>>
>>> This isn't a huge problem to those who are only developing on the
>>> latest
>>> Fedora, per-se (other than getting over the initial hump), but it's
>>> pretty bad for someone who wants to keep a single codebase across EL 4
>>> (Python 2.3) and up, which I think a lot of us do.   That gets to be
>>> darn impossible and we have to double our involvement with code because
>>> we essentially have to maintain a differently-compatible fork for each
>>> project.
>>>
>>> (NOTE: this requires the viewpoint that not everyone care just about
>>> the
>>> latest Fedora, which might be controversial... but to me, the latest
>>> Fedora is what I'll run as my dev environment but not everyone can
>>> upgrade -- and many folks are also running EL and EPEL deserves our
>>> full
>>> support and consideration)
>>>
>>> So, what of plans?
>>>
>>> Are we looking at also carrying on with packaging 2.N indefinitely when
>>> we do decide to carry 3, because as I know it, the code changes to make
>>> something Python 3 compatible will be severe and that's a big item for
>>> any release, and will probably result in some undiscovered bugs even
>>> after the initial ports (if applied).
>>>
>>> I haven't seen /anything/ regarding a compatibility mode for
>>> /usr/bin/python, and I'd hate to have to develop a non-core library
>>> that
>>> allows for functions that work the same way on both versions and use
>>> that instead.  That would be heinous.
>>>
>>> Short of porting everything over to Ruby, oCaml, or
>>> enterprise-Fortran.NET#4000, any ideas on planning for this?
>>>
>>
>> Well, this:
>>
>> http://docs.python.org/3.0/library/2to3.html#to3-reference
>>
>> should be helpful.  The work being done on 2.6 now is an excellent first
>> step.
>>
>> Other than that, I think we'll have to treat it like any other major
>> change, such as gcc-4.3, etc.
>>
>> It's gonna hurt, and obviously we'll need a compat-python26, but I think
>> we'll be able to port things over, and have them either use Python3k or
>> compat- as needed.  Not sure when we'd be completely cut over, but I'd
>> love to see 2.6 the default in F11, which I believe is the plan, and
>> Py3k
>> in the not too distant future*, F12.
>>
>>
>>> --Michael
>>>
>>> --
>>> fedora-devel-list mailing list
>>> fedora-devel-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>>
>>>
>>
>> * or maybe next Sunday A.D. :)
>>
>>
> You're suggesting running 2.3 at each build time?  I hope we can trust
> it that much and it knows how to automatically port all possibilities.

No, I was suggesting that this be done manually by maintainers if
possible.  Given that some maintainers would lack the time, I think it
would be beneficial to set up a bug for each package with Python code,
assign it to the maintainer, but have a tracking bug so that those
interesting in helping out can go through the packages and pick off all
the Py3k bugs.

> Otherwise we get into a fork situation.   The initial switchover does
> not concern me so much as a dual maintaince problem.

Again, we wouldn't be switching the whole distro en masse, simply
providing compat- and migrating as possible.

> A new gcc didn't really require that I stop using print() in the source,
> it was mostly a build thing, no?

Correct.  I'm thinking of this more like the patch_fuzz issue introduced
by the new version of rpm in F-10.  I didn't have a copy of rawhide
around, so all my packages got the macro band-aid, and I'll be doubling
back to fix them in the next few weeks.

> --Michael
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From rjones at redhat.com  Fri Dec  5 15:42:33 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 5 Dec 2008 15:42:33 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205151818.GA13246@nostromo.devel.redhat.com>
References: <49393DE3.1080707@redhat.com> <20081205150938.GA4142@thinkpad>
	<20081205151818.GA13246@nostromo.devel.redhat.com>
Message-ID: <20081205154233.GA26728@thinkpad>

On Fri, Dec 05, 2008 at 10:18:18AM -0500, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
> > ... Or take the opportunity to jump to a safe language .. we've
> > already got an OCaml cross-compiler.
> 
> Yes, let's move to something 'safer', which doesn't have ABI compatibility
> ANYWHERE. That makes perfect sense.

You can get the same illusion of ABI compatibility as in C by simply
wrapping your OCaml library in a C wrapper and publishing the C header
file as the ABI.  I even wrote a tool to do this automatically.  Real
ABI compatibility is a tricky problem that only works in very limited
cases (eg. you extend the interface with new functions and never
modify even the internals of existing functions).

Rich.



From pemboa at gmail.com  Fri Dec  5 16:06:31 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 5 Dec 2008 10:06:31 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <49393DE3.1080707@redhat.com>
References: <49393DE3.1080707@redhat.com>
Message-ID: <16de708d0812050806te18c699te29f3376a4f154ad@mail.gmail.com>

On Fri, Dec 5, 2008 at 8:42 AM, Michael DeHaan <mdehaan at redhat.com> wrote:
>
> We're just now dealing with Python 2.6, but over on the radar is perhaps one
> of the most incompatible upgrades to the language we've seen in Python 3.  I
> personally haven't tried it yet, but it /aims/ to be incompatble, which is
> perhaps one of the most glaring signs a language designer has lost it that
> I've seen.


Was that last line really necessary for your post?


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From james at fedoraproject.org  Fri Dec  5 16:07:04 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 05 Dec 2008 11:07:04 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205154233.GA26728@thinkpad>
References: <49393DE3.1080707@redhat.com> <20081205150938.GA4142@thinkpad>
	<20081205151818.GA13246@nostromo.devel.redhat.com>
	<20081205154233.GA26728@thinkpad>
Message-ID: <1228493224.26618.182.camel@code.and.org>

On Fri, 2008-12-05 at 15:42 +0000, Richard W.M. Jones wrote:

[snip pointless trolling]

>   Real
> ABI compatibility is a tricky problem that only works in very limited
> cases (eg. you extend the interface with new functions and never
> modify even the internals of existing functions).

 ABI does not mean what you think it means:

http://en.wikipedia.org/wiki/Application_binary_interface#Content

-- 
James Antill <james at fedoraproject.org>
Fedora



From auralvance at gmail.com  Fri Dec  5 16:09:00 2008
From: auralvance at gmail.com (David Halik)
Date: Fri, 05 Dec 2008 11:09:00 -0500
Subject: FC10 Koji builds failing instantly with BuildrootError
Message-ID: <4939521C.3090105@gmail.com>

Hi all,

I apologize if this has already been discussed, but searching around 
hasn't given me a clear answer. I've been attempting to do some Koji 
scratch builds that are no different than I have done in the past, but 
I'm suddenly getting this error message instantly afetr the package is 
uploaded:

FAILED: BuildrootError: error building package (arch x86_64), mock 
exited with status 1

My BuildRoot is the standard one given in the package builder docs and 
has worked for ages:

BuildRoot:      
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

I'm guessing this has something to do with the breakout of 
/usr/src/redhat into ~/rpmbuild with FC10 since I'm not having the 
problem with FC9 builds, but I can't figure out how to resolve this 
problem properly.

Any help would be appreciated.

Thanks!
-Dave
--------------
http://www.digitalruin.net



From ajax at redhat.com  Fri Dec  5 16:23:33 2008
From: ajax at redhat.com (Adam Jackson)
Date: Fri, 05 Dec 2008 11:23:33 -0500
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <20081205102903.GB18476@thinkpad>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com>  <20081205102903.GB18476@thinkpad>
Message-ID: <1228494213.21898.11.camel@atropine.boston.devel.redhat.com>

On Fri, 2008-12-05 at 10:29 +0000, Richard W.M. Jones wrote:
> On Fri, Dec 05, 2008 at 12:28:44AM -0500, Peter Jones wrote:
> > Responding to the correct mailing list for this discussion.  Cc:ing the other one.
> >
> > Ulrich Drepper wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> John Dennis wrote:
> >>> I've had my fill of autotool problems (especially libtool)
> >>
> >> Don't throw in libtool with the rest.  libtool was available in the
> >> spirit of the auto tools only in its very first version (which of those
> >> reading this only Jim and Tom will know).  Then came the windows and
> >> HP-SUX idiots and ruined it.  I've for the longest time said libtool
> >> should not be used (and I don't do it in my code).  In the worst case a
> >> simple Linux-only replacement for libtool should be used.
> >
> > I agree that a Linux-only replacement for libtool should be used, if at 
> > all.  So why isn't there one available in Fedora that deps on "libtool" 
> > will pick by default?
> 
> No one has explained yet how these packages that don't use libtool
> will work when cross-compiling to Windows (or on HP-SUX / all the
> other platforms that have different ways to make shared libraries).
> 
> Really: use libtool, it helps.

gcc -shared works on windows now, you know.

If the assertion is that we still need to care about non-gnu toolchains,
then that's one thing, but if all libtool is doing is wrapping gcc, then
it's worse than useless.

- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/83e6b18b/attachment.sig>

From auralvance at gmail.com  Fri Dec  5 16:28:03 2008
From: auralvance at gmail.com (David Halik)
Date: Fri, 05 Dec 2008 11:28:03 -0500
Subject: FC10 Koji builds failing instantly with BuildrootError
In-Reply-To: <4939521C.3090105@gmail.com>
References: <4939521C.3090105@gmail.com>
Message-ID: <49395693.4080902@gmail.com>


Nevermind, I did further digging in the logs and it seems to be a build 
issues and not related to the build system. The error message threw me 
off. ;)

Thanks.

David Halik wrote:
> Hi all,
>
> I apologize if this has already been discussed, but searching around 
> hasn't given me a clear answer. I've been attempting to do some Koji 
> scratch builds that are no different than I have done in the past, but 
> I'm suddenly getting this error message instantly afetr the package is 
> uploaded:
>
> FAILED: BuildrootError: error building package (arch x86_64), mock 
> exited with status 1
>
> My BuildRoot is the standard one given in the package builder docs and 
> has worked for ages:
>
> BuildRoot:      
> %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>
> I'm guessing this has something to do with the breakout of 
> /usr/src/redhat into ~/rpmbuild with FC10 since I'm not having the 
> problem with FC9 builds, but I can't figure out how to resolve this 
> problem properly.
>
> Any help would be appreciated.
>
> Thanks!
> -Dave
> --------------
> http://www.digitalruin.net



From s-t-rhbugzilla at wwwdotorg.org  Fri Dec  5 16:39:28 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Fri, 5 Dec 2008 09:39:28 -0700 (MST)
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205151902.GE4290@redhat.com>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<49394127.3050108@redhat.com> <20081205151134.GB4142@thinkpad>
	<20081205151902.GE4290@redhat.com>
Message-ID: <1228495168.6083.TMDA@tmda.severn.wwwdotorg.org>

On Fri, December 5, 2008 8:19 am, Daniel P. Berrange wrote:
> On Fri, Dec 05, 2008 at 03:11:34PM +0000, Richard W.M. Jones wrote:
>> On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
>> > So it means we can't dual maintain code easily between two
>> > branches/versions.
>>
>> Isn't it the case that you can use 3.x features in 2.6, using the
>> 'from future import ...' syntax?
>
> Which isn't much help if python 2.3, 2.4 and 2.5 don't support
> 'from future import' and you care about shipping stuff that works
> on the 99% of deployed Linux boxes today which don't have 2.6
> let alone 3.0.

For heavens sake, the world is not falling.

If you don't want to use the new features, just don't use them.



From s-t-rhbugzilla at wwwdotorg.org  Fri Dec  5 16:39:28 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Fri, 5 Dec 2008 09:39:28 -0700 (MST)
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205151902.GE4290@redhat.com>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<49394127.3050108@redhat.com> <20081205151134.GB4142@thinkpad>
	<20081205151902.GE4290@redhat.com>
Message-ID: <1228495168.6083.TMDA@tmda.severn.wwwdotorg.org>

On Fri, December 5, 2008 8:19 am, Daniel P. Berrange wrote:
> On Fri, Dec 05, 2008 at 03:11:34PM +0000, Richard W.M. Jones wrote:
>> On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
>> > So it means we can't dual maintain code easily between two
>> > branches/versions.
>>
>> Isn't it the case that you can use 3.x features in 2.6, using the
>> 'from future import ...' syntax?
>
> Which isn't much help if python 2.3, 2.4 and 2.5 don't support
> 'from future import' and you care about shipping stuff that works
> on the 99% of deployed Linux boxes today which don't have 2.6
> let alone 3.0.

For heavens sake, the world is not falling.

If you don't want to use the new features, just don't use them.



From rjones at redhat.com  Fri Dec  5 16:40:59 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 5 Dec 2008 16:40:59 +0000
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <1228494213.21898.11.camel@atropine.boston.devel.redhat.com>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com> <20081205102903.GB18476@thinkpad>
	<1228494213.21898.11.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081205164059.GA27146@thinkpad>

On Fri, Dec 05, 2008 at 11:23:33AM -0500, Adam Jackson wrote:
> gcc -shared works on windows now, you know.

That's not true.

You also need to generate an implib on Windows, which requires an
extra Windows-specific gcc option.

Furthermore you would normally want your Windows shared library to be
called foo-VERSION.dll versus foo.so.VERSION on Linux (and another,
completely different name on AIX or HP-UX).

You might also want to generate a *.def file on Windows (if you were
going to use/link with any VC code).

Libtool deals with this crap.  It's dumb to get every packager to
replicate it.

Rich.



From pertusus at free.fr  Fri Dec  5 17:11:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 18:11:15 +0100
Subject: starting a service if a subpackage is installed
In-Reply-To: <20081205135422.GA11026@nostromo.devel.redhat.com>
References: <20081205095334.GB17710@free.fr>
	<20081205135422.GA11026@nostromo.devel.redhat.com>
Message-ID: <20081205171115.GB13229@free.fr>

On Fri, Dec 05, 2008 at 08:54:22AM -0500, Bill Nottingham wrote:
> 
> Just rely on admin configuration, like is done for every other
> service.

Not for all the services. Local system services are automatically
enabled, like crond (and messagebus, lm_sensors...). I would like 
to do the same, but conditional on a package being installed. That way
it is possible to have cronie started in the default case and fcron
installed but activated by the admin (install cronie, fcron but not
fcron-startup). Or no cronie but fcron started automatically (install
fcron and fcron-startup).

The other possibility is to have fcron started automatically, including
the part that watch changes in config and automatically update spool
fcron tables, but I'd like to avoid that.

--
Pat



From mw_triad at users.sourceforge.net  Fri Dec  5 17:34:26 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 05 Dec 2008 11:34:26 -0600
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081205010942.GF2761@free.fr>
References: <1228190889.5593.2817.camel@beck.corsepiu.local>	<gh5j3o$5cp$1@ger.gmane.org>	<1228296680.20451.1794.camel@beck.corsepiu.local>	<gh7ggq$uk1$2@ger.gmane.org>
	<49380E63.9010801@gmail.com>	<gh9f75$28a$1@ger.gmane.org>
	<20081204204830.GB2761@free.fr>	<gh9k3g$kp1$1@ger.gmane.org>
	<20081204231320.GE2761@free.fr>	<gh9rgl$ddb$1@ger.gmane.org>
	<20081205010942.GF2761@free.fr>
Message-ID: <ghbon2$39b$1@ger.gmane.org>

Patrice Dumas wrote:
> On Thu, Dec 04, 2008 at 06:09:57PM -0600, Matthew Woehlke wrote:
>> expect to see third-party flavors of CMake (the way you see various  
>> vendor versions of e.g. sed, which have no relation to each other  
>> besides the degree to which they implement the POSIX spec for such tool).
> 
> Why so? There could be a solaris cmake, an IRIX cmake, an HP-UX cmake...
> 
> There could be. Why are there vendor sh, sed and awk?

Because they predate GNU? Such tools existed before GNU, therefore each 
vendor had to roll their own, as a result of which there are GNU, BSD, 
vendor-specific, etc. versions of each, and because there were already, 
there is a certain inertia in maintaining them.

Instead of asking "why not", ask *why*. I haven't heard of 
vendor-specific autotools; what makes you think vendors will suddenly 
roll their own CMake?

>> Cost of porting CMake: on POSIX platforms, about the same as autotools  
>> or better, and unlike autotools, doable for non-UNIX-like platforms.
> 
> All the GNU POSIX utilities are portable and have been ported on many
> platforms. 

Sorry, but there really is not a "nice" port of bash to Windows. And the 
mingw project should tell you something about the difficulty of porting 
POSIX tools to non-POSIX platforms (i.e. that you have to bootstrap 
something like a POSIX libc before you can even start).

At *worst* you'd have to do something similar for CMake. In reality, 
CMake doesn't have that problem because it doesn't need to look like 
POSIX, it just needs to look like CMake, which means it can adapt much 
more readily to the native environment.

Autotools *needs* a POSIX environment, which means on non-POSIX 
platforms you have to bring along all that baggage. On the plus side, 
your application code doesn't have to be as portable, but you don't have 
the *ability* to build native applications on some platforms (e.g. 
Windows). CMake itself doesn't need all that, so it's only needed (and 
even then, only the runtime, not all the supporting programs) if the 
application needs it.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
For great justice!! -- Captain (Zero Wing)



From cry_regarder at yahoo.com  Fri Dec  5 17:42:16 2008
From: cry_regarder at yahoo.com (Cry)
Date: Fri, 5 Dec 2008 17:42:16 +0000 (UTC)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
References: <loom.20081203T184910-257@post.gmane.org>
Message-ID: <loom.20081205T173743-221@post.gmane.org>

Cry <cry_regarder <at> yahoo.com> writes:

> 
> gallery2 has two new versions and outstanding security bugs.  I have tried
> several times to email the maintainer John Berninger with no replies to a few
> different addresses.  Is this software dead in fedora? 

Just for form's sake in case it is necessary and can't be accelerated, The
non-responsive maintainer process was initiated at

https://bugzilla.redhat.com/show_bug.cgi?id=474870

Since fedora security loaded several of these bugs and they have CVE numbers
assigned, why didn't they followup when the maintainer didn't respond?  Will the
slow fix time for these bugs reflect negatively on fedora's stats?

Oh, Jon, what version of gallery2 did you build packages for?  Do you feel
comfortable that they would be ready to test?

Cry






From walters at verbum.org  Fri Dec  5 17:44:33 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 5 Dec 2008 12:44:33 -0500
Subject: Status of libtool 2.2.X?
In-Reply-To: <ghbon2$39b$1@ger.gmane.org>
References: <1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh7ggq$uk1$2@ger.gmane.org> <49380E63.9010801@gmail.com>
	<gh9f75$28a$1@ger.gmane.org> <20081204204830.GB2761@free.fr>
	<gh9k3g$kp1$1@ger.gmane.org> <20081204231320.GE2761@free.fr>
	<gh9rgl$ddb$1@ger.gmane.org> <20081205010942.GF2761@free.fr>
	<ghbon2$39b$1@ger.gmane.org>
Message-ID: <faa16b610812050944x26b8dd66i8dac73d4716b816f@mail.gmail.com>

I like waf:

http://code.google.com/p/waf/

So far been using it in a few (small, but nontrivial) projects and I'm
relatively happy with it.

The main disadvantage is that because configure runs so quickly, and
parallel make actually works, you have less time to switch and check
your email while waiting for a project to build.



From rjones at redhat.com  Fri Dec  5 17:47:57 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 5 Dec 2008 17:47:57 +0000
Subject: OCaml status
Message-ID: <20081205174757.GA27576@thinkpad>

I believe that all broken dependencies should now be resolved.
There's just a couple of final packages going through Koji now and
once Koji does another createrepo, I hope that there won't be any
broken deps.  Well hopefully ...  we'll see tomorrow.

  http://cocan.org/fedora#Package_status

I've rebuilt all the OCaml-based applications, and they are all OK ..

Except for freetennis which FTBFS.  I don't care very much about
freetennis -- upstream seems to be dead.  I may have a go at fixing
the build problem tomorrow, else I'll orphan it.

Rich.



From limb at jcomserv.net  Fri Dec  5 17:52:30 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 5 Dec 2008 11:52:30 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <loom.20081205T173743-221@post.gmane.org>
References: <loom.20081203T184910-257@post.gmane.org>
	<loom.20081205T173743-221@post.gmane.org>
Message-ID: <1af208abd531c0a834256de6629f3715.squirrel@mail.jcomserv.net>


> Cry <cry_regarder <at> yahoo.com> writes:
>
>>
>> gallery2 has two new versions and outstanding security bugs.  I have
>> tried
>> several times to email the maintainer John Berninger with no replies to
>> a few
>> different addresses.  Is this software dead in fedora?
>
> Just for form's sake in case it is necessary and can't be accelerated, The
> non-responsive maintainer process was initiated at
>
> https://bugzilla.redhat.com/show_bug.cgi?id=474870
>
> Since fedora security loaded several of these bugs and they have CVE
> numbers
> assigned, why didn't they followup when the maintainer didn't respond?
> Will the
> slow fix time for these bugs reflect negatively on fedora's stats?
>
> Oh, Jon, what version of gallery2 did you build packages for?  Do you feel
> comfortable that they would be ready to test?

2.3. Probably.  SRPM here:
http://zanoni.jcomserv.net/fedora/gallery2-2.3-1.fc10.src.rpm

> Cry
>
>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From chris.stone at gmail.com  Fri Dec  5 17:54:09 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Fri, 5 Dec 2008 09:54:09 -0800
Subject: apache user is unable to resolve IP addresses in F10
In-Reply-To: <4938A740.40801@fedoraunity.org>
References: <d9c612bf0812041735p2e5a370apb0b5c5f4edd4d85d@mail.gmail.com>
	<4938A740.40801@fedoraunity.org>
Message-ID: <d9c612bf0812050954n325d06cci97340c39abc490fe@mail.gmail.com>

On Thu, Dec 4, 2008 at 8:00 PM, Jonathan Steffan <jon at fedoraunity.org> wrote:
> See this bug and please report this is also affecting php:
> https://bugzilla.redhat.com/show_bug.cgi?id=459756

Looks like that was it, as the work-around mentioned in this bug fixes
the problem for me.  Thanks.



From mike at cchtml.com  Fri Dec  5 17:56:07 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Fri, 05 Dec 2008 11:56:07 -0600
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <loom.20081205T173743-221@post.gmane.org>
References: <loom.20081203T184910-257@post.gmane.org>
	<loom.20081205T173743-221@post.gmane.org>
Message-ID: <49396B37.7090806@cchtml.com>

-------- Original Message --------
Subject: Re: gallery2 outstanding security bugs -- Abondoned by Berninger?
From: Cry <cry_regarder at yahoo.com>
To: fedora-devel-list at redhat.com
Date: 12/05/2008 11:42 AM

> 
> Just for form's sake in case it is necessary and can't be accelerated, The
> non-responsive maintainer process was initiated at
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=474870
> 

Would it be appropriate to tie the Bugzilla package into your bug? It's 
also out of date with some security patches in those updates.




From limb at jcomserv.net  Fri Dec  5 17:58:54 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 5 Dec 2008 11:58:54 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <49396B37.7090806@cchtml.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<loom.20081205T173743-221@post.gmane.org>
	<49396B37.7090806@cchtml.com>
Message-ID: <af0bc9bbf7de5b21d71bb226fe64d20d.squirrel@mail.jcomserv.net>


> -------- Original Message --------
> Subject: Re: gallery2 outstanding security bugs -- Abondoned by Berninger?
> From: Cry <cry_regarder at yahoo.com>
> To: fedora-devel-list at redhat.com
> Date: 12/05/2008 11:42 AM
>
>>
>> Just for form's sake in case it is necessary and can't be accelerated,
>> The
>> non-responsive maintainer process was initiated at
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=474870
>>
>
> Would it be appropriate to tie the Bugzilla package into your bug? It's
> also out of date with some security patches in those updates.

Indeed, it'd be good to link to all his packages.  Someone(s) will need to
take the others.

>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From notting at redhat.com  Fri Dec  5 18:04:11 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 5 Dec 2008 13:04:11 -0500
Subject: starting a service if a subpackage is installed
In-Reply-To: <20081205171115.GB13229@free.fr>
References: <20081205095334.GB17710@free.fr>
	<20081205135422.GA11026@nostromo.devel.redhat.com>
	<20081205171115.GB13229@free.fr>
Message-ID: <20081205180411.GB14599@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> > Just rely on admin configuration, like is done for every other
> > service.
> 
> Not for all the services. Local system services are automatically
> enabled, like crond (and messagebus, lm_sensors...).

If fcron is the default, it can start by default. Otherwise, it
can be like syslog-ng.

> to do the same, but conditional on a package being installed. That way
> it is possible to have cronie started in the default case and fcron
> installed but activated by the admin (install cronie, fcron but not
> fcron-startup). Or no cronie but fcron started automatically (install
> fcron and fcron-startup).

If the admin can install a package, they can run a chkconfig command;
it's not hard.

Bill



From loganjerry at gmail.com  Fri Dec  5 17:47:38 2008
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 5 Dec 2008 10:47:38 -0700
Subject: cpufreq module on x86_64
Message-ID: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>

I've got a fresh F-10 install on a Core 2 Quad machine.  While looking
through dmesg output for a clue to another problem, I noticed this:

p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq
module offers voltage scaling in addition of frequency scaling. You
should use that instead of p4-clockmod, if possible.
p4-clockmod: Unknown p4-clockmod-capable CPU. Please send an e-mail to
<cpufreq at vger.kernel.org>

(repeated 3 more times)

First I wondered why I was getting a cpufreq module loaded on a
desktop machine.  I guess I want to do something if the CPU
temperature gets too high, but it doesn't look like the default
configuration handles that case, does it?  Anyhow, I edited
/etc/sysconfig/cpuspeed to explicitly say:

DRIVER=acpi-cpufreq

On the next reboot, I had the same complaint in dmesg.  On a hunch, I
checked the output of lsmod; p4-clockmod isn't listed.  It does exist
as a module here:

/lib/modules/2.6.27.5-117.fc10.x86_64/kernel/arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko

So is it also compiled in?
-- 
Jerry James
http://loganjerry.googlepages.com/



From seg at haxxed.com  Fri Dec  5 18:16:53 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 05 Dec 2008 12:16:53 -0600
Subject: autotools hurts my brain; it's a monster out of control
In-Reply-To: <20081205164059.GA27146@thinkpad>
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com> <20081205102903.GB18476@thinkpad>
	<1228494213.21898.11.camel@atropine.boston.devel.redhat.com>
	<20081205164059.GA27146@thinkpad>
Message-ID: <1228501013.4755.4413.camel@localhost.localdomain>

On Fri, 2008-12-05 at 16:40 +0000, Richard W.M. Jones wrote:
> On Fri, Dec 05, 2008 at 11:23:33AM -0500, Adam Jackson wrote:
> > gcc -shared works on windows now, you know.
> 
> That's not true.
> 
> You also need to generate an implib on Windows, which requires an
> extra Windows-specific gcc option.
> 
> Furthermore you would normally want your Windows shared library to be
> called foo-VERSION.dll versus foo.so.VERSION on Linux (and another,
> completely different name on AIX or HP-UX).
> 
> You might also want to generate a *.def file on Windows (if you were
> going to use/link with any VC code).

At the risk of another flamewar, Cmake does all this on Windows just
fine, and is its major selling point really. Cmake supports Visual
Studio, which GNU tools will never, ever do. Say what you want about
MSVC, (It sucks.) but if you want to win over the masses of Windows
developers, you have to support it.

> Libtool deals with this crap.  It's dumb to get every packager to
> replicate it.

-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/36c8138d/attachment.sig>

From mjg at redhat.com  Fri Dec  5 18:29:15 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Fri, 5 Dec 2008 18:29:15 +0000
Subject: cpufreq module on x86_64
In-Reply-To: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
Message-ID: <20081205182915.GA28483@srcf.ucam.org>

On Fri, Dec 05, 2008 at 10:47:38AM -0700, Jerry James wrote:
> First I wondered why I was getting a cpufreq module loaded on a
> desktop machine.  I guess I want to do something if the CPU
> temperature gets too high, but it doesn't look like the default
> configuration handles that case, does it?  Anyhow, I edited
> /etc/sysconfig/cpuspeed to explicitly say:

I suspect what's happening is that acpi-cpufreq is loading and failing 
to bind, and then p4-clockmod gets loaded, fails to bind and the module 
load is aborted.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From lfarkas at lfarkas.org  Fri Dec  5 18:30:21 2008
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Fri, 05 Dec 2008 19:30:21 +0100
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205151305.GA13097@nostromo.devel.redhat.com>
References: <49393DE3.1080707@redhat.com>	<1228489052.29612.158.camel@ignacio.lan>
	<20081205151305.GA13097@nostromo.devel.redhat.com>
Message-ID: <4939733D.4000304@lfarkas.org>

Bill Nottingham wrote:
> Ignacio Vazquez-Abrams (ivazqueznet at gmail.com) said: 
>> On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
>>> Short of porting everything over to Ruby, oCaml, or 
>>> enterprise-Fortran.NET#4000, any ideas on planning for this?
>> I think we should continue on to 2.7 and 2.8; this will give us the time
>> we need to bring the compatibility versions into EL and inch us closer
>> to Python 3000.
> 
> Only one version of EL, though. It's not like RHEL 4/5 are going
> to move to new python.

but rhel-6 will be based on f11 and if f11 won't ve p3000 then nor el-6
which will hurt many people even in 2015...

-- 
  Levente                               "Si vis pacem para bellum!"



From a.badger at gmail.com  Fri Dec  5 18:32:15 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 10:32:15 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <49393DE3.1080707@redhat.com>
References: <49393DE3.1080707@redhat.com>
Message-ID: <493973AF.2030009@gmail.com>

Michael DeHaan wrote:
> 
> This isn't a huge problem to those who are only developing on the latest
> Fedora, per-se (other than getting over the initial hump), but it's
> pretty bad for someone who wants to keep a single codebase across EL 4
> (Python 2.3) and up, which I think a lot of us do.   That gets to be
> darn impossible and we have to double our involvement with code because
> we essentially have to maintain a differently-compatible fork for each
> project.
> 
This is a problem that hasn't been brought up before.  We can keep
Fedora going on python-2.6, 2.7 (and 2.8 if it occurs) and gradually
move code close to py3.x-ish syntax by using the "from __future__ import
*" mechanism.  But that doesn't help with older distros running
python-2.5 or less.  I don't believe there's anyway around that, though.

As we move to python-2.6+ w/ 3.x features we'll have this problem no
matter when we actually move to python-3.  So we eventually (unless we
hold off on moving to python3 until python-2.6 is standard on all RHEL
releases) will be maintaining two trees of code no matter what.

If we maintain a python2 package and a python3 package in one version of
Fedora we'll have even more work.  Right now we can have an EL-5 and
Fedora-9&10 package that are compatible with 2.5.  A different version
can run on Fedora11 with the syntax ported to python-2.6's understanding
of what 3.x will be like.  If we have both python2-2.6 and python3-3.0
in Fedora11 we'll have to maintain separate py2 and py3 packages for
every python module we ship as well.  We should avoid this if we can.

Note that I think this decision is only partially within the powers of
the Fedora Project to decide.  If 80% of our upstream libraries move to
py3, we'll need to move to py3 sooner.  If 80% refuse to move off of
py2, we can take our time working on migration code.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/4bc96a98/attachment.sig>

From seg at haxxed.com  Fri Dec  5 18:39:31 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 05 Dec 2008 12:39:31 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812050806te18c699te29f3376a4f154ad@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<16de708d0812050806te18c699te29f3376a4f154ad@mail.gmail.com>
Message-ID: <1228502371.4755.4421.camel@localhost.localdomain>

On Fri, 2008-12-05 at 10:06 -0600, Arthur Pemberton wrote:
> On Fri, Dec 5, 2008 at 8:42 AM, Michael DeHaan <mdehaan at redhat.com> wrote:
> >
> > We're just now dealing with Python 2.6, but over on the radar is perhaps one
> > of the most incompatible upgrades to the language we've seen in Python 3.  I
> > personally haven't tried it yet, but it /aims/ to be incompatble, which is
> > perhaps one of the most glaring signs a language designer has lost it that
> > I've seen.
> 
> 
> Was that last line really necessary for your post?

The implicit looming flamewar here should be taken upstream. Fedora
policy is to follow upstream, wherever it may take us.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/5c92f87b/attachment.sig>

From cry_regarder at yahoo.com  Fri Dec  5 18:38:44 2008
From: cry_regarder at yahoo.com (Cry)
Date: Fri, 5 Dec 2008 18:38:44 +0000 (UTC)
Subject: Can anyone contact missing John Beringer? (was: gallery2
	outstanding security bugs...)
References: <loom.20081203T184910-257@post.gmane.org>
	<loom.20081205T173743-221@post.gmane.org>
	<49396B37.7090806@cchtml.com>
	<af0bc9bbf7de5b21d71bb226fe64d20d.squirrel@mail.jcomserv.net>
Message-ID: <loom.20081205T183307-581@post.gmane.org>

Jon Ciesla <limb <at> jcomserv.net> writes:
>> From: Cry <cry_regarder <at> yahoo.com>
>>> The non-responsive maintainer process was initiated at
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=474870
> 
> Indeed, it'd be good to link to all his packages.  Someone(s) will need to
> take the others.

The other packages were added to the text of the above bug.  I don't know how to
make a single bug cover additional packages though.

Packages:  gallery2, wordpress, bugzilla, squidguard, ratpoison

Since there are so many bugs with CVEs assigned to this person, can we shortcut
the process a little and move to stage three "After 2 attempts (2 weeks)..."
mode at:

https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

?  Does anyone out there know how to reach John?  I've tried emailing him at his
redhat and ncphotography addresses and searching on the web.

Cry




From a.badger at gmail.com  Fri Dec  5 18:37:28 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 10:37:28 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
Message-ID: <493974E8.3000006@gmail.com>

Jon Ciesla wrote:
> It's gonna hurt, and obviously we'll need a compat-python26, but I think
> we'll be able to port things over, and have them either use Python3k or
> compat- as needed.  Not sure when we'd be completely cut over, but I'd
> love to see 2.6 the default in F11, which I believe is the plan, and Py3k
> in the not too distant future*, F12.
> 
We're going to avoid compat-python26 if possible.  The reason is that
third party modules are needed to make a program work.  So we wouldn't
just have a python26 package.... we'd have python26, python26-mozilla,
python26-libxml2, python26-pygtk, and etc.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/a41680d5/attachment.sig>

From pemboa at gmail.com  Fri Dec  5 18:40:14 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 5 Dec 2008 12:40:14 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <493973AF.2030009@gmail.com>
References: <49393DE3.1080707@redhat.com> <493973AF.2030009@gmail.com>
Message-ID: <16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>

2008/12/5 Toshio Kuratomi <a.badger at gmail.com>:
> Michael DeHaan wrote:
>>
>> This isn't a huge problem to those who are only developing on the latest
>> Fedora, per-se (other than getting over the initial hump), but it's
>> pretty bad for someone who wants to keep a single codebase across EL 4
>> (Python 2.3) and up, which I think a lot of us do.   That gets to be
>> darn impossible and we have to double our involvement with code because
>> we essentially have to maintain a differently-compatible fork for each
>> project.
>>
> This is a problem that hasn't been brought up before.  We can keep
> Fedora going on python-2.6, 2.7 (and 2.8 if it occurs) and gradually
> move code close to py3.x-ish syntax by using the "from __future__ import
> *" mechanism.  But that doesn't help with older distros running
> python-2.5 or less.  I don't believe there's anyway around that, though.
>
> As we move to python-2.6+ w/ 3.x features we'll have this problem no
> matter when we actually move to python-3.  So we eventually (unless we
> hold off on moving to python3 until python-2.6 is standard on all RHEL
> releases) will be maintaining two trees of code no matter what.
>
> If we maintain a python2 package and a python3 package in one version of
> Fedora we'll have even more work.  Right now we can have an EL-5 and
> Fedora-9&10 package that are compatible with 2.5.  A different version
> can run on Fedora11 with the syntax ported to python-2.6's understanding
> of what 3.x will be like.  If we have both python2-2.6 and python3-3.0
> in Fedora11 we'll have to maintain separate py2 and py3 packages for
> every python module we ship as well.  We should avoid this if we can.
>
> Note that I think this decision is only partially within the powers of
> the Fedora Project to decide.  If 80% of our upstream libraries move to
> py3, we'll need to move to py3 sooner.  If 80% refuse to move off of
> py2, we can take our time working on migration code.
>
> -Toshio


Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
ensure that all code is compatible with 3. And still have 3 in
parallel for those who want it. So we target 2.6+ , but have 3.0 there
to ensure everything would work with it, and for early adopters/devs

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From a.badger at gmail.com  Fri Dec  5 18:38:26 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 10:38:26 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205151134.GB4142@thinkpad>
References: <49393DE3.1080707@redhat.com>	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>	<49394127.3050108@redhat.com>
	<20081205151134.GB4142@thinkpad>
Message-ID: <49397522.7010303@gmail.com>

Richard W.M. Jones wrote:
> On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
>> So it means we can't dual maintain code easily between two  
>> branches/versions.
> 
> Isn't it the case that you can use 3.x features in 2.6, using the
> 'from future import ...' syntax?
> 
> http://www.python.org/dev/peps/pep-0236/
> 
Yes.  This figures into our plans for migrating code within Fedora to
3.x.  However, it doesn't address Michael's concerns about maintaining
code on python <= 2.5.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/74cdaa84/attachment.sig>

From a.badger at gmail.com  Fri Dec  5 18:40:16 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 10:40:16 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <1228495168.6083.TMDA@tmda.severn.wwwdotorg.org>
References: <49393DE3.1080707@redhat.com>	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>	<49394127.3050108@redhat.com>
	<20081205151134.GB4142@thinkpad>	<20081205151902.GE4290@redhat.com>
	<1228495168.6083.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <49397590.8030102@gmail.com>

Stephen Warren wrote:
> On Fri, December 5, 2008 8:19 am, Daniel P. Berrange wrote:
>> Which isn't much help if python 2.3, 2.4 and 2.5 don't support
>> 'from future import' and you care about shipping stuff that works
>> on the 99% of deployed Linux boxes today which don't have 2.6
>> let alone 3.0.
> 
> For heavens sake, the world is not falling.
> 
> If you don't want to use the new features, just don't use them.
> 
The problem is that you have to use some of the new features to be valid
 python3 code.  So being compatible with python <=2.5 and python3.x+
will be painful at best and impossible at worst.

-Toshio


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/7c69c7aa/attachment.sig>

From limb at jcomserv.net  Fri Dec  5 18:46:27 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 5 Dec 2008 12:46:27 -0600 (CST)
Subject: The looming Python 3(000) monster
In-Reply-To: <493974E8.3000006@gmail.com>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<493974E8.3000006@gmail.com>
Message-ID: <d98b436ba3100c946215ce7877bd31ae.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>> It's gonna hurt, and obviously we'll need a compat-python26, but I think
>> we'll be able to port things over, and have them either use Python3k or
>> compat- as needed.  Not sure when we'd be completely cut over, but I'd
>> love to see 2.6 the default in F11, which I believe is the plan, and
>> Py3k
>> in the not too distant future*, F12.
>>
> We're going to avoid compat-python26 if possible.  The reason is that
> third party modules are needed to make a program work.  So we wouldn't
> just have a python26 package.... we'd have python26, python26-mozilla,
> python26-libxml2, python26-pygtk, and etc.

I have to do this at work for 2.3, 2.4 and 2.5.  It SUCKS.  So I agree,
let's not. :)

> -Toshio
>
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From abu_hurayrah at hidayahonline.org  Fri Dec  5 18:45:41 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Fri, 05 Dec 2008 20:45:41 +0200
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
References: <49393DE3.1080707@redhat.com> <493973AF.2030009@gmail.com>
	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
Message-ID: <1228502748.3386.36.camel@beta>

On Fri, 2008-12-05 at 12:40 -0600, Arthur Pemberton wrote:
> 2008/12/5 Toshio Kuratomi <a.badger at gmail.com>:
> 
> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
> ensure that all code is compatible with 3. And still have 3 in
> parallel for those who want it. So we target 2.6+ , but have 3.0 there
> to ensure everything would work with it, and for early adopters/devs
> 
> -- 
> Fedora 9 : sulphur is good for the skin
> ( www.pembo13.com )
> 

It would be very hard to write 2.6 code that is completely compatible
with 3.0, because 3.0 has changed many fundamental language constructs,
including even the "print" statement, which in 3.0 is a function (syntax
change).

I am not sure how far the from __future__ import feature will work for
such changes as that.



From mclasen at redhat.com  Fri Dec  5 18:50:29 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 05 Dec 2008 13:50:29 -0500
Subject: orphaning gnome-volume-manager
In-Reply-To: <1227544518.11161.19.camel@x61.fubar.dk>
References: <1227544518.11161.19.camel@x61.fubar.dk>
Message-ID: <1228503029.3540.70.camel@localhost.localdomain>

On Mon, 2008-11-24 at 11:35 -0500, David Zeuthen wrote:
> Hey,
> 
> gnome-volume-manager is no longer in the default install since the
> functionality it provides has been replaced by Nautilus as of Fedora 9.
> As such I'm orphaning it.


Its been two weeks now, and no one showed interest in keeping
gnome-volume-manager alive. So I am going to go ahead with retiring it.



From pemboa at gmail.com  Fri Dec  5 18:50:23 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 5 Dec 2008 12:50:23 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <1228502748.3386.36.camel@beta>
References: <49393DE3.1080707@redhat.com> <493973AF.2030009@gmail.com>
	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
	<1228502748.3386.36.camel@beta>
Message-ID: <16de708d0812051050m26e0a696tce1ed336b43f39c3@mail.gmail.com>

On Fri, Dec 5, 2008 at 12:45 PM, Basil Mohamed Gohar
<abu_hurayrah at hidayahonline.org> wrote:
> On Fri, 2008-12-05 at 12:40 -0600, Arthur Pemberton wrote:
>> 2008/12/5 Toshio Kuratomi <a.badger at gmail.com>:
>>
>> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
>> ensure that all code is compatible with 3. And still have 3 in
>> parallel for those who want it. So we target 2.6+ , but have 3.0 there
>> to ensure everything would work with it, and for early adopters/devs
>>
>> --
>> Fedora 9 : sulphur is good for the skin
>> ( www.pembo13.com )
>>
>
> It would be very hard to write 2.6 code that is completely compatible
> with 3.0, because 3.0 has changed many fundamental language constructs,
> including even the "print" statement, which in 3.0 is a function (syntax
> change).

I believe 'print' is a poor example as it is very easy to fix. Are
there other, more problematic ones?

> I am not sure how far the from __future__ import feature will work for
> such changes as that.

Neither am I.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From lists at ralii.com  Fri Dec  5 18:46:22 2008
From: lists at ralii.com (Robert Locke)
Date: Fri, 05 Dec 2008 13:46:22 -0500
Subject: Whodunnit? F10 install without permission
Message-ID: <1228502782.3673.29.camel@localhost.localdomain>

Excuse the interruption, but I am trying to figure out who to bugzilla
this against...

This morning, shortly after logging in, three packages were installed
onto my machine without my knowledge/desire/permission.

The packages in question are: createrepo, anaconda-yum-plugins, and
preupgrade.

This happened on a "fresh F10 install" from DVD done back on 28-Nov.  It
has been subsequently updated by hand (yum update) and had the rpmfusion
and livna repos added to it.  But little else has been "configured" from
defaults, in fact, I checked under System-Preferences-System-Software
Updates which has been set to the following (since it was my first time
in there):
Check for updates: Daily
Automatic install: Nothing
Check for major upgrades: Weekly
Both Display notifications are checked/on

So, what caused these three packages to be installed?  And, apparently I
am not alone since others have chimed in on fedora-list.

So, whodunnit?  :-)

--Rob




From a.badger at gmail.com  Fri Dec  5 18:51:19 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 10:51:19 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <corn06xveo.ln2@ppp1053.in.ipex.cz>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
Message-ID: <49397827.2080807@gmail.com>

Matej Cepl wrote:
> 
> The party line is that you should develop against python 2.6 
> (which doesn't block you from being compatible with Python 2.3) 
> and then conversion from 2.6 to 3.* would be guaranteed to be 
> done just with a script.
> 
The guarantee that 2to3 will convert your code does not exist.

Additionally to be more compatible with 3.x syntax, you have to enable
3.x features in python-2.6.  Use of those features will make your code
incompatible with python <= 2.5.

So you either have 2.x compatible code or 3.x compatible code not both
(even including the script).

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/d3905dd7/attachment.sig>

From dominik at greysector.net  Fri Dec  5 18:57:12 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 5 Dec 2008 19:57:12 +0100
Subject: The looming Python 3(000) monster
In-Reply-To: <1228502371.4755.4421.camel@localhost.localdomain>
References: <49393DE3.1080707@redhat.com>
	<16de708d0812050806te18c699te29f3376a4f154ad@mail.gmail.com>
	<1228502371.4755.4421.camel@localhost.localdomain>
Message-ID: <20081205185712.GB15166@mokona.greysector.net>

On Friday, 05 December 2008 at 19:39, Callum Lerwick wrote:
> On Fri, 2008-12-05 at 10:06 -0600, Arthur Pemberton wrote:
> > On Fri, Dec 5, 2008 at 8:42 AM, Michael DeHaan <mdehaan at redhat.com> wrote:
> > >
> > > We're just now dealing with Python 2.6, but over on the radar is perhaps one
> > > of the most incompatible upgrades to the language we've seen in Python 3.  I
> > > personally haven't tried it yet, but it /aims/ to be incompatble, which is
> > > perhaps one of the most glaring signs a language designer has lost it that
> > > I've seen.
> > 
> > 
> > Was that last line really necessary for your post?
> 
> The implicit looming flamewar here should be taken upstream. Fedora
> policy is to follow upstream, wherever it may take us.

Sure it is not to follow blindly. Talking with upstream about problems
and solutions will earn you extra points.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From a.badger at gmail.com  Fri Dec  5 18:56:44 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 10:56:44 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <4939733D.4000304@lfarkas.org>
References: <49393DE3.1080707@redhat.com>	<1228489052.29612.158.camel@ignacio.lan>	<20081205151305.GA13097@nostromo.devel.redhat.com>
	<4939733D.4000304@lfarkas.org>
Message-ID: <4939796C.8040705@gmail.com>

Farkas Levente wrote:
> Bill Nottingham wrote:
>> Only one version of EL, though. It's not like RHEL 4/5 are going
>> to move to new python.
> 
> but rhel-6 will be based on f11 and if f11 won't ve p3000 then nor el-6
> which will hurt many people even in 2015...
> 
Short answer yes.

Longer answer, if it's based on F11, it should have at least python-2.6.
 If it has 2.6, then something resembling python3 code will be allowed.
  I qualify that since there are incompatibilities between what 2.6 with
python3 syntax and python3.0 do.  Whether the incompatibilities are
something we can deal with or not is something we need experience with
to find out.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/a90cca01/attachment.sig>

From jwboyer at gmail.com  Fri Dec  5 19:04:16 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 5 Dec 2008 14:04:16 -0500
Subject: OCaml status
In-Reply-To: <20081205174757.GA27576@thinkpad>
References: <20081205174757.GA27576@thinkpad>
Message-ID: <20081205190416.GB32621@yoda.jdub.homelinux.org>

On Fri, Dec 05, 2008 at 05:47:57PM +0000, Richard W.M. Jones wrote:
>I believe that all broken dependencies should now be resolved.
>There's just a couple of final packages going through Koji now and
>once Koji does another createrepo, I hope that there won't be any
>broken deps.  Well hopefully ...  we'll see tomorrow.

Awesome.  Thanks for fixing it up Rich.

josh



From peter at thecodergeek.com  Fri Dec  5 19:05:11 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Fri, 05 Dec 2008 11:05:11 -0800
Subject: License Addition: Deluge (CC-BY-SA Tango images)
In-Reply-To: <49390DBA.4060604@nicubunu.ro>
References: <1228472491.9341.370.camel@localhost.localdomain>
	<49390DBA.4060604@nicubunu.ro>
Message-ID: <1228503911.3161.20.camel@localhost.localdomain>

On Fri, 2008-12-05 at 13:17 +0200, Nicu Buculei wrote:
> I am surprised to learn the Tango people haven't managed to finish the 
> move from CC-BY-SA to PD, as it was announced a long time ago:
> http://lists.freedesktop.org/archives/tango-artists/2008-July/001821.html

Come to think of it, that puzzles me a bit as well. Bryan Petty recently
asked similarly, though:
http://lists.freedesktop.org/archives/tango-artists/2008-November/001920.html
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/c74a4fca/attachment.sig>

From a.badger at gmail.com  Fri Dec  5 19:04:40 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 11:04:40 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
References: <49393DE3.1080707@redhat.com> <493973AF.2030009@gmail.com>
	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
Message-ID: <49397B48.5090206@gmail.com>

Arthur Pemberton wrote:
> 
> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
> ensure that all code is compatible with 3. And still have 3 in
> parallel for those who want it. So we target 2.6+ , but have 3.0 there
> to ensure everything would work with it, and for early adopters/devs
> 
It is an oversimplification but how much is something we need experience
in order to discover.  2.6 != 3.x even though they are close.  There
will be a 2.7 and a 3.1 and some of those problems should be addressed
in those two releases.  Until we actually build experience trying to do
this, though, we don't know to what extent our work on making things
work on 2.6 will carry over to 3.x.

Note, the port we've just done to 2.6 is not all that's needed.
python-2.6 tries to have a 2.x mode and a 3.x mode (some changes are too
deep to truly have this but it tries).  We'll have to start porting code
to 2.6 with 3.x features turned on at some point.

Also note, this is a valid plan for Fedora but it doesn't address
mpdehaan's issue with supporting python <= 2.5 (which I don't think is
solvable in any elegant manner.)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/09debf97/attachment.sig>

From abu_hurayrah at hidayahonline.org  Fri Dec  5 18:58:15 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Fri, 05 Dec 2008 20:58:15 +0200
Subject: The looming Python 3(000) monster
In-Reply-To: <49397522.7010303@gmail.com>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<49394127.3050108@redhat.com> <20081205151134.GB4142@thinkpad>
	<49397522.7010303@gmail.com>
Message-ID: <1228503496.3386.41.camel@beta>

On Fri, 2008-12-05 at 10:38 -0800, Toshio Kuratomi wrote:
> Richard W.M. Jones wrote:
> Yes.  This figures into our plans for migrating code within Fedora to
> 3.x.  However, it doesn't address Michael's concerns about maintaining
> code on python <= 2.5.
> 
> -Toshio
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Short of a complete code audit, what would it take to identify what
packages need what degree of modifications?

For example, what if we ran 2to3 on a number of the "core" packages that
we consider to be essential to a Fedora system, and see how much really
needs to be done?  This might be a nice reality check to see what the
situation really is.

I'm sure we'll find a lot of surprises, good & bad, if someone can
commit to doing it...

Maybe a great start would be on the packages that Ignacio et al (or is
it just him?) have already converted over to 2.6 compatibility...



From pemboa at gmail.com  Fri Dec  5 18:58:22 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 5 Dec 2008 12:58:22 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <49397827.2080807@gmail.com>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<49397827.2080807@gmail.com>
Message-ID: <16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>

2008/12/5 Toshio Kuratomi <a.badger at gmail.com>:
> Matej Cepl wrote:
>>
>> The party line is that you should develop against python 2.6
>> (which doesn't block you from being compatible with Python 2.3)
>> and then conversion from 2.6 to 3.* would be guaranteed to be
>> done just with a script.
>>
> The guarantee that 2to3 will convert your code does not exist.
>
> Additionally to be more compatible with 3.x syntax, you have to enable
> 3.x features in python-2.6.  Use of those features will make your code
> incompatible with python <= 2.5.
>
> So you either have 2.x compatible code or 3.x compatible code not both
> (even including the script).
>
> -Toshio


Is there not a subset of features which exist in both 2.5 and 3.0
which can be used in 2.6?


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From james at fedoraproject.org  Fri Dec  5 19:11:12 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 05 Dec 2008 14:11:12 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <1228502748.3386.36.camel@beta>
References: <49393DE3.1080707@redhat.com> <493973AF.2030009@gmail.com>
	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
	<1228502748.3386.36.camel@beta>
Message-ID: <1228504272.26618.191.camel@code.and.org>

On Fri, 2008-12-05 at 20:45 +0200, Basil Mohamed Gohar wrote:

> It would be very hard to write 2.6 code that is completely compatible
> with 3.0, because 3.0 has changed many fundamental language constructs,
> including even the "print" statement, which in 3.0 is a function (syntax
> change).
> 
> I am not sure how far the from __future__ import feature will work for
> such changes as that.

 Sigh...

from __future__ import print_function

...can everyone who isn't involved in writing python code, and/or not
read about 2.6 / 3.0 before this thread please not comment?


 As Toshio Kuratomi said extremely well, in the grand parent to this
post:

        Note that I think this decision is only partially within the
        powers of the Fedora Project to decide.  If 80% of our upstream
        libraries move to py3, we'll need to move to py3 sooner.  If 80%
        refuse to move off of py2, we can take our time working on
        migration code.

...so as I said, we don't have concrete plans yet ... and some of that
is because it depends on available resources within the project, but a
lot of that is because we have to follow upstream and it's not obvious
how fast (the majority of) python developers upstream will move.

-- 
James Antill <james at fedoraproject.org>
Fedora



From a.badger at gmail.com  Fri Dec  5 19:11:06 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 11:11:06 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812051050m26e0a696tce1ed336b43f39c3@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<493973AF.2030009@gmail.com>	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>	<1228502748.3386.36.camel@beta>
	<16de708d0812051050m26e0a696tce1ed336b43f39c3@mail.gmail.com>
Message-ID: <49397CCA.70105@gmail.com>

Arthur Pemberton wrote:
> On Fri, Dec 5, 2008 at 12:45 PM, Basil Mohamed Gohar
> <abu_hurayrah at hidayahonline.org> wrote:
>> On Fri, 2008-12-05 at 12:40 -0600, Arthur Pemberton wrote:
>>> 2008/12/5 Toshio Kuratomi <a.badger at gmail.com>:
>>>
>>> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
>>> ensure that all code is compatible with 3. And still have 3 in
>>> parallel for those who want it. So we target 2.6+ , but have 3.0 there
>>> to ensure everything would work with it, and for early adopters/devs
>>>
>>> --
>>> Fedora 9 : sulphur is good for the skin
>>> ( www.pembo13.com )
>>>
>> It would be very hard to write 2.6 code that is completely compatible
>> with 3.0, because 3.0 has changed many fundamental language constructs,
>> including even the "print" statement, which in 3.0 is a function (syntax
>> change).
> 
> I believe 'print' is a poor example as it is very easy to fix. Are
> there other, more problematic ones?
> 
Yes, print is a poor example for the 2.6=>3.0 compatibility test (it is
a good example for 2.5=>3.0 compatibility, though, as there's no way to
redefine a keyword from within python.)

The problem area that I'm most aware of is unicode handling.  There have
been some major improvements to this that make it more sane.  However,
there's also been some regressions.  Some of those regressions lead to
code that looks like it should work but silently fail to do what's
expected on *nix in some corner cases.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/8219e012/attachment.sig>

From jkeating at redhat.com  Fri Dec  5 19:19:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 05 Dec 2008 11:19:00 -0800
Subject: Whodunnit? F10 install without permission
In-Reply-To: <1228502782.3673.29.camel@localhost.localdomain>
References: <1228502782.3673.29.camel@localhost.localdomain>
Message-ID: <1228504740.3275.48.camel@localhost.localdomain>

On Fri, 2008-12-05 at 13:46 -0500, Robert Locke wrote:
> So, whodunnit?  :-)

PackageKit did it... helpfully...?  It won't in the future.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/bf615aea/attachment.sig>

From lesmikesell at gmail.com  Fri Dec  5 19:25:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 05 Dec 2008 13:25:02 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <1228502371.4755.4421.camel@localhost.localdomain>
References: <49393DE3.1080707@redhat.com>	<16de708d0812050806te18c699te29f3376a4f154ad@mail.gmail.com>
	<1228502371.4755.4421.camel@localhost.localdomain>
Message-ID: <4939800E.1000000@gmail.com>

Callum Lerwick wrote:
> 
>>> We're just now dealing with Python 2.6, but over on the radar is perhaps one
>>> of the most incompatible upgrades to the language we've seen in Python 3.  I
>>> personally haven't tried it yet, but it /aims/ to be incompatble, which is
>>> perhaps one of the most glaring signs a language designer has lost it that
>>> I've seen.
>>
>> Was that last line really necessary for your post?
> 
> The implicit looming flamewar here should be taken upstream. Fedora
> policy is to follow upstream, wherever it may take us.

Just push the problems of changing API on regardless of the damage it 
causes to users who will be running their own and 3rd party code?

The only reasonable way to ship changes that aren't backwards-compatible 
once you have a user base is to allow multiple versions to run 
concurrently so everyone can migrate their components separately and at 
their own pace.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From pemboa at gmail.com  Fri Dec  5 19:25:16 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 5 Dec 2008 13:25:16 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <49397CCA.70105@gmail.com>
References: <49393DE3.1080707@redhat.com> <493973AF.2030009@gmail.com>
	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
	<1228502748.3386.36.camel@beta>
	<16de708d0812051050m26e0a696tce1ed336b43f39c3@mail.gmail.com>
	<49397CCA.70105@gmail.com>
Message-ID: <16de708d0812051125j4fca4a11q1f495234c0be583d@mail.gmail.com>

2008/12/5 Toshio Kuratomi <a.badger at gmail.com>:
> Arthur Pemberton wrote:
>> On Fri, Dec 5, 2008 at 12:45 PM, Basil Mohamed Gohar
>> <abu_hurayrah at hidayahonline.org> wrote:
>>> On Fri, 2008-12-05 at 12:40 -0600, Arthur Pemberton wrote:
>>>> 2008/12/5 Toshio Kuratomi <a.badger at gmail.com>:
>>>>
>>>> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
>>>> ensure that all code is compatible with 3. And still have 3 in
>>>> parallel for those who want it. So we target 2.6+ , but have 3.0 there
>>>> to ensure everything would work with it, and for early adopters/devs
>>>>
>>>> --
>>>> Fedora 9 : sulphur is good for the skin
>>>> ( www.pembo13.com )
>>>>
>>> It would be very hard to write 2.6 code that is completely compatible
>>> with 3.0, because 3.0 has changed many fundamental language constructs,
>>> including even the "print" statement, which in 3.0 is a function (syntax
>>> change).
>>
>> I believe 'print' is a poor example as it is very easy to fix. Are
>> there other, more problematic ones?
>>
> Yes, print is a poor example for the 2.6=>3.0 compatibility test (it is
> a good example for 2.5=>3.0 compatibility, though, as there's no way to
> redefine a keyword from within python.)
>
> The problem area that I'm most aware of is unicode handling.  There have
> been some major improvements to this that make it more sane.  However,
> there's also been some regressions.  Some of those regressions lead to
> code that looks like it should work but silently fail to do what's
> expected on *nix in some corner cases.
>
> -Toshio


Fair enough. Think I'll shutup for now as there seem to be smarter
stakeholders involved than I. However, would just like to say that it
will be nice to have 3.0 in parallel (but not built against) as soon
as possible. Especially as Python is pushing a head in areas such as
web dev.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From a.badger at gmail.com  Fri Dec  5 19:25:05 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Dec 2008 11:25:05 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
Message-ID: <49398011.9030100@gmail.com>

Arthur Pemberton wrote:
> 
> Is there not a subset of features which exist in both 2.5 and 3.0
> which can be used in 2.6?
> 

Trivial code can work but I wouldn't bet on any applications (with all
their library dependencies) being able to work in both 2.5 and 3.0.
Some things are a lot of work: you can't easily deal with methods in the
stdlib changing between 2.x and 3.x except to write your own version or
either the 3.x or 2.x version.

Other things are changed at a deep level.  For instance, str and unicode
in python2.x has become bytes and str(an abstract unicode type) in
python3.x.  Even with the 3.x compat mode in python 2.6 there's things
that have subtle bugs.  Attempting to write code compatible with both
2.5 and 3.0 will fail miserably.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/e64f3fef/attachment.sig>

From lists at ralii.com  Fri Dec  5 19:28:40 2008
From: lists at ralii.com (Robert Locke)
Date: Fri, 05 Dec 2008 14:28:40 -0500
Subject: Whodunnit? F10 install without permission
In-Reply-To: <1228504740.3275.48.camel@localhost.localdomain>
References: <1228502782.3673.29.camel@localhost.localdomain>
	<1228504740.3275.48.camel@localhost.localdomain>
Message-ID: <1228505320.3673.31.camel@localhost.localdomain>

On Fri, 2008-12-05 at 11:19 -0800, Jesse Keating wrote:
> On Fri, 2008-12-05 at 13:46 -0500, Robert Locke wrote:
> > So, whodunnit?  :-)
> 
> PackageKit did it... helpfully...?  It won't in the future.
> 

Two follow-on questions:

1) Was it configured somewhere?  Couldn't see anything
in /etc/PackageKit/

2) So, I don't need to Bugzilla this obvious invasion, since we won't do
that to machines again? <big grin>

Thanks,

--Rob




From pemboa at gmail.com  Fri Dec  5 19:33:29 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 5 Dec 2008 13:33:29 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <49398011.9030100@gmail.com>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
Message-ID: <16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>

2008/12/5 Toshio Kuratomi <a.badger at gmail.com>:
> Arthur Pemberton wrote:
>>
>> Is there not a subset of features which exist in both 2.5 and 3.0
>> which can be used in 2.6?
>>
>
> Trivial code can work but I wouldn't bet on any applications (with all
> their library dependencies) being able to work in both 2.5 and 3.0.
> Some things are a lot of work: you can't easily deal with methods in the
> stdlib changing between 2.x and 3.x except to write your own version or
> either the 3.x or 2.x version.


I'm sorry, I thought we were only discussing this in reference to
apps/tools that are directly under Fedora's control. And that
everything purely 3rd party would be built against 2.6 or 3.0 as
deemed by upstream. If this is not the case, then I better understand
the depth of the problem.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jkeating at redhat.com  Fri Dec  5 19:45:08 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 05 Dec 2008 11:45:08 -0800
Subject: Whodunnit? F10 install without permission
In-Reply-To: <1228505320.3673.31.camel@localhost.localdomain>
References: <1228502782.3673.29.camel@localhost.localdomain>
	<1228504740.3275.48.camel@localhost.localdomain>
	<1228505320.3673.31.camel@localhost.localdomain>
Message-ID: <1228506308.3275.51.camel@localhost.localdomain>

On Fri, 2008-12-05 at 14:28 -0500, Robert Locke wrote:
> Two follow-on questions:
> 
> 1) Was it configured somewhere?  Couldn't see anything
> in /etc/PackageKit/

I don't know.  PK did it so that it would know what options were
available for upgrades so that it could offer you the ability to
upgrade.  We've moved that information to a public webserver rather than
being in the preupgrade package so that PK can get this information
without stealth installing packages.

> 
> 2) So, I don't need to Bugzilla this obvious invasion, since we won't do
> that to machines again? <big grin>

Well, I don't think there are any current guidelines that would have
caught this, but it does fall into the "don't do that" category.  It
just wasn't noticed by many people until recentlyish.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/07a988e4/attachment.sig>

From kevin.kofler at chello.at  Fri Dec  5 19:45:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 05 Dec 2008 20:45:47 +0100
Subject: Status of libtool 2.2.X?
References: <1196809380.678451228188533311.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1228190889.5593.2817.camel@beck.corsepiu.local>
	<gh5j3o$5cp$1@ger.gmane.org>
	<1228296680.20451.1794.camel@beck.corsepiu.local>
	<gh7ggq$uk1$2@ger.gmane.org> <49380E63.9010801@gmail.com>
	<gh9f75$28a$1@ger.gmane.org> <20081205095329.GA2971@nb.net.home>
Message-ID: <ghc0dc$h4$1@ger.gmane.org>

Karel Zak wrote:

> On Thu, Dec 04, 2008 at 02:40:05PM -0600, Matthew Woehlke wrote:
>> needing only CMake vs. needing sh, sed, awk, etc is fewer dependencies.
> 
>  "The Right Tool For The Job" ...

That's kinda the point...

>  autotools use already implemented tools (POSIX sed, awk, sh, ..)

Tools which are really not intended to be used the way the autotools do.
Just look at all the glitches and incompatibilities the extremely complex
configure scripts uncover in various implementations (just try to read a
configure script and watch how often terms like "bug in ...", "work around"
etc. are used in comments - and that's where there _are_ comments). The
autotools are abusing shell scripts for things which should be done by real
programs (and that's also why they are so slow).

>  rather than duplicate functionality & code.

CMake doesn't duplicate anything, it just uses C++ rather than shell as its
language. The right tool for the job. :-)

The autotools are the ones which duplicate functionality by copying the same
scripts and script snippets over and over to every single program.

>  The dependences are price that we pay for this excellent UNIX idea.

There you say it: "UNIX idea" - i.e. non-portable. Not all the world is
POSIX (even if we can all wish it was).

        Kevin Kofler



From pertusus at free.fr  Fri Dec  5 19:47:49 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 20:47:49 +0100
Subject: remove fcron-watch-config if you installed it
Message-ID: <20081205194749.GA3227@free.fr>

Hello,

I removed the fcron subpackage:
 fcron-watch-config
You should uninstall it by hand if you installed it.  I don't want to
add obsoletes for such a short lived package that shouldn't have been
brought in by anything.

--
Pat



From pertusus at free.fr  Fri Dec  5 19:59:14 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 20:59:14 +0100
Subject: use fcron as default scheduler in Fedora?
Message-ID: <20081205195914.GB3227@free.fr>

Hello,

I think that fcron should be the default scheduler in fedora.
fcron, with the service fcron_watch_config activated should now be 
100% compatible with vixie-cron (cronie). The fcron_watch_config stuff 
is a bit convoluted (3 scripts and one C program...) but should work.

The advantages over cronie are the following:
* it also does what anacron does
* it has more features
* instead of waking up every minutes to look at config files, like
  cronie do, it uses inotify to watch the config. This should lead to
  less awaking and certainly be interesting for power saving in some
  situations

I won't push this more, somebody else has to volunteer to make this 
happen. I think it could be done in F11 and it should be a feature.

--
Pat



From jkeating at redhat.com  Fri Dec  5 20:05:30 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 05 Dec 2008 12:05:30 -0800
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081205195914.GB3227@free.fr>
References: <20081205195914.GB3227@free.fr>
Message-ID: <1228507530.3275.53.camel@localhost.localdomain>

On Fri, 2008-12-05 at 20:59 +0100, Patrice Dumas wrote:
> I won't push this more, somebody else has to volunteer to make this 
> happen. I think it could be done in F11 and it should be a feature.

What are the deplists comparatively?

Has fcron had a security audit recently?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/f5ad408a/attachment.sig>

From joe at nall.com  Fri Dec  5 20:07:40 2008
From: joe at nall.com (Joe Nall)
Date: Fri, 5 Dec 2008 14:07:40 -0600
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081205195914.GB3227@free.fr>
References: <20081205195914.GB3227@free.fr>
Message-ID: <70F2CCFE-F3BE-4987-9A62-17B90094BE26@nall.com>


On Dec 5, 2008, at 1:59 PM, Patrice Dumas wrote:

> Hello,
>
> I think that fcron should be the default scheduler in fedora.
> fcron, with the service fcron_watch_config activated should now be
> 100% compatible with vixie-cron (cronie). The fcron_watch_config stuff
> is a bit convoluted (3 scripts and one C program...) but should work.
>
> The advantages over cronie are the following:
> * it also does what anacron does
> * it has more features
> * instead of waking up every minutes to look at config files, like
>  cronie do, it uses inotify to watch the config. This should lead to
>  less awaking and certainly be interesting for power saving in some
>  situations
>
> I won't push this more, somebody else has to volunteer to make this
> happen. I think it could be done in F11 and it should be a feature.

Does fcron have the selinux context support that was added to cronie?

joe




From notting at redhat.com  Fri Dec  5 20:10:12 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 5 Dec 2008 15:10:12 -0500
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <1228507530.3275.53.camel@localhost.localdomain>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
Message-ID: <20081205201012.GA17997@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> On Fri, 2008-12-05 at 20:59 +0100, Patrice Dumas wrote:
> > I won't push this more, somebody else has to volunteer to make this 
> > happen. I think it could be done in F11 and it should be a feature.
> 
> What are the deplists comparatively?

Shorter than cronie, actually. It doesn't rely on the audit libs.
(That being said, the audit folks may want to look into that, as they
like to audit things.)

> Has fcron had a security audit recently?

Not sure. It did support SELinux before vixie-cron and derivatives did.

Bill



From pertusus at free.fr  Fri Dec  5 20:16:21 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 21:16:21 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <1228507530.3275.53.camel@localhost.localdomain>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
Message-ID: <20081205201621.GC3227@free.fr>

On Fri, Dec 05, 2008 at 12:05:30PM -0800, Jesse Keating wrote:
> On Fri, 2008-12-05 at 20:59 +0100, Patrice Dumas wrote:
> > I won't push this more, somebody else has to volunteer to make this 
> > happen. I think it could be done in F11 and it should be a feature.
> 
> What are the deplists comparatively?

fcron has additionally 
 vim-minimal  
But I think that this is also a cronie dep that is missing (I think
/usr/bin/crontab defaults to use it).

fcron also uses /usr/bin/setsid. I don't think this is annoying, and to
avoid it trivial C code could be used.

> Has fcron had a security audit recently?

What exactly do you mean here? Are you referring to an audit done by
some specific people, or using some methodology? Or a security audit in
a vague sense?

--
Pat



From pertusus at free.fr  Fri Dec  5 20:18:50 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 21:18:50 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081205195914.GB3227@free.fr>
References: <20081205195914.GB3227@free.fr>
Message-ID: <20081205201850.GE3227@free.fr>

On Fri, Dec 05, 2008 at 08:59:14PM +0100, Patrice Dumas wrote:
> Hello,
> 
> I think that fcron should be the default scheduler in fedora.

I also think that I think that cronie+anacron should stay.

--
Pat



From kevin.kofler at chello.at  Fri Dec  5 20:21:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 05 Dec 2008 21:21:47 +0100
Subject: The looming Python 3(000) monster
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<1228490078.26618.163.camel@code.and.org>
Message-ID: <ghc2gr$78s$1@ger.gmane.org>

James Antill wrote:
>  We also have _much less_ resources dedicated to python than we do GCC.
>  My guess is that if a second python is proposed for py3k, it'll get
> voted down again.

I think migrating without shipping parallel versions of Python at any point
is a completely unrealistic dream. Just look at how many packages still
depend on qt3 and kdelibs3, and how there are still packages depending on
gtk+-1.2 even when plans for GTK+ 3 are already ongoing. We have no reason
to believe Python will be any different.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec  5 20:29:36 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 05 Dec 2008 21:29:36 +0100
Subject: The looming Python 3(000) monster
References: <49393DE3.1080707@redhat.com> <20081205150949.GD4290@redhat.com>
	<1228491139.26618.171.camel@code.and.org>
Message-ID: <ghc2vg$9pl$1@ger.gmane.org>

James Antill wrote:
> The API is very similar and uses the same shared library
> name ... so what do you do about all the C programs that link with
> libpython?
> 
> repoquery --whatrequires 'libpython2.5.so.*'

The same thing we do about kdelibs3 and kdelibs 4 coexisting: move one (or
both) of the 2 conflicting -devel symlinks to a subdirectory of the libdir
and have the dependent packages use -L flags.

But is there even a conflict at all? libpython2.5.so != libpython3.0.so.

And if there is one, maybe try to get upstream to fix it?

> ...are you going to offer two versions of rhythmbox?

But Python is not an application, it's a programming language and a set of
libraries. Shipping 2 versions of an application doesn't make much sense
(and in fact we don't do that for KDE 3 and 4), but libraries (e.g.
kdelibs3/kdelibs4) and programming languages are different. Getting
everything which depends on the library/language ported at the same time is
almost always infeasible for incompatible versions.

        Kevin Kofler



From notting at redhat.com  Fri Dec  5 20:30:58 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 5 Dec 2008 15:30:58 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <ghc2gr$78s$1@ger.gmane.org>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<1228490078.26618.163.camel@code.and.org>
	<ghc2gr$78s$1@ger.gmane.org>
Message-ID: <20081205203058.GA18292@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> I think migrating without shipping parallel versions of Python at any point
> is a completely unrealistic dream. Just look at how many packages still
> depend on qt3 and kdelibs3, and how there are still packages depending on
> gtk+-1.2 even when plans for GTK+ 3 are already ongoing.

The packages that still depend on GTK1 are all effectively dead, IMO. At some
point, you have to cull the corpses.

Bill



From kevin.kofler at chello.at  Fri Dec  5 20:34:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 05 Dec 2008 21:34:59 +0100
Subject: autotools hurts my brain; it's a monster out of control
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com> <20081205102903.GB18476@thinkpad>
	<1228494213.21898.11.camel@atropine.boston.devel.redhat.com>
	<20081205164059.GA27146@thinkpad>
Message-ID: <ghc39j$9pl$2@ger.gmane.org>

Richard W.M. Jones wrote:
> You also need to generate an implib on Windows, which requires an
> extra Windows-specific gcc option.

MinGW can actually link a DLL directly these days.

The problem is with directories: the executable wants the DLL in bin, but
the linker will only find it in lib. For this reason, and in some cases
also because of compatibility with M$VC, import libraries are usually still
used.

        Kevin Kofler



From walters at verbum.org  Fri Dec  5 20:39:51 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 5 Dec 2008 15:39:51 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <20081205203058.GA18292@nostromo.devel.redhat.com>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<1228490078.26618.163.camel@code.and.org> <ghc2gr$78s$1@ger.gmane.org>
	<20081205203058.GA18292@nostromo.devel.redhat.com>
Message-ID: <faa16b610812051239q19b2d827u4c45dbec94684a48@mail.gmail.com>

On Fri, Dec 5, 2008 at 3:30 PM, Bill Nottingham <notting at redhat.com> wrote:
> Kevin Kofler (kevin.kofler at chello.at) said:
>> I think migrating without shipping parallel versions of Python at any point
>> is a completely unrealistic dream. Just look at how many packages still
>> depend on qt3 and kdelibs3, and how there are still packages depending on
>> gtk+-1.2 even when plans for GTK+ 3 are already ongoing.
>
> The packages that still depend on GTK1 are all effectively dead, IMO. At some
> point, you have to cull the corpses.

Also, GTK+ 3 is not likely anytime soon, and by soon I mean anytime
before the next 5 years.  The discussions so far have a similar
motiviation as Python 3000; effectively a housecleaning without any
really compelling reason to jump.



From lesmikesell at gmail.com  Fri Dec  5 20:36:53 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 05 Dec 2008 14:36:53 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<49397827.2080807@gmail.com>	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
Message-ID: <493990E5.3060408@gmail.com>

Arthur Pemberton wrote:
>
>>> Is there not a subset of features which exist in both 2.5 and 3.0
>>> which can be used in 2.6?
>>>
>> Trivial code can work but I wouldn't bet on any applications (with all
>> their library dependencies) being able to work in both 2.5 and 3.0.
>> Some things are a lot of work: you can't easily deal with methods in the
>> stdlib changing between 2.x and 3.x except to write your own version or
>> either the 3.x or 2.x version.
> 
> 
> I'm sorry, I thought we were only discussing this in reference to
> apps/tools that are directly under Fedora's control. And that
> everything purely 3rd party would be built against 2.6 or 3.0 as
> deemed by upstream. If this is not the case, then I better understand
> the depth of the problem.

Is there a plan for how yum is going to upgrade itself?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Fri Dec  5 20:36:18 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 05 Dec 2008 21:36:18 +0100
Subject: autotools hurts my brain; it's a monster out of control
References: <4938540D.80606@redhat.com> <49385677.8090701@redhat.com>
	<4938BC0C.5070701@redhat.com>
	<20081205111313.GA3036@evileye.atkac.englab.brq.redhat.com>
Message-ID: <ghc3c2$9pl$3@ger.gmane.org>

I can't speak for Ulrich, but:

Adam Tkac wrote:
> Could I ask you how are you building shared librares from one source
> for multiple platforms? I need, for example, to compile and run shared
> library on Linux, AIX, HP-UX and Solaris. Do you know what tool is
> better than libtool?

CMake.

        Kevin Kofler



From mw_triad at users.sourceforge.net  Fri Dec  5 20:46:41 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 05 Dec 2008 14:46:41 -0600
Subject: cpufreq module on x86_64
In-Reply-To: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
Message-ID: <ghc3vh$bjc$1@ger.gmane.org>

Jerry James wrote:
> First I wondered why I was getting a cpufreq module loaded on a
> desktop machine.

...so your machine draws less power when you aren't using it?

I hear that there is a general trend to add power-friendliness to 
Fedora, mainly for laptops/netbooks, which is probably the "why". 
However, I agree with doing it in general since saving power is good on 
desktops also :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
For great justice!! -- Captain (Zero Wing)



From notting at redhat.com  Fri Dec  5 21:02:10 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 5 Dec 2008 16:02:10 -0500
Subject: package seeking new owner: jed
Message-ID: <20081205210210.GA19180@nostromo.devel.redhat.com>

I don't really use it any more, so I figure I might as well give
the opportunity to maintain it to someone who does. Has had one
actual bug (FTBFS) filed in the past four years.

Bill



From limb at jcomserv.net  Fri Dec  5 21:03:06 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 5 Dec 2008 15:03:06 -0600 (CST)
Subject: The looming Python 3(000) monster
In-Reply-To: <493990E5.3060408@gmail.com>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
Message-ID: <6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>


> Arthur Pemberton wrote:
>>
>>>> Is there not a subset of features which exist in both 2.5 and 3.0
>>>> which can be used in 2.6?
>>>>
>>> Trivial code can work but I wouldn't bet on any applications (with all
>>> their library dependencies) being able to work in both 2.5 and 3.0.
>>> Some things are a lot of work: you can't easily deal with methods in
>>> the
>>> stdlib changing between 2.x and 3.x except to write your own version or
>>> either the 3.x or 2.x version.
>>
>>
>> I'm sorry, I thought we were only discussing this in reference to
>> apps/tools that are directly under Fedora's control. And that
>> everything purely 3rd party would be built against 2.6 or 3.0 as
>> deemed by upstream. If this is not the case, then I better understand
>> the depth of the problem.
>
> Is there a plan for how yum is going to upgrade itself?

Should it not execute from the 2.6 version on disk and use rpm to alter
the copy on disk to use 3.0, so that the next run will use 3.0?  It'll
require python 3.0, so it'll be in the same execution.

In short, shouldn't it work just like it does now?

> --
>    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
>


-- 
in your fear, speak only peace
in your fear, speak only love

-d. bowie



From jkeating at redhat.com  Fri Dec  5 21:04:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 05 Dec 2008 13:04:12 -0800
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081205201621.GC3227@free.fr>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr>
Message-ID: <1228511052.3275.54.camel@localhost.localdomain>

On Fri, 2008-12-05 at 21:16 +0100, Patrice Dumas wrote:
> What exactly do you mean here? Are you referring to an audit done by
> some specific people, or using some methodology? Or a security audit in
> a vague sense?

Any of the above really.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/5c24f84f/attachment.sig>

From jkeating at redhat.com  Fri Dec  5 21:10:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 05 Dec 2008 13:10:32 -0800
Subject: cpufreq module on x86_64
In-Reply-To: <ghc3vh$bjc$1@ger.gmane.org>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
	<ghc3vh$bjc$1@ger.gmane.org>
Message-ID: <1228511432.3275.55.camel@localhost.localdomain>

On Fri, 2008-12-05 at 14:46 -0600, Matthew Woehlke wrote:
> Jerry James wrote:
> > First I wondered why I was getting a cpufreq module loaded on a
> > desktop machine.
> 
> ...so your machine draws less power when you aren't using it?
> 
> I hear that there is a general trend to add power-friendliness to 
> Fedora, mainly for laptops/netbooks, which is probably the "why". 
> However, I agree with doing it in general since saving power is good on 
> desktops also :-).

s,laptops/netbooks,the environment

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/fe2d5b47/attachment.sig>

From seg at haxxed.com  Fri Dec  5 21:35:34 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 05 Dec 2008 15:35:34 -0600
Subject: cpufreq module on x86_64
In-Reply-To: <ghc3vh$bjc$1@ger.gmane.org>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
	<ghc3vh$bjc$1@ger.gmane.org>
Message-ID: <1228512934.4755.4442.camel@localhost.localdomain>

On Fri, 2008-12-05 at 14:46 -0600, Matthew Woehlke wrote:
> Jerry James wrote:
> > First I wondered why I was getting a cpufreq module loaded on a
> > desktop machine.
> 
> ...so your machine draws less power when you aren't using it?
> 
> I hear that there is a general trend to add power-friendliness to 
> Fedora, mainly for laptops/netbooks, which is probably the "why". 
> However, I agree with doing it in general since saving power is good on 
> desktops also :-).

Also note that power usage directly manifests in heat output. The amount
of heat spewed into the room by a high performance desktop system is
very much a concern on a hot humid summer day in a trailer house with no
air conditioning, sitting in your underwear with sweat dripping down
your face just trying to catch up on fedora-devel...

However it may be desirable in the winter. :)

It also can manifest in noise. Hard drives spinning, fans... Noise noise
noise. If you've got temp regulated fans, less heat means less noise...

I noticed that at some point my Athlon 64 3000+ (2ghz) desktop system
lost its ability to change frequency. I think it happened in a F9
update, but its definately gone in F10. It was capable of switching
between 2ghz and 1ghz. Is mine one of the old Athlon 64's that take too
much time to switch or something? I never had too much problem, if I was
doing something really demanding I'd just manually lock it at 2ghz...
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/40fcbae1/attachment.sig>

From james at fedoraproject.org  Fri Dec  5 21:46:15 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 05 Dec 2008 16:46:15 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <ghc2vg$9pl$1@ger.gmane.org>
References: <49393DE3.1080707@redhat.com> <20081205150949.GD4290@redhat.com>
	<1228491139.26618.171.camel@code.and.org> <ghc2vg$9pl$1@ger.gmane.org>
Message-ID: <1228513575.26618.203.camel@code.and.org>

On Fri, 2008-12-05 at 21:29 +0100, Kevin Kofler wrote:
> James Antill wrote:
> > The API is very similar and uses the same shared library
> > name ... so what do you do about all the C programs that link with
> > libpython?
> > 
> > repoquery --whatrequires 'libpython2.5.so.*'
> 
> The same thing we do about kdelibs3 and kdelibs 4 coexisting: move one (or
> both) of the 2 conflicting -devel symlinks to a subdirectory of the libdir
> and have the dependent packages use -L flags.

 You are confused, this isn't the same as KDE because _KDE isn't a
programming language_.

> > ...are you going to offer two versions of rhythmbox?
> 
> But Python is not an application, it's a programming language and a set of
> libraries. Shipping 2 versions of an application doesn't make much sense
> (and in fact we don't do that for KDE 3 and 4), but libraries (e.g.
> kdelibs3/kdelibs4) and programming languages are different. Getting
> everything which depends on the library/language ported at the same time is
> almost always infeasible for incompatible versions.

 Again, you are confused. Yes, you can ship two different libraries that
two different applications can use ... like gtk1/gtk2, but you can't mix
them within an application.
 And that's much more common within a programming language. For example:

http://live.gnome.org/RhythmboxPlugins/WritingGuide

...you have:

application => libpython* => plugin [ => python modules ]

...here you _must_ ship one layer of python throughout, saying "it
should be compatible" works about as well as saying "we should be able
to run kde3 and kde4 in a single applications" ... you can ask for it,
and a pony at the same time, but don't hold your breath.

-- 
James Antill <james at fedoraproject.org>
Fedora



From mw_triad at users.sourceforge.net  Fri Dec  5 21:45:58 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 05 Dec 2008 15:45:58 -0600
Subject: cpufreq module on x86_64
In-Reply-To: <1228511432.3275.55.camel@localhost.localdomain>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>	<ghc3vh$bjc$1@ger.gmane.org>
	<1228511432.3275.55.camel@localhost.localdomain>
Message-ID: <ghc7em$op2$1@ger.gmane.org>

Jesse Keating wrote:
> On Fri, 2008-12-05 at 14:46 -0600, Matthew Woehlke wrote:
>> Jerry James wrote:
>>> First I wondered why I was getting a cpufreq module loaded on a
>>> desktop machine.
>> ...so your machine draws less power when you aren't using it?
>>
>> I hear that there is a general trend to add power-friendliness to 
>> Fedora, mainly for laptops/netbooks, which is probably the "why". 
>> However, I agree with doing it in general since saving power is good on 
>> desktops also :-).
> 
> s,laptops/netbooks,the environment

That wasn't the impression I got, but as I said, that's why I agree with 
doing it for everything, regardless of if "the environment" is the 
reason versus "just" laptops/netbooks :-).

(And since I'm now running Cambridge on my Asus, I'm in favor of power 
saving for both reasons :-).)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
For great justice!! -- Captain (Zero Wing)



From mw_triad at users.sourceforge.net  Fri Dec  5 21:48:05 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 05 Dec 2008 15:48:05 -0600
Subject: cpufreq module on x86_64
In-Reply-To: <1228512934.4755.4442.camel@localhost.localdomain>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>	<ghc3vh$bjc$1@ger.gmane.org>
	<1228512934.4755.4442.camel@localhost.localdomain>
Message-ID: <ghc7il$op2$2@ger.gmane.org>

Callum Lerwick wrote:
> Also note that power usage directly manifests in heat output. The amount
> of heat spewed into the room by a high performance desktop system is
> very much a concern on a hot humid summer day in a trailer house with no
> air conditioning, sitting in your underwear with sweat dripping down
> your face just trying to catch up on fedora-devel...
> 
> However it may be desirable in the winter. :)

There's always folding at home (or whatever distributed computing project 
you prefer) if you need the extra heat ;-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
For great justice!! -- Captain (Zero Wing)



From lesmikesell at gmail.com  Fri Dec  5 21:51:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 05 Dec 2008 15:51:49 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<49397827.2080807@gmail.com>	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>	<49398011.9030100@gmail.com>	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
Message-ID: <4939A275.1070603@gmail.com>

Jon Ciesla wrote:
>
>> Is there a plan for how yum is going to upgrade itself?
> 
> Should it not execute from the 2.6 version on disk and use rpm to alter
> the copy on disk to use 3.0, so that the next run will use 3.0?  It'll
> require python 3.0, so it'll be in the same execution.
> 
> In short, shouldn't it work just like it does now?

Theoretically yes, but historically python's habit of incompatible 
changes have caused problems especially when things were done in the 
wrong order or a system was interrupted before the complete set was 
installed and then couldn't fix itself.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From kevin.kofler at chello.at  Fri Dec  5 21:54:10 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 05 Dec 2008 22:54:10 +0100
Subject: The looming Python 3(000) monster
References: <49393DE3.1080707@redhat.com> <20081205150949.GD4290@redhat.com>
	<1228491139.26618.171.camel@code.and.org>
	<ghc2vg$9pl$1@ger.gmane.org>
	<1228513575.26618.203.camel@code.and.org>
Message-ID: <ghc7u2$o0u$1@ger.gmane.org>

James Antill wrote:
>  Again, you are confused. Yes, you can ship two different libraries that
> two different applications can use ... like gtk1/gtk2, but you can't mix
> them within an application.
>  And that's much more common within a programming language. For example:
> 
> http://live.gnome.org/RhythmboxPlugins/WritingGuide
> 
> ...you have:
> 
> application => libpython* => plugin [ => python modules ]
> 
> ...here you _must_ ship one layer of python throughout, saying "it
> should be compatible" works about as well as saying "we should be able
> to run kde3 and kde4 in a single applications" ... you can ask for it,
> and a pony at the same time, but don't hold your breath.

Rhythmbox will have to pick one version of Python to support (probably the
default version in Fedora), but that doesn't mean other programs won't want
to use the other version.

        Kevin Kofler



From jspaleta at gmail.com  Fri Dec  5 21:56:53 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 5 Dec 2008 12:56:53 -0900
Subject: The looming Python 3(000) monster
In-Reply-To: <4939A275.1070603@gmail.com>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
Message-ID: <604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>

On Fri, Dec 5, 2008 at 12:51 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Theoretically yes, but historically python's habit of incompatible changes
> have caused problems especially when things were done in the wrong order or
> a system was interrupted before the complete set was installed and then
> couldn't fix itself.

interrupted rpm transactions can cause pretty much any sub system to
stop working. Feel free to dive into rpm development and create a fix
for that problem.

-jef



From mike.cloaked at gmail.com  Fri Dec  5 21:58:56 2008
From: mike.cloaked at gmail.com (Mike)
Date: Fri, 5 Dec 2008 21:58:56 +0000 (UTC)
Subject: Java JRE updates?
Message-ID: <loom.20081205T215733-724@post.gmane.org>

After the Java vulnerability alert today at
http://www.us-cert.gov/cas/techalerts/TA08-340A.html
Will there soon be updates to the java packages for current supported
Fedora versions?




From james at fedoraproject.org  Fri Dec  5 22:01:02 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 05 Dec 2008 17:01:02 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <ghc2gr$78s$1@ger.gmane.org>
References: <49393DE3.1080707@redhat.com>
	<e15beb35401d5b956983b3086cdcd8d4.squirrel@mail.jcomserv.net>
	<1228490078.26618.163.camel@code.and.org> <ghc2gr$78s$1@ger.gmane.org>
Message-ID: <1228514462.26618.218.camel@code.and.org>

On Fri, 2008-12-05 at 21:21 +0100, Kevin Kofler wrote:
> James Antill wrote:
> >  We also have _much less_ resources dedicated to python than we do GCC.
> >  My guess is that if a second python is proposed for py3k, it'll get
> > voted down again.
> 
> I think migrating without shipping parallel versions of Python at any point
> is a completely unrealistic dream.

 And yet everyone who's been involved in trying to do that says it's a
giant mess, which they have no wish to repeat. And it has been voted
down when we had only a single significant application that needed an
old version, which would be _much easier_ to manage than your vision of
the future where random amounts of applications have migrated and random
amounts haven't.
 Of course, you could be right ... I would just not bet on that
happening.

>  Just look at how many packages still
> depend on qt3 and kdelibs3, and how there are still packages depending on
> gtk+-1.2 even when plans for GTK+ 3 are already ongoing. We have no reason
> to believe Python will be any different.

 My hope is that as future iterations of both the 2.* and 3.* versions
come out (and the applications using them), the porting burden dwindles
to something "easy enough" for a flag day.

 And as I said before, my current guess is that it'll be much more like
Apache-httpd's 2.* migration and thus. RHEL-7 (yes, seven) will have a
single python that is from the 2.* version stream.
 Yes, py3k was released yesterday. No, that doesn't mean we need to move
to it by next week, month or year.

 Also as has been said before, a lot of the timeline depends on the
various upstreams ... we may be forced to make certain less desirable
choices depending on what happens.

-- 
James Antill <james at fedoraproject.org>
Fedora



From skvidal at fedoraproject.org  Fri Dec  5 22:02:46 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 5 Dec 2008 17:02:46 -0500 (EST)
Subject: orphaning gnome-volume-manager
In-Reply-To: <1228503029.3540.70.camel@localhost.localdomain>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<1228503029.3540.70.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0812051702340.3883@localhost.localdomain>



On Fri, 5 Dec 2008, Matthias Clasen wrote:

> On Mon, 2008-11-24 at 11:35 -0500, David Zeuthen wrote:
>> Hey,
>>
>> gnome-volume-manager is no longer in the default install since the
>> functionality it provides has been replaced by Nautilus as of Fedora 9.
>> As such I'm orphaning it.
>
>
> Its been two weeks now, and no one showed interest in keeping
> gnome-volume-manager alive. So I am going to go ahead with retiring it.

Great. please obsolete it somewhere.

thanks,
-sv



From mike at cchtml.com  Fri Dec  5 22:03:52 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Fri, 05 Dec 2008 16:03:52 -0600
Subject: Java JRE updates?
In-Reply-To: <loom.20081205T215733-724@post.gmane.org>
References: <loom.20081205T215733-724@post.gmane.org>
Message-ID: <4939A548.5060002@cchtml.com>

-------- Original Message --------
Subject: Java JRE updates?
From: Mike  <mike.cloaked at gmail.com>
To: fedora-devel-list at redhat.com
Date: 12/05/2008 03:58 PM

> After the Java vulnerability alert today at
> http://www.us-cert.gov/cas/techalerts/TA08-340A.html
> Will there soon be updates to the java packages for current supported
> Fedora versions?
> 
> 

Since Fedora does not ship Sun Java JRE, why would there be updates?



From mike.cloaked at gmail.com  Fri Dec  5 22:06:14 2008
From: mike.cloaked at gmail.com (Mike)
Date: Fri, 5 Dec 2008 22:06:14 +0000 (UTC)
Subject: Java JRE updates?
References: <loom.20081205T215733-724@post.gmane.org>
	<4939A548.5060002@cchtml.com>
Message-ID: <loom.20081205T220536-121@post.gmane.org>

Michael Cronenworth <mike <at> cchtml.com> writes:

> Since Fedora does not ship Sun Java JRE, why would there be updates?

Are we sure that the versions shipped in F10/9 are free of the same problems? 






From lesmikesell at gmail.com  Fri Dec  5 22:08:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 05 Dec 2008 16:08:51 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<49397827.2080807@gmail.com>	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>	<49398011.9030100@gmail.com>	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
Message-ID: <4939A673.3090907@gmail.com>

Jeff Spaleta wrote:
> On Fri, Dec 5, 2008 at 12:51 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> Theoretically yes, but historically python's habit of incompatible changes
>> have caused problems especially when things were done in the wrong order or
>> a system was interrupted before the complete set was installed and then
>> couldn't fix itself.
> 
> interrupted rpm transactions can cause pretty much any sub system to
> stop working. Feel free to dive into rpm development and create a fix
> for that problem.

I thought that was a separate problem (in a flurry in the FC2/FC3 era) 
but similar in dealing with RPM swapping incompatible db libs underneath 
itself.  I recall for a while I defensively did a separate run of yum to 
just update rpm and yum to minimize the chances of failure or mismatches 
  pulled from out-of-sync repos before starting a larger update.  I 
don't think there have been many problems recently, but it will still be 
tricky to make the yum/python switch foolproof - especially if you don't 
permit multiple versions of python to exist at once.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From bmaly at redhat.com  Fri Dec  5 22:15:40 2008
From: bmaly at redhat.com (Brian Maly)
Date: Fri, 05 Dec 2008 17:15:40 -0500
Subject: cpufreq module on x86_64
In-Reply-To: <1228512934.4755.4442.camel@localhost.localdomain>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>	<ghc3vh$bjc$1@ger.gmane.org>
	<1228512934.4755.4442.camel@localhost.localdomain>
Message-ID: <4939A80C.30006@redhat.com>

Callum Lerwick wrote:
> I noticed that at some point my Athlon 64 3000+ (2ghz) desktop system
> lost its ability to change frequency. I think it happened in a F9
> update, but its definately gone in F10. It was capable of switching
> between 2ghz and 1ghz. Is mine one of the old Athlon 64's that take too
> much time to switch or something? I never had too much problem, if I was
> doing something really demanding I'd just manually lock it at 2ghz...
>   

Did your powernow-k8 driver load properly? Does 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver exist?  What are the 
contents of this file?


Brian



From cry_regarder at yahoo.com  Fri Dec  5 22:21:06 2008
From: cry_regarder at yahoo.com (Cry)
Date: Fri, 5 Dec 2008 22:21:06 +0000 (UTC)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
References: <loom.20081203T184910-257@post.gmane.org>
	<loom.20081205T173743-221@post.gmane.org>
	<1af208abd531c0a834256de6629f3715.squirrel@mail.jcomserv.net>
Message-ID: <loom.20081205T221527-606@post.gmane.org>

Jon Ciesla <limb <at> jcomserv.net> writes:

>> Cry <cry_regarder <at> yahoo.com> writes:
>> Oh, Jon, what version of gallery2 did you build packages for?  Do you feel
>> comfortable that they would be ready to test?
> 
> 2.3. Probably.  SRPM here:
> http://zanoni.jcomserv.net/fedora/gallery2-2.3-1.fc10.src.rpm

I rebuilt for fedora9 and they seam to be working fine on my tests so far.  The
only glitch I had was that the jpegtran plugin test doesn't accept fedora 9's
jpegtran binary as acceptable:

 
Jpegtran binary test results
Binary Name 	Pass/Fail
rotate 	
Passed
crop 	
Failed
Error messages:

Incorrect exit status for jpegtran command.

It seems that the -crop command isn't supported by our jpegtran?

Cry





From mike.cloaked at gmail.com  Fri Dec  5 22:30:46 2008
From: mike.cloaked at gmail.com (Mike)
Date: Fri, 5 Dec 2008 22:30:46 +0000 (UTC)
Subject: Java JRE updates?
References: <loom.20081205T215733-724@post.gmane.org>
	<4939A548.5060002@cchtml.com>
Message-ID: <loom.20081205T222940-28@post.gmane.org>

Michael Cronenworth <mike <at> cchtml.com> writes:

> Since Fedora does not ship Sun Java JRE, why would there be updates?

OK - I could get access to koji earlier - but now it is back I can see builds
that seem to fix some of the vulnerabilities - eg the build at
http://koji.fedoraproject.org/koji/buildinfo?buildID=72811
So it does look like there are new builds on the way.... 






From dex.mbox at googlemail.com  Fri Dec  5 22:43:24 2008
From: dex.mbox at googlemail.com (dexter)
Date: Fri, 5 Dec 2008 22:43:24 +0000
Subject: Whodunnit? F10 install without permission
In-Reply-To: <1228504740.3275.48.camel@localhost.localdomain>
References: <1228502782.3673.29.camel@localhost.localdomain>
	<1228504740.3275.48.camel@localhost.localdomain>
Message-ID: <a993ebee0812051443p7a91c331m19b0da08e125af69@mail.gmail.com>

2008/12/5 Jesse Keating <jkeating at redhat.com>:
> On Fri, 2008-12-05 at 13:46 -0500, Robert Locke wrote:
>> So, whodunnit?  :-)
>
> PackageKit did it... helpfully...?  It won't in the future.
>
Can we have that in writing or a least a dialogbox ...

...dex



From sundaram at fedoraproject.org  Fri Dec  5 23:03:19 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 06 Dec 2008 04:33:19 +0530
Subject: Whodunnit? F10 install without permission
In-Reply-To: <a993ebee0812051443p7a91c331m19b0da08e125af69@mail.gmail.com>
References: <1228502782.3673.29.camel@localhost.localdomain>	<1228504740.3275.48.camel@localhost.localdomain>
	<a993ebee0812051443p7a91c331m19b0da08e125af69@mail.gmail.com>
Message-ID: <4939B337.50500@fedoraproject.org>

dexter wrote:
> 2008/12/5 Jesse Keating <jkeating at redhat.com>:
>> On Fri, 2008-12-05 at 13:46 -0500, Robert Locke wrote:
>>> So, whodunnit?  :-)
>> PackageKit did it... helpfully...?  It won't in the future.
>>
> Can we have that in writing or a least a dialogbox ...

What would you want the dialog box to say?

Rahul



From jspaleta at gmail.com  Fri Dec  5 23:07:51 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 5 Dec 2008 14:07:51 -0900
Subject: The looming Python 3(000) monster
In-Reply-To: <4939A673.3090907@gmail.com>
References: <49393DE3.1080707@redhat.com> <49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
Message-ID: <604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>

On Fri, Dec 5, 2008 at 1:08 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> I thought that was a separate problem (in a flurry in the FC2/FC3 era) but
> similar in dealing with RPM swapping incompatible db libs underneath itself.
Hey your the one who brought it up. rpm transactions which abort in
the middle...are a general problem. There is nothing yum or python
specific about it. If an rpm transaction which updates python and all
that depends on that new python stops in the middle before completing
you have a problem. Just as you would have the same problem if the
transaction failed while updating any dependancy chain..including
rpms.

The answer right now is... don't let the rpm transaction stop in the middle.


>  I recall for a while I defensively did a separate run of yum to just update
> rpm and yum to minimize the chances of failure or mismatches  pulled from
> out-of-sync repos before starting a larger update.  I don't think there have
> been many problems recently, but it will still be tricky to make the
> yum/python switch foolproof - especially if you don't permit multiple
> versions of python to exist at once.

If you can't solve the general problem of fool proofing rpm
transactions..if rpm transactions can fail or be terminated in the
middle..without a way to come back and finish where they left
off...then no there is no way to foolproof an update..even an update
to rpm itself if an important library necessary for rpm operation was
in the transaction.

Do not let rpm transactions fail in the middle. Do not forcibly
terminate them...do not cut power to the system...hold your breath and
walk away from the console.

-jef



From rjones at redhat.com  Fri Dec  5 23:12:25 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 5 Dec 2008 23:12:25 +0000
Subject: MinGW subpackages of OCaml packages
Message-ID: <20081205231225.GA28600@thinkpad>

So as I mentioned before we have an OCaml Windows cross-compiler as
part of the Fedora MinGW project:

http://hg.et.redhat.com/misc/fedora-mingw--devel/
  (click 'manifest' then 'ocaml' or the 'ocaml-*' subdirectories)
  mingw32-ocaml               - the cross-compiler (native Fedora prog)
  mingw32-ocaml-calendar      - cross-compiled OCaml Calendar library
  mingw32-ocaml-csv           - cross-compiled OCaml CSV library
  mingw32-ocaml-curses        - cross-compiled OCaml curses bindings
  mingw32-ocaml-extlib        - cross-compiled OCaml extlib (library)
  mingw32-ocaml-findlib       - (this just has a single config file)
  mingw32-ocaml-lablgl        - cross-compiled OCaml OpenGL bindings
  mingw32-ocaml-lablgtk       - cross-compiled OCaml Gtk bindings
  mingw32-ocaml-libvirt       - cross-compiled OCaml libvirt bindings
  mingw32-ocaml-xml-light     - cross-compiled OCaml XML library

When we were doing the original packaging, we explored the option of
building the MinGW packages as subpackages of the native Fedora
packages, eg: the gnutls specfile would contain the '-n mingw32-gnutls'
subpackage.  This would have made it simpler to keep the packages in
synch with native Fedora, but we felt that native packagers wouldn't
be so happy about this.  They wouldn't be expert in MinGW packaging,
and would drop the MinGW subpackage at the first sign of trouble.

However, since I'm in the unique position of maintaining most of the
corresponding ocaml-* (native) and mingw32-ocaml-* (cross-compiled)
packages, I would like to ask whether I can create the packages above
and others in future as subpackages of the already approved ocaml-*
native packages.

I'm not looking for any exception to the relevant packaging
guidelines, which I would try to follow (excepting any mistakes).

If you want to see what some RPMs look like, see:
  http://www.annexia.org/tmp/mingw/fedora-10/x86_64/RPMS/

Thoughts?  I set follow-ups to the fedora-packaging list.

Rich.



From seg at haxxed.com  Fri Dec  5 23:27:01 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 05 Dec 2008 17:27:01 -0600
Subject: More PATH fallout. Who decided this was a good idea?
Message-ID: <1228519621.22587.19.camel@localhost.localdomain>

So, I spent 10 minutes trying to figure out why "userm[tab]" only came
up with usermount. usermod had disappeared from my system! I eventually
figured out that it and all the other account tools have been changed to
mode 750, inaccessible to normal users.

$ ls -l /sbin/ /usr/sbin/|grep \\---
-rwxr-x--- 1 root root  97000 2008-11-05 14:58 audispd
-rwxr-x--- 1 root root 121056 2008-11-05 14:58 auditctl
-rwxr-x--- 1 root root 175416 2008-11-05 14:58 auditd
-rwxr-x--- 1 root root  98496 2008-11-05 14:58 autrace
-rwxr-x--- 1 root root 145472 2008-09-11 23:23 dhcp6c
-rwx------ 1 root root  29664 2008-09-23 09:12 unix_update
-rwxr-x--- 1 root root     23192 2008-11-11 07:59 acpid
-rwx------ 1 root root    648560 2008-11-13 17:23 build-locale-archive
-rwx------ 1 root root    564524 2008-11-13 17:41 glibc_post_upgrade.i686
-rwx------ 1 root root    615608 2008-11-13 17:23 glibc_post_upgrade.x86_64
-rwxr-x--- 1 root root     47704 2008-09-24 08:38 groupadd
-rwxr-x--- 1 root root     38832 2008-09-24 08:38 groupdel
-rwxr-x--- 1 root root     33888 2008-09-24 08:38 groupmems
-rwxr-x--- 1 root root     47608 2008-09-24 08:38 groupmod
-rwsr-x--- 1 root gnokii   10384 2008-10-06 02:50 mgnokiidev
-rwx------ 1 root root    615768 2008-08-28 01:11 redhat_lsb_trigger.x86_64
-rwx------ 1 root root      5512 2008-11-13 17:23 tzdata-update
-rwxr-x--- 1 root root     83864 2008-09-24 08:38 useradd
-rwxr-x--- 1 root root     56528 2008-09-24 08:38 userdel
-rwxr-x--- 1 root root     82296 2008-09-24 08:38 usermod

$ /usr/sbin/usermod
bash: /usr/sbin/usermod: Permission denied

$ sudo /usr/sbin/usermod
Usage: usermod [options] LOGIN

Options:
  -c, --comment COMMENT         new value of the GECOS field
  -d, --home HOME_DIR           new home directory for the user account
  -e, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -f, --inactive INACTIVE       set password inactive after expiration
                                to INACTIVE
  -g, --gid GROUP               force use GROUP as new primary group
  -G, --groups GROUPS           new list of supplementary GROUPS
  -a, --append                  append the user to the supplemental GROUPS
                                mentioned by the -G option without removing
                                him/her from other groups
  -h, --help                    display this help message and exit
  -l, --login NEW_LOGIN         new value of the login name
  -L, --lock                    lock the user account
  -m, --move-home               move contents of the home directory to the
                                new location (use only with -d)
  -o, --non-unique              allow using duplicate (non-unique) UID
  -p, --password PASSWORD       use encrypted password for the new password
  -s, --shell SHELL             new login shell for the user account
  -u, --uid UID                 new UID for the user account
  -U, --unlock                  unlock the user account
  -Z, --selinux-user            new selinux user mapping for the use


As a sudo user, I believe that running admin tools such as usermod as an
unprivileged user to get the help page is a perfectly valid use case,
and this change is a bad idea that should be reversed.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/cd073e49/attachment.sig>

From seg at haxxed.com  Fri Dec  5 23:41:53 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 05 Dec 2008 17:41:53 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <493990E5.3060408@gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
Message-ID: <1228520513.22587.26.camel@localhost.localdomain>

On Fri, 2008-12-05 at 14:36 -0600, Les Mikesell wrote:
> 
> Is there a plan for how yum is going to upgrade itself?

Good question, actually. And the answer is this is exactly the reason we
don't officially support "yum upgrades" across major releases.

The upgrade is done in an anaconda environment, completely shielded from
what's happening to the system being upgraded.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/1f29313b/attachment.sig>

From seg at haxxed.com  Sat Dec  6 00:18:34 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 05 Dec 2008 18:18:34 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <200811252242.mAPMghOd009940@laptop14.inf.utfsm.cl>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
	<1227152010.3752.767.camel@beck.corsepiu.local>
	<1227561575.4755.206.camel@localhost.localdomain>
	<200811252242.mAPMghOd009940@laptop14.inf.utfsm.cl>
Message-ID: <1228522715.22587.56.camel@localhost.localdomain>

On Tue, 2008-11-25 at 19:42 -0300, Horst H. von Brand wrote:
> Callum Lerwick <seg at haxxed.com> wrote:
> > On Thu, 2008-11-20 at 04:33 +0100, Ralf Corsepius wrote:
> > > > Let me point out that rollback itself would require testing.
> 
> > Quite do-able. See my reply to Jeff.
> 
> > > Let me point out that package rollbacks will never work in general,
> > > because updates may contain non-reversable state-full operations (e.g.
> > > reformatting databases).
> 
> > So, only do such updates in distribution upgrades.
> 
> How do you find out if something in a %pre or %post, or even in the package
> installation itself, is impossible to undo? Sure, you can require it
> doesn't happen, but mistakes are a fact of life...

Which is why I proposed automated regression tests, which would catch
this.

I'm not sure what you're arguing here. You can always rpm -e a package,
last I checked that was always a valid use case. Thus reversal of what a
package install does is already expected to happen. Nothing here has
changed.

This is what is driving me nuts. If rpm -e of a package is always valid,
that means you can always rpm -e any package then install an older
version. Thus rollback is fundamentally possible. Seriously, what about
this is so hard to comprehend?

> > Something I'm regretting to note earlier, is that I do not expect the
> > per-package rollback mechanism to work across distribution releases.
> > It's intended for updates inside releases only.
> 
> Great. Get users hooked on "if it breaks, just roll back" and then leave
> them out in the cold when they will most likely have a need for it.

Yeah, because "My system broke, fuck this shit I'm going back to Vista"
is so much better.

I'm talking about making something people  *already* do by hand,
automated and painless. If something really essential breaks, like your
X drivers or kernel, do you really just sit there with a useless broken
system and wait for it to get fixed? Or do you boot the old kernel, boot
in run level 3, rpm -e the new X drivers and reinstall the old ones?
(Then file a bug report...)

How are you even going to file a bug report with a broken system? Not
everyone has ten computers in their house.

I don't know about you, but I have shit to do, I can't afford to sit and
wait for someone else to fix it.

> > IMHO I think discrete releases are one of our most powerful features. We
> > can make drastic changes across the distribution, in an atomic manner.
> 
> It has /never/ been "atomic".

Are you just being contrary for the fun of it? How is an officially
sanctioned anaconda distribution upgrade not an atomic operation, from
the perspective of an RPM transaction?

> > We want to preserve this feature. It allows us to make a clean break
> > with previous releases. It allows us to make irreversible changes.
> 
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/939c06e0/attachment.sig>

From markg85 at gmail.com  Sat Dec  6 00:25:39 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 6 Dec 2008 01:25:39 +0100
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <1228445747.19595.4.camel@localhost.localdomain>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
	<6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
	<4938928D.5020603@cchtml.com>
	<1228445747.19595.4.camel@localhost.localdomain>
Message-ID: <6e24a8e80812051625s7e3f479am87448e6fea85fbca@mail.gmail.com>

On Fri, Dec 5, 2008 at 3:55 AM, Matthias Clasen <mclasen at redhat.com> wrote:
> On Thu, 2008-12-04 at 20:31 -0600, Michael Cronenworth wrote:
>> Mark wrote:
>> >
>> > Is there really no interest for this long standing bug?
>> >
>> >
>> I'd help you, but I hate system sounds. It shouldn't be that hard to
>> follow the source or setup some debugging? Start with where the sound is
>> emitted and go backwards.
>
>
> There is no need for debugging, the problem is well understood.
> We install /usr/share/gnome/shutdown/libcanberra-logout-sound.sh, but
> there is nothing in gnome-session that does anything  with that script.
> It should be easy enough to come up with a basic implementation of
> logout actions, if someone is really interested in fixing this bug.

Am i right that the patch would have to be something like this:
http://bugzilla.gnome.org/show_bug.cgi?id=546989 (for nautilus but
just for the idea)

Also if it's that then what's the use of that file:
"/usr/share/gnome/shutdown/libcanberra-logout-sound.sh" because
canberra is going to play the "desktop-logout" sound (defined here:
http://0pointer.de/public/sound-naming-spec.html)... or is that done
as a separate file so it will finish it and not break the sound after
a few microseconds?

If you tell me how i can execute a file inside c code (in a way that
gnome accepts it) then i will do my best to make a patch.

And just to be sure.. if i make a patch with logout sound support i
need to edit the gsm_logout_supports_* function in the
gsm_logout_dialog.c file right and assign there appropriate sound name
in each function (logout gets a logout sound, shutdown gets a shutdown
sound etc...)

Thanx,
Mark



From stlwrt at gmail.com  Sat Dec  6 00:30:52 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Sat, 6 Dec 2008 02:30:52 +0200
Subject: cpufreq module on x86_64
In-Reply-To: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
Message-ID: <d25f375f0812051630y35e8628dx1b6d155287bbff52@mail.gmail.com>

On Fri, Dec 5, 2008 at 7:47 PM, Jerry James <loganjerry at gmail.com> wrote:
> First I wondered why I was getting a cpufreq module loaded on a
> desktop machine.  I guess I want to do something if the CPU
> temperature gets too high

By lowering frequency you allow coolers to rotate at lower speed and
produce less noise. I couldn't run my Core 2 Quad without scaling -
it's loud as airbus taking off when running at full speed =)

-- 
http://scwlab.com



From jkeating at redhat.com  Sat Dec  6 00:40:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 05 Dec 2008 16:40:01 -0800
Subject: My roadmap for a better Fedora
In-Reply-To: <1228522715.22587.56.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
	<1227152010.3752.767.camel@beck.corsepiu.local>
	<1227561575.4755.206.camel@localhost.localdomain>
	<200811252242.mAPMghOd009940@laptop14.inf.utfsm.cl>
	<1228522715.22587.56.camel@localhost.localdomain>
Message-ID: <1228524001.3511.0.camel@localhost.localdomain>

On Fri, 2008-12-05 at 18:18 -0600, Callum Lerwick wrote:
> 
> This is what is driving me nuts. If rpm -e of a package is always valid,
> that means you can always rpm -e any package then install an older
> version. Thus rollback is fundamentally possible. Seriously, what about
> this is so hard to comprehend?

rpm -e of a package followed by an rpm -ivh of an older version of the
package is by no means any safer for your data than a rollback.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/8567c828/attachment.sig>

From jonstanley at gmail.com  Sat Dec  6 00:44:46 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 5 Dec 2008 19:44:46 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228519621.22587.19.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
Message-ID: <da159fda0812051644l7c12b2d4m3b4cc5378204d789@mail.gmail.com>

2008/12/5 Callum Lerwick <seg at haxxed.com>:

> As a sudo user, I believe that running admin tools such as usermod as an
> unprivileged user to get the help page is a perfectly valid use case,
> and this change is a bad idea that should be reversed.

These permissions have been in place for over 2 years, with valid
reasoning. Just because it's in your PATH doesn't mean you should be
able to execute it.

revision 1.84
date: 2006/10/04 21:03:00;  author: pvrabec;  state: Exp;  lines: +11 -3
- fix regression. Permissions on user* group* binaries
  should be 0750, because of CAPP/LSPP certification
- fix groupdel man page



From dbn.lists at gmail.com  Sat Dec  6 00:52:33 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 5 Dec 2008 16:52:33 -0800
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <6e24a8e80812051625s7e3f479am87448e6fea85fbca@mail.gmail.com>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
	<6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
	<4938928D.5020603@cchtml.com>
	<1228445747.19595.4.camel@localhost.localdomain>
	<6e24a8e80812051625s7e3f479am87448e6fea85fbca@mail.gmail.com>
Message-ID: <91705d080812051652n11e72dem18683e7a768e3eae@mail.gmail.com>

On Fri, Dec 5, 2008 at 4:25 PM, Mark <markg85 at gmail.com> wrote:
> On Fri, Dec 5, 2008 at 3:55 AM, Matthias Clasen <mclasen at redhat.com> wrote:
>> On Thu, 2008-12-04 at 20:31 -0600, Michael Cronenworth wrote:
>>> Mark wrote:
>>> >
>>> > Is there really no interest for this long standing bug?
>>> >
>>> >
>>> I'd help you, but I hate system sounds. It shouldn't be that hard to
>>> follow the source or setup some debugging? Start with where the sound is
>>> emitted and go backwards.
>>
>>
>> There is no need for debugging, the problem is well understood.
>> We install /usr/share/gnome/shutdown/libcanberra-logout-sound.sh, but
>> there is nothing in gnome-session that does anything  with that script.
>> It should be easy enough to come up with a basic implementation of
>> logout actions, if someone is really interested in fixing this bug.
>
> Am i right that the patch would have to be something like this:
> http://bugzilla.gnome.org/show_bug.cgi?id=546989 (for nautilus but
> just for the idea)
>
> Also if it's that then what's the use of that file:
> "/usr/share/gnome/shutdown/libcanberra-logout-sound.sh" because
> canberra is going to play the "desktop-logout" sound (defined here:
> http://0pointer.de/public/sound-naming-spec.html)... or is that done
> as a separate file so it will finish it and not break the sound after
> a few microseconds?
>
> If you tell me how i can execute a file inside c code (in a way that
> gnome accepts it) then i will do my best to make a patch.
>
> And just to be sure.. if i make a patch with logout sound support i
> need to edit the gsm_logout_supports_* function in the
> gsm_logout_dialog.c file right and assign there appropriate sound name
> in each function (logout gets a logout sound, shutdown gets a shutdown
> sound etc...)

I think the problem is that gnome-session doesn't know about logout
actions. So, the sound might get queued up at exit by
gnome-settings-daemon or something, but gnome-session doesn't know to
wait for it and just shuts down as fast as it can.

--
Dan



From jspaleta at gmail.com  Sat Dec  6 01:00:57 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 5 Dec 2008 16:00:57 -0900
Subject: My roadmap for a better Fedora
In-Reply-To: <1228522715.22587.56.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
	<1227152010.3752.767.camel@beck.corsepiu.local>
	<1227561575.4755.206.camel@localhost.localdomain>
	<200811252242.mAPMghOd009940@laptop14.inf.utfsm.cl>
	<1228522715.22587.56.camel@localhost.localdomain>
Message-ID: <604aa7910812051700k5abb6c3v955306bf9c4f47fb@mail.gmail.com>

2008/12/5 Callum Lerwick <seg at haxxed.com>:
> Which is why I proposed automated regression tests, which would catch
> this.

I think you have all the necessary tools in hand to start exploring
this sort of regression concept.  If you want to regression test go
right ahead by using rpm with the appropriate cmdline options to
"downgrade" to a previous version. Do filesystem diffs after
individual transations and mine the data.  And keep track of how long
these sort of tests take on average.  Just make sure you regression
test all possible pre/post  and trigger scenarios for every package
that has pre/post and trigger scripts.  Triggers are a pain in the
ass.. or so I'm told.


> This is what is driving me nuts. If rpm -e of a package is always valid,

I don't think you can actually assume that.  Though it would be
something you could start regression testing and show us if it is.
Start F8 gold, snapshot the filesystem, update a package to the latest
update, snapshot the filesystem, remove the package, snapshot the
filesystem, install the gold version, snapshot the filesystem. Do some
filesystem diffing and see if you end up where you started...for every
self-consistent set of updates.

-jef



From mclasen at redhat.com  Sat Dec  6 01:06:17 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 05 Dec 2008 20:06:17 -0500
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <91705d080812051652n11e72dem18683e7a768e3eae@mail.gmail.com>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
	<6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
	<4938928D.5020603@cchtml.com>
	<1228445747.19595.4.camel@localhost.localdomain>
	<6e24a8e80812051625s7e3f479am87448e6fea85fbca@mail.gmail.com>
	<91705d080812051652n11e72dem18683e7a768e3eae@mail.gmail.com>
Message-ID: <1228525577.7956.3.camel@localhost.localdomain>

On Fri, 2008-12-05 at 16:52 -0800, Dan Nicholson wrote:

> > If you tell me how i can execute a file inside c code (in a way that
> > gnome accepts it) then i will do my best to make a patch.
> >
> > And just to be sure.. if i make a patch with logout sound support i
> > need to edit the gsm_logout_supports_* function in the
> > gsm_logout_dialog.c file right and assign there appropriate sound name
> > in each function (logout gets a logout sound, shutdown gets a shutdown
> > sound etc...)
> 
> I think the problem is that gnome-session doesn't know about logout
> actions. So, the sound might get queued up at exit by
> gnome-settings-daemon or something, but gnome-session doesn't know to
> wait for it and just shuts down as fast as it can.

The problem is that gnome-session does not know about logout actions,
therefore no sound is queued at all. The idea is that gnome-session
would execute all the shell scripts in /usr/share/gnome/shutdown/. Of
course, there is some details to work out, like when in the shutdown
sequence to do this (or can scripts register to run in a  certain phase
of the shutodwn ?), and how to wait for the logout sound to be completed
without letting a misbehaving script block logout, etc. This should best
happen in upstream bugzilla.



From markg85 at gmail.com  Sat Dec  6 01:12:58 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 6 Dec 2008 02:12:58 +0100
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <1228525577.7956.3.camel@localhost.localdomain>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
	<6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
	<4938928D.5020603@cchtml.com>
	<1228445747.19595.4.camel@localhost.localdomain>
	<6e24a8e80812051625s7e3f479am87448e6fea85fbca@mail.gmail.com>
	<91705d080812051652n11e72dem18683e7a768e3eae@mail.gmail.com>
	<1228525577.7956.3.camel@localhost.localdomain>
Message-ID: <6e24a8e80812051712g31826adele0305778b53500b7@mail.gmail.com>

On Sat, Dec 6, 2008 at 2:06 AM, Matthias Clasen <mclasen at redhat.com> wrote:
> On Fri, 2008-12-05 at 16:52 -0800, Dan Nicholson wrote:
>
>> > If you tell me how i can execute a file inside c code (in a way that
>> > gnome accepts it) then i will do my best to make a patch.
>> >
>> > And just to be sure.. if i make a patch with logout sound support i
>> > need to edit the gsm_logout_supports_* function in the
>> > gsm_logout_dialog.c file right and assign there appropriate sound name
>> > in each function (logout gets a logout sound, shutdown gets a shutdown
>> > sound etc...)
>>
>> I think the problem is that gnome-session doesn't know about logout
>> actions. So, the sound might get queued up at exit by
>> gnome-settings-daemon or something, but gnome-session doesn't know to
>> wait for it and just shuts down as fast as it can.
>
> The problem is that gnome-session does not know about logout actions,
> therefore no sound is queued at all. The idea is that gnome-session
> would execute all the shell scripts in /usr/share/gnome/shutdown/. Of
> course, there is some details to work out, like when in the shutdown
> sequence to do this (or can scripts register to run in a  certain phase
> of the shutodwn ?), and how to wait for the logout sound to be completed
> without letting a misbehaving script block logout, etc. This should best
> happen in upstream bugzilla.

Well for the sounds and logout i wouldn't mind it if gnome is not
waiting for the sound and just logs out. then a part of the sound
might still be playing when your already back at the login screen
which doesn't seem to bad to me..

But for the "logout actions" ... where in all of gnome are those
defined anyway? and what are those gsm_logout_supports_* functions in
gsm-logout-dialog.c?? i thought those for logout handling ^_^



From mclasen at redhat.com  Sat Dec  6 01:28:07 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 05 Dec 2008 20:28:07 -0500
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <6e24a8e80812051712g31826adele0305778b53500b7@mail.gmail.com>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
	<6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
	<4938928D.5020603@cchtml.com>
	<1228445747.19595.4.camel@localhost.localdomain>
	<6e24a8e80812051625s7e3f479am87448e6fea85fbca@mail.gmail.com>
	<91705d080812051652n11e72dem18683e7a768e3eae@mail.gmail.com>
	<1228525577.7956.3.camel@localhost.localdomain>
	<6e24a8e80812051712g31826adele0305778b53500b7@mail.gmail.com>
Message-ID: <1228526887.7956.8.camel@localhost.localdomain>

On Sat, 2008-12-06 at 02:12 +0100, Mark wrote:
 
> 
> Well for the sounds and logout i wouldn't mind it if gnome is not
> waiting for the sound and just logs out. then a part of the sound
> might still be playing when your already back at the login screen
> which doesn't seem to bad to me..

But that is not what is happening. When the session ends, PA stops the
sound.

> But for the "logout actions" ... where in all of gnome are those
> defined anyway? and what are those gsm_logout_supports_* functions in
> gsm-logout-dialog.c?? i thought those for logout handling ^_^

There is no place where logout actions are defined. They were an idea
that came up to handle logout sound, more or less. Maybe this is all
over the top, and gnome-session should just play the login/logout
sounds. Dunno.



From sgrubb at redhat.com  Sat Dec  6 01:29:45 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Fri, 5 Dec 2008 20:29:45 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228519621.22587.19.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
Message-ID: <200812052029.45500.sgrubb@redhat.com>

On Friday 05 December 2008 18:27:01 Callum Lerwick wrote:
> So, I spent 10 minutes trying to figure out why "userm[tab]" only came
> up with usermount. usermod had disappeared from my system!

These should have been gone for quite a while...and on purpose. You cannot do 
anything with them unless you are root. Allowing anyone even to execute them 
would require lots of bad things for our LSPP/CAPP evaluations.


> -rwxr-x--- 1 root root  97000 2008-11-05 14:58 audispd
> -rwxr-x--- 1 root root 121056 2008-11-05 14:58 auditctl
> -rwxr-x--- 1 root root 175416 2008-11-05 14:58 auditd
> -rwxr-x--- 1 root root  98496 2008-11-05 14:58 autrace

The audit tools are protected from casual use for a reason.


> -rwxr-x--- 1 root root     47704 2008-09-24 08:38 groupadd
> -rwxr-x--- 1 root root     38832 2008-09-24 08:38 groupdel
> -rwxr-x--- 1 root root     33888 2008-09-24 08:38 groupmems
> -rwxr-x--- 1 root root     47608 2008-09-24 08:38 groupmod
> -rwxr-x--- 1 root root     83864 2008-09-24 08:38 useradd
> -rwxr-x--- 1 root root     56528 2008-09-24 08:38 userdel
> -rwxr-x--- 1 root root     82296 2008-09-24 08:38 usermod

These are required to be this way for our Common Criteria evaluations.


> As a sudo user, I believe that running admin tools such as usermod as an
> unprivileged user to get the help page is a perfectly valid use case,

You have a man page that should be accurate. If not file a bug.


> and this change is a bad idea that should be reversed.

Nope.

-Steve



From markg85 at gmail.com  Sat Dec  6 01:40:16 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 6 Dec 2008 02:40:16 +0100
Subject: Logout sound ever gonna be fixed?
In-Reply-To: <1228526887.7956.8.camel@localhost.localdomain>
References: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>
	<6e24a8e80812041648ydc89eder12d08d0273480c9b@mail.gmail.com>
	<4938928D.5020603@cchtml.com>
	<1228445747.19595.4.camel@localhost.localdomain>
	<6e24a8e80812051625s7e3f479am87448e6fea85fbca@mail.gmail.com>
	<91705d080812051652n11e72dem18683e7a768e3eae@mail.gmail.com>
	<1228525577.7956.3.camel@localhost.localdomain>
	<6e24a8e80812051712g31826adele0305778b53500b7@mail.gmail.com>
	<1228526887.7956.8.camel@localhost.localdomain>
Message-ID: <6e24a8e80812051740t5c1e7cd3s43820fffeef396f8@mail.gmail.com>

On Sat, Dec 6, 2008 at 2:28 AM, Matthias Clasen <mclasen at redhat.com> wrote:
> On Sat, 2008-12-06 at 02:12 +0100, Mark wrote:
>
>>
>> Well for the sounds and logout i wouldn't mind it if gnome is not
>> waiting for the sound and just logs out. then a part of the sound
>> might still be playing when your already back at the login screen
>> which doesn't seem to bad to me..
>
> But that is not what is happening. When the session ends, PA stops the
> sound.

Then that's a design decision that gets a nasty tail.
Is it possible to leave pulseaudio  out of it and use alsa directly
assuming that is not being stopped when you logout..
or wait let me guess.. canberra can't switch between alsa and pulseaudio...

>
>> But for the "logout actions" ... where in all of gnome are those
>> defined anyway? and what are those gsm_logout_supports_* functions in
>> gsm-logout-dialog.c?? i thought those for logout handling ^_^
>
> There is no place where logout actions are defined. They were an idea
> that came up to handle logout sound, more or less. Maybe this is all
> over the top, and gnome-session should just play the login/logout
> sounds. Dunno.

There are probably 2 ways to go here:
easy : add those sounds directly in gnome-session
hard : make those logout actions and let them (where ever that might
be) play them.. having those events could end up handy for other
applications..? don't know a case really.



From pertusus at free.fr  Fri Dec  5 20:16:55 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 5 Dec 2008 21:16:55 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <70F2CCFE-F3BE-4987-9A62-17B90094BE26@nall.com>
References: <20081205195914.GB3227@free.fr>
	<70F2CCFE-F3BE-4987-9A62-17B90094BE26@nall.com>
Message-ID: <20081205201655.GD3227@free.fr>

On Fri, Dec 05, 2008 at 02:07:40PM -0600, Joe Nall wrote:
>
> Does fcron have the selinux context support that was added to cronie?

It had it before cronie.

--
Pat



From dex.mbox at googlemail.com  Sat Dec  6 02:49:13 2008
From: dex.mbox at googlemail.com (dexter)
Date: Sat, 6 Dec 2008 02:49:13 +0000
Subject: Whodunnit? F10 install without permission
In-Reply-To: <4939B337.50500@fedoraproject.org>
References: <1228502782.3673.29.camel@localhost.localdomain>
	<1228504740.3275.48.camel@localhost.localdomain>
	<a993ebee0812051443p7a91c331m19b0da08e125af69@mail.gmail.com>
	<4939B337.50500@fedoraproject.org>
Message-ID: <a993ebee0812051849x3e1d3bf5kb82878cb1efdddd@mail.gmail.com>

2008/12/5 Rahul Sundaram <sundaram at fedoraproject.org>:
> dexter wrote:
>>
>> 2008/12/5 Jesse Keating <jkeating at redhat.com>:
>>>
>>> On Fri, 2008-12-05 at 13:46 -0500, Robert Locke wrote:
>>>>
>>>> So, whodunnit?  :-)
>>>
>>> PackageKit did it... helpfully...?  It won't in the future.
>>>
>> Can we have that in writing or a least a dialogbox ...
>
> What would you want the dialog box to say?

As I don't use this Kit I'll never see it, but along the lines of 'is
it ok to install x.y.z to enable auto-updates [y|n]'
followed by a 'always do this | dont ask again'. The important keyword
here is opt-in!


...dex



From jkeating at redhat.com  Sat Dec  6 05:53:46 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 05 Dec 2008 21:53:46 -0800
Subject: Whodunnit? F10 install without permission
In-Reply-To: <a993ebee0812051849x3e1d3bf5kb82878cb1efdddd@mail.gmail.com>
References: <1228502782.3673.29.camel@localhost.localdomain>
	<1228504740.3275.48.camel@localhost.localdomain>
	<a993ebee0812051443p7a91c331m19b0da08e125af69@mail.gmail.com>
	<4939B337.50500@fedoraproject.org>
	<a993ebee0812051849x3e1d3bf5kb82878cb1efdddd@mail.gmail.com>
Message-ID: <1228542826.4814.32.camel@localhost.localdomain>

On Sat, 2008-12-06 at 02:49 +0000, dexter wrote:
> As I don't use this Kit I'll never see it, but along the lines of 'is
> it ok to install x.y.z to enable auto-updates [y|n]'
> followed by a 'always do this | dont ask again'. The important keyword
> here is opt-in!

Well that wasn't what the package was installed for.  It was installed
so that PackageKit could have the appropriate information to check if
there were distro level upgrades (say 9 to 10) available for you.  The
upstream has been asked to please not install any software in Fedora
without a users consent, so hopefully this scenario won't happen again,
at least not with PackageKit.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/8d5ed7c7/attachment.sig>

From jkeating at redhat.com  Sat Dec  6 05:55:24 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 05 Dec 2008 21:55:24 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812052029.45500.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
Message-ID: <1228542924.4814.33.camel@localhost.localdomain>

On Fri, 2008-12-05 at 20:29 -0500, Steve Grubb wrote:
> These are required to be this way for our Common Criteria evaluations.

Is the thought here that if the code can be executed by a non-root user,
the audit of the code would have to be far more strict?  If you keep the
user from being able to execute, you don't have to worry as much about
how they might exploit it?

I'm just curious what added security you really get.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081205/34dfbb11/attachment.sig>

From skvidal at fedoraproject.org  Sat Dec  6 06:06:41 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sat, 6 Dec 2008 01:06:41 -0500 (EST)
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228542924.4814.33.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
	<1228542924.4814.33.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>



On Fri, 5 Dec 2008, Jesse Keating wrote:

> On Fri, 2008-12-05 at 20:29 -0500, Steve Grubb wrote:
>> These are required to be this way for our Common Criteria evaluations.
>
> Is the thought here that if the code can be executed by a non-root user,
> the audit of the code would have to be far more strict?  If you keep the
> user from being able to execute, you don't have to worry as much about
> how they might exploit it?

And do we seriously think we can keep the code away from a non-root user 
by chmodd'ing the binaries? A user can get a binary for anything 
fedora can install in about 30s w/firefox.

-sv





From cmadams at hiwaay.net  Sat Dec  6 06:26:32 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 6 Dec 2008 00:26:32 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
	<1228542924.4814.33.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>
Message-ID: <20081206062632.GC1450194@hiwaay.net>

Once upon a time, Seth Vidal <skvidal at fedoraproject.org> said:
> And do we seriously think we can keep the code away from a non-root user 
> by chmodd'ing the binaries? A user can get a binary for anything 
> fedora can install in about 30s w/firefox.

The same really applies to RHEL, except it might take a few minutes.
There's not much reason for any file that isn't intended to be modified
(e.g. included in an RPM and not marked %config) to be "protected".

I opened a bug (441495) about BIND permissions (in RHEL 5 specifically
but Fedora as well) a while back, because the restricted permissions are
even stupider there; it is possible to allow a non-root user to use rndc
with permissions on the rndc config file, but RHEL/Fedora distribute
rndc owned root:root perms 0750.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From rakesh at fedoraproject.org  Sat Dec  6 09:03:56 2008
From: rakesh at fedoraproject.org (Rakesh Pandit)
Date: Sat, 6 Dec 2008 14:33:56 +0530
Subject: package seeking new owner: jed
In-Reply-To: <20081205210210.GA19180@nostromo.devel.redhat.com>
References: <20081205210210.GA19180@nostromo.devel.redhat.com>
Message-ID: <b401d2530812060103h5e60a461q5dd810d53da0a71@mail.gmail.com>

2008/12/6 Bill Nottingham <notting at redhat.com>:
> I don't really use it any more, so I figure I might as well give
> the opportunity to maintain it to someone who does. Has had one
> actual bug (FTBFS) filed in the past four years.
>
> Bill
>

Looks cool, will take care, in case no one is interested.

-- 
rakesh



From hughsient at gmail.com  Sat Dec  6 09:29:08 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sat, 06 Dec 2008 09:29:08 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
References: <49393DE3.1080707@redhat.com> <49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
Message-ID: <1228555748.4211.2.camel@hughsie-work.lan>

On Fri, 2008-12-05 at 14:07 -0900, Jeff Spaleta wrote:
> Do not let rpm transactions fail in the middle. Do not forcibly
> terminate them...do not cut power to the system...hold your breath and
> walk away from the console.

This was one of the problems PackageKit tries to solve. You can start an
install and do ctrl-alt-backspace and then re-login, and the transaction
is still running in the background. It also stops you shutting down
using a system and session inhibit if the transaction is an a
non-cancellable state.

If you /sbin/shutdown as root, or suffer a power failure without a UPS,
then all bets are off :-)

Richard.




From pertusus at free.fr  Sat Dec  6 11:00:02 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 6 Dec 2008 12:00:02 +0100
Subject: orphaning chm related packages
Message-ID: <20081206110002.GA2932@free.fr>

Hello,

I have orphaned the following chm related packages. 

I orphaned only devel. I'd like to remain co-maintainer. I'd prefer also 
be only co-maintainer for other branches, but obviously only if somebody 
volunteer to be the primary maintainer. So if you want to be maintainer, 
please state for which branches. Some already have co-maintainers.

* kchmviewer
This one is currently built without kde support. kde support builds fine
locally, but not in mock due to
https://bugzilla.redhat.com/show_bug.cgi?id=460828
You can have a look at comments following
https://bugzilla.redhat.com/show_bug.cgi?id=458573#c9
I could try to handle this as co-maintainer, I know what to do once the
build issue is fixed.

The 2 following should be handled together:
* gnochm
* python-chm

The following are less crucial, but also also very low maintainance
* archmage
* libchmxx
* perl-Text-CHM

It may be relevant for people interested to be libchm co-maintainer.

--
Pat



From pertusus at free.fr  Sat Dec  6 12:24:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 6 Dec 2008 13:24:20 +0100
Subject: orphaning many packages
Message-ID: <20081206122420.GC2932@free.fr>

Hello,

Some more misc packages I'd like to orphan.

I orphaned only devel. I'd like to remain co-maintainer. I'd prefer also
be only co-maintainer for other branches, but obviously only if somebody
volunteer to be the primary maintainer. So if you want to be maintainer,
please state for which branches. Some already have co-maintainers, they
should have priority for ownership.

In my opinion gnash and tetex-tex4ht are strategic packages for Fedora
and if nobody steps up a kind of collective maintainance should be
organized.


* gnash
People interested in gnash should also take agg and flasm, in my
opinion. They should also help reviewing ming:
https://bugzilla.redhat.com/show_bug.cgi?id=232790
And also mtasc, I added it to the wishlist and made a srpm here:
http://www.environnement.ens.fr/perso/dumas/fc-srpms/mtasc-1.13-0.1.cvs04062008.fc10.src.rpm
ming and mtasc are used for tests. (and also swftools, but I think
that swftools packaging is still out of reach for now).
* flasm
* agg

The OpenDAP server stack (an interested maintainer should take them
all... and maybe package olfs, the hyrax front-end):
* bes
* dap-server
* dap-freeform_handler
* dap-hdf4_handler
* dap-netcdf_handler

* tetex-tex4ht
It should be renamed tex-tex4ht. There is a system of 2 level sources.
Literal sources are included, but second level sources are really used.
With the debian packager, and with upstream, we collaborated on a debian
script that can be used to rebuild the second level sources from the
literate sources.

* elektra

* wdm
There is the Consolekit issue. I hope that it would be fixed one day?

It is an interesting package in my opinion since it looks good while
being very lightweight. Trouble is that upstream is dead and so is not
resyncing with xdm, so retiring this package may unfortunatly be the
best thing to do.

* debootstrap
I should not be the primary maintainer, but only a co-maintainer,
don't know how I became primary maintainer.


Those perl modules are very low maintainance:
* perl-File-NFSLock
* perl-Cache
* perl-Feed-Find
* perl-Heap
* perl-HTML-FormatText-WithLinks
* perl-LWP-Authen-Wsse

* html2ps
This is an a2ps dependency. There are unresolved bugs that can be seen
in debian, but overall it works fine and is pretty dead upstream so is
very low maintainance.

* pmount
Very low maintainance

* pam_ssh
Very low maintainance


Very low maintainance dead upstream packages
* intuitively
* ooo2txt
* libnet10
Though libnet10 is an older version of a dead package, there are
certainly some codes not in fedora that still use that api, for
example some stuff here:
http://www.stearns.org/doc/pcap-apps.html
It is properly parallel installable with libnet so in my opinion
should stay indefinitely (or as long as it builds).
* libnet
There are a lot of people wanting to have shared libraries for this
one. I always resisted for the reasons stated in
https://fedoraproject.org/wiki/User:Pertusus#On_not_shipping_shared_libraries_when_upstream_doesn.27t
especially in that case I think that at some point somebody will
resurect libnet since, as far as I know there is no replacement.

--
Pat



From sgrubb at redhat.com  Sat Dec  6 12:45:36 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 07:45:36 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228542924.4814.33.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
	<1228542924.4814.33.camel@localhost.localdomain>
Message-ID: <200812060745.37122.sgrubb@redhat.com>

On Saturday 06 December 2008 00:55:24 Jesse Keating wrote:
>  These are required to be this way for our Common Criteria evaluations.
>
> Is the thought here that if the code can be executed by a non-root user,
> the audit of the code would have to be far more strict?

No, it has more to do with the fact that we have to audit all attempts to 
modify trusted databases - in this case, shadow. No one can use these tools 
since they do not have the permissions required to be successful. So, we 
remove the ability to use these tools so that we don't have to audit it. 

IOW, if we open the permissions, we need to make these become setuid root so 
that we send audit events saying they failed.


> I'm just curious what added security you really get.

Its not so much a security thing as much as its a certification thing. An 
ordinary user cannot possibly use these tools since they do not have the 
requisite permissions.

-Steve



From sgrubb at redhat.com  Sat Dec  6 12:48:00 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 07:48:00 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228542924.4814.33.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>
Message-ID: <200812060748.00510.sgrubb@redhat.com>

On Saturday 06 December 2008 01:06:41 Seth Vidal wrote:
> And do we seriously think we can keep the code away from a non-root user
> by chmodd'ing the binaries? A user can get a binary for anything
> fedora can install in about 30s w/firefox.

Sure and that can be audited. We can also point out that this act takes the 
system out of the certified configuration. So, if you need to be in the CAPP 
certified configuration, don't let users do this.

-Steve



From pertusus at free.fr  Sat Dec  6 13:23:06 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 6 Dec 2008 14:23:06 +0100
Subject: orphaning many packages
In-Reply-To: <20081206122420.GC2932@free.fr>
References: <20081206122420.GC2932@free.fr>
Message-ID: <20081206132306.GC4166@free.fr>

On Sat, Dec 06, 2008 at 01:24:20PM +0100, Patrice Dumas wrote:

> * libnet

Taken by Robert Scheck.

libnet10 is still to be taken.

--
Pat



From pertusus at free.fr  Sat Dec  6 13:29:03 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 6 Dec 2008 14:29:03 +0100
Subject: orphaning many packages
In-Reply-To: <20081206122420.GC2932@free.fr>
References: <20081206122420.GC2932@free.fr>
Message-ID: <20081206132903.GD4166@free.fr>

On Sat, Dec 06, 2008 at 01:24:20PM +0100, Patrice Dumas wrote:
> Hello,
> 
> * gnash

Also orphaned 
* docbook2X

This is used by gnash to generate documentation, so should be, in my
opinion, taken by the gnash maintainer if nobody else steps up.

--
Pat



From robert at fedoraproject.org  Sat Dec  6 13:37:02 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sat, 6 Dec 2008 14:37:02 +0100
Subject: orphaning many packages
In-Reply-To: <20081206132306.GC4166@free.fr>
References: <20081206122420.GC2932@free.fr> <20081206132306.GC4166@free.fr>
Message-ID: <20081206133702.GA2895@hurricane.linuxnetz.de>

On Sat, 06 Dec 2008, Patrice Dumas wrote:
> On Sat, Dec 06, 2008 at 01:24:20PM +0100, Patrice Dumas wrote:
> 
> > * libnet
> 
> Taken by Robert Scheck.
> 
> libnet10 is still to be taken.

Taking libnet10 as well, a package of a friend depends on this, I saw some
days ago. Luckily I've not to put it into Fedora, when it already exists
there...


Greetings,
  Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/76892722/attachment.sig>

From rawhide at fedoraproject.org  Sat Dec  6 13:41:09 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat,  6 Dec 2008 13:41:09 +0000 (UTC)
Subject: rawhide report: 20081206 changes
Message-ID: <20081206134110.3FBBA1F81C9@releng2.fedora.phx.redhat.com>

Compose started at Sat Dec  6 06:01:04 UTC 2008

New package fprintd
        D-Bus service for Fingerprint reader access
New package gmp-ecm
        Elliptic Curve Method for Integer Factorization
New package irclog2html
        Script to convert IRC logs to HTML and other formats
New package perl-HTML-FormFu
        HTML Form Creation, Rendering and Validation Framework
Removed package gnome-volume-manager
Updated Packages:

VLGothic-fonts-20081203-2.fc11
------------------------------
* Fri Dec  5 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 20081203-2
- update fontconfig config according to Fontconfig packaging tips.


alevt-1.6.2-8.fc11
------------------
* Fri Dec  5 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.6.2-8
- update build requires

* Fri Dec  5 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.6.2-7
- add doublefont patch; fixes #459294


alsa-tools-1.0.17-2.fc11
------------------------
* Fri Dec  5 17:00:00 2008 Jon McCann <jmccann at redhat.com> - 1.0.17-2
- Convert hotplug stuff to udev


aria2-1.0.1-1.fc11
------------------

beagle-0.3.8-16.fc11
--------------------
* Fri Dec  5 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.3.8-17
- Update for gmime-2.4

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.8-15
- Rebuild for Python 2.6


cduce-0.5.2.1-11.fc11
---------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.5.2.1-11
- Attempt to rebuild against OCaml 3.11.0.

* Sat Nov 22 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.5.2.1-10
- Don't include the name in the summary line.


codeblocks-8.02-4.fc10
----------------------
* Fri Oct 31 18:00:00 2008 Dan Horak <dan[at]danny.cz> 8.02-4
- fix gcc detection (#469096)


compiz-0.7.8-7.fc11
-------------------
* Fri Dec  5 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.7.8-7
- Readd compiz-0.7.6-utility-windows.patch
- Fix memory leaks


compiz-fusion-extras-0.7.8-4.fc11
---------------------------------
* Mon Dec  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-4
- Remove crap from scriptlet


comps-extras-16-1
-----------------
* Fri Dec  5 17:00:00 2008 Bill Nottingham <notting at redhat.com> - 16-1
- add a copy of the comps dtd & cleanup file (#204704)


coq-8.1pl4-1.fc11
-----------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 8.1pl4-1
- New upstream version 8.1pl4.
- Attempt to rebuild against OCaml 3.11.0.
- Run make with VERBOSE=1 so we can see the actual commands.
- Pass -camlp5dir to configure so it uses camlp5 (overriding existence
  of camlp4 if it happens to be installed).


cyphesis-0.5.17-3.fc11
----------------------
* Fri Dec  5 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.17-3
- Add fixes for 2.6

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.17-2
- Rebuild for Python 2.6


dbus-1.2.6-1.fc11
-----------------
* Fri Dec  5 17:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.6-1
- New upstream 1.2.6

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.2.4-2
- Tweak descriptions


deluge-1.0.6-1.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 1.0.6-1
- Update to new upstream release (1.0.6)
- Adds Tango images to the WebUI data (CC-BY-SA) and some man pages.
- Properly mark translation files with %lang.


devhelp-0.22-2.fc11
-------------------
* Fri Dec  5 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 0.22.2
- Drop the gecko requirement, since it uses WebKit now.


duplicity-0.4.12-3.fc11
-----------------------
* Fri Dec  5 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 0.4.12-3
- rebuild for python 2.6


eclipse-3.4.1-9.fc11
--------------------
* Thu Dec  4 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 1:3.4.1-8
- Increase MaxPermSize when running tests.

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:3.4.1-8
- Rebuild for Python 2.6


emacs-vm-8.0.12-3.fc11
----------------------
* Fri Dec  5 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 8.0.12-3
- Add patch to make vm-decode-postponed-mime-message autoloaded (BZ 474728)


epiphany-2.24.2.1-1.fc11
------------------------
* Fri Dec  5 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2.1-1
- Update to 2.24.2.1


esound-0.2.41-1.fc10
--------------------
* Mon Nov 24 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0 1:0.2.41-1
- Update t 0.2.41


fcron-3.0.4-4.fc11
------------------
* Fri Dec  5 17:00:00 2008 Patrice Dumas <pertusus[AT]free[DOT]fr> 3.0.4-4
- instead of using inotifywait use a specific C program to watch config
  - don't try to run anything in the default case and merge the 
    fcron-watch-config subpackage


file-roller-2.24.2-1.fc10
-------------------------
* Mon Nov 24 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2-1
- Update to 2.24.2


foobillard-3.0a-10
------------------
* Sat Dec  6 17:00:00 2008 Miloslav Trma?? <mitr at volny.cz> - 3.0a-10
- Add SportsGame category to foobillard.spec
  Resolves: #465700


freeradius-2.1.3-1.fc11
-----------------------
* Thu Dec  4 17:00:00 2008 John Dennis <jdennis at redhat.com> - 2.1.3-1
- upgrade to latest upstream release, upstream summary follows:
  The focus of this release is stability.
  Feature Improvements:
    * Allow running with "user=radiusd" and binding to secure sockets.
    * Start sending Status-Server "are you alive" messages earlier, which
      helps with proxying multiple realms to a home server.
    * Removed thread pool code from rlm_perl.  It's not necessary.
    * Added example Perl configuration to raddb/modules/perl
    * Force OpenSSL to support certificates with SHA256. This seems to be
      necessary for WiMAX certs.
  Bug fixes:
    * Fix Debian patch to allow it to build.
    * Fix potential NULL dereference in debugging mode on certain
      platforms for TTLS and PEAP inner tunnels.
    * Fix uninitialized memory in handling of vendor definitions
    * Fix parsing of quoted (but non-string) attributes in the "users" file.
    * Initialize uknown NAS IP to 255.255.255.255, rather than 0.0.0.0
    * use SUN_LEN in control socket, to avoid truncation on some platforms.
    * Correct internal handling of "debug condition" to prevent it from
      being over-written.
    * Check return code of regcomp in "unlang", so that invalid regular
      expressions are caught rather than mishandled.
    * Make rlm_sql use <ltdl.h>.  Addresses bug #610.
    * Document list "type = status" better.  Closes bug #580.
    * Set "default days" for certificates, because OpenSSL won't do it.
      This closes bug #615.
    * Reference correct list in example raddb/modules/ldap. Closes #596.
    * Increase default schema size for Acct-Session-Id to 64. Closes #540.
    * Fix use of temporary files in dialup-admin.  Closes #605 and
      addresses CVE-2008-4474.
    * Addressed a number of minor issues found by Coverity.
    * Added DHCP option 150 to the dictionary.  Closes #618.


freetype-2.3.7-2.fc11
---------------------
* Fri Dec  5 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> 2.3.7-2
- Add freetype-autohinter-ligature.patch
- Resolves: #368561


frysk-0.4-3.fc11
----------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4-3
- Rebuild for Python 2.6


fuse-emulator-0.10.0-1.fc11
---------------------------
* Fri Dec  5 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.10.0-1
- new upstream release 0.10.0


gdesklets-0.36.1-4.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.36.1-4
- Rebuild for Python 2.6


gedit-plugins-2.22.3-3.fc11
---------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.22.3-3
- Rebuild for Python 2.6


generic-logos-10.0.2-1.fc10
---------------------------
* Wed Dec  3 17:00:00 2008 Bill Nottingham <notting at redhat.com> - 10.0.2-1
- fix syslinux splash (accidentally branded)


gift-0.11.8.1-11.fc11
---------------------
* Fri Dec  5 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.7.4-4
- respin (libtool)


gnome-bluetooth-0.11.0-8.fc11
-----------------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.11.0-8
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.0-7
- Rebuild for Python 2.6

* Fri Oct 31 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.0-6
- Remove a few more .la files


gnome-desktop-2.25.2-4.fc11
---------------------------
* Fri Dec  5 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-4
- Fix leak in previous update (bug 468339)


gnome-packagekit-0.3.11-3.fc11
------------------------------
* Thu Dec  4 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0.3.11-3
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.11-2
- Rebuild for Python 2.6


gnome-python2-extras-2.19.1-26.fc11
-----------------------------------
* Fri Dec  5 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.19.1-26
- Rebuild against new gecko


gnome-settings-daemon-2.25.2-2.fc11
-----------------------------------
* Thu Dec  4 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-2
- Rebase fade patch to apply with Behdad's updates to
  g-s-d

* Wed Dec  3 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Ypdate to 2.25.2


gnome-speech-0.4.22-1.fc10
--------------------------
* Tue Nov 25 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.4.22-1
- Update to 0.4.22


gnonlin-0.10.10-2.fc9
---------------------
* Mon Nov  3 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.10.10-2
- Don't forget to upload the new sources!

* Mon Nov  3 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.10.10-1
- Update to 0.10.10

* Thu Oct 30 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.10.9.2-1
- Update to 0.10.9.2

* Tue Mar  4 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.10.9-4
- Update source url.


greadelf-1.0-1.fc11
-------------------
* Fri Dec  5 17:00:00 2008 Parag Nemade <panemade at gmail.com>- 1.0-1
- Update to next release 1.0


gtk-sharp-1.0.10-21.fc11
------------------------
* Fri Dec  5 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1.0.10-21
- Rebuild for pkg-config provides


gucharmap-2.24.2-1.fc10
-----------------------
* Mon Nov 24 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2-1
- Update to 2.24.2


guidance-power-manager-4.1.3-2.fc11
-----------------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.1.3-2
- Rebuild for Python 2.6


gutenprint-5.2.2-2.fc11
-----------------------
* Fri Dec  5 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 5.2.2-2
- Fixed generation of globalized PPDs.


gvfs-1.1.1-3.fc11
-----------------
* Fri Dec  5 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.1.1-3
- Added experimental smb-browse auth patch


hevea-1.10-2.fc11
-----------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.10-2
- Rebuild for OCaml 3.11.0+rc1.


jakarta-commons-cli-1.1-1.fc11
------------------------------
* Fri Dec  5 17:00:00 2008 Jesus M. Rodriguez <jesusr at redhat.com> - 0:1.1-1
- update to 1.1


kbibtex-0.2.1-24.fc10
---------------------
* Wed Dec  3 17:00:00 2008 Christian Nolte <ch.nolte at noltec.org> - 0.2.1-24
- Desktop files are now conform to the latest freedesktop spec. (#468937)
- Update to version 0.2.1. Seems that mass branching has picked up the F-7
  branch.


kernel-2.6.28-0.113.rc7.git5.fc11
---------------------------------
* Fri Dec  5 17:00:00 2008 Dave Jones <davej at redhat.com>
- SELinux: check open perms in dentry_open not inode_permission

* Fri Dec  5 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc7-git5

* Fri Dec  5 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc7-git4


koffice-1.9.98.3-1.fc11
-----------------------
* Fri Dec  5 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1:1.9.98.3-1
- koffice-1.9.98.3 (koffice2 beta4)


libprelude-0.9.21.2-5.fc11
--------------------------
* Fri Dec  5 17:00:00 2008 Steve Grubb <sgrubb at redhat.com> - 0.9.21.2-5
- Rebuild _again_ for Python 2.6


libraw1394-2.0.0-4.fc11
-----------------------
* Fri Dec  5 17:00:00 2008 Jarod Wilson <jarod at redhat.com> - 2.0.0-4
- Fix channel modify code, should make iso reception work reliably now


libspectrum-0.5.0-1.fc11
------------------------
* Fri Dec  5 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.5.0-1
- new upstream 0.5.0


libtunepimp-0.5.3-13.fc11
-------------------------
* Fri Dec  5 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.5.3-13
- fix build (libtool(2) and more rpath fun)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.3-12
- Rebuild for Python 2.6


libwnck-2.24.2-1.fc10
---------------------
* Tue Nov 25 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2-1
- Update to 2.24.2


lsscsi-0.21-2.fc10
------------------

memtest86+-2.10-1.fc10
----------------------
* Wed Nov 12 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.10-1
- 2.10


mesa-7.2-0.14.fc10
------------------
* Fri Nov 28 17:00:00 2008 Dave Airlie <airlied at redhat.com> 7.2-0.14
- mesa-7.1-fix-i8xx-vbos.patch: fix i8xx hw rendering


nautilus-2.25.1-5.fc11
----------------------
* Fri Dec  5 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.25.1-4
- Properly open new windows after long mount operation
- Fix callback connection to the GtkMountOperation dialog

* Fri Dec  5 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-5
- Obsolete gnome-volume-manager


ocaml-SDL-0.7.2-17.fc11
-----------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.7.2-17
- Force rebuild.


ocaml-bitstring-2.0.0-7.fc11
----------------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.0.0-7
- Patch for OCaml 3.11.0 official.


ocaml-camlimages-3.0.1-5.fc11
-----------------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.0.1-5
- Rebuild.


ocaml-cil-1.3.6-9.fc11
----------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.3.6-9
- Patch to fix stricter -output-obj checks in OCaml 3.11.0.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.3.6-8
- Rebuild for OCaml 3.11.0


ocaml-cmigrep-1.5-9.fc11
------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.5-9
- Rebuild for OCaml 3.11.0.

* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.5-8
- Rebuild for OCaml 3.11.0+rc1.
- Remove string-index-from patch.


ocaml-deriving-0.1.1a-6.fc11
----------------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.1.1a-6
- Patch to add dynlink.cma for camlp4lib.cma.
- Rebuild for OCaml 3.11.0.

* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.1.1a-5
- Rebuild for OCaml 3.11.0+rc1.


ocaml-gettext-0.3.2-6.fc11
--------------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.3.2-6
- Patch to temporarily fix missing dynlink.cma.
- Rebuild for OCaml 3.11.0.

* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.3.2-5
- Rebuild for OCaml 3.11.0+rc1.


ocaml-gsl-0.6.0-6.fc11
----------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.6.0-6
- Force rebuild.


ocaml-json-wheel-1.0.4-7.fc11
-----------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.4-7
- Rebuild.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.4-6
- Rebuild for OCaml 3.11.0


ocaml-mikmatch-1.0.0-4.fc11
---------------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.0-4
- Patch for dynlink.cma dependency for camlp4.
- Rebuild for OCaml 3.11.0.

* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.0-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-ocamlgraph-1.0-3.fc11
---------------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0-3
- Rebuild for OCaml 3.11.0.
- Requires lablgtk2.
- Pull in gtk / libgnomecanvas too.

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0-1
- New upstream release 1.0.
- Patch0 removed - now upstream.
- Added a patch to fix documentation problem.
- Run tests with 'make --no-print-directory'.


ocaml-ocamlnet-2.2.9-9.fc11
---------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.2.9-9
- Rebuild for OCaml 3.11.0+rc1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.2.9-8
- Rebuild for OCaml 3.11.0


ocaml-omake-0.9.8.5-4.fc11
--------------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9.8.5-4
- Rebuild for OCaml 3.11.0.


ocaml-pa-monad-1.2.0-7.fc11
---------------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0-7
- Remove -warn-error which caused tests to fail.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0-6
- Rebuild for OCaml 3.11.0


ocaml-pgocaml-1.1-6.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1-6
- Rebuild for OCaml 3.11.0+rc1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1-5
- Rebuild for OCaml 3.11.0


ocaml-pxp-1.2.0test2-5.fc11
---------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0test2-5
- Rebuild for OCaml 3.11.0+rc1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0test2-4
- Rebuild for OCaml 3.11.0


ocaml-reins-0.1a-3.fc11
-----------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.1a-3
- Rebuild for OCaml 3.11.0+rc1.


ocaml-sexplib-4.2.1-2.fc11
--------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 4.2.1-2
- Rebuild for OCaml 3.11.0+rc1.

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 4.2.1-1
- New upstream version 4.2.1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 4.0.1-2
- Rebuild for OCaml 3.11.0


ocaml-xmlrpc-light-0.6-5.fc11
-----------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.6-5
- Rebuild for OCaml 3.11.0+rc1.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.6-4
- Rebuild for OCaml 3.11.0


ochusha-0.5.99.68-0.4.cvs20081206T0140.fc11
-------------------------------------------
* Sat Dec  6 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


olpc-utils-0.89-6.fc11
----------------------
* Fri Dec  5 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.89-6
- Rebuild for Python 2.6 and merge from branch


perl-DBD-Pg-2.11.6-2.fc11
-------------------------
* Fri Dec  5 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 2.11.6-2
- fix the source URL

* Fri Dec  5 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 2.11.6-1
- update

* Fri Oct 31 18:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> - 2.11.2-1
- update to 2.11.2


perl-File-Find-Rule-VCS-1.05-1.fc11
-----------------------------------
* Fri Dec  5 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 1.05-1
- update


perl-File-ShareDir-PAR-0.03-1.fc11
----------------------------------
* Fri Dec  5 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 0.03-1
- update to 0.03


perl-Wx-Perl-Dialog-0.03-1.fc11
-------------------------------
* Fri Dec  5 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 0.03-1
- update to 0.03


pexpect-2.3-2.fc11
------------------
* Fri Dec  5 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 2.3-2
- Rebuild for python 2.6


pidgin-2.5.2-6.fc10
-------------------
* Sat Nov 22 17:00:00 2008 Warren Togami <wtogami at redhat.com> 2.5.2-6
- Automatically detect booleans to enable build features from dist tag
- Unify RHEL4 and RHEL5 spec with Fedora to make both easier to maintain

* Fri Nov 21 17:00:00 2008 Warren Togami <wtogami at redhat.com> 2.5.2-2
- Upstream backports:
  100: sametime-redirect-null crash
  101: NetworkManager-improvement
  102: no-password-in-dialog-if-not-remembering
  103: temporarily-remember-password-during-auto-reconnect
  104: smilie-theme-change-crash
  105: url_fetch_connect_cb-double-free crash
  106: GtkIMHtmlSmileys-remove-crash
  107: remove-dialog-from-open-dialog-list


plplot-5.9.0-4.svn8985.fc11
---------------------------
* Thu Dec  4 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 5.9.0-4.svn8985
- Rebuild for OCaml 3.11.0.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 5.9.0-3.svn8985
- Rebuild for Python 2.6


pmpu-0.2-3.fc11
---------------
* Fri Dec  5 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> - 0.2-3
- Owns pushmepullyou directory
- Source URL


ppl-0.10-4.fc11
---------------
* Fri Dec  5 17:00:00 2008 Roberto Bagnara <bagnara at cs.unipr.it> 0.10-4
- Added `%dir %{_datadir}/doc/pwl' to the `%files' section
  of the `ppl-pwl' package.


preupgrade-1.0.1-1.fc11
-----------------------
* Mon Dec  8 17:00:00 2008 Will Woods <wwoods at redhat.com> - 1.0.1-1
- Fix yaboot Conflicts: to allow installation on ppc (bug 473065)
- Fix crash with separate /var partition or mdraid root (bug 473782)
- Fix crash with mdraid (software RAID) root (bug 473103)
- CLI: Use the right dir for createrepo 
- CLI: Fix network option parsing, add --dhcp
- CLI: Write network options into ks.cfg (bug 472933)


python-GnuPGInterface-0.3.2-4.fc11
----------------------------------
* Fri Dec  5 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 0.3.2-4
- Rebuild for python 2.6


python-boto-1.2a-2.fc11
-----------------------
* Fri Dec  5 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 1.2a-2
- Rebuild for python 2.6


pywebkitgtk-1.0.1-4.fc11
------------------------
* Fri Dec  5 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 1.0.1-4
- Fix build for python 2.6.  Patch matches what went upstream to 
  fix the same problem

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.1-3
- Rebuild for Python 2.6


qlandkartegt-0.9.1-1.fc11
-------------------------
* Fri Dec  5 17:00:00 2008 Dan Horak <dan[at]danny.cz> 0.9.1-1
- update to 0.9.1


qmmp-0.2.3-1.fc11
-----------------
* Fri Dec  5 17:00:00 2008 Karel Volny <kvolny at redhat.com> 0.2.3-1
- new version
- added %{?_smp_mflags} to make, as parallel build was fixed


qpidc-0.3.722557-1.fc10
-----------------------
* Tue Dec  2 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.722557-1
- Rebased to svn rev 722557
- Temporarily disabled cluster due to openais version incompatibility

* Wed Nov 26 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.720979-1
- Rebased to svn rev 720979

* Fri Nov 21 17:00:00 2008 Mick Goulish <mgoulish at redhat.com>
- updated to 719552

* Thu Nov 20 17:00:00 2008 Mick Goulish <mgoulish at redhat.com>
- updated to 719323
- For subpackage qpidd-cluster, added dependency to cman-devel.
- For subpackage qpidd-cluster, added dependency to qpidc.
- added BuildRequires cman-devel

* Fri Nov 14 17:00:00 2008 Justin Ross <jross at redhat.com> - 0.3.714072-1
- Update to svn rev 714072
- Enable building --with-cpg

* Wed Nov 12 17:00:00 2008 Justin Ross <jross at redhat.com> - 0.3.713378-1
- Update to svn rev 713378

* Fri Nov  7 17:00:00 2008 Justin Ross <jross at redhat.com> - 0.3.712127-1
- Update to svn rev 712127

* Thu Nov  6 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.711915-2
- Removed extraneous openais-devel dependency

* Thu Nov  6 17:00:00 2008 Justin Ross <jross at redhat.com> - 0.3.711915-1
- Update to svn rev 711915

* Tue Nov  4 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.709187-2
- Remove extraneous dependency


revelation-0.4.11-7
-------------------
* Fri Dec  5 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 0.4.11-7
- rebuild for python 2.6 harder

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.11-6.1
- Rebuild for Python 2.6


rhm-0.3.2913-1.fc10
-------------------
* Thu Dec  4 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.2913-1
- Rebased to svn rev 2913/722557


sqlite-3.6.6.2-4.fc11
---------------------
* Fri Dec  5 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 3.6.6.2-4
- add lemon subpackage


sysstat-8.0.4-6.fc11
--------------------
* Fri Dec  5 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 8.0.4-6
- add /proc/diskstats reading patch


system-config-printer-1.0.12-1.fc11
-----------------------------------
* Mon Dec  1 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.12-1
- Updated to 1.0.12:
  - Don't automatically replace network printer URIs with
    HPLIP URIs (bug #473129).
  - Fixed some file descriptor and temporary file leaks.


tuxpaint-0.9.20-2.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:0.9.20-2
- Rebuild for Python 2.6


unison213-2.13.16-12.fc11
-------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.13.16-12
- Rebuild for OCaml 3.11.0+rc1.


unison227-2.27.57-10.fc11
-------------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.27.57-10
- Rebuild for OCaml 3.11.0+rc1.


virt-ctrl-1.0.1-2.fc11
----------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.1-2
- Rebuild for OCaml 3.11.0+rc1.


virt-df-2.1.4-3.fc11
--------------------
* Wed Nov  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.1.4-3
- Patch to fix camlp4 parsing problem in 3.11.0.


virt-mem-0.3.1-5.fc11
---------------------
* Fri Dec  5 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.3.1-5
- Rebuild for OCaml 3.11.0.
- Fix for bitstring 2.0.0.
- Fix for dynlink.cma dep on camlp4.
- Avoid stack overflow on ppc64.

* Mon Aug 25 18:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.3.1-2
- Forgot to add the new sources to previous release.

* Mon Aug 25 18:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.3.1-1
- New upstream release 0.3.1.


virt-top-1.0.3-3.fc11
---------------------
* Wed Nov 26 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.3-3
- Rebuild for OCaml 3.11.0+rc1.


vte-0.19.3-1.fc11
-----------------
* Fri Dec  5 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> 0.19.3-1
- Update to 0.19.3

* Fri Dec  5 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> 0.19.2-1
- Update to 0.19.2


vym-1.12.2-1.fc11
-----------------
* Fri Dec  5 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.12.2-1
- Updated to new upstream version.


warzone2100-2.1.0-0.8.rc2.fc11
------------------------------
* Fri Dec  5 17:00:00 2008 Karol Trzcionka <karlikt at gmail.com> - 2.1.0-0.8.rc2
- Update to v2.1.0-rc2


xapian-bindings-1.0.9-2.fc11
----------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 1.0.9-2
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 1.0.9-1
- Update to 1.0.9


xapian-core-1.0.9-2.fc11
------------------------
* Fri Dec  5 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 1.0.9-2
- Fix build

* Sat Nov 29 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 1.0.9-1
- Update to 1.0.9


xorg-x11-drv-radeonhd-1.2.3-1.7.20081206git.fc11
------------------------------------------------
* Sat Dec  6 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.2.3-1.7.20081206git
- New snapshot (upstream commit 48def66ce9592926ed9b23530fb21a55ac253392):
  - 48def66c: Document that Option "DRI" also affects Xv
  - de7a4147: R5xx XAA: pass correct size to xf86InitFBManager.
  - 46df4169: RandR 1.3 Panning support
  - 907365c7: RandR 1.3 Panning support
  - ae56abc1: RandR: Improve heuristics to determine of an output is connected.
  - ed532a70: ID: Add connector table for HD 2400 "0x94c3:0x000:0x0000".
  - 69eadbf2: ID: Supply fixed connector table for  Radeon X1300 0x7187:0x1545:0x1930.


Summary:
Added Packages: 4
Removed Packages: 1
Modified Packages: 113
Broken deps for i386
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.i386 requires libpython2.5.so.1.0
	ScientificPython-qt-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	avahi-ui-sharp-0.6.22-13.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	beecrypt-python-4.1.2-17.fc10.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.i386 requires libspectrum.so.5
	ganglia-gmond-python-3.1.1-1.fc10.i386 requires libpython2.5.so.1.0
	gdal-python-1.5.3-1.fc10.i386 requires python(abi) = 0:2.5
	gdal-python-1.5.3-1.fc10.i386 requires libpython2.5.so.1.0
	gdl-0.9-0.rc1.4.fc10.i386 requires libpython2.5.so.1.0
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gimmie-0.2.8-2.fc9.i386 requires python(abi) = 0:2.5
	glipper-1.0-4.fc10.i386 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.i386 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.i386 requires libpython2.5.so.1.0
	1:gnumeric-1.8.2-4.fc10.i386 requires libpython2.5.so.1.0
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	graphviz-python-2.20.3-1.fc11.i386 requires python(abi) = 0:2.5
	gtkglextmm-devel-1.2.0-8.fc11.i386 requires pkgconfig(gdkglext-1.0)
	hamster-applet-2.24.2-2.fc11.i386 requires python(abi) = 0:2.5
	hulahop-0.4.6-4.fc10.i386 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	liblicense-devel-0.8-3.i386 requires pkgconfig(raptor)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	libscigraphica-devel-2.1.1-9.fc11.i386 requires pkgconfig(gtkextra-2.0)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	listen-0.5-19.fc10.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mkinitrd-6.0.73-2.fc11.i386 requires libdhcp-1.99.so.1
	mkinitrd-6.0.73-2.fc11.i386 requires libdhcp6client-1.0.so.2
	mkinitrd-6.0.73-2.fc11.i386 requires libdhcp4client-4.0.so.0
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nash-6.0.73-2.fc11.i386 requires libdhcp4client
	nash-6.0.73-2.fc11.i386 requires libdhcp6client
	nash-6.0.73-2.fc11.i386 requires libdhcp
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.i386 requires python(abi) = 0:2.5
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.i386 requires libpython2.5.so.1.0
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-HTML-FormFu-0.03005-3.fc11.noarch requires perl(defaults)
	perl-HTML-FormFu-0.03005-3.fc11.noarch requires perl(model_config)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-gui-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	prewikka-0.9.14-1.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyabiword-0.6.1-3.fc10.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-brlapi-0.5.2-1.fc10.i386 requires libpython2.5.so.1.0
	python-brlapi-0.5.2-1.fc10.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rdflib-2.4.0-7.fc10.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rpy-1.0.3-4.fc10.i386 requires libpython2.5.so.1.0
	rpy-1.0.3-4.fc10.i386 requires python(abi) = 0:2.5
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	scigraphica-2.1.0-6.fc9.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.i386 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ScientificPython-qt-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.x86_64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.x86_64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	avahi-ui-sharp-0.6.22-13.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	beecrypt-python-4.1.2-17.fc10.x86_64 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.x86_64 requires libspectrum.so.5()(64bit)
	ganglia-gmond-python-3.1.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	gdal-python-1.5.3-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	gdal-python-1.5.3-1.fc10.x86_64 requires python(abi) = 0:2.5
	gdl-0.9-0.rc1.4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gimmie-0.2.8-2.fc9.x86_64 requires python(abi) = 0:2.5
	glipper-1.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.i386 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.i386 requires libpython2.5.so.1.0
	glom-1.6.17-1.fc10.x86_64 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:gnumeric-1.8.2-4.fc10.i386 requires libpython2.5.so.1.0
	1:gnumeric-1.8.2-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	graphviz-python-2.20.3-1.fc11.x86_64 requires python(abi) = 0:2.5
	gtkglextmm-devel-1.2.0-8.fc11.i386 requires pkgconfig(gdkglext-1.0)
	gtkglextmm-devel-1.2.0-8.fc11.x86_64 requires pkgconfig(gdkglext-1.0)
	hamster-applet-2.24.2-2.fc11.x86_64 requires python(abi) = 0:2.5
	hulahop-0.4.6-4.fc10.x86_64 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
	liblicense-devel-0.8-3.i386 requires pkgconfig(raptor)
	liblicense-devel-0.8-3.x86_64 requires pkgconfig(raptor)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	libscigraphica-devel-2.1.1-9.fc11.i386 requires pkgconfig(gtkextra-2.0)
	libscigraphica-devel-2.1.1-9.fc11.x86_64 requires pkgconfig(gtkextra-2.0)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.x86_64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	listen-0.5-19.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mkinitrd-6.0.73-2.fc11.x86_64 requires libdhcp-1.99.so.1()(64bit)
	mkinitrd-6.0.73-2.fc11.x86_64 requires libdhcp6client-1.0.so.2()(64bit)
	mkinitrd-6.0.73-2.fc11.x86_64 requires libdhcp4client-4.0.so.0()(64bit)
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	muine-devel-0.8.10-3.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nash-6.0.73-2.fc11.i386 requires libdhcp4client
	nash-6.0.73-2.fc11.i386 requires libdhcp6client
	nash-6.0.73-2.fc11.i386 requires libdhcp
	nash-6.0.73-2.fc11.x86_64 requires libdhcp6client
	nash-6.0.73-2.fc11.x86_64 requires libdhcp
	nash-6.0.73-2.fc11.x86_64 requires libdhcp4client
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.x86_64 requires python(abi) = 0:2.5
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-HTML-FormFu-0.03005-3.fc11.noarch requires perl(defaults)
	perl-HTML-FormFu-0.03005-3.fc11.noarch requires perl(model_config)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	prewikka-0.9.14-1.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyabiword-0.6.1-3.fc10.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-brlapi-0.5.2-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-brlapi-0.5.2-1.fc10.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	rpy-1.0.3-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	rpy-1.0.3-4.fc10.x86_64 requires python(abi) = 0:2.5
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	scigraphica-2.1.0-6.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.x86_64 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.ppc requires libpython2.5.so.1.0
	ScientificPython-qt-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	avahi-ui-sharp-0.6.22-13.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	beecrypt-python-4.1.2-17.fc10.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc requires libspectrum.so.5
	ganglia-gmond-python-3.1.1-1.fc10.ppc requires libpython2.5.so.1.0
	gdal-python-1.5.3-1.fc10.ppc requires libpython2.5.so.1.0
	gdal-python-1.5.3-1.fc10.ppc requires python(abi) = 0:2.5
	gdl-0.9-0.rc1.4.fc10.ppc requires libpython2.5.so.1.0
	ghc-gtk2hs-gtkglext-0.9.13-5.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-5.20081108.fc11
	gimmie-0.2.8-2.fc9.ppc requires python(abi) = 0:2.5
	glipper-1.0-4.fc10.ppc requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.ppc requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.ppc requires libpython2.5.so.1.0
	glom-1.6.17-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	glom-1.6.17-1.fc10.ppc64 requires python(abi) = 0:2.5
	1:gnumeric-1.8.2-4.fc10.ppc requires libpython2.5.so.1.0
	1:gnumeric-1.8.2-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	graphviz-python-2.20.3-1.fc11.ppc requires python(abi) = 0:2.5
	gtkglextmm-devel-1.2.0-8.fc11.ppc requires pkgconfig(gdkglext-1.0)
	gtkglextmm-devel-1.2.0-8.fc11.ppc64 requires pkgconfig(gdkglext-1.0)
	hamster-applet-2.24.2-2.fc11.ppc requires python(abi) = 0:2.5
	hulahop-0.4.6-4.fc10.ppc requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	liblicense-devel-0.8-3.ppc requires pkgconfig(raptor)
	liblicense-devel-0.8-3.ppc64 requires pkgconfig(raptor)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libscigraphica-devel-2.1.1-9.fc11.ppc requires pkgconfig(gtkextra-2.0)
	libscigraphica-devel-2.1.1-9.fc11.ppc64 requires pkgconfig(gtkextra-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	listen-0.5-19.fc10.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mkinitrd-6.0.73-2.fc11.ppc requires libdhcp-1.99.so.1
	mkinitrd-6.0.73-2.fc11.ppc requires libdhcp6client-1.0.so.2
	mkinitrd-6.0.73-2.fc11.ppc requires libdhcp4client-4.0.so.0
	muine-devel-0.8.10-3.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nash-6.0.73-2.fc11.ppc requires libdhcp4client
	nash-6.0.73-2.fc11.ppc requires libdhcp6client
	nash-6.0.73-2.fc11.ppc requires libdhcp
	nash-6.0.73-2.fc11.ppc64 requires libdhcp6client
	nash-6.0.73-2.fc11.ppc64 requires libdhcp
	nash-6.0.73-2.fc11.ppc64 requires libdhcp4client
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.ppc requires python(abi) = 0:2.5
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.ppc requires libpython2.5.so.1.0
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-HTML-FormFu-0.03005-3.fc11.noarch requires perl(defaults)
	perl-HTML-FormFu-0.03005-3.fc11.noarch requires perl(model_config)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	prewikka-0.9.14-1.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyabiword-0.6.1-3.fc10.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-brlapi-0.5.2-1.fc10.ppc requires libpython2.5.so.1.0
	python-brlapi-0.5.2-1.fc10.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	rpy-1.0.3-4.fc10.ppc requires libpython2.5.so.1.0
	rpy-1.0.3-4.fc10.ppc requires python(abi) = 0:2.5
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	scigraphica-2.1.0-6.fc9.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.ppc requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ScientificPython-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	ScientificPython-qt-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	beecrypt-python-4.1.2-17.fc10.ppc64 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc64 requires libspectrum.so.5()(64bit)
	ganglia-gmond-python-3.1.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gdal-python-1.5.3-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gdal-python-1.5.3-1.fc10.ppc64 requires python(abi) = 0:2.5
	gdl-0.9-0.rc1.4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gimmie-0.2.8-2.fc9.ppc64 requires python(abi) = 0:2.5
	glipper-1.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	glom-1.6.17-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	glom-1.6.17-1.fc10.ppc64 requires python(abi) = 0:2.5
	1:gnumeric-1.8.2-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	graphviz-python-2.20.3-1.fc11.ppc64 requires python(abi) = 0:2.5
	gtkglextmm-devel-1.2.0-8.fc11.ppc64 requires pkgconfig(gdkglext-1.0)
	hamster-applet-2.24.2-2.fc11.ppc64 requires python(abi) = 0:2.5
	hulahop-0.4.6-4.fc10.ppc64 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	liblicense-devel-0.8-3.ppc64 requires pkgconfig(raptor)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libscigraphica-devel-2.1.1-9.fc11.ppc64 requires pkgconfig(gtkextra-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	listen-0.5-19.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mkinitrd-6.0.73-2.fc11.ppc64 requires libdhcp-1.99.so.1()(64bit)
	mkinitrd-6.0.73-2.fc11.ppc64 requires libdhcp6client-1.0.so.2()(64bit)
	mkinitrd-6.0.73-2.fc11.ppc64 requires libdhcp4client-4.0.so.0()(64bit)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nash-6.0.73-2.fc11.ppc64 requires libdhcp6client
	nash-6.0.73-2.fc11.ppc64 requires libdhcp
	nash-6.0.73-2.fc11.ppc64 requires libdhcp4client
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.ppc64 requires python(abi) = 0:2.5
	1:openoffice.org-pyuno-3.0.1-12.1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-HTML-FormFu-0.03005-3.fc11.noarch requires perl(defaults)
	perl-HTML-FormFu-0.03005-3.fc11.noarch requires perl(model_config)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	prewikka-0.9.14-1.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyabiword-0.6.1-3.fc10.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-brlapi-0.5.2-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-brlapi-0.5.2-1.fc10.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	rpy-1.0.3-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	rpy-1.0.3-4.fc10.ppc64 requires python(abi) = 0:2.5
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	scigraphica-2.1.0-6.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.ppc64 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(pangoft2)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From lists at ralii.com  Sat Dec  6 14:03:21 2008
From: lists at ralii.com (Robert Locke)
Date: Sat, 06 Dec 2008 09:03:21 -0500
Subject: Whodunnit? F10 install without permission
In-Reply-To: <1228542826.4814.32.camel@localhost.localdomain>
References: <1228502782.3673.29.camel@localhost.localdomain>
	<1228504740.3275.48.camel@localhost.localdomain>
	<a993ebee0812051443p7a91c331m19b0da08e125af69@mail.gmail.com>
	<4939B337.50500@fedoraproject.org>
	<a993ebee0812051849x3e1d3bf5kb82878cb1efdddd@mail.gmail.com>
	<1228542826.4814.32.camel@localhost.localdomain>
Message-ID: <1228572201.3612.11.camel@localhost.localdomain>

On Fri, 2008-12-05 at 21:53 -0800, Jesse Keating wrote:
> On Sat, 2008-12-06 at 02:49 +0000, dexter wrote:
> > As I don't use this Kit I'll never see it, but along the lines of 'is
> > it ok to install x.y.z to enable auto-updates [y|n]'
> > followed by a 'always do this | dont ask again'. The important keyword
> > here is opt-in!
> 
> Well that wasn't what the package was installed for.  It was installed
> so that PackageKit could have the appropriate information to check if
> there were distro level upgrades (say 9 to 10) available for you.  The
> upstream has been asked to please not install any software in Fedora
> without a users consent, so hopefully this scenario won't happen again,
> at least not with PackageKit.

I think, in this case, it would have made more sense to have added a new
Pre-Req to an update of PackageKit, since it was not defined in the
initial package of F10.  I would have probably happily agreed to have
those three packages brought along for the ride at my next "yum
update"....  What was disconcerting to me is when the settings for the
PackageKit tool say: "Automatic install: Nothing".

It's great when folks don't even pay attention to their own settings....
<evil grin>

Thanks Jesse for clarifying with upstream,

--Rob



From chris.stone at gmail.com  Sat Dec  6 16:31:36 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Sat, 6 Dec 2008 08:31:36 -0800
Subject: Fedora 10 and YUM
In-Reply-To: <bfdeacfa0812050624l3185dd5pf9fdb3d7fb829b11@mail.gmail.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
	<20081128091450.01790757@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0812031446130.21833@localhost.localdomain>
	<4937A430.3040109@niemueller.de>
	<alpine.LFD.2.00.0812040841300.27394@localhost.localdomain>
	<4937E458.3000106@niemueller.de>
	<645d17210812040646h3f6514ddj281eaa2038e5bd0@mail.gmail.com>
	<bfdeacfa0812050624l3185dd5pf9fdb3d7fb829b11@mail.gmail.com>
Message-ID: <d9c612bf0812060831sac0d98fn29b5e58c5c26c9c8@mail.gmail.com>

I have added an entry to the common bugs page [1], so hopefully
newbies will be able to find the bug more easily.

Please feel free to add more detailed wiki text.

[1] https://fedoraproject.org/wiki/Common_F10_bugs#DNS_Resolver_not_Reliable



From ihok at hotmail.com  Sat Dec  6 16:37:59 2008
From: ihok at hotmail.com (Jack Tanner)
Date: Sat, 6 Dec 2008 16:37:59 +0000 (UTC)
Subject: release notes page borked
Message-ID: <loom.20081206T163607-609@post.gmane.org>

The page http://docs.fedoraproject.org/release-notes/f10/ has wrong links to
release notes in ALL languages. For example, en_US link is

http://docs.fedoraproject.org/release-notes/f10/f10/en_US/

but it should be

http://docs.fedoraproject.org/release-notes/f10/en_US/

Not filing this in Bugzilla, since I figure anyone with wiki rights can fix this
quicker.



From jkeating at redhat.com  Sat Dec  6 16:52:38 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 06 Dec 2008 08:52:38 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812060748.00510.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228542924.4814.33.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>
	<200812060748.00510.sgrubb@redhat.com>
Message-ID: <1228582358.4814.34.camel@localhost.localdomain>

On Sat, 2008-12-06 at 07:48 -0500, Steve Grubb wrote:
> Sure and that can be audited. We can also point out that this act takes the 
> system out of the certified configuration. So, if you need to be in the CAPP 
> certified configuration, don't let users do this.

To be CAPP certified, you can't have a web browser?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/83075ed3/attachment.sig>

From jkeating at redhat.com  Sat Dec  6 16:56:31 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 06 Dec 2008 08:56:31 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812060745.37122.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
	<1228542924.4814.33.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
Message-ID: <1228582591.4814.37.camel@localhost.localdomain>

On Sat, 2008-12-06 at 07:45 -0500, Steve Grubb wrote:
> 
> No, it has more to do with the fact that we have to audit all attempts to 
> modify trusted databases - in this case, shadow. No one can use these tools 
> since they do not have the permissions required to be successful. So, we 
> remove the ability to use these tools so that we don't have to audit it. 
> 
> IOW, if we open the permissions, we need to make these become setuid root so 
> that we send audit events saying they failed.
> 
> 
> > I'm just curious what added security you really get.
> 
> Its not so much a security thing as much as its a certification thing. An 
> ordinary user cannot possibly use these tools since they do not have the 
> requisite permissions.
> 

Now I'm confused.  Why would the binary have to be suid?  Why can't the
binary detect that hte calling user is not root, and just print out the
usage and a message saying that you have to be root?  How would this
action make it any less auditable?

It seems that the cert folks have a different definition of "use" than
we do.  A normal user should be able to use the binary to get help
output, and the binary would be useful in path for things like tab
completion leading up to a sudo call.

Still wondering what "value" this is adding.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/51f44fe7/attachment.sig>

From kevin.kofler at chello.at  Sat Dec  6 17:26:25 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 06 Dec 2008 18:26:25 +0100
Subject: release notes page borked
References: <loom.20081206T163607-609@post.gmane.org>
Message-ID: <gheck1$snb$1@ger.gmane.org>

Jack Tanner wrote:
> The page http://docs.fedoraproject.org/release-notes/f10/ has wrong links
> to release notes in ALL languages. For example, en_US link is
> 
> http://docs.fedoraproject.org/release-notes/f10/f10/en_US/
> 
> but it should be
> 
> http://docs.fedoraproject.org/release-notes/f10/en_US/
> 
> Not filing this in Bugzilla, since I figure anyone with wiki rights can
> fix this quicker.

Those pages are not actually in the wiki, they are static pages generated
from an old snapshot of the wiki, so only few people can fix this.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Dec  6 17:35:38 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 06 Dec 2008 18:35:38 +0100
Subject: More PATH fallout. Who decided this was a good idea?
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228542924.4814.33.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>
	<200812060748.00510.sgrubb@redhat.com>
	<1228582358.4814.34.camel@localhost.localdomain>
Message-ID: <ghed5a$snb$2@ger.gmane.org>

Jesse Keating wrote:

> On Sat, 2008-12-06 at 07:48 -0500, Steve Grubb wrote:
>> Sure and that can be audited. We can also point out that this act takes
>> the system out of the certified configuration. So, if you need to be in
>> the CAPP certified configuration, don't let users do this.
> 
> To be CAPP certified, you can't have a web browser?

Mounting the home directories with noexec should also prevent users from
doing this.

That said, AFAIK the CAPP profile implies no Internet access. (But the
people actually working on security might correct me on that.)

        Kevin Kofler



From skvidal at fedoraproject.org  Sat Dec  6 17:38:35 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sat, 6 Dec 2008 12:38:35 -0500 (EST)
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <ghed5a$snb$2@ger.gmane.org>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228542924.4814.33.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>
	<200812060748.00510.sgrubb@redhat.com>
	<1228582358.4814.34.camel@localhost.localdomain>
	<ghed5a$snb$2@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0812061238130.2777@localhost.localdomain>



On Sat, 6 Dec 2008, Kevin Kofler wrote:

> Jesse Keating wrote:
>
>> On Sat, 2008-12-06 at 07:48 -0500, Steve Grubb wrote:
>>> Sure and that can be audited. We can also point out that this act takes
>>> the system out of the certified configuration. So, if you need to be in
>>> the CAPP certified configuration, don't let users do this.
>>
>> To be CAPP certified, you can't have a web browser?
>
> Mounting the home directories with noexec should also prevent users from
> doing this.

and /tmp and /dev/shm and /var/tmp and /usr/tmp

:)

-sv



From forum at ru.bir.ru  Sat Dec  6 17:39:46 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sat, 06 Dec 2008 20:39:46 +0300
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228582591.4814.37.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812052029.45500.sgrubb@redhat.com>	<1228542924.4814.33.camel@localhost.localdomain>	<200812060745.37122.sgrubb@redhat.com>
	<1228582591.4814.37.camel@localhost.localdomain>
Message-ID: <ghedd2$qit$1@ger.gmane.org>

Jesse Keating ?????:
> It seems that the cert folks have a different definition of "use" than
> we do.  A normal user should be able to use the binary to get help
> output, and the binary would be useful in path for things like tab
> completion leading up to a sudo call.
If only for this reason very easy modify bash-completion (really 1 
string in .bashrc for mentioned case. Or even may be provided in rpm for 
wide use) then binary to add this logic to it.



From seg at haxxed.com  Sat Dec  6 17:43:25 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 11:43:25 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812052029.45500.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
Message-ID: <1228585406.4683.13.camel@localhost.localdomain>

On Fri, 2008-12-05 at 20:29 -0500, Steve Grubb wrote:
> On Friday 05 December 2008 18:27:01 Callum Lerwick wrote:
> > So, I spent 10 minutes trying to figure out why "userm[tab]" only came
> > up with usermount. usermod had disappeared from my system!
> 
> These should have been gone for quite a while...and on purpose. You cannot do 
> anything with them unless you are root. Allowing anyone even to execute them 
> would require lots of bad things for our LSPP/CAPP evaluations.

Uhhh, Fedora is LSPP/CAPP certified? Or do you really mean RHEL? In
which case, just because RHEL has to do stupid ignorant shit to appease
certification authorities doesn't mean Fedora has to do it too.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/a0922500/attachment.sig>

From sgrubb at redhat.com  Sat Dec  6 17:46:52 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 12:46:52 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228582358.4814.34.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060748.00510.sgrubb@redhat.com>
	<1228582358.4814.34.camel@localhost.localdomain>
Message-ID: <200812061246.55247.sgrubb@redhat.com>

On Saturday 06 December 2008 11:52:38 Jesse Keating wrote:
> On Sat, 2008-12-06 at 07:48 -0500, Steve Grubb wrote:
> > Sure and that can be audited. We can also point out that this act takes
> > the system out of the certified configuration. So, if you need to be in
> > the CAPP certified configuration, don't let users do this.
>
> To be CAPP certified, you can't have a web browser?

Not sure where you are going with this line of questions, but yes there are 
console packages with utilities in the CAPP package set that could be used to 
grab remote files. Curl, elinks, and ftp are a few I spotted during a quick 
look. The admin would need to chmod those to prevent their unauthorized use or 
take some other measure to protect the system to maintain their config.

The bottom line is that we aren't making shadow-utils setuid root so that
--help works.  :)

-Steve



From sgrubb at redhat.com  Sat Dec  6 17:52:26 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 12:52:26 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228582591.4814.37.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228582591.4814.37.camel@localhost.localdomain>
Message-ID: <200812061252.26557.sgrubb@redhat.com>

On Saturday 06 December 2008 11:56:31 Jesse Keating wrote:
>  ordinary user cannot possibly use these tools since they do not have the
>
> > requisite permissions.
>
> Now I'm confused. ?Why would the binary have to be suid?

Because if they didn't type --help, we are going to have to log the attempted 
compromise. Sending an audit event requires CAP_AUDIT_WRITE. You have to be 
setuid root from the beginning or not at all.


> It seems that the cert folks have a different definition of "use" than
> we do. ?A normal user should be able to use the binary to get help
> output, and the binary would be useful in path for things like tab
> completion leading up to a sudo call.

An unprivileged user cannot successfully use this utility. Just like tcpdump 
can't be used. The difference is that shadow-utils modifies a trusted database 
and tcpdump doesn't. 

If you need to see the command options, look at the man page. That's what its 
there for.

-Steve



From sgrubb at redhat.com  Sat Dec  6 17:56:14 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 12:56:14 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228585406.4683.13.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
	<1228585406.4683.13.camel@localhost.localdomain>
Message-ID: <200812061256.14522.sgrubb@redhat.com>

On Saturday 06 December 2008 12:43:25 Callum Lerwick wrote:
> hhh, Fedora is LSPP/CAPP certified?

No but its certifiable. That is our goal.

> Or do you really mean RHEL?

RHEL is many times over.

> In which case, just because RHEL has to do stupid ignorant shit to appease
> certification authorities doesn't mean Fedora has to do it too.

I want Fedora in a certifiable state so that we know everything is working 
correctly.

-Steve



From joe at nall.com  Sat Dec  6 17:58:11 2008
From: joe at nall.com (Joe Nall)
Date: Sat, 6 Dec 2008 11:58:11 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061252.26557.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228582591.4814.37.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
Message-ID: <7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>


On Dec 6, 2008, at 11:52 AM, Steve Grubb wrote:

> On Saturday 06 December 2008 11:56:31 Jesse Keating wrote:
>> ordinary user cannot possibly use these tools since they do not  
>> have the
>>
>>> requisite permissions.
>>
>> Now I'm confused.  Why would the binary have to be suid?
>
> Because if they didn't type --help, we are going to have to log the  
> attempted
> compromise. Sending an audit event requires CAP_AUDIT_WRITE. You  
> have to be
> setuid root from the beginning or not at all.

Can't a non-root user audit now that we have file system capabilities?

joe



From jkeating at redhat.com  Sat Dec  6 17:59:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 06 Dec 2008 09:59:33 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061252.26557.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228582591.4814.37.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
Message-ID: <1228586373.4814.40.camel@localhost.localdomain>

On Sat, 2008-12-06 at 12:52 -0500, Steve Grubb wrote:
> 
> Because if they didn't type --help, we are going to have to log the attempted 
> compromise. Sending an audit event requires CAP_AUDIT_WRITE. You have to be 
> setuid root from the beginning or not at all.

Er, so you have to be root, in order to be audited?  Doesn't that sound
rather um... bad planning?  Doesn't that mean a non-root user can bang
on a binary all day long and never get audited?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/17284c4c/attachment.sig>

From jkeating at redhat.com  Sat Dec  6 18:01:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 06 Dec 2008 10:01:14 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061246.55247.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060748.00510.sgrubb@redhat.com>
	<1228582358.4814.34.camel@localhost.localdomain>
	<200812061246.55247.sgrubb@redhat.com>
Message-ID: <1228586474.4814.42.camel@localhost.localdomain>

On Sat, 2008-12-06 at 12:46 -0500, Steve Grubb wrote:
> Not sure where you are going with this line of questions, but yes there are 
> console packages with utilities in the CAPP package set that could be used to 
> grab remote files. Curl, elinks, and ftp are a few I spotted during a quick 
> look. The admin would need to chmod those to prevent their unauthorized use or 
> take some other measure to protect the system to maintain their config.

What is a CAPP certified system supposed to accomplish?

> 
> The bottom line is that we aren't making shadow-utils setuid root so that
> --help works.  :)

Who's "we"?  Perhaps "we" shouldn't piss on Fedora in order to meet some
cert that I highly highly doubt any Fedora install will find useful.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/bd38f555/attachment.sig>

From sgrubb at redhat.com  Sat Dec  6 18:05:14 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 13:05:14 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
Message-ID: <200812061305.14958.sgrubb@redhat.com>

On Saturday 06 December 2008 12:58:11 Joe Nall wrote:
> > Because if they didn't type --help, we are going to have to log the ?
> > attempted compromise. Sending an audit event requires CAP_AUDIT_WRITE. You
> > have to be setuid root from the beginning or not at all.
>
> Can't a non-root user audit now that we have file system capabilities?

Yes, but so far the only test we tried was soundly rejected by the Fedora 
community. So, I think this is a non-starter. If we couldn't do ping, we 
definitely can't do shadow-utils.

But even if we did use the filesystem capabilities, now you have a program with 
elevated privileges and much more work has to be done to prove that its safe, 
document its internal logic, and test its protection. Any program with file 
system capabilities becomes a target for attack.

And all this work just for --help ?  Seriously.

-Steve



From sgrubb at redhat.com  Sat Dec  6 18:07:13 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 13:07:13 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228586373.4814.40.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<1228586373.4814.40.camel@localhost.localdomain>
Message-ID: <200812061307.13702.sgrubb@redhat.com>

On Saturday 06 December 2008 12:59:33 Jesse Keating wrote:
> Er, so you have to be root, in order to be audited?

No, you have to have CAP_AUDIT_WRITE to send audit events.

> Doesn't that sound rather um... bad planning?

No, its working rather well.

> Doesn't that mean a non-root user can bang on a binary all day long and
> never get audited?

Nope, we took the perms away. Problem solved. :)

-Steve



From seg at haxxed.com  Sat Dec  6 18:02:39 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 12:02:39 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812060745.37122.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
	<1228542924.4814.33.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
Message-ID: <1228586559.4683.30.camel@localhost.localdomain>

On Sat, 2008-12-06 at 07:45 -0500, Steve Grubb wrote:
> On Saturday 06 December 2008 00:55:24 Jesse Keating wrote:
> >  These are required to be this way for our Common Criteria evaluations.
> >
> > Is the thought here that if the code can be executed by a non-root user,
> > the audit of the code would have to be far more strict?
> 
> No, it has more to do with the fact that we have to audit all attempts to 
> modify trusted databases - in this case, shadow. No one can use these tools 
> since they do not have the permissions required to be successful. So, we 
> remove the ability to use these tools so that we don't have to audit it. 

So "cat >> /etc/shadow" is audited?

> IOW, if we open the permissions, we need to make these become setuid root so 
> that we send audit events saying they failed.
> 
> 
> > I'm just curious what added security you really get.
> 
> Its not so much a security thing as much as its a certification thing. An 
> ordinary user cannot possibly use these tools since they do not have the 
> requisite permissions.

Yet "vi /etc/shadow" is okay? Is that audited? Its sounding like the
certification board's idea of "attempting to modify trusted databases"
is far detached from reality.

Unix security happens at the syscall layer and given the focus on the
filesystem, at the filesystem layer. If you're not auditing *every*
attempt to open() /etc/shadow at the syscall layer it sounds to me like
you are doing it wrong.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/1f706b35/attachment.sig>

From skvidal at fedoraproject.org  Sat Dec  6 18:12:28 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sat, 6 Dec 2008 13:12:28 -0500 (EST)
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228586474.4814.42.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060748.00510.sgrubb@redhat.com>
	<1228582358.4814.34.camel@localhost.localdomain>
	<200812061246.55247.sgrubb@redhat.com>
	<1228586474.4814.42.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0812061311350.2777@localhost.localdomain>



On Sat, 6 Dec 2008, Jesse Keating wrote:

>> The bottom line is that we aren't making shadow-utils setuid root so that
>> --help works.  :)
>
> Who's "we"?  Perhaps "we" shouldn't piss on Fedora in order to meet some
> cert that I highly highly doubt any Fedora install will find useful.


This is an interesting one to me, too.

when did this decision get made?

-sv



From seg at haxxed.com  Sat Dec  6 18:14:37 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 12:14:37 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061252.26557.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228582591.4814.37.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
Message-ID: <1228587277.4683.38.camel@localhost.localdomain>

On Sat, 2008-12-06 at 12:52 -0500, Steve Grubb wrote:
> On Saturday 06 December 2008 11:56:31 Jesse Keating wrote:
> >  ordinary user cannot possibly use these tools since they do not have the
> >
> > > requisite permissions.
> >
> > Now I'm confused.  Why would the binary have to be suid?
> 
> Because if they didn't type --help, we are going to have to log the attempted 
> compromise. Sending an audit event requires CAP_AUDIT_WRITE. You have to be 
> setuid root from the beginning or not at all.

On Sat, 2008-12-06 at 12:02 -0600, Callum Lerwick wrote:
> If you're not auditing *every* attempt to open() /etc/shadow at the
> syscall layer 

... IN THE KERNEL

> it sounds to me like
> you are doing it wrong.

> > It seems that the cert folks have a different definition of "use" than
> > we do.  A normal user should be able to use the binary to get help
> > output, and the binary would be useful in path for things like tab
> > completion leading up to a sudo call.
> 
> An unprivileged user cannot successfully use this utility. Just like tcpdump 
> can't be used. The difference is that shadow-utils modifies a trusted database 
> and tcpdump doesn't. 

They can successfully use it to get the help page. I don't need a whole
man page I just need a short reminder of available flags. And I often
strip man and all documentation off most of my secondary systems to save
on disk space and stop !@#$ing makewhatis from pointlessly chewing CPU
and disk IO for no reason.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/f0ce3dbc/attachment.sig>

From jkeating at redhat.com  Sat Dec  6 18:12:20 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 06 Dec 2008 10:12:20 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061307.13702.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<1228586373.4814.40.camel@localhost.localdomain>
	<200812061307.13702.sgrubb@redhat.com>
Message-ID: <1228587140.4814.43.camel@localhost.localdomain>

On Sat, 2008-12-06 at 13:07 -0500, Steve Grubb wrote:
> Nope, we took the perms away. Problem solved. :)
> 

Er, you took the perms away from the one we ship, but not one that a
user can gather from the network, or copy in from elsewhere.  Surely
you'd want to audit any attempt at these things, not just from root
level users?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/80147dcc/attachment.sig>

From skvidal at fedoraproject.org  Sat Dec  6 18:14:09 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sat, 6 Dec 2008 13:14:09 -0500 (EST)
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061305.14958.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
	<200812061305.14958.sgrubb@redhat.com>
Message-ID: <alpine.LFD.2.00.0812061313160.2777@localhost.localdomain>



On Sat, 6 Dec 2008, Steve Grubb wrote:

> On Saturday 06 December 2008 12:58:11 Joe Nall wrote:
>>> Because if they didn't type --help, we are going to have to log the ?
>>> attempted compromise. Sending an audit event requires CAP_AUDIT_WRITE. You
>>> have to be setuid root from the beginning or not at all.
>>
>> Can't a non-root user audit now that we have file system capabilities?
>
> Yes, but so far the only test we tried was soundly rejected by the Fedora
> community. So, I think this is a non-starter. If we couldn't do ping, we
> definitely can't do shadow-utils.
>
> But even if we did use the filesystem capabilities, now you have a program with
> elevated privileges and much more work has to be done to prove that its safe,
> document its internal logic, and test its protection. Any program with file
> system capabilities becomes a target for attack.
>
> And all this work just for --help ?  Seriously.
>

I think the resistance you're getting is how binaries (to a person running 
as non-root) appear to be vanishing. Things they could do, they suddenly 
cannot. And the justification appears to be a certification that fedora 
has never decided to pursue.

You see the reason for the pushback?

-sv

From sgrubb at redhat.com  Sat Dec  6 18:16:23 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 13:16:23 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228586559.4683.30.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228586559.4683.30.camel@localhost.localdomain>
Message-ID: <200812061316.24055.sgrubb@redhat.com>

On Saturday 06 December 2008 13:02:39 Callum Lerwick wrote:
> > No, it has more to do with the fact that we have to audit all attempts to
> > modify trusted databases - in this case, shadow. No one can use these
> > tools since they do not have the permissions required to be successful.
> > So, we remove the ability to use these tools so that we don't have to
> > audit it.
>
> So "cat >> /etc/shadow" is audited?

Of course.


> > IOW, if we open the permissions, we need to make these become setuid root
> > so that we send audit events saying they failed.
> >
> > > I'm just curious what added security you really get.
> >
> > Its not so much a security thing as much as its a certification thing. An
> > ordinary user cannot possibly use these tools since they do not have the
> > requisite permissions.
>
> Yet "vi /etc/shadow" is okay? Is that audited?

Yep.

> Its sounding like the certification board's idea of "attempting to modify
> trusted databases" is far detached from reality.

No its actually quite good. By the way, we also get yelled at for not having 
Fedora locked down enough at install time. Its a constant tug-of-war between 
loosen it up and tighten it down.


> Unix security happens at the syscall layer and given the focus on the
> filesystem, at the filesystem layer. If you're not auditing *every*
> attempt to open() /etc/shadow at the syscall layer it sounds to me like
> you are doing it wrong.

Nope. We are doing it right or we wouldn't have achieved LSPP.

-Steve



From skvidal at fedoraproject.org  Sat Dec  6 18:19:00 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sat, 6 Dec 2008 13:19:00 -0500 (EST)
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061316.24055.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228586559.4683.30.camel@localhost.localdomain>
	<200812061316.24055.sgrubb@redhat.com>
Message-ID: <alpine.LFD.2.00.0812061318440.2777@localhost.localdomain>



On Sat, 6 Dec 2008, Steve Grubb wrote:
>
>> Its sounding like the certification board's idea of "attempting to modify
>> trusted databases" is far detached from reality.
>
> No its actually quite good. By the way, we also get yelled at for not having
> Fedora locked down enough at install time. Its a constant tug-of-war between
> loosen it up and tighten it down.

Yelled at by whom?


-sv



From sgrubb at redhat.com  Sat Dec  6 18:22:46 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 13:22:46 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <alpine.LFD.2.00.0812061313160.2777@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061305.14958.sgrubb@redhat.com>
	<alpine.LFD.2.00.0812061313160.2777@localhost.localdomain>
Message-ID: <200812061322.46599.sgrubb@redhat.com>

On Saturday 06 December 2008 13:14:09 Seth Vidal wrote:
> I think the resistance you're getting is how binaries (to a person running
> as non-root) appear to be vanishing. Things they could do, they suddenly
> cannot.

Its been this way since about 2005. This didn't suddenly happen.

-Steve



From sgrubb at redhat.com  Sat Dec  6 18:24:18 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 13:24:18 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <alpine.LFD.2.00.0812061318440.2777@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061316.24055.sgrubb@redhat.com>
	<alpine.LFD.2.00.0812061318440.2777@localhost.localdomain>
Message-ID: <200812061324.18700.sgrubb@redhat.com>

On Saturday 06 December 2008 13:19:00 Seth Vidal wrote:
> > No its actually quite good. By the way, we also get yelled at for not
> > having Fedora locked down enough at install time. Its a constant
> > tug-of-war between loosen it up and tighten it down.
>
> Yelled at by whom?

By people wanting more secure systems.

-Steve



From seg at haxxed.com  Sat Dec  6 18:28:44 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 12:28:44 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228587140.4814.43.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<1228586373.4814.40.camel@localhost.localdomain>
	<200812061307.13702.sgrubb@redhat.com>
	<1228587140.4814.43.camel@localhost.localdomain>
Message-ID: <1228588125.4683.50.camel@localhost.localdomain>

On Sat, 2008-12-06 at 10:12 -0800, Jesse Keating wrote:
> On Sat, 2008-12-06 at 13:07 -0500, Steve Grubb wrote:
> > Nope, we took the perms away. Problem solved. :)
> > 
> 
> Er, you took the perms away from the one we ship, but not one that a
> user can gather from the network, or copy in from elsewhere.  Surely
> you'd want to audit any attempt at these things, not just from root
> level users?

Furthermore, we're supposedly gaining security by preventing
*unprivileged* user accounts from executing usermod, yet an ACTUAL
compromised scenario, like oh say breaking into root with a privilege
escalation vulnerability and modifying passwd and shadow directly with
kernel syscalls, goes unaudited?

Am I the only one who thinks this security model is mindbogglingly
broken and nothing more than security masturbation?

If you're not auditing at a lower level than executing /bin/usermod, you
are DOING IT WRONG period.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/0709431f/attachment.sig>

From jkeating at redhat.com  Sat Dec  6 18:29:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 06 Dec 2008 10:29:35 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061324.18700.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061316.24055.sgrubb@redhat.com>
	<alpine.LFD.2.00.0812061318440.2777@localhost.localdomain>
	<200812061324.18700.sgrubb@redhat.com>
Message-ID: <1228588175.4814.53.camel@localhost.localdomain>

On Sat, 2008-12-06 at 13:24 -0500, Steve Grubb wrote:
> On Saturday 06 December 2008 13:19:00 Seth Vidal wrote:
> > > No its actually quite good. By the way, we also get yelled at for not
> > > having Fedora locked down enough at install time. Its a constant
> > > tug-of-war between loosen it up and tighten it down.
> >
> > Yelled at by whom?
> 
> By people wanting more secure systems.
> 
> -Steve

Where is this yelling going on?  Where are the bug reports?  Where is
the public discussion about supposed problems in our install processes?
Where is the discussion with domain knowledge experts debating whether
or not the complaint has merit?  Where is the open and frank discussion?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/ef7fa2e0/attachment.sig>

From sgrubb at redhat.com  Sat Dec  6 18:35:26 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 13:35:26 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228588125.4683.50.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228587140.4814.43.camel@localhost.localdomain>
	<1228588125.4683.50.camel@localhost.localdomain>
Message-ID: <200812061335.26488.sgrubb@redhat.com>

On Saturday 06 December 2008 13:28:44 Callum Lerwick wrote:
> Furthermore, we're supposedly gaining security by preventing
> *unprivileged* user accounts from executing usermod, yet an ACTUAL
> compromised scenario, like oh say breaking into root with a privilege
> escalation vulnerability and modifying passwd and shadow directly with
> kernel syscalls, goes unaudited?

No one ever said that.


> Am I the only one who thinks this security model is mindbogglingly
> broken and nothing more than security masturbation?

I think you aren't looking at all the pieces to see how it fits together.


> If you're not auditing at a lower level than executing /bin/usermod, you
> are DOING IT WRONG period.

That is being audited at a lower level, too.

-Steve



From seg at haxxed.com  Sat Dec  6 18:36:50 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 12:36:50 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061316.24055.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228586559.4683.30.camel@localhost.localdomain>
	<200812061316.24055.sgrubb@redhat.com>
Message-ID: <1228588610.4683.57.camel@localhost.localdomain>

On Sat, 2008-12-06 at 13:16 -0500, Steve Grubb wrote:
> On Saturday 06 December 2008 13:02:39 Callum Lerwick wrote:
> > > No, it has more to do with the fact that we have to audit all attempts to
> > > modify trusted databases - in this case, shadow. No one can use these
> > > tools since they do not have the permissions required to be successful.
> > > So, we remove the ability to use these tools so that we don't have to
> > > audit it.
> >
> > So "cat >> /etc/shadow" is audited?
> 
> Of course.

So we *are* auditing low level filesystem calls? So then what, other
than security theater, does auditing execution of usermod gain us?

> > > IOW, if we open the permissions, we need to make these become setuid root
> > > so that we send audit events saying they failed.
> > >
> > > > I'm just curious what added security you really get.
> > >
> > > Its not so much a security thing as much as its a certification thing. An
> > > ordinary user cannot possibly use these tools since they do not have the
> > > requisite permissions.
> >
> > Yet "vi /etc/shadow" is okay? Is that audited?
> 
> Yep.
> 
> > Its sounding like the certification board's idea of "attempting to modify
> > trusted databases" is far detached from reality.
> 
> No its actually quite good. By the way, we also get yelled at for not having 
> Fedora locked down enough at install time. Its a constant tug-of-war between 
> loosen it up and tighten it down.

If you consider "no internet" quite good. That may work for NSA spooks
but I'm going to go out on a limb and say it has absolutely no value for
the vast, vast majority of Fedora users.

> > Unix security happens at the syscall layer and given the focus on the
> > filesystem, at the filesystem layer. If you're not auditing *every*
> > attempt to open() /etc/shadow at the syscall layer it sounds to me like
> > you are doing it wrong.
> 
> Nope. We are doing it right or we wouldn't have achieved LSPP.

I would note that my "doing it wrong" is then ultimately directed at the
LSPP. Rightly following a wrong authority doesn't make things right
unless you're a suit with checkboxes to tick.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/48bcf984/attachment.sig>

From seg at haxxed.com  Sat Dec  6 18:52:48 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 12:52:48 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061322.46599.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061305.14958.sgrubb@redhat.com>
	<alpine.LFD.2.00.0812061313160.2777@localhost.localdomain>
	<200812061322.46599.sgrubb@redhat.com>
Message-ID: <1228589568.4683.73.camel@localhost.localdomain>

On Sat, 2008-12-06 at 13:22 -0500, Steve Grubb wrote:
> On Saturday 06 December 2008 13:14:09 Seth Vidal wrote:
> > I think the resistance you're getting is how binaries (to a person running
> > as non-root) appear to be vanishing. Things they could do, they suddenly
> > cannot.
> 
> Its been this way since about 2005. This didn't suddenly happen.

I've been using RHL/Fedora since 1999, and before that Slackware
starting in 1997. So that depends on what your definition of "suddenly"
is... ;)

I also may be thinking of my *Debian* server, which to this day does not
suffer from this braindeadness:

$ ls -l /sbin/ /usr/sbin/|grep \\---

$ ls -l /usr/sbin/usermod 
-rwxr-xr-x 1 root root 60160 2007-02-27 01:53 /usr/sbin/usermod
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/51612b76/attachment.sig>

From jspaleta at gmail.com  Sat Dec  6 18:57:13 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 6 Dec 2008 09:57:13 -0900
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061335.26488.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228587140.4814.43.camel@localhost.localdomain>
	<1228588125.4683.50.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
Message-ID: <604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>

On Sat, Dec 6, 2008 at 9:35 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> I think you aren't looking at all the pieces to see how it fits together.

Okay... what are all the pieces and how do they fit together?  Has
this ever been explained to the Fedora base? It it was I missed it.


-jef



From seg at haxxed.com  Sat Dec  6 19:05:19 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 13:05:19 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061305.14958.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
	<200812061305.14958.sgrubb@redhat.com>
Message-ID: <1228590320.4683.78.camel@localhost.localdomain>

On Sat, 2008-12-06 at 13:05 -0500, Steve Grubb wrote:
> But even if we did use the filesystem capabilities, now you have a program with 
> elevated privileges and much more work has to be done to prove that its safe, 
> document its internal logic, and test its protection. Any program with file 
> system capabilities becomes a target for attack.
> 
> And all this work just for --help ?  Seriously.

Which is why we don't do all this work, because it is indeed stupid and
pointless, and we just chmod 755 /usr/sbin/user* and be done with it.
Relying purely on userspace to enforce security is fundamentally broken.
Face it, Fedora is never going to be certified. Why then would people
pay for RHEL. ;D
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/3c523341/attachment.sig>

From walters at verbum.org  Sat Dec  6 19:08:37 2008
From: walters at verbum.org (Colin Walters)
Date: Sat, 6 Dec 2008 14:08:37 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228590320.4683.78.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
	<200812061305.14958.sgrubb@redhat.com>
	<1228590320.4683.78.camel@localhost.localdomain>
Message-ID: <faa16b610812061108t1bdbb5c6od404157b6cbd35e3@mail.gmail.com>

A not too difficult compromise would be a bash completion plugin which
knows when the command starts with "sudo" to complete these kinds of
binaries.

One could also argue that since sudo isn't the default, it can't have
a strong influence on how the OS works.  (I do personally wish sudo
*was* the default though)



From seg at haxxed.com  Sat Dec  6 19:14:33 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 13:14:33 -0600
Subject: cpufreq module on x86_64
In-Reply-To: <ghc7il$op2$2@ger.gmane.org>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
	<ghc3vh$bjc$1@ger.gmane.org>
	<1228512934.4755.4442.camel@localhost.localdomain>
	<ghc7il$op2$2@ger.gmane.org>
Message-ID: <1228590873.4683.81.camel@localhost.localdomain>

On Fri, 2008-12-05 at 15:48 -0600, Matthew Woehlke wrote:
> Callum Lerwick wrote:
> > Also note that power usage directly manifests in heat output. The amount
> > of heat spewed into the room by a high performance desktop system is
> > very much a concern on a hot humid summer day in a trailer house with no
> > air conditioning, sitting in your underwear with sweat dripping down
> > your face just trying to catch up on fedora-devel...
> > 
> > However it may be desirable in the winter. :)
> 
> There's always folding at home (or whatever distributed computing project 
> you prefer) if you need the extra heat ;-).

Which I do indeed run. I have it set so nice processes don't up the
frequency, which provides some balance between curing cancer and cooking
myself in the summer. :)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/baf66c62/attachment.sig>

From seg at haxxed.com  Sat Dec  6 19:24:49 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 13:24:49 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <faa16b610812061108t1bdbb5c6od404157b6cbd35e3@mail.gmail.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
	<200812061305.14958.sgrubb@redhat.com>
	<1228590320.4683.78.camel@localhost.localdomain>
	<faa16b610812061108t1bdbb5c6od404157b6cbd35e3@mail.gmail.com>
Message-ID: <1228591489.4683.89.camel@localhost.localdomain>

On Sat, 2008-12-06 at 14:08 -0500, Colin Walters wrote:
> A not too difficult compromise would be a bash completion plugin which
> knows when the command starts with "sudo" to complete these kinds of
> binaries.

Well the point is I want to execute these commands *without* sudo.

> One could also argue that since sudo isn't the default, it can't have
> a strong influence on how the OS works.  (I do personally wish sudo
> *was* the default though)

There was an argument about this a while back. One side argues that sudo
provides no additional security thus should not be default, the other
side (well, me at least) argues that sudo adds convenience and helps
reduce foot-shooting. Which is why I'm in the habit of running admin
commands to get the help page as non-root. My foot has some ugly
scars... :)

I'm inclined to agree sudo doesn't necessarily add security. But sudo is
*in* the distro, and it's clear a lot of people use it. Just because
it's not default does not mean its usage does not deserve consideration.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/0c7abab9/attachment.sig>

From jspaleta at gmail.com  Sat Dec  6 19:29:18 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 6 Dec 2008 10:29:18 -0900
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228590320.4683.78.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
	<200812061305.14958.sgrubb@redhat.com>
	<1228590320.4683.78.camel@localhost.localdomain>
Message-ID: <604aa7910812061129qebaec9ep329e722e1ffdfac4@mail.gmail.com>

2008/12/6 Callum Lerwick <seg at haxxed.com>:
> Which is why we don't do all this work, because it is indeed stupid and
> pointless, and we just chmod 755 /usr/sbin/user* and be done with it.
> Relying purely on userspace to enforce security is fundamentally broken.
> Face it, Fedora is never going to be certified. Why then would people
> pay for RHEL. ;D


But other fedora derived spins may.  Is there need for certified
'appliance' situations that a new 3rd party could leverage Fedora to
create?  I can imagine all sorts of no network software appliance
situations where the CAPP certification applies and a Fedora derived
image would be a good development target.

CAPP certiafiability is just another desired feature which may or may
not be compatible with other desired features. The question for me is,
can CAPP certification it be implemented in a modular fashion or does
it have to be integrated by impacting traditional defaults.

I think CAPP certification, as I understand it, is a poor fit for the
security needs of our default Fedora offerings, where we expect an
active network.  That could be part of the problem. CAPP certification
certainly feels like the wrong capability to try to target in our
default usage case. Our default usage scenario for the supported spins
is simply not the usage that CAPP tries to handle.  But it could be
very useful for a new spin concept which targets exactly the usage
case the CAPP speak to.

-jef



From jspaleta at gmail.com  Sat Dec  6 19:31:22 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 6 Dec 2008 10:31:22 -0900
Subject: The looming Python 3(000) monster
In-Reply-To: <1228555748.4211.2.camel@hughsie-work.lan>
References: <49393DE3.1080707@redhat.com> <49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
	<1228555748.4211.2.camel@hughsie-work.lan>
Message-ID: <604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>

On Sat, Dec 6, 2008 at 12:29 AM, Richard Hughes <hughsient at gmail.com> wrote:
> If you /sbin/shutdown as root, or suffer a power failure without a UPS,
> then all bets are off :-)


Can you prevent a transaction from starting if its a laptop on battery
power and the battery is expected to be "too low" for the transaction
to complete?

-jef



From jkeating at redhat.com  Sat Dec  6 19:36:40 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 06 Dec 2008 11:36:40 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>
References: <49393DE3.1080707@redhat.com> <49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
	<1228555748.4211.2.camel@hughsie-work.lan>
	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>
Message-ID: <1228592200.3417.7.camel@localhost.localdomain>

On Sat, 2008-12-06 at 10:31 -0900, Jeff Spaleta wrote:
> 
> 
> Can you prevent a transaction from starting if its a laptop on battery
> power and the battery is expected to be "too low" for the transaction
> to complete?

Well in that case, when the battery gets too low, you suspend.  Upon
resume, the transaction will finish.  (I've had this happen once)

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/e862b82e/attachment.sig>

From dominik at greysector.net  Sat Dec  6 19:53:09 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 6 Dec 2008 20:53:09 +0100
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <alpine.LFD.2.00.0812061311350.2777@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060748.00510.sgrubb@redhat.com>
	<1228582358.4814.34.camel@localhost.localdomain>
	<200812061246.55247.sgrubb@redhat.com>
	<1228586474.4814.42.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812061311350.2777@localhost.localdomain>
Message-ID: <20081206195309.GB20740@mokona.greysector.net>

On Saturday, 06 December 2008 at 19:12, Seth Vidal wrote:
> 
> 
> On Sat, 6 Dec 2008, Jesse Keating wrote:
> 
> >>The bottom line is that we aren't making shadow-utils setuid root so that
> >>--help works.  :)
> >
> >Who's "we"?  Perhaps "we" shouldn't piss on Fedora in order to meet some
> >cert that I highly highly doubt any Fedora install will find useful.
> 
> 
> This is an interesting one to me, too.
> 
> when did this decision get made?

And more importantly, by whom?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From seg at haxxed.com  Sat Dec  6 20:01:18 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 06 Dec 2008 14:01:18 -0600
Subject: ATTN shadow-utils maintainer (Was Re: More PATH fallout. Who
 decided this was a good idea?)
In-Reply-To: <604aa7910812061129qebaec9ep329e722e1ffdfac4@mail.gmail.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
	<200812061305.14958.sgrubb@redhat.com>
	<1228590320.4683.78.camel@localhost.localdomain>
	<604aa7910812061129qebaec9ep329e722e1ffdfac4@mail.gmail.com>
Message-ID: <1228593678.4683.109.camel@localhost.localdomain>

On Sat, 2008-12-06 at 10:29 -0900, Jeff Spaleta wrote:
> I think CAPP certification, as I understand it, is a poor fit for the
> security needs of our default Fedora offerings, where we expect an
> active network.  That could be part of the problem. CAPP certification
> certainly feels like the wrong capability to try to target in our
> default usage case. Our default usage scenario for the supported spins
> is simply not the usage that CAPP tries to handle.  But it could be
> very useful for a new spin concept which targets exactly the usage
> case the CAPP speak to.

So I guess this is what all this really comes down to: Do we care about
certification? 

Hey, Steve Grubb, are you the shadow-utils maintainer? Whoever the
shadow-utils maintainer(s) is/are, do you want to agree to put this up
to a FESCo vote? If FESCo says yes to certification, things stay as is.
If no, shadow-utils gets set 755 like every other binary on the system.

Your other option is to stand your ground as is your maintainer
privilege. :P
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/b2b858f9/attachment.sig>

From mitr at volny.cz  Sat Dec  6 20:11:20 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Sat, 06 Dec 2008 20:11:20 +0000
Subject: ATTN shadow-utils maintainer (Was Re: More PATH fallout. Who
 decided this was a good idea?)
In-Reply-To: <1228593678.4683.109.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>
	<200812061305.14958.sgrubb@redhat.com>
	<1228590320.4683.78.camel@localhost.localdomain>
	<604aa7910812061129qebaec9ep329e722e1ffdfac4@mail.gmail.com>
	<1228593678.4683.109.camel@localhost.localdomain>
Message-ID: <1228594280.3334.26.camel@localhost.localdomain>

Callum Lerwick p??e v So 06. 12. 2008 v 14:01 -0600:
> Hey, Steve Grubb, are you the shadow-utils maintainer? Whoever the
> shadow-utils maintainer(s) is/are
Peter is away and will be away for roughly one more week.
	Mirek



From vonbrand at inf.utfsm.cl  Sat Dec  6 20:28:29 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sat, 06 Dec 2008 17:28:29 -0300
Subject: Python 2.6 now in Rawhide; breakage to follow
In-Reply-To: <1228435411.29612.142.camel@ignacio.lan>
References: <1228435411.29612.142.camel@ignacio.lan>
Message-ID: <200812062028.mB6KSTjj006655@laptop14.inf.utfsm.cl>

Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> wrote:
> Python 2.6 is now in Rawhide and ready to be battle-tested. Tools up to
> yum and system-config-* work, with some DeprecationWarnings;
> higher-level tools are still being worked on.

I have dozens of packages that can't be upgraded (including yum and rpm)
now. Any (simple) way to find out what the offending packages are?
-- 
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 sgrubb at redhat.com  Sat Dec  6 20:38:22 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 6 Dec 2008 15:38:22 -0500
Subject: ATTN shadow-utils maintainer (Was Re: More PATH fallout. Who
	decided this was a good idea?)
In-Reply-To: <1228593678.4683.109.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<604aa7910812061129qebaec9ep329e722e1ffdfac4@mail.gmail.com>
	<1228593678.4683.109.camel@localhost.localdomain>
Message-ID: <200812061538.22592.sgrubb@redhat.com>

On Saturday 06 December 2008 15:01:18 Callum Lerwick wrote:
> On Sat, 2008-12-06 at 10:29 -0900, Jeff Spaleta wrote:
> > I think CAPP certification, as I understand it, is a poor fit for the
> > security needs of our default Fedora offerings, where we expect an
> > active network.  That could be part of the problem. CAPP certification
> > certainly feels like the wrong capability to try to target in our
> > default usage case. Our default usage scenario for the supported spins
> > is simply not the usage that CAPP tries to handle.  But it could be
> > very useful for a new spin concept which targets exactly the usage
> > case the CAPP speak to.
>
> So I guess this is what all this really comes down to: Do we care about
> certification?

I think the answer is yes. A lot of work goes into analyzing the software. The 
fact that you have a man page for each syscall is a product of our 
certification work. As of fedora 7 you had man pages for each syscall. Since 
then we have not had to do work aimed at a CAPP cert and guess what? You once 
again have syscalls without man pages.

We go over all the code that makes any kind of decision related to access 
control, trusted databases, and crypto. We file and fix many bugs. Test suites 
are created out of this effort and the whole community has access to them. This 
work is done by a team of people in and outside of Red Hat with a like-minded 
goal of giving Linux the ability to be certified. As a result, Fedora is the 
ONLY community distribution that actually meets certification requirements. 
OpenSuse might be close for CAPP, but not LSPP/RSBAC, but that would be the 
only one I can think of that might be getting close.

Do you like the way that IPv6 works in Fedora? That was done by working on a 
certification. Do you like crypto that works? We are currently doing that 
certification. Would you like to see virtualization with strong guarantees of 
vm separation...guess what?...another certification effort. These are what 
enable Linux to be used confidently knowing that it will interoperate or follow 
industry guidelines.


> Hey, Steve Grubb, are you the shadow-utils maintainer?

No, but he's on my team. 


> Whoever the shadow-utils maintainer(s) is/are, do you want to agree to put
> this up to a FESCo vote?

That depends on what we are voting on.

-Steve



From lesmikesell at gmail.com  Sat Dec  6 20:59:03 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 06 Dec 2008 14:59:03 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228591489.4683.89.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812061252.26557.sgrubb@redhat.com>	<7C4527D9-B5BA-4307-881D-DC0262087E8B@nall.com>	<200812061305.14958.sgrubb@redhat.com>	<1228590320.4683.78.camel@localhost.localdomain>	<faa16b610812061108t1bdbb5c6od404157b6cbd35e3@mail.gmail.com>
	<1228591489.4683.89.camel@localhost.localdomain>
Message-ID: <493AE797.5080807@gmail.com>

Callum Lerwick wrote:
> On Sat, 2008-12-06 at 14:08 -0500, Colin Walters wrote:
>> A not too difficult compromise would be a bash completion plugin which
>> knows when the command starts with "sudo" to complete these kinds of
>> binaries.
> 
> Well the point is I want to execute these commands *without* sudo.
> 
>> One could also argue that since sudo isn't the default, it can't have
>> a strong influence on how the OS works.  (I do personally wish sudo
>> *was* the default though)
> 
> There was an argument about this a while back. One side argues that sudo
> provides no additional security thus should not be default, the other
> side (well, me at least) argues that sudo adds convenience and helps
> reduce foot-shooting. Which is why I'm in the habit of running admin
> commands to get the help page as non-root. My foot has some ugly
> scars... :)

Basically, if you don't like sudo in a distro that tries to force it on 
you, you'll end up doing 'sudo su -'in a few windows and keeping them 
open so you don't have to do it all the time.

> I'm inclined to agree sudo doesn't necessarily add security. But sudo is
> *in* the distro, and it's clear a lot of people use it. Just because
> it's not default does not mean its usage does not deserve consideration.

Sudo can be sort-of handy to hide behind launchers for people who don't 
use the command line, but then the issue of path is mostly irrelevant.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From darrellpf at gmail.com  Sat Dec  6 21:05:38 2008
From: darrellpf at gmail.com (darrell pfeifer)
Date: Sat, 6 Dec 2008 13:05:38 -0800
Subject: Python 2.6 now in Rawhide; breakage to follow
In-Reply-To: <200812062028.mB6KSTjj006655@laptop14.inf.utfsm.cl>
References: <1228435411.29612.142.camel@ignacio.lan>
	<200812062028.mB6KSTjj006655@laptop14.inf.utfsm.cl>
Message-ID: <f6e5806f0812061305w7761f8c5u4692be6be917327b@mail.gmail.com>

On Sat, Dec 6, 2008 at 12:28, Horst H. von Brand <vonbrand at inf.utfsm.cl>wrote:

> Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> wrote:
> > Python 2.6 is now in Rawhide and ready to be battle-tested. Tools up to
> > yum and system-config-* work, with some DeprecationWarnings;
> > higher-level tools are still being worked on.
>
> I have dozens of packages that can't be upgraded (including yum and rpm)
> now. Any (simple) way to find out what the offending packages are?
>

If you're running yum upgrade by hand you can look at the yum output. Right
after it has gotten all the packages it runs the dependency checking.

Usually the packages that yum mentions again at the tail of the output are
the ones with issues.

In my case, I had to remove system-config-httpd, alchemist, libopensync and
python-turboflot. I don't think the first pair has been updated yet and the
latter didn't seem to be used by anything. You'll probably have different
packages with issues.

After that, I'm running just fine on today's rawhide.

darrell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081206/fde2e817/attachment.htm>

From lesmikesell at gmail.com  Sat Dec  6 21:18:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 06 Dec 2008 15:18:59 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061246.55247.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812060748.00510.sgrubb@redhat.com>	<1228582358.4814.34.camel@localhost.localdomain>
	<200812061246.55247.sgrubb@redhat.com>
Message-ID: <493AEC43.5030902@gmail.com>

Steve Grubb wrote:
> 
>>> Sure and that can be audited. We can also point out that this act takes
>>> the system out of the certified configuration. So, if you need to be in
>>> the CAPP certified configuration, don't let users do this.
>> To be CAPP certified, you can't have a web browser?
> 
> Not sure where you are going with this line of questions, but yes there are 
> console packages with utilities in the CAPP package set that could be used to 
> grab remote files.

I think the logical implication is that such a system would be 
essentially useless these days.   Do you value the ease of obtaining 
some certification that will rarely/never be used enough to break things 
for the vast majority of users.

 > Curl, elinks, and ftp are a few I spotted during a quick
> look. The admin would need to chmod those to prevent their unauthorized use or 
> take some other measure to protect the system to maintain their config.

Still sounds like a useless system to me.  I could have kept my 
typewriter if I wanted something that couldn't access a network.

> The bottom line is that we aren't making shadow-utils setuid root so that
> --help works.  :)

You lost me there.  What device/file with root-only access would 
shadow-utils need to open to make --help work?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Dec  6 21:29:55 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 06 Dec 2008 15:29:55 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061252.26557.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812060745.37122.sgrubb@redhat.com>	<1228582591.4814.37.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
Message-ID: <493AEED3.7020501@gmail.com>

Steve Grubb wrote:
> On Saturday 06 December 2008 11:56:31 Jesse Keating wrote:
>>  ordinary user cannot possibly use these tools since they do not have the
>>
>>> requisite permissions.
>> Now I'm confused.  Why would the binary have to be suid?
> 
> Because if they didn't type --help, we are going to have to log the attempted 
> compromise. Sending an audit event requires CAP_AUDIT_WRITE. You have to be 
> setuid root from the beginning or not at all.

OK, so log it.  Why do we care?  If someone thinks that typing a program 
name is an attempted compromise they are so far wrong already that 
nothing else you can do will help.

>> It seems that the cert folks have a different definition of "use" than
>> we do.  A normal user should be able to use the binary to get help
>> output, and the binary would be useful in path for things like tab
>> completion leading up to a sudo call.
> 
> An unprivileged user cannot successfully use this utility. Just like tcpdump 
> can't be used. The difference is that shadow-utils modifies a trusted database 
> and tcpdump doesn't. 

It is whether or not you can successfully open the trusted database that 
matters, not whether or not some program attempts the open.  Anyone with 
  access to any program at all that accepts filenames has exactly the 
same access to the shadow file as the shadow-utils program.  That's the 
whole point of a unix-like system: everything is a file and all the 
access control magic has to do with whether or not you can open that file.

> 
> If you need to see the command options, look at the man page. That's what its 
> there for.

How do you deal with ifconfig which has obviously useful information for 
   ordinary users and potentially destructive capability for privileged 
users?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pemboa at gmail.com  Sat Dec  6 21:36:07 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sat, 6 Dec 2008 15:36:07 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <1228592200.3417.7.camel@localhost.localdomain>
References: <49393DE3.1080707@redhat.com> <493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
	<1228555748.4211.2.camel@hughsie-work.lan>
	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>
	<1228592200.3417.7.camel@localhost.localdomain>
Message-ID: <16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>

2008/12/6 Jesse Keating <jkeating at redhat.com>:
> On Sat, 2008-12-06 at 10:31 -0900, Jeff Spaleta wrote:
>>
>>
>> Can you prevent a transaction from starting if its a laptop on battery
>> power and the battery is expected to be "too low" for the transaction
>> to complete?
>
> Well in that case, when the battery gets too low, you suspend.  Upon
> resume, the transaction will finish.  (I've had this happen once)

suspend seems highly flaky, not sure if it is something to depend upon.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From lesmikesell at gmail.com  Sat Dec  6 22:09:10 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 06 Dec 2008 16:09:10 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>	<4939A673.3090907@gmail.com>	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>	<1228555748.4211.2.camel@hughsie-work.lan>	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>	<1228592200.3417.7.camel@localhost.localdomain>
	<16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>
Message-ID: <493AF806.5040804@gmail.com>

Arthur Pemberton wrote:
> 2008/12/6 Jesse Keating <jkeating at redhat.com>:
>> On Sat, 2008-12-06 at 10:31 -0900, Jeff Spaleta wrote:
>>>
>>> Can you prevent a transaction from starting if its a laptop on battery
>>> power and the battery is expected to be "too low" for the transaction
>>> to complete?
>> Well in that case, when the battery gets too low, you suspend.  Upon
>> resume, the transaction will finish.  (I've had this happen once)
> 
> suspend seems highly flaky, not sure if it is something to depend upon.
> 

Not sure it is something you want to copy, but I've had Mac laptops 
refuse to start system updates because the battery was too low - and I 
think even cell phones do that too.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jfm512 at free.fr  Sat Dec  6 22:53:53 2008
From: jfm512 at free.fr (Jean Francois Martinez)
Date: Sat, 06 Dec 2008 23:53:53 +0100
Subject: Scanner's firmware HOWTO and suggestions for improving user's
	experience with scanners
Message-ID: <1228604033.3495.90.camel@agnes.fremen.dune>

Some scanners need a firmawre file who, while it cannot be provided by 
Fedora can be legally downloaded from the manufacturer's site.  The
problem is that Fedora provides zero hints about it.  

I have an EPSON USB scanner (snapscan driver) and if you look at the
sane-backends doc it says _nothing_ about firmware and it points to a
web page who hasn't been updated in _eight_ years.  In other words
official documentation is zero help.

In the following I detail what to do and make a few suggestions for
improving user experience with scanners requiring firmware.

Go to http://avasys.jp/english and  grab the two RPMS proposed.
Their names are respectively iscan and iscan-plugin-something.
Iscan is a nice frontend and is GPL but it requires the non GPL
iscan-plugin who is the one who contains the firmware.  Iscan-plugin's 
licence can be summarized by free to copy and to give but 
not free to disassemble or sell

Don't bother with the source in tgz format since it it doesn't
provide the firmware.

If you are running in 32 bits and you have nothing against having a
non free piece of software in your box then install both RPMS:
if you try to run xsane, this will probe the epson driver first who will
load the  firmware.  With a loaded formware sane's driver will also
work so xsane will ask the user which driver he want to use.
If you Iscan instead that is Epson's GPL frontend, it will ever use
epson's driver, but it is easier to use and offers both higher and lower
resolutions than xsane.


If you are running in 64 bits you can do as above but you will not be
able to run xsane (epson doesn't provide 64 bits version of its
software) only iscan will work (I also strongly recommend you erase
the /etc/sane.d/epkowa.conf otherwise sane will try to load the 32 bit
driver)

In case you re religious about free sowftware or, you are running in 64
bits and prefer to scan from xsane or gimp then:
Install both RPMs mentionned above
mkdir /usr/share/sane/snapscan
Copy the .bin file who is under /usr/share/iscan to /usr/share/snapscan/
Edit the /etc/sane.d/snapscan.conf and change the firmware line so it
points to the file you have just copied
Eventually uninstall both iscan and iscan-plugin rpms

Suggestions:

In completely ideal world fedora would procide the firmware files and
everything would just work but I guess Epson's licensing (copy, give,
don't disassemble, don't sell) is a NO-NO 


If Fedora can't provide the formware then perhaps we could provide that
ewhen sane fails to drive a scanner its error message points to firmware
and towards a file  telling the above.

A less ambitious proposition would be:
-to include the above text in sane's doc
-Modify the /etc/sane.d/snapscan.conf so it points the user to the
file in the preceeding alinea
-the directory /usr/share/sane/snapscan should be part of the xsane
package
-The firmware line in /etc/sane.d/snapscan.conf should not point towards
your-firmware-file.bin in the /etc/share/sane.d/snapcan but towards
snapscan.bin and, when user powers on the scan it would be udev's work
to make a snapcan.bin sumbolic link pointing towards the right firmware
file.

Regards

JF Martinez






From kevin.kofler at chello.at  Sat Dec  6 23:07:09 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 07 Dec 2008 00:07:09 +0100
Subject: The looming Python 3(000) monster
References: <49393DE3.1080707@redhat.com>
	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>	<4939A673.3090907@gmail.com>	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>	<1228555748.4211.2.camel@hughsie-work.lan>	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>	<1228592200.3417.7.camel@localhost.localdomain>
	<16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>
	<493AF806.5040804@gmail.com>
Message-ID: <ghf0it$j5h$1@ger.gmane.org>

Les Mikesell wrote:
> Not sure it is something you want to copy, but I've had Mac laptops
> refuse to start system updates because the battery was too low - and I
> think even cell phones do that too.

PackageKit (at least gnome-packagekit, it might not be implemented yet in
kpackagekit) won't check for updates at all if you're on battery.

        Kevin Kofler



From mdehaan at redhat.com  Sat Dec  6 23:09:08 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Sat, 06 Dec 2008 18:09:08 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <49397B48.5090206@gmail.com>
References: <49393DE3.1080707@redhat.com>
	<493973AF.2030009@gmail.com>	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
	<49397B48.5090206@gmail.com>
Message-ID: <493B0614.6040306@redhat.com>

Toshio Kuratomi wrote:
> Arthur Pemberton wrote:
>   
>> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
>> ensure that all code is compatible with 3. And still have 3 in
>> parallel for those who want it. So we target 2.6+ , but have 3.0 there
>> to ensure everything would work with it, and for early adopters/devs
>>
>>     
> It is an oversimplification but how much is something we need experience
> in order to discover.  2.6 != 3.x even though they are close.  There
> will be a 2.7 and a 3.1 and some of those problems should be addressed
> in those two releases.  Until we actually build experience trying to do
> this, though, we don't know to what extent our work on making things
> work on 2.6 will carry over to 3.x.
>
> Note, the port we've just done to 2.6 is not all that's needed.
> python-2.6 tries to have a 2.x mode and a 3.x mode (some changes are too
> deep to truly have this but it tries).  We'll have to start porting code
> to 2.6 with 3.x features turned on at some point.
>
> Also note, this is a valid plan for Fedora but it doesn't address
> mpdehaan's issue with supporting python <= 2.5 (which I don't think is
> solvable in any elegant manner.)
>
> -Toshio
>
>   
Exactly, it's not solvable in any elegant manner.

The parallel versions provides a solution for upstream, if at any point 
at which we go from 2.X to 3.0 by dropping 2.X will cause us to lose a 
lot of packages -- or lose package updates for EPEL as maintainers stop 
being able to focus on that.   Requiring an EPEL user to upgrade his 
Python to use an app isn't going to happen -- that defeats most of the 
points of stability for EL.  

Source conversation  cannot be mathematically proven and definitely 
cannot be fully automated.  It's a developers tool that results in two 
separately maintained branches.  For many applications this will be way 
too much for developers, and they will continue to maintain one or the 
other -- with differing preferences.  (Upstream's goals aren't always to 
work with a compatible Python version that we have in Fedora -- perhaps 
it's an app who's main audience is EL 5 but also wants to work in 
Fedora).   For this, we really /do/ need the split versions.

I understand why this was shot down in the past.  Then changes were 
minor, now they are intentionally larger.

These have to be treated as two different languages, even if they are 
95% similar.   (Imagine if you will, Python 2.X and 3.X being chimp and 
human, and Perl 5 and Perl 6 perhaps being archeopetryx and more 
modern-day bird) -- they still cannot interbreed.

For those who have implied I haven't know about this, yes, I've known 
about this, I've been writing Python code for at least 5-6 years.   It's 
just an excellent time to talk about it since it was just now 
"released", so that we have a solid plan for now, and if we need to 
start thinking incrementally we can.

I'm not so much trying to spell out doom, but we need to know what we 
are going to do -- and more importantly -- what the impact on our 
package list will be if we do something like drop 2.X.

--Michael



From mdehaan at redhat.com  Sat Dec  6 23:30:57 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Sat, 06 Dec 2008 18:30:57 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <1228504272.26618.191.camel@code.and.org>
References: <49393DE3.1080707@redhat.com>
	<493973AF.2030009@gmail.com>	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>	<1228502748.3386.36.camel@beta>
	<1228504272.26618.191.camel@code.and.org>
Message-ID: <493B0B31.2040605@redhat.com>

James Antill wrote:
> On Fri, 2008-12-05 at 20:45 +0200, Basil Mohamed Gohar wrote:
>
>   
>> It would be very hard to write 2.6 code that is completely compatible
>> with 3.0, because 3.0 has changed many fundamental language constructs,
>> including even the "print" statement, which in 3.0 is a function (syntax
>> change).
>>
>> I am not sure how far the from __future__ import feature will work for
>> such changes as that.
>>     
>
>  Sigh...
>
> from __future__ import print_function
>
> ...can everyone who isn't involved in writing python code, and/or not
> read about 2.6 / 3.0 before this thread please not comment?
>   

Not defined in older versions of python however, hence the need to 
branch code, hence a problem with EPEL supporting code.

--Michael
>
>  As Toshio Kuratomi said extremely well, in the grand parent to this
> post:
>
>         Note that I think this decision is only partially within the
>         powers of the Fedora Project to decide.  If 80% of our upstream
>         libraries move to py3, we'll need to move to py3 sooner.  If 80%
>         refuse to move off of py2, we can take our time working on
>         migration code.
>
> ...so as I said, we don't have concrete plans yet ... and some of that
> is because it depends on available resources within the project, but a
> lot of that is because we have to follow upstream and it's not obvious
> how fast (the majority of) python developers upstream will move.
>
>   



From cmadams at hiwaay.net  Sun Dec  7 01:57:34 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 6 Dec 2008 19:57:34 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <alpine.LFD.2.00.0812061238130.2777@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228542924.4814.33.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812060105030.2777@localhost.localdomain>
	<200812060748.00510.sgrubb@redhat.com>
	<1228582358.4814.34.camel@localhost.localdomain>
	<ghed5a$snb$2@ger.gmane.org>
	<alpine.LFD.2.00.0812061238130.2777@localhost.localdomain>
Message-ID: <20081207015734.GB569180@hiwaay.net>

Once upon a time, Seth Vidal <skvidal at fedoraproject.org> said:
> On Sat, 6 Dec 2008, Kevin Kofler wrote:
> >Mounting the home directories with noexec should also prevent users from
> >doing this.
> 
> and /tmp and /dev/shm and /var/tmp and /usr/tmp

Don't forget "yum remove python perl" (noexec doesn't stop scripts).
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From cmadams at hiwaay.net  Sun Dec  7 01:59:44 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 6 Dec 2008 19:59:44 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812060745.37122.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
	<1228542924.4814.33.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
Message-ID: <20081207015944.GC569180@hiwaay.net>

Once upon a time, Steve Grubb <sgrubb at redhat.com> said:
> On Saturday 06 December 2008 00:55:24 Jesse Keating wrote:
> >  These are required to be this way for our Common Criteria evaluations.
> >
> > Is the thought here that if the code can be executed by a non-root user,
> > the audit of the code would have to be far more strict?
> 
> No, it has more to do with the fact that we have to audit all attempts to 
> modify trusted databases - in this case, shadow. No one can use these tools 
> since they do not have the permissions required to be successful. So, we 
> remove the ability to use these tools so that we don't have to audit it. 
> 
> IOW, if we open the permissions, we need to make these become setuid root so 
> that we send audit events saying they failed.

Then later, Steve Grubb <sgrubb at redhat.com> said:
> > So "cat >> /etc/shadow" is audited?
>
> Of course.

So cat will have to be setuid root so it can audit?  What about echo,
bash, perl, etc.?

This is absurd.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From ewan at macmahon.me.uk  Sun Dec  7 02:53:21 2008
From: ewan at macmahon.me.uk (Ewan Mac Mahon)
Date: Sun, 7 Dec 2008 02:53:21 +0000
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061335.26488.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228587140.4814.43.camel@localhost.localdomain>
	<1228588125.4683.50.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
Message-ID: <20081207025320.GS19269@macmahon.me.uk>

On Sat, Dec 06, 2008 at 01:35:26PM -0500, Steve Grubb wrote:
> On Saturday 06 December 2008 13:28:44 Callum Lerwick wrote:
> 
> > If you're not auditing at a lower level than executing /bin/usermod, you
> > are DOING IT WRONG period.
> 
> That is being audited at a lower level, too.
>
So why would you need to worry about usermod et al having the ability to
log audit messages about their use, when any 'real' use of them (as in,
anything that actually tried to touch the databases) would presumably be
logged by the same lower levels that would catch someone using another
tool?

Ewan



From james at fedoraproject.org  Sun Dec  7 06:57:50 2008
From: james at fedoraproject.org (James Antill)
Date: Sun, 07 Dec 2008 01:57:50 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <1228555748.4211.2.camel@hughsie-work.lan>
References: <49393DE3.1080707@redhat.com> <49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
	<1228555748.4211.2.camel@hughsie-work.lan>
Message-ID: <1228633070.26618.236.camel@code.and.org>

On Sat, 2008-12-06 at 09:29 +0000, Richard Hughes wrote:
> On Fri, 2008-12-05 at 14:07 -0900, Jeff Spaleta wrote:
> > Do not let rpm transactions fail in the middle. Do not forcibly
> > terminate them...do not cut power to the system...hold your breath and
> > walk away from the console.
> 
> This was one of the problems PackageKit tries to solve.

 In it's usual way, of ignoring the real (but harder to solve) problems
and concentrating on a couple of very simple desktop cases and
implementing the most complicated solution possible ... and then
declaring the problem fixed, after minimal testing.

>  You can start an
> install and do ctrl-alt-backspace and then re-login, and the transaction
> is still running in the background.

 rpm eats SIGHUP when in a transaction, so yum/rpm should do this too.
However rpm had a "feature" where it would abort if the stdout yum was
using went away, which was ... unexpected.
 rpm in Fedora 10 fixed that (not sure which older releases), and
yum-3.2.20+ tries to work around it.

>  It also stops you shutting down
> using a system and session inhibit if the transaction is an a
> non-cancellable state.

 Which isn't really helpful, esp. as the messages I've seen say
something like "Some program is stopping you from doing this" ... pretty
much guaranteeing the next words out of the users mouth will be "die
when I tell you too, scum sucking laptop, die; die; die!".

> If you /sbin/shutdown as root, or suffer a power failure without a UPS,
> then all bets are off :-)

 Or press the power button, or rpm gets OOMed, etc. etc.
 Which is to say it works about as well as yum itself.

-- 
James Antill <james at fedoraproject.org>
Fedora



From james at fedoraproject.org  Sun Dec  7 07:08:34 2008
From: james at fedoraproject.org (James Antill)
Date: Sun, 07 Dec 2008 02:08:34 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <493B0B31.2040605@redhat.com>
References: <49393DE3.1080707@redhat.com> <493973AF.2030009@gmail.com>
	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>
	<1228502748.3386.36.camel@beta>
	<1228504272.26618.191.camel@code.and.org>
	<493B0B31.2040605@redhat.com>
Message-ID: <1228633714.26618.248.camel@code.and.org>

On Sat, 2008-12-06 at 18:30 -0500, Michael DeHaan wrote:

> Not defined in older versions of python however, hence the need to 
> branch code, hence a problem with EPEL supporting code.

 True, 2.5.x and earlier won't be compatible. Which means that
RHEL-5/CentOS-5 python won't be compatible with any code that uses this
feature of py3k and/or 2.6.x (via. the from future import).

 This is _far_ from unprecedented though, lack of decorators and/or
yield alone makes the python in RHEL-4/CentOS-4 incompatible for any
modern development. And I've had to upgrade boxes because of this, and
told a lot of people "Yeh, any recent yum just isn't going to work
there ... sucks".
 This wasn't the end of the world then, and didn't mean we wanted/needed
to hold python back in Fedora. I don't see anything materially different
now.

-- 
James Antill <james at fedoraproject.org>
Fedora



From hughsient at gmail.com  Sun Dec  7 08:55:38 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 07 Dec 2008 08:55:38 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <1228633070.26618.236.camel@code.and.org>
References: <49393DE3.1080707@redhat.com> <49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
	<1228555748.4211.2.camel@hughsie-work.lan>
	<1228633070.26618.236.camel@code.and.org>
Message-ID: <1228640138.4266.20.camel@hughsie-work.lan>

On Sun, 2008-12-07 at 01:57 -0500, James Antill wrote:
> > This was one of the problems PackageKit tries to solve.
> 
>  In it's usual way, of ignoring the real (but harder to solve) problems
> and concentrating on a couple of very simple desktop cases and
> implementing the most complicated solution possible ... and then
> declaring the problem fixed, after minimal testing.

Excuse me? Could you care to explain please?

> >  It also stops you shutting down
> > using a system and session inhibit if the transaction is an a
> > non-cancellable state.
> 
>  Which isn't really helpful, esp. as the messages I've seen say
> something like "Some program is stopping you from doing this" ... pretty
> much guaranteeing the next words out of the users mouth will be "die
> when I tell you too, scum sucking laptop, die; die; die!".

Right, and the sort of unstable user to say to their laptop "scum
sucking laptop, die; die; die!" probably deserves to rebuild their rpmdb
on next reboot.

> > If you /sbin/shutdown as root, or suffer a power failure without a UPS,
> > then all bets are off :-)
> 
>  Or press the power button

Power button goes through HAL, so we catch this too.

> or rpm gets OOMed, etc. etc.

If you get OOMed, all bets are off. But if you're in OOM, you've got
bigger problems on your plate.

Richard.




From nicolas.mailhot at laposte.net  Sun Dec  7 09:50:19 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 07 Dec 2008 10:50:19 +0100
Subject: The looming Python 3(000) monster
In-Reply-To: <1228640138.4266.20.camel@hughsie-work.lan>
References: <49393DE3.1080707@redhat.com> <49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
	<1228555748.4211.2.camel@hughsie-work.lan>
	<1228633070.26618.236.camel@code.and.org>
	<1228640138.4266.20.camel@hughsie-work.lan>
Message-ID: <1228643419.28999.4.camel@arekh.okg>

Le dimanche 07 d?cembre 2008 ? 08:55 +0000, Richard Hughes a ?crit :

> >  Which isn't really helpful, esp. as the messages I've seen say
> > something like "Some program is stopping you from doing this" ... pretty
> > much guaranteeing the next words out of the users mouth will be "die
> > when I tell you too, scum sucking laptop, die; die; die!".
> 
> Right, and the sort of unstable user to say to their laptop "scum
> sucking laptop, die; die; die!" probably deserves to rebuild their rpmdb
> on next reboot.

I would be more constructive to tell the user what the blocking program
is (command name, user, PID).

A lot of PK messages suffer from this kind of lack of details which is
not helpful for the user and just makes him want to scream. Please try
to give users *context* instead of vague maddening generic blurbs.

Remember, the user, not PK, is supposed to be in control. No black magic
please.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/82663deb/attachment.sig>

From dwmw2 at infradead.org  Sun Dec  7 11:02:02 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 07 Dec 2008 11:02:02 +0000
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061252.26557.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228582591.4814.37.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
Message-ID: <1228647722.18239.1.camel@macbook.infradead.org>

On Sat, 2008-12-06 at 12:52 -0500, Steve Grubb wrote:
> An unprivileged user cannot successfully use this utility. Just like
> tcpdump can't be used.

That's news to me...

[dwmw2 at macbook ~]$ whoami
dwmw2
[dwmw2 at macbook ~]$ tcpdump -r testsession.cap
reading from file testsession.cap, link-type EN10MB (Ethernet)
17:02:49.885932 IP 192.168.0.101.35750 > vpntest.https: UDP, length 100
17:02:50.617537 IP vpntest.https > 192.168.0.101.35750: UDP, length 28
17:02:50.617638 IP 192.168.0.101.35750 > vpntest.https: UDP, length 100
17:02:51.270518 IP vpntest.https > 192.168.0.101.35750: UDP, length 186
17:02:51.270673 IP 192.168.0.101.35750 > vpntest.https: UDP, length 20

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From nicolas.mailhot at laposte.net  Sun Dec  7 11:18:57 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 07 Dec 2008 12:18:57 +0100
Subject: Classroom session on Fedora fonts packaging
In-Reply-To: <1228582462.2983.5.camel@arekh.okg>
References: <1228582462.2983.5.camel@arekh.okg>
Message-ID: <1228648737.30858.2.camel@arekh.okg>

Le samedi 06 d?cembre 2008 ? 17:54 +0100, Nicolas Mailhot a ?crit :
> Hi all,
> 
> This is a bit impromptu, but as part of the Fedora classroom program,
> I'll animate a session on fonts packaging tomorrow the 7th of December
> at 12:15 UTC in the #fedora-classroom irc.freenode.net IRC channel.
> 
> http://fedoraproject.org/wiki/Communicate/IRC/Classroom
> 
> The actual content of the session is rather fluid and will depend on the
> audience questions.

This is just a reminder the session will start in one hour.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/d53e2aa9/attachment.sig>

From rakesh.pandit at gmail.com  Sun Dec  7 13:30:22 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 7 Dec 2008 19:00:22 +0530
Subject: mayavi - anyone interested in collaborating on packaging?
Message-ID: <b401d2530812070530h787c339exe3ba76aa748ada64@mail.gmail.com>

Hello,

http://code.enthought.com/projects/mayavi/

$subject

I already started working on it. The project is big and has a good
user base. Anyone interested in getting it into fedora and helping in
packaging would be greatly appreciated :). Please drop a mail off list
so that we can coordinate.

It needs Traits and Traits UI [1] to be in and I am about to finish these two.

[1] http://code.enthought.com/projects/traits/

--
Regards,
Rakesh Pandit



From sgrubb at redhat.com  Sun Dec  7 13:36:25 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 7 Dec 2008 08:36:25 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <alpine.LFD.2.00.0812061311350.2777@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228586474.4814.42.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812061311350.2777@localhost.localdomain>
Message-ID: <200812070836.26066.sgrubb@redhat.com>

On Saturday 06 December 2008 13:12:28 Seth Vidal wrote:
> > Who's "we"? ?Perhaps "we" shouldn't piss on Fedora in order to meet some
> > cert that I highly highly doubt any Fedora install will find useful.
>
> This is an interesting one to me, too.
>
> when did this decision get made?

By me after a group presented the options back in 2005. Back in those days 
shadow-utils was in "Core" and that was maintained by Red Hat. Remember, we 
are not talking about something that suddenly changed. We are talking about 
something that was recently noticed. So, this is a holdover from before Fedora 
went into its own data center.

-Steve



From sgrubb at redhat.com  Sun Dec  7 14:54:31 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 7 Dec 2008 09:54:31 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
	<604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
Message-ID: <200812070954.31864.sgrubb@redhat.com>

On Saturday 06 December 2008 13:57:13 Jeff Spaleta wrote:
> > I think you aren't looking at all the pieces to see how it fits together.
>
> Okay... what are all the pieces and how do they fit together?

You would need to read the CAPP guidelines and look at a couple audit patches 
and rule sets.


> Has this ever been explained to the Fedora base?

Probably not. Since you are asking nicely, I'll explain it. For this 
discussion lets look at:

http://www.niap-ccevs.org/cc-scheme/pp/pp_os_ca_v1.d.pdf

Lets start with the assumptions, 

Section 3.3.2 
A.NO_EVIL_ADM
The system administrative personnel are not careless, willfully negligent, or 
hostile, and will follow and abide by the instructions provided by the 
administrator documentation.

Section 3.3.3
A.PEER
Any other systems with which the TOE communicates are assumed to be under the 
same management control and operate under the same security policy 
constraints.

Now for the Objectives related to our discussion,

Section 4.1
O.AUTHORIZATION
The TSF must ensure that only authorized users gain access to the TOE and its 
resources.

O.AUDITING
The TSF must record the security relevant actions of users of the TOE. The TSF 
must present this information to authorized administrators.

And the relevant Functional Requirements

5.1.1.1        The TSF shall be able to generate an audit record of the 
auditable events listed in  column ?Event? of Table 1 (Auditable Events). This 
includes all auditable events for the basic level of audit, except FIA_UID.1?s 
user identity during failures. FAU_GEN.1.1 / NOTE 4

FMT_REV.1 All modifications to the values of TSF data.

5.3.6.1         The TSF shall associate the following user security attributes 
with subjects acting on the behalf of that user: FIA_USB.1.1 / NOTE 2
        a)  The user identity which is associated with auditable events;
        b)  The user identity or identities which are used to enforce the 
Discretionary Access Control Policy;
        c)  The group membership or memberships used to enforce the 
Discretionary Access

What this means, is that 
1) admins are not hostile and follow proceedures. 
2) In order for DAC to work there must be accounts established that Identify 
Users.
3) We must audit changes that affect the user-subject binding since that is the 
foundation of all DAC security controls.
4) We specifically need to know in the case of someone acting upon a user's 
behalf, who did it, and what was modified.
5) We must audit changes to trusted databases

To accomplish this, we instrument the shadow-utils code. This lets us see who 
modified any account and which account and how it was modified. You can find 
these in your audit logs ny looking for 

ausearch --start this-month -m ADD_USER
----
time->Wed Dec  3 06:27:22 2008
node=127.0.0.1 type=ADD_USER msg=audit(1228303642.238:3290): user pid=3919 
uid=0 auid=4325 ses=1 subj=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 
msg='op=adding user acct="rpc" exe="/usr/sbin/useradd" (hostname=?, addr=?, 
terminal=? res=success)' 

and

ausearch --start this-month -m ADD_GROUP
----
time->Wed Dec  3 06:27:22 2008
node=127.0.0.1 type=ADD_GROUP msg=audit(1228303642.155:2796): user pid=3915 
uid=0 auid=4325 ses=1 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 
msg='op=adding group acct="rpc" exe="/usr/sbin/groupadd" (hostname=?, addr=?, 
terminal=? res=success)' 

This takes care of 1-4. To accomplish 5, we add an audit rule

https://fedorahosted.org/audit/browser/trunk/contrib/capp.rules#L195

This results in events like this:

time->Wed Dec  3 06:27:22 2008
node=127.0.0.1 type=PATH msg=audit(1228303642.237:3286): item=0 
name="/etc/shadow" inode=20776439 dev=08:08 mode=0100400 ouid=0 ogid=0 
rdev=00:00 obj=system_u:object_r:shadow_t:s0 
node=127.0.0.1 type=CWD msg=audit(1228303642.237:3286):  cwd="/" 
node=127.0.0.1 type=SYSCALL msg=audit(1228303642.237:3286): arch=c000003e 
syscall=2 success=yes exit=6 a0=612bc0 a1=2 a2=1b6 a3=7f118a6f6780 items=1 
ppid=3907 pid=3919 auid=4325 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 
fsgid=0 tty=pts0 ses=1 comm="useradd" exe="/usr/sbin/useradd" 
subj=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 
key=61757468016964732D66696C652D6869 

Which as you can see has the same time stamp as the audit event for ADD_USER. 
So we now meet #5.

But what about audit of any attempt to change an account and its outcome? The 
shadow file cannot be accessed unless you are root. The utilities that would 
allow you to modify it cannot be accessed unless you are root. The assumptions 
state that any system you have access to is also managed with the same 
policies, therefore users cannot download their own copy. All requirements are 
covered.

This allows us to make some reports about system activity. To see a summary of 
these actions, you can run 

aureport --start this-month --mods -i

For the direct access as well as through approved utilities, you can see it 
like this

ausearch --start this-month -f /etc/shadow --raw | aureport -x -i

Now, if anyone wants to discuss this any further, I am willing as long as we 
drop all the hostility. I'm tired of it. Attacking the security target is not 
something I want to debate as its out of my control. I just want to meet it.

Hope you find this informtion useful.

-Steve



From rawhide at fedoraproject.org  Sun Dec  7 15:44:48 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun,  7 Dec 2008 15:44:48 +0000 (UTC)
Subject: rawhide report: 20081207 changes
Message-ID: <20081207154448.E25B31F81D6@releng2.fedora.phx.redhat.com>

Compose started at Sun Dec  7 06:01:04 UTC 2008

New package mysqlreport
        A friendly report of important MySQL status values
New package perl-MooseX-App-Cmd
        Mashes up MooseX::Getopt and App::Cmd
New package perl-MooseX-Types-URI
        URI related types and coercions for Moose
New package perl-Test-Dependencies
        Ensure that your Makefile.PL specifies all module dependencies
New package ssbd
        Voice keyer for use in hamradio
Updated Packages:

awstats-6.8-3.fc11
------------------
* Sat Dec  6 17:00:00 2008 Aurelien Bompard <abompard at fedoraproject.org> 6.8-3
- Use Debian's patch for CVE-2008-3714 (rh#474396)


cairo-dock-2.0.0-0.1.svn1429_trunk.fc11
---------------------------------------
* Sun Dec  7 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Try 2.0.0 development branch
- Build weblet plugin with WebKit, switching from Gecko,
  rename weblet related plugin
- Disable xfce related plugin for now until hal-devel is properly
  rebuilt


curl-7.18.2-8.fc11
------------------
* Sat Dec  6 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 7.18.2-8
- use improved NSS patch, thanks to Rob Crittenden (#472489)


cvs2cl-2.72-1
-------------
* Sat Dec  6 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 2.72-1
- 2.72.


ekg2-0.2-0.6.rc1.fc11.1
-----------------------
* Sat Dec  6 17:00:00 2008 Karol Trzcionka <karlikt at gmail.com> - 0.2-0.6.rc1.1
- Fix ruby building

* Sat Dec  6 17:00:00 2008 Karol Trzcionka <karlikt at gmail.com> - 0.2-0.6.rc1
- Fix typo in changelog
- Remove %attr
- Add unowned directories (#474640)
- Add ruby plugin
- Sort plugins alphabetically


fet-5.7.5-1.fc11
----------------
* Sat Dec  6 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 5.7.5-1
- new upstream release


gdal-1.6.0-0.1.rc4.fc11
-----------------------
* Sat Dec  6 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 1.6.0-0.1.rc4
- new branch
- disable grass
- fix ruby compile

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.5.3-2
- Rebuild for Python 2.6


gdl-0.9-0.rc1.4.fc11.1
----------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9-0.rc1.4.1
- Rebuild for Python 2.6


geos-3.0.3-1.fc11
-----------------
* Sat Dec  6 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 3.0.3-1
- new upstream stable


ghc-gtk2hs-0.9.13-6.20081108.fc11
---------------------------------
* Fri Dec  5 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.9.13-6.20081108
- install the .o files at build time rather than generating them at install
  (reported by Gregory Weber, #250767)
- update docs building to haddock 2.4.1


gimmie-0.2.8-3.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.8-3
- Rebuild for Python 2.6


glipper-1.0-5.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0-5
- Rebuild for Python 2.6


glom-1.6.17-3.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.17-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.17-2
- Rebuild for Python 2.6


gnome-commander-1.2.8-0.2.svn2332_trunk.fc11
--------------------------------------------
* Sat Dec  6 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2332
- libtool 2.2 patch went upstream
- "replace_icon" hack seems no longer needed


gnumeric-1.8.2-5.fc11
---------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:1.8.2-5
- Rebuild for Python 2.6


graphviz-2.20.3-1.fc11.1
------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.20.3-1.1
- Rebuild for Python 2.6


grass-6.3.0-9.fc11
------------------
* Sun Dec  7 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> 6.3.0-9
- rebuild against newer gdal

* Sun Dec  7 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> 6.3.0-8
- rebuild against newer gdal


gtk+extra-2.1.1-9.fc11
----------------------
* Sat Dec  6 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 2.1.1-9
- Rebuild for pkgconfig


gtkglext-1.2.0-8.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.2.0-8
- Rebuild for pkgconfig provides


hulahop-0.4.7-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4.7-2
- Rebuild for Python 2.6

* Mon Nov  3 17:00:00 2008 Simon Schampijer <simon at laptop.org> - 0.4.7-1
- Provide the ground to make downloads and uploads work for 
multiple instances (marco)


hunspell-en-0.20081205-1.fc11
-----------------------------
* Sat Dec  6 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081205-1
- latest version


java-1.6.0-openjdk-1.6.0.0-8.b14.fc11
-------------------------------------
* Fri Dec  5 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-8.b14
- Added hotspot source.
- Added --with-hotspot-src-zip build option.
- Set runtests to 1.
- Updated jtreg log.
- Added new patch to add GNOME to java.security.
- Updated icedteasnapshot.
- Updated openjdkver.
- Updated openjdkdate.
- Resolves: rhbz#474431
- Resolves: rhbz#474503
- Resolves: rhbz#472862


libXtst-1.0.3-4.fc11
--------------------
* Sun Dec  7 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.0.3-4
- Rebuild for pkgconfig provides


libtool-2.2.6-5.fc11
--------------------
* Sat Dec  6 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 2.2.6-5
- Own /usr/include/libltdl (#475004)


listen-0.5-21.fc11
------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5-21
- Rebuild for Python 2.6

* Sun Sep 28 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.5-20
- fix up for sparc64


mingw32-filesystem-40-2.fc11
----------------------------
* Sat Dec  6 17:00:00 2008 Levente Farkas <lfarkas at lfarkas.org> - 40-2
- Rewrite mingw32-scripts to run in the current shell
- (Re-add mingw32-make) - Removed by RWMJ.
- Add mingw32-env to mingw32.sh


mkinitrd-6.0.73-5.fc11
----------------------
* Sat Dec  6 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 6.0.73-5
- Rebuild again for python-2.6


ochusha-0.5.99.68-0.4.cvs20081207T0000.fc11
-------------------------------------------
* Sun Dec  7 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


opal-3.4.2-2.fc11
-----------------
* Fri Dec  5 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.4.2-2
- Update spec to ensure we own directories


openoffice.org-3.0.1-12.3.fc11.1
--------------------------------
* Sat Dec  6 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-12.3
- rebuild for python
- Resolves: rhbz#473390 add workspace.swffixes.patch
- Resolves: rhbz#473390 add openoffice.org-3.0.1.ooo96970.pluginfixups.patch
- add openoffice.org-3.0.1.ooo96906.ucb.symlinks.and.size.patch
- rename openoffice.org-2.4.0.ooo87490.sfx2.allprotocols.urlopen.patch to
  upstream workspace.mba31issues01.patch
- rename openoffice.org-3.0.0.ooo96203.sfx2.3layer-qstart.patch to 
  upstream workspace.cmcfixes51.patch
- rename openoffice.org-3.0.0.ooo90653.pyuno.debugging.spew.patch to
  upstream workspace.sb101.patch
- rename openoffice.org-3.0.0.ooo95533.sw.safertableexport.patch and
  openoffice.org-3.0.0.ooo93949.sw.better_rtf_encodings.patch to 
  upstream workspace.hb12.patch
- rename openoffice.org-3.0.0.ooo94659.sal.magazine.patch to
  upstream workspace.mhu17.patch
- drop integrated openoffice.org-3.0.0.ooo93942.svx.accessibity-loops.patch to
- rename openoffice.org-3.0.0.ooo86142.serbiannumbering.patch to
  upstream workspace.locales31.patch

* Mon Dec  1 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-12.2
- Resolves: rhbz#474058 messy patch
- Resolves: rhbz#473570 Add dejavu requires

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:3.0.1-12.1.1
- Rebuild for Python 2.6


pango-1.22.3-2.fc11
-------------------
* Sun Dec  7 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.22.3-2
- Rebuild for pkgconfig provides


perl-Class-MOP-0.71-1.fc11
--------------------------
* Sat Dec  6 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.71-1
- update to 0.71


perl-Config-Any-0.16-1.fc11
---------------------------
* Sat Dec  6 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.16-1
- update to 0.16


perl-Gtk2-Ex-PodViewer-0.18-1.fc11
----------------------------------
* Sat Dec  6 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.18-1
- v 0.18


perl-HTML-FormFu-0.03005-4.fc11
-------------------------------
* Sat Dec  6 17:00:00 2008 Iain Arnell <iarnell at gmail.com> 0.03005-4
- remove wrongly detected requires (defaults and model_config)


perl-Moose-0.62-1.fc11
----------------------
* Sat Dec  6 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.62-1
- update to 0.62
- new Task::Weaken and Class::MOP requirements


php-5.2.7-1.fc11.1
------------------
* Sat Dec  6 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 5.2.7-1.1
- aclocal workaround

* Fri Dec  5 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 5.2.7-1
- update to 5.2.7
- enable pdo_dblib driver in php-mssql

* Mon Nov 24 17:00:00 2008 Joe Orton <jorton at redhat.com> 5.2.6-7
- tweak Summary, thanks to Richard Hughes

* Tue Nov  4 17:00:00 2008 Joe Orton <jorton at redhat.com> 5.2.6-6
- move gd_README to php-gd
- update to r4 of systzdata patch; introduces a default timezone
  name of "System/Localtime", which uses /etc/localtime (#469532)


policycoreutils-2.0.60-4.fc11
-----------------------------
* Sat Dec  6 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.60-4
- Change md5 to hashlib.md5 in sepolgen


prelude-correlator-0.9.0-0.5.beta3.fc11
---------------------------------------
* Fri Dec  5 17:00:00 2008 Steve Grubb <sgrubb at redhat.com> 0.9.0-0.5.beta3
- Fix bz#469824 Correct brute force correlation rules
- Add signal header to prelude-correlator.c so it builds correctly
- Include unowned /usr/include/prelude-correlator directory


prewikka-0.9.14-2.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.14-2
- Rebuild for Python 2.6


pyabiword-0.6.1-4.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.1-4
- Rebuild for Python 2.6


pyroom-0.3.2-1.fc11
-------------------
* Sat Dec  6 17:00:00 2008 Sven Lankes <sven at lank.es> - 0.3.2-1
- new upstream release


python-tempita-0.3-1.fc11
-------------------------
* Sat Dec  6 17:00:00 2008 Ricky Zhou <ricky at fedoraproject.org> - 0.3-1
- Upstream released a new version.


python-webob-0.9.4-1.fc11
-------------------------
* Sat Dec  6 17:00:00 2008 Ricky Zhou <ricky at fedoraproject.org> 0.9.4-1
- Upstream released new version.


python-webtest-1.1-1.fc11
-------------------------
* Sat Dec  6 17:00:00 2008 Ricky Zhou <ricky at fedoraproject.org> - 1.1-1
- Upstream released new version.


raptor-1.4.18-1.fc11
--------------------

rcsslogplayer-13.0.1-1.fc11
---------------------------
* Thu Dec  4 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.0.1-1
- Updated to the new released version (13.0.1)


rcssserver-13.0.2-1.fc11
------------------------
* Thu Dec  4 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.0.2-1
- Bump to 13.0.2 version.


rpy-1.0.3-5.fc11
----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.3-5
- Rebuild for Python 2.6


sigen-0.0.2-0.25.20081206git529cd0e.fc11
----------------------------------------
* Sat Dec  6 17:00:00 2008 Ben Boeckel <MathStuf at gmail.com> 0.0.2-0.25.20081206git529cd0e
- CMake export files added

* Mon Dec  1 17:00:00 2008 Ben Boeckel <MathStuf at gmail.com> 0.0.2-0.24.20081201git2fe921ca
- Sigworld added

* Mon Dec  1 17:00:00 2008 Ben Boeckel <MathStuf at gmail.com> 0.0.2-0.23.20081201git2fe921ca
- Missed a / when making the tarball

* Mon Dec  1 17:00:00 2008 Ben Boeckel <MathStuf at gmail.com> 0.0.2-0.22.20081201git2fe921ca
- Using git now instead of subversion

* Wed Nov  5 17:00:00 2008 Ben Boeckel <MathStuf at gmail.com> 0.0.2-0.21.20081105svn305
- Moved the mimetype files outside of the spec file
- Now owns the mime, mimelnk, and applications directories
- Newer SVN (now with signet)


telepathy-gabble-0.7.16-1.fc11
------------------------------
* Tue Dec  2 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.16-1
- Update to 0.7.16.


telepathy-salut-0.3.6-1.fc11
----------------------------
* Sat Dec  6 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.3.6-1
- Update to 0.3.6.
- Add BR on libsoup22-devel.


textflow-0.2.3.2-3.fc11
-----------------------
* Sun Dec  7 17:00:00 2008 Mads Villadsen <maxx at krakoa.dk> - 0.2.3.2-3
- Fix package summary


translate-toolkit-1.2.1-1.fc11
------------------------------
* Sat Dec  6 17:00:00 2008 Dwayne Bailey <dwayne at translate.org.za> - 1.2.1-1
- Update to 1.2.1
- Refresh poterminology patch


Summary:
Added Packages: 5
Removed Packages: 0
Modified Packages: 54
Broken deps for i386
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.i386 requires libpython2.5.so.1.0
	ScientificPython-qt-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	avahi-ui-sharp-0.6.22-13.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	beecrypt-python-4.1.2-17.fc10.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.i386 requires libspectrum.so.5
	ganglia-gmond-python-3.1.1-1.fc10.i386 requires libpython2.5.so.1.0
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	hamster-applet-2.24.2-2.fc11.i386 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-gui-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.i386 requires libgeos-3.0.1.so
	python-brlapi-0.5.2-1.fc10.i386 requires libpython2.5.so.1.0
	python-brlapi-0.5.2-1.fc10.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rdflib-2.4.0-7.fc10.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	scigraphica-2.1.0-6.fc9.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.i386 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ScientificPython-qt-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.i386 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.x86_64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.x86_64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	avahi-ui-sharp-0.6.22-13.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	beecrypt-python-4.1.2-17.fc10.x86_64 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.x86_64 requires libspectrum.so.5()(64bit)
	ganglia-gmond-python-3.1.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	hamster-applet-2.24.2-2.fc11.x86_64 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.x86_64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	muine-devel-0.8.10-3.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.x86_64 requires libgeos-3.0.1.so()(64bit)
	python-brlapi-0.5.2-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-brlapi-0.5.2-1.fc10.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	scigraphica-2.1.0-6.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.x86_64 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.ppc requires libpython2.5.so.1.0
	ScientificPython-qt-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	avahi-ui-sharp-0.6.22-13.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	beecrypt-python-4.1.2-17.fc10.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc requires libspectrum.so.5
	ganglia-gmond-python-3.1.1-1.fc10.ppc requires libpython2.5.so.1.0
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	hamster-applet-2.24.2-2.fc11.ppc requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.ppc requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	muine-devel-0.8.10-3.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-gui-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc requires libgeos-3.0.1.so
	python-brlapi-0.5.2-1.fc10.ppc requires libpython2.5.so.1.0
	python-brlapi-0.5.2-1.fc10.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	scigraphica-2.1.0-6.fc9.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.ppc requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ScientificPython-qt-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python-abi = 0:2.5
	alchemist-1.0.37-4.fc9.ppc64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	beecrypt-python-4.1.2-17.fc10.ppc64 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	cohoba-0.0.4-6.fc10.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc64 requires libspectrum.so.5()(64bit)
	ganglia-gmond-python-3.1.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	hamster-applet-2.24.2-2.fc11.ppc64 requires python(abi) = 0:2.5
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-gui-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc64 requires libgeos-3.0.1.so()(64bit)
	python-brlapi-0.5.2-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-brlapi-0.5.2-1.fc10.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	scigraphica-2.1.0-6.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.ppc64 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From enrico.scholz at informatik.tu-chemnitz.de  Sun Dec  7 16:31:54 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sun, 07 Dec 2008 17:31:54 +0100
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812070954.31864.sgrubb@redhat.com> (Steve Grubb's message of
	"Sun, 7 Dec 2008 09:54:31 -0500")
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
	<604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
	<200812070954.31864.sgrubb@redhat.com>
Message-ID: <87k5ac9cat.fsf@sheridan.bigo.ensc.de>

Steve Grubb <sgrubb at redhat.com> writes:

> 5) We must audit changes to trusted databases
>
> To accomplish this, we instrument the shadow-utils code. This lets
> us see who modified any account and which account and how it was
> modified. You can find these in your audit logs ny looking for
>
> ausearch --start this-month -m ADD_USER

# vipw
i
foo:x:1111:1111:x:/bin/foo:/bin/sh

# ausearch --start this-month -m ADD_USER
#

or

$ ldapadd
dn: uid=foo,...

# ausearch --start this-month -m ADD_USER
#


Both 'vipw' and 'ldapadd' are official and documented tools to manage
user database.


> The utilities that would allow you to modify it cannot be accessed
> unless you are root.

Sounds like "when the algorithm is hidden, the crypto mechanism is
secure"...




Enrico



From sgrubb at redhat.com  Sun Dec  7 16:51:38 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 7 Dec 2008 11:51:38 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <87k5ac9cat.fsf@sheridan.bigo.ensc.de>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812070954.31864.sgrubb@redhat.com>
	<87k5ac9cat.fsf@sheridan.bigo.ensc.de>
Message-ID: <200812071151.38419.sgrubb@redhat.com>

On Sunday 07 December 2008 11:31:54 Enrico Scholz wrote:
> Both 'vipw' and 'ldapadd' are official and documented tools to manage
> user database.

vipw I believe is forbidden due to its ability to circumvent auditing of user-
subject binding. ldap is not part of the evaluation.

However, we could certainly extend the auditing to other programs if we wanted 
to. Nothing is preventing this except someone having the time to do it. If you 
wanted to add auditing, I'm all for it and don't mind helping where I can.


> > The utilities that would allow you to modify it cannot be accessed
> > unless you are root.
>
> Sounds like "when the algorithm is hidden, the crypto mechanism is
> secure"...

I wouldn't characterize it like that. It means that you have established 
proceedures that ensure the Security Objectives are met. As for crypto, the 
unprivileged user has access to passwd and that does crypto for them.

-Steve



From jkeating at redhat.com  Sun Dec  7 16:51:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 07 Dec 2008 08:51:33 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812070954.31864.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
	<604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
	<200812070954.31864.sgrubb@redhat.com>
Message-ID: <1228668693.3370.5.camel@localhost.localdomain>

On Sun, 2008-12-07 at 09:54 -0500, Steve Grubb wrote:
> Now, if anyone wants to discuss this any further, I am willing as long as we 
> drop all the hostility. I'm tired of it. Attacking the security target is not 
> something I want to debate as its out of my control. I just want to meet it.
> 
> Hope you find this informtion useful.

Unfortunately, attacking the security target is exactly what the Fedora
community is going to do.  We don't just meet things because it's a
checkbox on a list.  If changes are going to be made (or kept) in
Fedora, they need to be for an understandable and agreeable reason.

I have yet to see anything in your definition of CAPP that adds real
security to our system.  What I get out of it so far is "If all the
admins play nice, we can track what they're doing".  But if admins stop
playing nice, all bets are off.  What kind of security is that?  What
value does that add to Fedora systems?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/8e932daf/attachment.sig>

From mitr at volny.cz  Sun Dec  7 17:00:40 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Sun, 07 Dec 2008 17:00:40 +0000
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228668693.3370.5.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
	<604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
	<200812070954.31864.sgrubb@redhat.com>
	<1228668693.3370.5.camel@localhost.localdomain>
Message-ID: <1228669240.3311.30.camel@localhost.localdomain>

Jesse Keating p??e v Ne 07. 12. 2008 v 08:51 -0800:
> I have yet to see anything in your definition of CAPP that adds real
> security to our system.  What I get out of it so far is "If all the
> admins play nice, we can track what they're doing".  But if admins stop
> playing nice, all bets are off.  What kind of security is that?
More exactly, it is "after admins stop playing nice, all bets are off".
The system is supposed to audit all attempts to violate the security
policy up to the first successful violation, so it should identify at
least one accomplice.  If you have an accomplice, you have a specific
lead for further investigation.
	Mirek



From jkeating at redhat.com  Sun Dec  7 17:11:04 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 07 Dec 2008 09:11:04 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228669240.3311.30.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
	<604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
	<200812070954.31864.sgrubb@redhat.com>
	<1228668693.3370.5.camel@localhost.localdomain>
	<1228669240.3311.30.camel@localhost.localdomain>
Message-ID: <1228669864.3370.12.camel@localhost.localdomain>

On Sun, 2008-12-07 at 17:00 +0000, Miloslav Trma? wrote:
> More exactly, it is "after admins stop playing nice, all bets are off".
> The system is supposed to audit all attempts to violate the security
> policy up to the first successful violation, 

But only through pre-approved interfaces... what if the admin doesn't
use any of those for their first attempts?  (why would an admin use any
of those?)

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/df5e6191/attachment.sig>

From sgrubb at redhat.com  Sun Dec  7 17:14:24 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 7 Dec 2008 12:14:24 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228668693.3370.5.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812070954.31864.sgrubb@redhat.com>
	<1228668693.3370.5.camel@localhost.localdomain>
Message-ID: <200812071214.24267.sgrubb@redhat.com>

On Sunday 07 December 2008 11:51:33 Jesse Keating wrote:
> I have yet to see anything in your definition of CAPP that adds real
> security to our system.

I didn't attempt to explain CAPP, that would be a book or at least a big  
chapter in a book. What I attempted to explain is the parts of it that apply 
to user account management.


> What I get out of it so far is "If all the admins play nice, we can track
> what they're doing". ?But if admins stop playing nice, all bets are off.

True. To track a hostile admin requires meeting yet another Security Target. 
You need 

1) Remote audit logging - we have that
2) Separation of roles such that a security officer and an admin role exist - we 
have that.
3) keystroke logging - we have that

These are called out for in higher security standards. The higher standards 
typically extend the lower standards.


> What value does that add to Fedora systems?

CAPP basically says you have a normal unix system. As the threat increases, 
you have to take different steps to counter it. We have a layered security 
approach that lets you tailor the counter-measures to the perceived threat.

-Steve




From sgrubb at redhat.com  Sun Dec  7 17:16:20 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 7 Dec 2008 12:16:20 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228669864.3370.12.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<1228669240.3311.30.camel@localhost.localdomain>
	<1228669864.3370.12.camel@localhost.localdomain>
Message-ID: <200812071216.20966.sgrubb@redhat.com>

On Sunday 07 December 2008 12:11:04 Jesse Keating wrote:
> But only through pre-approved interfaces... what if the admin doesn't
> use any of those for their first attempts? ?(why would an admin use any
> of those?)

That's where audit by tty comes into play. Check out pam_tty_audit.

-Steve



From mitr at volny.cz  Sun Dec  7 17:20:17 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Sun, 07 Dec 2008 17:20:17 +0000
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228669864.3370.12.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
	<604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
	<200812070954.31864.sgrubb@redhat.com>
	<1228668693.3370.5.camel@localhost.localdomain>
	<1228669240.3311.30.camel@localhost.localdomain>
	<1228669864.3370.12.camel@localhost.localdomain>
Message-ID: <1228670417.3311.37.camel@localhost.localdomain>

Jesse Keating p??e v Ne 07. 12. 2008 v 09:11 -0800:
> On Sun, 2008-12-07 at 17:00 +0000, Miloslav Trma? wrote:
> > More exactly, it is "after admins stop playing nice, all bets are off".
> > The system is supposed to audit all attempts to violate the security
> > policy up to the first successful violation, 
> 
> But only through pre-approved interfaces... what if the admin doesn't
> use any of those for their first attempts?  (why would an admin use any
> of those?)
Nobody can prevent you from configuring the system in a way that doesn't
allow auditing, nor from doing other unexpected - whether useful or
stupid - things.

But you can choose to configure the system in a way that makes audit
useful.

(The lower-level attacks like direct modification of /etc/shadow are
audited as well, but as attacks "against the file", not "against a
specific user".  In either case the event and the administrator are
identified.)
	Mirek



From hughsient at gmail.com  Sun Dec  7 17:50:21 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 07 Dec 2008 17:50:21 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <1228643419.28999.4.camel@arekh.okg>
References: <49393DE3.1080707@redhat.com> <49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
	<1228555748.4211.2.camel@hughsie-work.lan>
	<1228633070.26618.236.camel@code.and.org>
	<1228640138.4266.20.camel@hughsie-work.lan>
	<1228643419.28999.4.camel@arekh.okg>
Message-ID: <1228672221.4232.1.camel@hughsie-work.lan>

On Sun, 2008-12-07 at 10:50 +0100, Nicolas Mailhot wrote:
> 
> I would be more constructive to tell the user what the blocking
> program is (command name, user, PID).

The application name and perhaps the user seems useful, I'm not sure
about the cmdline or PID data (although we have this logged if needed).

> A lot of PK messages suffer from this kind of lack of details which is
> not helpful for the user and just makes him want to scream. Please try
> to give users *context* instead of vague maddening generic blurbs.

Right, can you please file a bug against the gnome-packagekit package
and I'll have a look on Monday. Thanks.

Richard.




From nicolas.mailhot at laposte.net  Sun Dec  7 18:07:47 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 07 Dec 2008 19:07:47 +0100
Subject: The looming Python 3(000) monster
In-Reply-To: <1228672221.4232.1.camel@hughsie-work.lan>
References: <49393DE3.1080707@redhat.com> <49397827.2080807@gmail.com>
	<16de708d0812051058j2e0ae917m89e05b845cc7f5b2@mail.gmail.com>
	<49398011.9030100@gmail.com>
	<16de708d0812051133u6f063bcwac169356af196c17@mail.gmail.com>
	<493990E5.3060408@gmail.com>
	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>
	<4939A275.1070603@gmail.com>
	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>
	<4939A673.3090907@gmail.com>
	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>
	<1228555748.4211.2.camel@hughsie-work.lan>
	<1228633070.26618.236.camel@code.and.org>
	<1228640138.4266.20.camel@hughsie-work.lan>
	<1228643419.28999.4.camel@arekh.okg>
	<1228672221.4232.1.camel@hughsie-work.lan>
Message-ID: <1228673267.2305.5.camel@arekh.okg>

Le dimanche 07 d?cembre 2008 ? 17:50 +0000, Richard Hughes a ?crit :
> On Sun, 2008-12-07 at 10:50 +0100, Nicolas Mailhot wrote:
> > 
> > I would be more constructive to tell the user what the blocking
> > program is (command name, user, PID).
> 
> The application name and perhaps the user seems useful, I'm not sure
> about the cmdline or PID data (although we have this logged if needed).

That's for bashing or killing (as appropriate) :p

https://bugzilla.redhat.com/show_bug.cgi?id=475094

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/77bf9849/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Dec  7 18:16:56 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 07 Dec 2008 19:16:56 +0100
Subject: Classroom session on Fedora fonts packaging
In-Reply-To: <1228582462.2983.5.camel@arekh.okg>
References: <1228582462.2983.5.camel@arekh.okg>
Message-ID: <1228673816.2820.1.camel@arekh.okg>

Le samedi 06 d?cembre 2008 ? 17:54 +0100, Nicolas Mailhot a ?crit :
> Hi all,
> 
> This is a bit impromptu, but as part of the Fedora classroom program,
> I'll animate a session on fonts packaging tomorrow the 7th of December
> at 12:15 UTC in the #fedora-classroom irc.freenode.net IRC channel.
> 
> http://fedoraproject.org/wiki/Communicate/IRC/Classroom
> 
> The actual content of the session is rather fluid and will depend on the
> audience questions.

The minutes of the session are now published here:
http://fedoraproject.org/wiki/Packaging_fonts_in_Fedora_(2008-12-07_classroom)

With best regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/6053f616/attachment.sig>

From Jochen at herr-schmitt.de  Sun Dec  7 18:26:28 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Sun, 07 Dec 2008 19:26:28 +0100
Subject: orphaning many packages
In-Reply-To: <20081206122420.GC2932@free.fr>
References: <20081206122420.GC2932@free.fr>
Message-ID: <0ML31I-1L9OL820IS-0000zd@mrelayeu.kundenserver.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 6 Dec 2008 13:24:20 +0100, you wrote:

>* pam_ssh
>Very low maintainance

I will take it.

Best Regards:

Jochen Schmitt

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.9.0 (Build 397)
Charset: us-ascii

wj8DBQFJPBViT2AHK6txfgwRAnXmAKDk7EakNR5skk1f157YkBQ4Lla3qACfeZRi
AyVLe8kNW1bN+58KxMSCMbQ=
=Rg2t
-----END PGP SIGNATURE-----



From mdehaan at redhat.com  Sun Dec  7 18:51:43 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Sun, 07 Dec 2008 13:51:43 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <1228633714.26618.248.camel@code.and.org>
References: <49393DE3.1080707@redhat.com>
	<493973AF.2030009@gmail.com>	<16de708d0812051040q11978c07s7408e70d34266143@mail.gmail.com>	<1228502748.3386.36.camel@beta>	<1228504272.26618.191.camel@code.and.org>	<493B0B31.2040605@redhat.com>
	<1228633714.26618.248.camel@code.and.org>
Message-ID: <493C1B3F.50202@redhat.com>

James Antill wrote:
> On Sat, 2008-12-06 at 18:30 -0500, Michael DeHaan wrote:
>
>   
>> Not defined in older versions of python however, hence the need to 
>> branch code, hence a problem with EPEL supporting code.
>>     
>
>  True, 2.5.x and earlier won't be compatible. Which means that
> RHEL-5/CentOS-5 python won't be compatible with any code that uses this
> feature of py3k and/or 2.6.x (via. the from future import).
>
>  This is _far_ from unprecedented though, lack of decorators and/or
> yield alone makes the python in RHEL-4/CentOS-4 incompatible for any
> modern development. And I've had to upgrade boxes because of this, and
> told a lot of people "Yeh, any recent yum just isn't going to work
> there ... sucks".
>   

That's a backwards compatibility example.

I'm talking about a break in forwards compatibility.
>  This wasn't the end of the world then, and didn't mean we wanted/needed
> to hold python back in Fedora. I don't see anything materially different
> now.
>
>   

(A) This is a different issue than the above.   This is equivalent to 
older Python targetting code not being run on the /new/, not newer code 
running on the old.
Completely different problem.

(B) Nobody said the world was ending :)



From pertusus at free.fr  Sun Dec  7 19:12:06 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 7 Dec 2008 20:12:06 +0100
Subject: orphaning many packages
In-Reply-To: <0ML31I-1L9OL820IS-0000zd@mrelayeu.kundenserver.de>
References: <20081206122420.GC2932@free.fr>
	<0ML31I-1L9OL820IS-0000zd@mrelayeu.kundenserver.de>
Message-ID: <20081207191206.GB2547@free.fr>

On Sun, Dec 07, 2008 at 07:26:28PM +0100, Jochen Schmitt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, 6 Dec 2008 13:24:20 +0100, you wrote:
> 
> >* pam_ssh
> >Very low maintainance
> 
> I will take it.

Dmitry who was co-maintainer from the start already took it. But more
co-maintainers shouldn't hurt, just apply.

--
Pat



From mschwendt at gmail.com  Sun Dec  7 19:17:46 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 07 Dec 2008 19:17:46 -0000
Subject: Broken dependencies in Fedora 10 - 2008-12-07
Message-ID: <20081207191746.20260.94026@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by owner):

    aconway AT redhat.com
        qpidc

    dhuff AT redhat.com
        appliance-tools

    iarnell AT gmail.com
        perl-HTML-FormFu

    nphilipp AT redhat.com
        ufraw

    sundaram AT redhat.com
        gyachi
        olpc-utils


======================================================================
Broken packages in fedora-10-i386:

    gyachi-plugin-photo_album-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    qpidd-cluster-0.3.705289-1.fc10.i386  requires  qpidd = 0:0.3.705289-1.fc10


======================================================================
Broken packages in fedora-10-ppc:

    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10


======================================================================
Broken packages in fedora-10-ppc64:

    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10


======================================================================
Broken packages in fedora-10-x86_64:

    gyachi-plugin-photo_album-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    qpidd-cluster-0.3.705289-1.fc10.x86_64  requires  qpidd = 0:0.3.705289-1.fc10


======================================================================
Broken packages in fedora-updates-10-i386:

    olpc-utils-0.89-6.fc10.i386  requires  olpcupdate >= 0:2.10
    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(defaults)
    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(model_config)


======================================================================
Broken packages in fedora-updates-10-ppc:

    olpc-utils-0.89-6.fc10.ppc  requires  olpcupdate >= 0:2.10
    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(defaults)
    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(model_config)


======================================================================
Broken packages in fedora-updates-10-ppc64:

    appliance-tools-003.9-1.fc10.noarch  requires  qemu-img
    olpc-utils-0.89-6.fc10.ppc64  requires  olpcupdate >= 0:2.10
    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(defaults)
    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(model_config)


======================================================================
Broken packages in fedora-updates-10-x86_64:

    olpc-utils-0.89-6.fc10.x86_64  requires  olpcupdate >= 0:2.10
    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(defaults)
    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(model_config)


======================================================================
Broken packages in fedora-updates-testing-10-i386:

    ufraw-cinepaint-0.14.1-3.fc10.i386  requires  cinepaint(x86-32)


======================================================================
Broken packages in fedora-updates-testing-10-ppc:

    ufraw-cinepaint-0.14.1-3.fc10.ppc  requires  cinepaint(ppc-32)


======================================================================
Broken packages in fedora-updates-testing-10-ppc64:

    ufraw-cinepaint-0.14.1-3.fc10.ppc64  requires  cinepaint(ppc-64)


======================================================================
Broken packages in fedora-updates-testing-10-x86_64:

    ufraw-cinepaint-0.14.1-3.fc10.x86_64  requires  cinepaint(x86-64)



From mschwendt at gmail.com  Sun Dec  7 19:21:29 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 07 Dec 2008 19:21:29 -0000
Subject: Broken dependencies in Fedora 9 - 2008-12-07
Message-ID: <20081207192129.20282.65590@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by owner):

    berrange AT redhat.com
        perl-Test-AutoBuild

    dhuff AT redhat.com
        appliance-tools

    ebmunson AT us.ibm.com
        libhugetlbfs

    huzaifas AT redhat.com
        openvas-libraries

    katzj AT redhat.com
        livecd-tools

    matthias AT rpmforge.net
        pigment-python

    nigjones AT redhat.com
        mediawiki-SpecialInterwiki

    oliver AT linux-kernel.at
        syck

    orion AT cora.nwra.com
        paraview

    phuang AT redhat.com
        scim-bridge

    sundaram AT redhat.com
        gyachi

    wart AT kobold.org
        cyphesis
        sear


======================================================================
Broken packages in fedora-9-i386:

    cyphesis-selinux-0.5.15-6.fc9.i386  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.i386  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.i386  requires  gyachi = 0:1.1.0-7.fc9
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-gtk-0.3.so.4
    sear-0.6.3-10.fc9.i386  requires  libmercator-0.2.so.4
    syck-php-0.61-4.3.fc9.i386  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc:

    cyphesis-selinux-0.5.15-6.fc9.ppc  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.ppc  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.ppc  requires  gyachi = 0:1.1.0-7.fc9
    libhugetlbfs-test-1.1-6.fc9.ppc  requires  libhugetlbfs = 0:1.1-6.fc9
    paraview-3.2.1-6.fc9.ppc64  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.ppc64  requires  paraview-data = 0:3.2.1-6.fc9
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-gtk-0.3.so.4
    scim-bridge-qt-0.4.15-5.fc9.ppc64  requires  scim-bridge = 0:0.4.15-5.fc9
    sear-0.6.3-10.fc9.ppc  requires  libmercator-0.2.so.4
    syck-php-0.61-4.3.fc9.ppc  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc64:

    cyphesis-selinux-0.5.15-6.fc9.ppc64  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.ppc64  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.ppc64  requires  gyachi = 0:1.1.0-7.fc9
    libhugetlbfs-test-1.1-6.fc9.ppc64  requires  libhugetlbfs = 0:1.1-6.fc9
    perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch  requires  darcs >= 0:1.0.0
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-0.3.so.4()(64bit)
    sear-0.6.3-10.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    syck-php-0.61-4.3.fc9.ppc64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-x86_64:

    cyphesis-selinux-0.5.15-6.fc9.x86_64  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.x86_64  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.x86_64  requires  gyachi = 0:1.1.0-7.fc9
    libhugetlbfs-test-1.1-6.fc9.x86_64  requires  libhugetlbfs = 0:1.1-6.fc9
    paraview-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-0.3.so.4()(64bit)
    scim-bridge-qt-0.4.15-5.fc9.i386  requires  scim-bridge = 0:0.4.15-5.fc9
    sear-0.6.3-10.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    syck-php-0.61-4.3.fc9.x86_64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-updates-9-i386:

    cyphesis-0.5.15-8.fc9.i386  requires  libmercator-0.2.so.4
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.i386  requires  libresolv.so.2(GLIBC_PRIVATE)


======================================================================
Broken packages in fedora-updates-9-ppc:

    cyphesis-0.5.15-8.fc9.ppc  requires  libmercator-0.2.so.4
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.ppc  requires  libresolv.so.2(GLIBC_PRIVATE)
    openvas-libraries-1.0.2-2.fc9.ppc64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)


======================================================================
Broken packages in fedora-updates-9-ppc64:

    appliance-tools-002-4.fc9.noarch  requires  qemu-img
    cyphesis-0.5.15-8.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    livecd-tools-017.1-1.fc9.ppc64  requires  yaboot
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.ppc64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)


======================================================================
Broken packages in fedora-updates-9-x86_64:

    cyphesis-0.5.15-8.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.i386  requires  libresolv.so.2(GLIBC_PRIVATE)
    openvas-libraries-1.0.2-2.fc9.x86_64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)



From mschwendt at gmail.com  Sun Dec  7 19:23:58 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 07 Dec 2008 19:23:58 -0000
Subject: Broken dependencies in Fedora 8 - 2008-12-07
Message-ID: <20081207192358.20294.60600@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by owner):

    Axel.Thimm AT ATrpms.net
        mediawiki-openid

    berrange AT redhat.com
        perl-Test-AutoBuild

    dwmw2 AT infradead.org
        callweaver

    ebmunson AT us.ibm.com
        libhugetlbfs

    ianweller AT gmail.com
        mediawiki-HNP
        mediawiki-ParserFunctions
        mediawiki-StubManager

    ismael AT olea.org
        mediawiki-imagemap

    jesusfreak91 AT gmail.com
        nxt_python

    karlthered AT gmail.com
        gtkmozembedmm

    konrad AT tylerc.org
        joda-time

    nigjones AT redhat.com
        mediawiki-SpecialInterwiki

    oliver AT linux-kernel.at
        syck

    rmeggins AT redhat.com
        idm-console-framework


======================================================================
Broken packages in fedora-8-i386:

    callweaver-zaptel-1.2-0.3.rc4.20070822.i386  requires  libpri.so.1.0
    libhugetlbfs-test-1.1-4.fc8.i386  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.i386  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-ppc:

    callweaver-zaptel-1.2-0.3.rc4.20070822.ppc  requires  libpri.so.1.0
    libhugetlbfs-test-1.1-4.fc8.ppc  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.ppc  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-ppc64:

    callweaver-zaptel-1.2-0.3.rc4.20070822.ppc64  requires  libpri.so.1.0()(64bit)
    libhugetlbfs-test-1.1-4.fc8.ppc64  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.ppc64  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-x86_64:

    callweaver-zaptel-1.2-0.3.rc4.20070822.x86_64  requires  libpri.so.1.0()(64bit)
    libhugetlbfs-test-1.1-4.fc8.x86_64  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.x86_64  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-updates-8-i386:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.i386  requires  gecko-libs = 0:1.8.1.17
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb


======================================================================
Broken packages in fedora-updates-8-ppc:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc  requires  gecko-libs = 0:1.8.1.17
    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc64  requires  gecko-libs = 0:1.8.1.17
    idm-console-framework-1.1.2-1.fc8.noarch  requires  java > 0:1.5.0
    joda-time-1.5.2-7.tzdata2008d.fc8.noarch  requires  java > 0:1.5.0
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb


======================================================================
Broken packages in fedora-updates-8-ppc64:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc64  requires  gecko-libs = 0:1.8.1.17
    idm-console-framework-1.1.2-1.fc8.noarch  requires  java > 0:1.5.0
    joda-time-1.5.2-7.tzdata2008d.fc8.noarch  requires  java > 0:1.5.0
    mediawiki-HNP-1.1.2-1.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    mediawiki-StubManager-1.2.0-1.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-imagemap-0-0.1.r37906.fc8.noarch  requires  mediawiki >= 0:1.13
    mediawiki-openid-0.8.2-7.0.1.noarch  requires  mediawiki
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch  requires  darcs >= 0:1.0.0


======================================================================
Broken packages in fedora-updates-8-x86_64:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.i386  requires  gecko-libs = 0:1.8.1.17
    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.x86_64  requires  gecko-libs = 0:1.8.1.17
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb



From iarnell at gmail.com  Sun Dec  7 19:32:35 2008
From: iarnell at gmail.com (Iain Arnell)
Date: Sun, 7 Dec 2008 20:32:35 +0100
Subject: Broken dependencies in Fedora 10 - 2008-12-07
In-Reply-To: <20081207191746.20260.94026@faldor.intranet>
References: <20081207191746.20260.94026@faldor.intranet>
Message-ID: <81487f820812071132t388fe464x3d96ddb186af74f6@mail.gmail.com>

On Sun, Dec 7, 2008 at 8:17 PM, Michael Schwendt <mschwendt at gmail.com> wrote:
[snip]
> Broken packages in fedora-updates-10-i386:
>
>    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(defaults)
>    perl-HTML-FormFu-0.03005-3.fc10.noarch  requires  perl(model_config)
[snip]

I thought I caught this before it was pushed; fix is pending in bodhi.

-- 
Iain.



From lemenkov at gmail.com  Sun Dec  7 20:05:35 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 7 Dec 2008 23:05:35 +0300
Subject: How to determine $JDK_HOME ?
Message-ID: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>

Hello All!
Subj.
Just found that on x86  and ppc OpenJDK-devel installs into
"/usr/lib/jvm/java-1.6.0-openjdk", on x86_64 - into
"/usr/lib/jvm/java-1.6.0-openjdk.x86_64", and on ppc64 - into
"/usr/lib/jvm/java-1.6.0-openjdk.ppc64".

Is it intentional, or this is a bug? In any case how can I pass JDK
home to buildscripts w/o ugly %ifarch/else?

-- 
With best regards!



From walters at verbum.org  Sun Dec  7 20:12:39 2008
From: walters at verbum.org (Colin Walters)
Date: Sun, 7 Dec 2008 15:12:39 -0500
Subject: How to determine $JDK_HOME ?
In-Reply-To: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>
References: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>
Message-ID: <faa16b610812071212h745bcba2g975bc3672b554501@mail.gmail.com>

On Sun, Dec 7, 2008 at 3:05 PM, Peter Lemenkov <lemenkov at gmail.com> wrote:
> In any case how can I pass JDK
> home to buildscripts w/o ugly %ifarch/else?

First, try to make scripts not reliant on the presence of the
JAVA_HOME environment variable.  It should be enough to simply invoke
"java" to get a JVM.

However, if you need it, simply wrap invocations to the scripts with
JAVA_HOME=/etc/alternatives/jre
which uses the alternatives system to point to the system-preferred JRE.



From bashton at brennanashton.com  Sun Dec  7 20:16:16 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sun, 7 Dec 2008 12:16:16 -0800
Subject: How to determine $JDK_HOME ?
In-Reply-To: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>
References: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>
Message-ID: <981da310812071216o4dbb542exe3893972b0ad9458@mail.gmail.com>

On Sun, Dec 7, 2008 at 12:05 PM, Peter Lemenkov <lemenkov at gmail.com> wrote:
> Hello All!
> Subj.
> Just found that on x86  and ppc OpenJDK-devel installs into
> "/usr/lib/jvm/java-1.6.0-openjdk", on x86_64 - into
> "/usr/lib/jvm/java-1.6.0-openjdk.x86_64", and on ppc64 - into
> "/usr/lib/jvm/java-1.6.0-openjdk.ppc64".
>
> Is it intentional, or this is a bug? In any case how can I pass JDK
> home to buildscripts w/o ugly %ifarch/else?
>
> --
> With best regards!

Everything that I have been building, I have been doing without
requiring any of the java environment variables, the way it is setup
right now it should JustWork tm if you call java javac etc.

--Brennan Ashton



From konrad at tylerc.org  Sun Dec  7 20:11:49 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sun, 7 Dec 2008 12:11:49 -0800
Subject: How to determine $JDK_HOME ?
In-Reply-To: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>
References: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>
Message-ID: <200812071211.49565.konrad@tylerc.org>

On Sunday 07 December 2008 12:05:35 pm Peter Lemenkov wrote:
> Hello All!
> Subj.
> Just found that on x86  and ppc OpenJDK-devel installs into
> "/usr/lib/jvm/java-1.6.0-openjdk", on x86_64 - into
> "/usr/lib/jvm/java-1.6.0-openjdk.x86_64", and on ppc64 - into
> "/usr/lib/jvm/java-1.6.0-openjdk.ppc64".
>
> Is it intentional, or this is a bug? In any case how can I pass JDK
> home to buildscripts w/o ugly %ifarch/else?
>
> --
> With best regards!

Well, we also use alternatives to handle choosing the java version to use. If 
JDK_HOME is just supposed to contain 'bin/javac' then you can set it 
to '/usr'.

-- 
Conrad Meyer <konrad at tylerc.org>




From nicolas.mailhot at laposte.net  Sun Dec  7 20:44:43 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 07 Dec 2008 21:44:43 +0100
Subject: How to determine $JDK_HOME ?
In-Reply-To: <200812071211.49565.konrad@tylerc.org>
References: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>
	<200812071211.49565.konrad@tylerc.org>
Message-ID: <1228682683.5333.1.camel@arekh.okg>

Le dimanche 07 d?cembre 2008 ? 12:11 -0800, Conrad Meyer a ?crit :
> On Sunday 07 December 2008 12:05:35 pm Peter Lemenkov wrote:
> > Hello All!
> > Subj.
> > Just found that on x86  and ppc OpenJDK-devel installs into
> > "/usr/lib/jvm/java-1.6.0-openjdk", on x86_64 - into
> > "/usr/lib/jvm/java-1.6.0-openjdk.x86_64", and on ppc64 - into
> > "/usr/lib/jvm/java-1.6.0-openjdk.ppc64".
> >
> > Is it intentional, or this is a bug? In any case how can I pass JDK
> > home to buildscripts w/o ugly %ifarch/else?

> Well, we also use alternatives to handle choosing the java version to use. If 
> JDK_HOME is just supposed to contain 'bin/javac' then you can set it 
> to '/usr'.

The "jre" alternative controls access to the default system jre, and the
"java" alternative does the same for the full jdk

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/6c90458d/attachment.sig>

From lemenkov at gmail.com  Sun Dec  7 20:46:58 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 7 Dec 2008 23:46:58 +0300
Subject: How to determine $JDK_HOME ?
In-Reply-To: <faa16b610812071212h745bcba2g975bc3672b554501@mail.gmail.com>
References: <adf480660812071205t1fc094ccra01833b0c6f8eeaa@mail.gmail.com>
	<faa16b610812071212h745bcba2g975bc3672b554501@mail.gmail.com>
Message-ID: <adf480660812071246j14a09d2bydf8c859a70b89d68@mail.gmail.com>

2008/12/7, Colin Walters <walters at verbum.org>:
> On Sun, Dec 7, 2008 at 3:05 PM, Peter Lemenkov <lemenkov at gmail.com> wrote:
>  > In any case how can I pass JDK
>  > home to buildscripts w/o ugly %ifarch/else?

> First, try to make scripts not reliant on the presence of the
>  JAVA_HOME environment variable.  It should be enough to simply invoke
>  "java" to get a JVM.

I'll do.

>  However, if you need it, simply wrap invocations to the scripts with
>  JAVA_HOME=/etc/alternatives/jre
>  which uses the alternatives system to point to the system-preferred JRE.

Thanks! It's working.

-- 
With best regards!



From kevin at scrye.com  Sun Dec  7 21:09:22 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 7 Dec 2008 14:09:22 -0700
Subject: OCaml status
In-Reply-To: <20081205174757.GA27576@thinkpad>
References: <20081205174757.GA27576@thinkpad>
Message-ID: <20081207140922.272d1506@ohm.scrye.com>

On Fri, 5 Dec 2008 17:47:57 +0000
rjones at redhat.com ("Richard W.M. Jones") wrote:

> I believe that all broken dependencies should now be resolved.
> There's just a couple of final packages going through Koji now and
> once Koji does another createrepo, I hope that there won't be any
> broken deps.  Well hopefully ...  we'll see tomorrow.
> 
>   http://cocan.org/fedora#Package_status
> 
> I've rebuilt all the OCaml-based applications, and they are all OK ..

Excellent. That you for taking care of those so quickly and
smoothly. ;) 

...snip...
>
> Rich.
> 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/a6ad588b/attachment.sig>

From jkeating at redhat.com  Sun Dec  7 21:22:46 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 07 Dec 2008 13:22:46 -0800
Subject: Work needed, how you can help!
Message-ID: <1228684966.3370.22.camel@localhost.localdomain>

rpm recently began auto-discovering requirements based on contents of
pkg-config files (.pc).  This is awesome stuff, and will help developers
out a lot.  However because of this, non-devel packages are suddenly
requiring pkg-config deps, and pkgconfig itself.

This is due to packages having their .pc file in the base package rather
than a -devel subpackage.  There is a review guideline for this ( tail
end of http://fedoraproject.org/wiki/Packaging/ReviewGuidelines ) but I
couldn't find the matching Guideline entry so it's not surprising that
this could have been missed.

The work needed is for somebody to examine all the packages in rawhide
that provide .pc files and ensure proper placement of them based on the
review guideline.  This will likely require interaction with the
packages maintainer(s) so the first step should probably be to produce a
list of packages that ship .pc in a non -devel package and send the list
(sorted by maintainer) to here so that we can discuss and pick off
items.

Thanks!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/aaf88e27/attachment.sig>

From kevin.kofler at chello.at  Sun Dec  7 21:34:49 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 07 Dec 2008 22:34:49 +0100
Subject: Work needed, how you can help!
References: <1228684966.3370.22.camel@localhost.localdomain>
Message-ID: <ghhfhp$erv$2@ger.gmane.org>

Jesse Keating wrote:
> This is due to packages having their .pc file in the base package rather
> than a -devel subpackage.  There is a review guideline for this ( tail
> end of http://fedoraproject.org/wiki/Packaging/ReviewGuidelines ) but I
> couldn't find the matching Guideline entry so it's not surprising that
> this could have been missed.

Well, there are cases where pkg-config is used at runtime, which is why the
MUST was changed to a SHOULD and the "The placement of pkgconfig(.pc) files
depends on their usecase, and this is usually for development purposes"
wording is now used. Talk to the FPC folks if you need to know more about
this issue. In the cases where it is indeed used at runtime, requiring
pkgconfig is actually the right thing to do (but requiring various -devel
packages isn't - if that's what's happpening, something needs to be done
about it).

        Kevin Kofler



From jkeating at redhat.com  Sun Dec  7 21:38:28 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 07 Dec 2008 13:38:28 -0800
Subject: Work needed, how you can help!
In-Reply-To: <ghhfhp$erv$2@ger.gmane.org>
References: <1228684966.3370.22.camel@localhost.localdomain>
	<ghhfhp$erv$2@ger.gmane.org>
Message-ID: <1228685908.3370.24.camel@localhost.localdomain>

On Sun, 2008-12-07 at 22:34 +0100, Kevin Kofler wrote:
> 
> Well, there are cases where pkg-config is used at runtime, which is why the
> MUST was changed to a SHOULD and the "The placement of pkgconfig(.pc) files
> depends on their usecase, and this is usually for development purposes"
> wording is now used. Talk to the FPC folks if you need to know more about
> this issue. In the cases where it is indeed used at runtime, requiring
> pkgconfig is actually the right thing to do (but requiring various -devel
> packages isn't - if that's what's happpening, something needs to be done
> about it).

That's why I said "ensure proper placement of them based on the
review guideline." and the guideline explains the proper placement.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/a1abe134/attachment.sig>

From lesmikesell at gmail.com  Sun Dec  7 21:42:32 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 07 Dec 2008 15:42:32 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812050806te18c699te29f3376a4f154ad@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<16de708d0812050806te18c699te29f3376a4f154ad@mail.gmail.com>
Message-ID: <493C4348.20701@gmail.com>

Arthur Pemberton wrote:
> 
>> We're just now dealing with Python 2.6, but over on the radar is perhaps one
>> of the most incompatible upgrades to the language we've seen in Python 3.  I
>> personally haven't tried it yet, but it /aims/ to be incompatble, which is
>> perhaps one of the most glaring signs a language designer has lost it that
>> I've seen.
> 
> 
> Was that last line really necessary for your post?

Incompatibility isn't a relative thing.  More/most, etc., are irrelevant 
because compatibility is a yes or no question.  If you want a language 
that you can expect to run your programs unchanged in the future, you 
should have learned years ago that python wasn't it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mschwendt at gmail.com  Sun Dec  7 21:46:01 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 7 Dec 2008 22:46:01 +0100
Subject: Work needed, how you can help!
In-Reply-To: <ghhfhp$erv$2@ger.gmane.org>
References: <1228684966.3370.22.camel@localhost.localdomain>
	<ghhfhp$erv$2@ger.gmane.org>
Message-ID: <20081207224601.dd75822c.mschwendt@gmail.com>

On Sun, 07 Dec 2008 22:34:49 +0100, Kevin wrote:

> Well, there are cases where pkg-config is used at runtime, which is why the
> MUST was changed to a SHOULD and the "The placement of pkgconfig(.pc) files
> depends on their usecase, and this is usually for development purposes"
> wording is now used. Talk to the FPC folks if you need to know more about
> this issue. In the cases where it is indeed used at runtime, requiring
> pkgconfig is actually the right thing to do 

That only works if the entire .pc dependency-chain is available
in non-devel packages. In other words, it breaks if one of the .pc
files Requires a .pc file located in a -devel pkg.



From dominik at greysector.net  Sun Dec  7 21:47:03 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sun, 7 Dec 2008 22:47:03 +0100
Subject: Scanner's firmware HOWTO and suggestions for improving user's
	experience with scanners
In-Reply-To: <1228604033.3495.90.camel@agnes.fremen.dune>
References: <1228604033.3495.90.camel@agnes.fremen.dune>
Message-ID: <20081207214702.GA1280@mokona.greysector.net>

On Saturday, 06 December 2008 at 23:53, Jean Francois Martinez wrote:
[...]
> Suggestions:
> 
> In completely ideal world fedora would procide the firmware files and
> everything would just work but I guess Epson's licensing (copy, give,
> don't disassemble, don't sell) is a NO-NO 
> 
> 
> If Fedora can't provide the formware then perhaps we could provide that
> ewhen sane fails to drive a scanner its error message points to firmware
> and towards a file  telling the above.

We could probably ship the firmware in RPMFusion. If you're not interested
in maintaining a firmware package then I'll see if I can do it myself or find
someone else who will.

> A less ambitious proposition would be:
> -to include the above text in sane's doc
> -Modify the /etc/sane.d/snapscan.conf so it points the user to the
> file in the preceeding alinea
> -the directory /usr/share/sane/snapscan should be part of the xsane
> package

File a bug, please.

> -The firmware line in /etc/sane.d/snapscan.conf should not point towards
> your-firmware-file.bin in the /etc/share/sane.d/snapcan but towards
> snapscan.bin and, when user powers on the scan it would be udev's work
> to make a snapcan.bin sumbolic link pointing towards the right firmware
> file.

File a bug, please.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jkeating at redhat.com  Sun Dec  7 21:50:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 07 Dec 2008 13:50:14 -0800
Subject: Work needed, how you can help!
In-Reply-To: <20081207224601.dd75822c.mschwendt@gmail.com>
References: <1228684966.3370.22.camel@localhost.localdomain>
	<ghhfhp$erv$2@ger.gmane.org>
	<20081207224601.dd75822c.mschwendt@gmail.com>
Message-ID: <1228686614.3370.25.camel@localhost.localdomain>

On Sun, 2008-12-07 at 22:46 +0100, Michael Schwendt wrote:
> 
> That only works if the entire .pc dependency-chain is available
> in non-devel packages. In other words, it breaks if one of the .pc
> files Requires a .pc file located in a -devel pkg.

that's acceptable.  The scenario is if the base package /is/ a
development type package, it just doesn't have -devel.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/f5c72aaa/attachment.sig>

From lesmikesell at gmail.com  Sun Dec  7 21:54:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 07 Dec 2008 15:54:51 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <corn06xveo.ln2@ppp1053.in.ipex.cz>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
Message-ID: <493C462B.4070607@gmail.com>

Matej Cepl wrote:
> On 2008-12-05, 14:42 GMT, Michael DeHaan wrote:
>> I personally haven't tried it yet, but it /aims/ to be 
>> incompatble, which is perhaps one of the most glaring signs 
>> a language designer has lost it that I've seen.
> 
> Guido was preparing on this incompatibility for years, so unless 
> you were sleeping you should not be surprised.

Not being surprised is one thing, but I don't see how anyone could be 
prepared other than not using any python code.


>> but it's pretty bad for someone who wants to keep a single 
>> codebase across EL 4 (Python 2.3) and up, which I think a lot 
>> of us do.
> 
> The party line is that you should develop against python 2.6 
> (which doesn't block you from being compatible with Python 2.3) 
> and then conversion from 2.6 to 3.* would be guaranteed to be 
> done just with a script.

Is there some shortage of names?  Why can't a new and incompatible 
language be given a different name so people don't try to use it with 
the old and different code?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From berrange at redhat.com  Sun Dec  7 22:09:18 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Sun, 7 Dec 2008 22:09:18 +0000
Subject: Work needed, how you can help!
In-Reply-To: <1228684966.3370.22.camel@localhost.localdomain>
References: <1228684966.3370.22.camel@localhost.localdomain>
Message-ID: <20081207220918.GF3386@redhat.com>

On Sun, Dec 07, 2008 at 01:22:46PM -0800, Jesse Keating wrote:
> rpm recently began auto-discovering requirements based on contents of
> pkg-config files (.pc).  This is awesome stuff, and will help developers
> out a lot.  However because of this, non-devel packages are suddenly
> requiring pkg-config deps, and pkgconfig itself.
> 
> This is due to packages having their .pc file in the base package rather
> than a -devel subpackage.  There is a review guideline for this ( tail
> end of http://fedoraproject.org/wiki/Packaging/ReviewGuidelines ) but I
> couldn't find the matching Guideline entry so it's not surprising that
> this could have been missed.
> 
> The work needed is for somebody to examine all the packages in rawhide
> that provide .pc files and ensure proper placement of them based on the
> review guideline.  This will likely require interaction with the
> packages maintainer(s) so the first step should probably be to produce a
> list of packages that ship .pc in a non -devel package and send the list
> (sorted by maintainer) to here so that we can discuss and pick off
> items.

FYI, a reminder to anyone generating reports on this... All Mingw 
packages are effectively developement packages, so it is expected
that the base mingw32-XXXX RPM contains the .pc file.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -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 lesmikesell at gmail.com  Sun Dec  7 22:56:58 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 07 Dec 2008 16:56:58 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812071151.38419.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812070954.31864.sgrubb@redhat.com>	<87k5ac9cat.fsf@sheridan.bigo.ensc.de>
	<200812071151.38419.sgrubb@redhat.com>
Message-ID: <493C54BA.2020008@gmail.com>

Steve Grubb wrote:
> 
>>> The utilities that would allow you to modify it cannot be accessed
>>> unless you are root.
>> Sounds like "when the algorithm is hidden, the crypto mechanism is
>> secure"...
> 
> I wouldn't characterize it like that. It means that you have established 
> proceedures that ensure the Security Objectives are met.

What does that mean?  Why is it necessary to prevent anyone but root 
from running the utility when in fact your security objectives can only 
be met when the files the utility accesses can only be modified by root? 
Which program is used to modify the file is pretty much irrelevant.

It is hard to take these concepts seriously when they add unnecessary cruft.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From abartlet at samba.org  Sun Dec  7 23:03:09 2008
From: abartlet at samba.org (Andrew Bartlett)
Date: Mon, 08 Dec 2008 10:03:09 +1100
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812071151.38419.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812070954.31864.sgrubb@redhat.com>
	<87k5ac9cat.fsf@sheridan.bigo.ensc.de>
	<200812071151.38419.sgrubb@redhat.com>
Message-ID: <1228690989.3923.9.camel@naomi.s4.naomi.abartlet.net>

On Sun, 2008-12-07 at 11:51 -0500, Steve Grubb wrote:
> On Sunday 07 December 2008 11:31:54 Enrico Scholz wrote:
> > Both 'vipw' and 'ldapadd' are official and documented tools to manage
> > user database.
> 
> vipw I believe is forbidden due to its ability to circumvent auditing of user-
> subject binding. 

Perhaps I'm a bit slow this morning, but vipw is forbidden but
vi /etc/passwd isn't?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/9c0253f5/attachment.sig>

From jkeating at redhat.com  Sun Dec  7 23:05:21 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 07 Dec 2008 15:05:21 -0800
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228690989.3923.9.camel@naomi.s4.naomi.abartlet.net>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812070954.31864.sgrubb@redhat.com>
	<87k5ac9cat.fsf@sheridan.bigo.ensc.de>
	<200812071151.38419.sgrubb@redhat.com>
	<1228690989.3923.9.camel@naomi.s4.naomi.abartlet.net>
Message-ID: <1228691121.3370.28.camel@localhost.localdomain>

On Mon, 2008-12-08 at 10:03 +1100, Andrew Bartlett wrote:
> 
> Perhaps I'm a bit slow this morning, but vipw is forbidden but
> vi /etc/passwd isn't?

I think he means "forbidden by policy" in which using anything /but/ the
audit-able tools is "forbidden by policy".  If you're expecting
everybody to follow policy, why not just set policy that says "don't
hack this box".  That'll work right?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081207/afc02dd4/attachment.sig>

From mitr at volny.cz  Sun Dec  7 23:09:24 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Sun, 07 Dec 2008 23:09:24 +0000
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228691121.3370.28.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812070954.31864.sgrubb@redhat.com>
	<87k5ac9cat.fsf@sheridan.bigo.ensc.de>
	<200812071151.38419.sgrubb@redhat.com>
	<1228690989.3923.9.camel@naomi.s4.naomi.abartlet.net>
	<1228691121.3370.28.camel@localhost.localdomain>
Message-ID: <1228691364.3311.66.camel@localhost.localdomain>

Jesse Keating p??e v Ne 07. 12. 2008 v 15:05 -0800:
> On Mon, 2008-12-08 at 10:03 +1100, Andrew Bartlett wrote:
> > 
> > Perhaps I'm a bit slow this morning, but vipw is forbidden but
> > vi /etc/passwd isn't?
> 
> I think he means "forbidden by policy" in which using anything /but/ the
> audit-able tools is "forbidden by policy".  If you're expecting
> everybody to follow policy, why not just set policy that says "don't
> hack this box".  That'll work right?
Violations of "don't hack this box" don't generate audit messages that
can be manually examined for actual intrusions.  Violations of "don't
access /etc/shadow manually" do.
	Mirek



From jspaleta at gmail.com  Sun Dec  7 23:29:47 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 7 Dec 2008 14:29:47 -0900
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812070954.31864.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
	<604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
	<200812070954.31864.sgrubb@redhat.com>
Message-ID: <604aa7910812071529h4e14eff7l55614033eeddddd0@mail.gmail.com>

On Sun, Dec 7, 2008 at 5:54 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> Hope you find this informtion useful.

Well it's certainly going to make for a more rational discussion.

I still come back to one thing.  Could the file permissions be
implemented differently so that CAPP compliance could be a system
install time choice, instead of being expressed in the configuration
of all installs?

Sort of how we make it possible for people who care about LSB
compliance to be able to install the necessary bits without enforcing
compliance on everyone else. Just sort of, I'm not suggesting security
compliance and LSB compliance are anywhere close to the same thing in
scope.

But what I am saying is that I'm not sure the restrictions and
assumptions behind the logic of CAPP makes a lot of sense for our
default target usecases.  We don't currently have a server target for
example, and I'm not sure CAPP can be applied to something like a
laptop desktop case without warping spacetime.

So taking a look at how CAPP compliance is handled now, could some of
the restrictions like the permissions be handled in a more modular
way? Could for example, things be changed so I could install a
specialized fedora-CAPP package at install time which tightens up
aspects of the system to bring it into CAPP compliance, instead of
expressing those restrictions in the defualt settings of all installs?

-jef



From lesmikesell at gmail.com  Sun Dec  7 23:34:18 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 07 Dec 2008 17:34:18 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <1228691364.3311.66.camel@localhost.localdomain>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812070954.31864.sgrubb@redhat.com>	<87k5ac9cat.fsf@sheridan.bigo.ensc.de>	<200812071151.38419.sgrubb@redhat.com>	<1228690989.3923.9.camel@naomi.s4.naomi.abartlet.net>	<1228691121.3370.28.camel@localhost.localdomain>
	<1228691364.3311.66.camel@localhost.localdomain>
Message-ID: <493C5D7A.101@gmail.com>

Miloslav Trma? wrote:
> Jesse Keating p??e v Ne 07. 12. 2008 v 15:05 -0800:
>> On Mon, 2008-12-08 at 10:03 +1100, Andrew Bartlett wrote:
>>> Perhaps I'm a bit slow this morning, but vipw is forbidden but
>>> vi /etc/passwd isn't?
>> I think he means "forbidden by policy" in which using anything /but/ the
>> audit-able tools is "forbidden by policy".  If you're expecting
>> everybody to follow policy, why not just set policy that says "don't
>> hack this box".  That'll work right?

> Violations of "don't hack this box" don't generate audit messages that
> can be manually examined for actual intrusions.  Violations of "don't
> access /etc/shadow manually" do.

Is attempting an access that the kernel routinely prevents considered a 
violation?  That is, if I type 'file /etc/*' on such a system should I 
expect the black helicopters to start firing?  I don't see how accesses 
that are denied matter to anyone - or why anyone running the 
shadow-tools utility without permission to access the relevant files 
should bother anyone either.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From bernie at codewiz.org  Mon Dec  8 00:15:35 2008
From: bernie at codewiz.org (Bernie Innocenti)
Date: Sun, 07 Dec 2008 19:15:35 -0500
Subject: libgnome-devel depends on esound-devel
Message-ID: <493C6727.5020701@codewiz.org>

Any idea why?  Can we drop this dependency?

-- 
   // Bernie Innocenti - http://www.codewiz.org/
 \X/  Sugar Labs       - http://www.sugarlabs.org/



From abartlet at samba.org  Mon Dec  8 00:55:27 2008
From: abartlet at samba.org (Andrew Bartlett)
Date: Mon, 08 Dec 2008 11:55:27 +1100
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <604aa7910812071529h4e14eff7l55614033eeddddd0@mail.gmail.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812061335.26488.sgrubb@redhat.com>
	<604aa7910812061057v1ae4cfe8y8cbb70477a6431d6@mail.gmail.com>
	<200812070954.31864.sgrubb@redhat.com>
	<604aa7910812071529h4e14eff7l55614033eeddddd0@mail.gmail.com>
Message-ID: <1228697727.3923.19.camel@naomi.s4.naomi.abartlet.net>

On Sun, 2008-12-07 at 14:29 -0900, Jeff Spaleta wrote:
> On Sun, Dec 7, 2008 at 5:54 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> > Hope you find this informtion useful.
> 
> Well it's certainly going to make for a more rational discussion.
> 
> I still come back to one thing.  Could the file permissions be
> implemented differently so that CAPP compliance could be a system
> install time choice, instead of being expressed in the configuration
> of all installs?
> 
> Sort of how we make it possible for people who care about LSB
> compliance to be able to install the necessary bits without enforcing
> compliance on everyone else. Just sort of, I'm not suggesting security
> compliance and LSB compliance are anywhere close to the same thing in
> scope.
> 
> But what I am saying is that I'm not sure the restrictions and
> assumptions behind the logic of CAPP makes a lot of sense for our
> default target usecases.  We don't currently have a server target for
> example, and I'm not sure CAPP can be applied to something like a
> laptop desktop case without warping spacetime.
> 
> So taking a look at how CAPP compliance is handled now, could some of
> the restrictions like the permissions be handled in a more modular
> way? Could for example, things be changed so I could install a
> specialized fedora-CAPP package at install time which tightens up
> aspects of the system to bring it into CAPP compliance, instead of
> expressing those restrictions in the defualt settings of all installs?

Perhaps a bit like the 'bastille' hardening script?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/025565b8/attachment.sig>

From roopesh.majeti at gmail.com  Mon Dec  8 03:52:09 2008
From: roopesh.majeti at gmail.com (Roopesh Majeti)
Date: Mon, 8 Dec 2008 09:22:09 +0530
Subject: mayavi - anyone interested in collaborating on packaging?
In-Reply-To: <b401d2530812070530h787c339exe3ba76aa748ada64@mail.gmail.com>
References: <b401d2530812070530h787c339exe3ba76aa748ada64@mail.gmail.com>
Message-ID: <599059470812071952j720929ai63488226c692c0fb@mail.gmail.com>

Hi Rakesh,
Would be interested, if the project is in its initial phase.
Please let me know, as what contribution i can do, as iam new to Fedora [
but ofcourse installed F9 and setup my Fedora account ].

Regards
Roopesh
alias : RAT.




On Sun, Dec 7, 2008 at 7:00 PM, Rakesh Pandit <rakesh.pandit at gmail.com>wrote:

> Hello,
>
> http://code.enthought.com/projects/mayavi/
>
> $subject
>
> I already started working on it. The project is big and has a good
> user base. Anyone interested in getting it into fedora and helping in
> packaging would be greatly appreciated :). Please drop a mail off list
> so that we can coordinate.
>
> It needs Traits and Traits UI [1] to be in and I am about to finish these
> two.
>
> [1] http://code.enthought.com/projects/traits/
>
> --
> Regards,
> Rakesh Pandit
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/cfbe9ac4/attachment.htm>

From balbir at linux.vnet.ibm.com  Mon Dec  8 06:29:52 2008
From: balbir at linux.vnet.ibm.com (Balbir Singh)
Date: Mon, 8 Dec 2008 11:59:52 +0530
Subject: Enabling the memory controller for F11
Message-ID: <20081208062952.GG13333@balbir.in.ibm.com>

Hi,

Its me again with a request to enable the memory controller for F11.
2.6.28-rc1 got rid of the cgroup member in struct page and thus the
overhead w.r.t. having it enabled on 32 bit systems. As we move into
the F11 cycle, I would request enablement of the memory controller.

Please let me know if you need more information.

-- 
	Balbir



From huzaifas at redhat.com  Mon Dec  8 07:20:44 2008
From: huzaifas at redhat.com (Huzaifa Sidhpurwala)
Date: Mon, 08 Dec 2008 12:50:44 +0530
Subject: Can luks in fedora 10 ,
	encrypt using a combination of keys and passphrase
Message-ID: <493CCACC.1010707@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
I am looking at a corporate deployment scenario here, where the laptop
is encrypted by anaconda during the kickstart process.
However users can forget their passwords and we dont want to re-install
their laptops if they do.

Can we add a key to the already encrypted luks partition, so that when
the user forgets the passphrase, we can make use of the private key + IT
passphrase and unlock the partitions?

It would be just great if this is possible,


- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)


GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFJPMrMzHDc8tpb2uURAphiAJ9f7wMpcsmc7KY6iFTvOxcHgDkbTACfWYtn
Md/WZcTqk93K0kwD9smEMQ4=
=Wp3l
-----END PGP SIGNATURE-----



From trond.danielsen at gmail.com  Mon Dec  8 07:24:34 2008
From: trond.danielsen at gmail.com (Trond Danielsen)
Date: Mon, 8 Dec 2008 08:24:34 +0100
Subject: mayavi - anyone interested in collaborating on packaging?
In-Reply-To: <b401d2530812070530h787c339exe3ba76aa748ada64@mail.gmail.com>
References: <b401d2530812070530h787c339exe3ba76aa748ada64@mail.gmail.com>
Message-ID: <409676c70812072324j409d45d0sc5f82f4aeda9ea46@mail.gmail.com>

2008/12/7 Rakesh Pandit <rakesh.pandit at gmail.com>:
> Hello,
>
> http://code.enthought.com/projects/mayavi/
>
> $subject
>
> I already started working on it. The project is big and has a good
> user base. Anyone interested in getting it into fedora and helping in
> packaging would be greatly appreciated :). Please drop a mail off list
> so that we can coordinate.
>
> It needs Traits and Traits UI [1] to be in and I am about to finish these two.
>
> [1] http://code.enthought.com/projects/traits/

You might want to check out this thread from fedora-python-devel:
https://www.redhat.com/archives/fedora-python-devel-list/2008-April/msg00006.html

-- 
Trond Danielsen



From bruno at wolff.to  Mon Dec  8 07:27:34 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 8 Dec 2008 01:27:34 -0600
Subject: Can luks in fedora 10 , encrypt using a combination of keys
	and passphrase
In-Reply-To: <493CCACC.1010707@redhat.com>
References: <493CCACC.1010707@redhat.com>
Message-ID: <20081208072734.GA9119@wolff.to>

On Mon, Dec 08, 2008 at 12:50:44 +0530,
> 
> Can we add a key to the already encrypted luks partition, so that when
> the user forgets the passphrase, we can make use of the private key + IT
> passphrase and unlock the partitions?

Luks supports multiple keys. In general you need to know the passphrase
for a key slot in order to muck with it in supported ways. So users should
not be able to change the admin passphrase without admin type access.



From huzaifas at redhat.com  Mon Dec  8 07:31:03 2008
From: huzaifas at redhat.com (Huzaifa Sidhpurwala)
Date: Mon, 08 Dec 2008 13:01:03 +0530
Subject: Can luks in fedora 10 , encrypt using a combination of keys	and
 passphrase
In-Reply-To: <20081208072734.GA9119@wolff.to>
References: <493CCACC.1010707@redhat.com> <20081208072734.GA9119@wolff.to>
Message-ID: <493CCD37.1000803@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Wolff III wrote:
> On Mon, Dec 08, 2008 at 12:50:44 +0530,
>> Can we add a key to the already encrypted luks partition, so that when
>> the user forgets the passphrase, we can make use of the private key + IT
>> passphrase and unlock the partitions?
> 
> Luks supports multiple keys. In general you need to know the passphrase
> for a key slot in order to muck with it in supported ways. So users should
> not be able to change the admin passphrase without admin type access.
Right,
But i am looking at a scenario in which i can have the encryption done
with passphrase + a public key,
i dont want to depend upon just the passphrase to decrypt stuff

- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)


GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFJPM03zHDc8tpb2uURAlN2AJoDPl2owbjWcLLJaX2+4tQbq7G9zACfbOjI
QUDyEzMhYI/Zu2xcoCLOcw0=
=9ZSL
-----END PGP SIGNATURE-----



From bruno at wolff.to  Mon Dec  8 07:42:57 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 8 Dec 2008 01:42:57 -0600
Subject: Can luks in fedora 10 , encrypt using a combination of keys and
	passphrase
In-Reply-To: <493CCD37.1000803@redhat.com>
References: <493CCACC.1010707@redhat.com> <20081208072734.GA9119@wolff.to>
	<493CCD37.1000803@redhat.com>
Message-ID: <20081208074257.GA11244@wolff.to>

On Mon, Dec 08, 2008 at 13:01:03 +0530,
  Huzaifa Sidhpurwala <huzaifas at redhat.com> wrote:
> But i am looking at a scenario in which i can have the encryption done
> with passphrase + a public key,
> i dont want to depend upon just the passphrase to decrypt stuff

I don't think Fedora's boot environment supports dongles for use with luks if
that is what you want to do.
I think luks supports some different ways to get the key from a key slot.
I remember seeing an option for supplying a key file instead of a password.
I haven't played with that though and haven't looked at the luks documentation
for a while. It may be that there are some other options.
The home page for luks has some low level details on the data structures
for the key slots and the like.
You might also find some useful information in the man page for cryptsetup.



From mmaslano at redhat.com  Mon Dec  8 08:18:23 2008
From: mmaslano at redhat.com (Marcela Maslanova)
Date: Mon, 08 Dec 2008 09:18:23 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081205201621.GC3227@free.fr>
References: <20081205195914.GB3227@free.fr>	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr>
Message-ID: <493CD84F.6010309@redhat.com>

Patrice Dumas wrote:
> On Fri, Dec 05, 2008 at 12:05:30PM -0800, Jesse Keating wrote:
>> On Fri, 2008-12-05 at 20:59 +0100, Patrice Dumas wrote:
>>> I won't push this more, somebody else has to volunteer to make this 
>>> happen. I think it could be done in F11 and it should be a feature.
>> What are the deplists comparatively?
> 
> fcron has additionally 
>  vim-minimal  
> But I think that this is also a cronie dep that is missing (I think
> /usr/bin/crontab defaults to use it).
cronie isn't missing vim. It uses default text editor.
> 
> fcron also uses /usr/bin/setsid. I don't think this is annoying, and to
> avoid it trivial C code could be used.
> 
>> Has fcron had a security audit recently?
> 
> What exactly do you mean here? Are you referring to an audit done by
> some specific people, or using some methodology? Or a security audit in
> a vague sense?
> 
> --
> Pat
> 


-- 
Marcela Ma?l??ov?
BaseOS team Brno



From mmaslano at redhat.com  Mon Dec  8 08:26:24 2008
From: mmaslano at redhat.com (Marcela Maslanova)
Date: Mon, 08 Dec 2008 09:26:24 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081205195914.GB3227@free.fr>
References: <20081205195914.GB3227@free.fr>
Message-ID: <493CDA30.7030909@redhat.com>

Patrice Dumas wrote:
> Hello,
> 
> I think that fcron should be the default scheduler in fedora.
> fcron, with the service fcron_watch_config activated should now be 
> 100% compatible with vixie-cron (cronie). The fcron_watch_config stuff 
> is a bit convoluted (3 scripts and one C program...) but should work.
> 
> The advantages over cronie are the following:
> * it also does what anacron does
> * it has more features
> * instead of waking up every minutes to look at config files, like
>   cronie do, it uses inotify to watch the config. This should lead to
>   less awaking and certainly be interesting for power saving in some
>   situations
cronie is also using inotify, longer than fcron ;-) So this is not
advantage.
> 
> I won't push this more, somebody else has to volunteer to make this 
> happen. I think it could be done in F11 and it should be a feature.
> 
> --
> Pat
> 


-- 
Marcela Ma?l??ov?
BaseOS team Brno



From huzaifas at redhat.com  Mon Dec  8 08:40:58 2008
From: huzaifas at redhat.com (Huzaifa Sidhpurwala)
Date: Mon, 08 Dec 2008 14:10:58 +0530
Subject: Can luks in fedora 10 , encrypt using a combination of keys and
 passphrase
In-Reply-To: <20081208074257.GA11244@wolff.to>
References: <493CCACC.1010707@redhat.com> <20081208072734.GA9119@wolff.to>
	<493CCD37.1000803@redhat.com> <20081208074257.GA11244@wolff.to>
Message-ID: <493CDD9A.60706@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Wolff III wrote:
> On Mon, Dec 08, 2008 at 13:01:03 +0530,
>   Huzaifa Sidhpurwala <huzaifas at redhat.com> wrote:
>> But i am looking at a scenario in which i can have the encryption done
>> with passphrase + a public key,
>> i dont want to depend upon just the passphrase to decrypt stuff
> 
> I don't think Fedora's boot environment supports dongles for use with luks if
> that is what you want to do.
> I think luks supports some different ways to get the key from a key slot.
> I remember seeing an option for supplying a key file instead of a password.
> I haven't played with that though and haven't looked at the luks documentation
> for a while. It may be that there are some other options.
> The home page for luks has some low level details on the data structures
> for the key slots and the like.
> You might also find some useful information in the man page for cryptsetup.
Yep,
I am wondering if i can have one slot filled by a passphrase and the
second one by a key, do you know if that is possible?

- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)


GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFJPN2azHDc8tpb2uURAusBAJsF32BNT0BVHCus54WFCtVyHJmRNgCeNcNY
LxIOzEsO+G1LMuL60VACP3w=
=YAeE
-----END PGP SIGNATURE-----



From benny+usenet at amorsen.dk  Mon Dec  8 10:05:42 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Mon, 08 Dec 2008 11:05:42 +0100
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061252.26557.sgrubb@redhat.com> (Steve Grubb's message of
	"Sat\, 6 Dec 2008 12\:52\:26 -0500")
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228582591.4814.37.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
Message-ID: <m3bpvn9e2x.fsf@ursa.amorsen.dk>

Steve Grubb <sgrubb at redhat.com> writes:

> An unprivileged user cannot successfully use this utility. Just like tcpdump 
> can't be used. The difference is that shadow-utils modifies a trusted database 
> and tcpdump doesn't. 

tcpdump runs perfectly fine as a normal user. Notice the -r option.


/Benny



From paul at all-the-johnsons.co.uk  Mon Dec  8 10:31:27 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Mon, 08 Dec 2008 10:31:27 +0000
Subject: Problem importing packages
Message-ID: <1228732287.29271.35.camel@PB3.Linux>

Hi,

Has something changed for importing to rawhide?

I've just rebuild mono-2.2 preview 2 and am trying to upload it using

./cvs-import.sh ~/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm

and all I get back out is an annoying error

ERROR: Package /home/paul/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm
does not look like a source RPM package

Any ideas on what is causing 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/858d262d/attachment.sig>

From pertusus at free.fr  Mon Dec  8 10:57:21 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 11:57:21 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <493CDA30.7030909@redhat.com>
References: <20081205195914.GB3227@free.fr> <493CDA30.7030909@redhat.com>
Message-ID: <20081208105721.GA2611@free.fr>

On Mon, Dec 08, 2008 at 09:26:24AM +0100, Marcela Maslanova wrote:

> cronie is also using inotify, longer than fcron ;-) So this is not
> advantage.

There is something strange, then it seemed to me that it accessed config
file and directories every minutes. I'll have a look at the code.

--
Pat



From pertusus at free.fr  Mon Dec  8 11:12:31 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 12:12:31 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <493CD84F.6010309@redhat.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
Message-ID: <20081208111231.GB2611@free.fr>

On Mon, Dec 08, 2008 at 09:18:23AM +0100, Marcela Maslanova wrote:

> cronie isn't missing vim. It uses default text editor.

If there is none, it uses /bin/vi. In fact I have sone a bit of
investigations and it uses, in pathnames.h _PATH_VI which is defined in
/usr/invlude/paths.h.

So it is a missing dependency, in my opinion.

--
Pat



From pertusus at free.fr  Mon Dec  8 11:29:19 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 12:29:19 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <493CDA30.7030909@redhat.com>
References: <20081205195914.GB3227@free.fr> <493CDA30.7030909@redhat.com>
Message-ID: <20081208112919.GC2611@free.fr>

On Mon, Dec 08, 2008 at 09:26:24AM +0100, Marcela Maslanova wrote:

> cronie is also using inotify, longer than fcron ;-) So this is not
> advantage.

Indeed. (As a side note, since fcron didn't watched at all for those 
files and directories, 'longer than fcron' has not a well defined
meaning ;-).

I haven't fully understood the code, but it seems to me that cronie will
miss the creation of /etc/crontab if it didn't exist when the select in
check_inotify_database is entered? And does it watch modifications of
files in RH_CROND_DIR?

In any case you may have a look at 
http://cvs.fedoraproject.org/viewvc/rpms/fcron/devel/fcron_config_modified.c?revision=1.1&view=markup
though it is not exactly the same context (it is called from a shell
script and if it exits with exit code 0 the configuration is reread by
another shell script), here I also watch /etc in case crontab wasn't
there already, to watch for its creation.

--
Pat



From pertusus at free.fr  Mon Dec  8 12:18:55 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 13:18:55 +0100
Subject: orphaning chm related packages
In-Reply-To: <20081206110002.GA2932@free.fr>
References: <20081206110002.GA2932@free.fr>
Message-ID: <20081208121855.GD2611@free.fr>

On Sat, Dec 06, 2008 at 12:00:02PM +0100, Patrice Dumas wrote:
> Hello,
> 
> * kchmviewer
> This one is currently built without kde support. kde support builds fine
> locally, but not in mock due to
> https://bugzilla.redhat.com/show_bug.cgi?id=460828

This is fixed now, in de vel kde support is reenabled.

--
Pat



From pertusus at free.fr  Mon Dec  8 12:21:08 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 13:21:08 +0100
Subject: orphaning chm related packages
In-Reply-To: <20081208121855.GD2611@free.fr>
References: <20081206110002.GA2932@free.fr> <20081208121855.GD2611@free.fr>
Message-ID: <20081208122107.GE2611@free.fr>

On Mon, Dec 08, 2008 at 01:18:55PM +0100, Patrice Dumas wrote:
> On Sat, Dec 06, 2008 at 12:00:02PM +0100, Patrice Dumas wrote:
> > Hello,
> > 
> > * kchmviewer
> > This one is currently built without kde support. kde support builds fine
> > locally, but not in mock due to
> > https://bugzilla.redhat.com/show_bug.cgi?id=460828
> 
> This is fixed now, in de vel kde support is reenabled.

In devel kde support is reenabled.

--
Pat



From mmaslano at redhat.com  Mon Dec  8 12:43:14 2008
From: mmaslano at redhat.com (Marcela Maslanova)
Date: Mon, 08 Dec 2008 13:43:14 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081208112919.GC2611@free.fr>
References: <20081205195914.GB3227@free.fr> <493CDA30.7030909@redhat.com>
	<20081208112919.GC2611@free.fr>
Message-ID: <493D1662.4050105@redhat.com>

Patrice Dumas wrote:
> On Mon, Dec 08, 2008 at 09:26:24AM +0100, Marcela Maslanova wrote:
> 
>> cronie is also using inotify, longer than fcron ;-) So this is not
>> advantage.
> 
> Indeed. (As a side note, since fcron didn't watched at all for those 
> files and directories, 'longer than fcron' has not a well defined
> meaning ;-).
> 
> I haven't fully understood the code, but it seems to me that cronie will
> miss the creation of /etc/crontab if it didn't exist when the select in
> check_inotify_database is entered? And does it watch modifications of
> files in RH_CROND_DIR?
> 
No, inotify is set to watch /etc/crontab even in case it's created after
start of daemon.
Yes, I set watch on /etc/cron.d/, so it's checking all changes in this
directory.
> In any case you may have a look at 
> http://cvs.fedoraproject.org/viewvc/rpms/fcron/devel/fcron_config_modified.c?revision=1.1&view=markup
> though it is not exactly the same context (it is called from a shell
> script and if it exits with exit code 0 the configuration is reread by
> another shell script), here I also watch /etc in case crontab wasn't
> there already, to watch for its creation.
> 
How many times is lstat touching the disc? I suppose you are lstat'ing,
only when you are creating the watch?
> --
> Pat
> 


-- 
Marcela Ma?l??ov?
BaseOS team Brno



From mschwendt at gmail.com  Mon Dec  8 12:54:46 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 8 Dec 2008 13:54:46 +0100
Subject: Problem importing packages
In-Reply-To: <1228732287.29271.35.camel@PB3.Linux>
References: <1228732287.29271.35.camel@PB3.Linux>
Message-ID: <20081208135446.ce04525e.mschwendt@gmail.com>

On Mon, 08 Dec 2008 10:31:27 +0000, Paul wrote:

> Hi,
> 
> Has something changed for importing to rawhide?
> 
> I've just rebuild mono-2.2 preview 2 and am trying to upload it using
> 
> ./cvs-import.sh ~/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm
> 
> and all I get back out is an annoying error
> 
> ERROR: Package /home/paul/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm
> does not look like a source RPM package
> 
> Any ideas on what is causing this?

cvs-import.sh is a shell script. Search for the error message and
try the comments manually. What do you get for...?
rpm -qp --qf "%{SOURCERPM}" ~/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm



From mschwendt at gmail.com  Mon Dec  8 13:02:34 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 8 Dec 2008 14:02:34 +0100
Subject: Work needed, how you can help!
In-Reply-To: <1228684966.3370.22.camel@localhost.localdomain>
References: <1228684966.3370.22.camel@localhost.localdomain>
Message-ID: <20081208140234.9a7ca66d.mschwendt@gmail.com>

On Sun, 07 Dec 2008 13:22:46 -0800, Jesse wrote:

> The work needed is for somebody to examine all the packages in rawhide
> that provide .pc files and ensure proper placement of them based on the
> review guideline.  This will likely require interaction with the
> packages maintainer(s) so the first step should probably be to produce a
> list of packages that ship .pc in a non -devel package and send the list
> (sorted by maintainer) to here so that we can discuss and pick off
> items.

Here are some different details. The following list shows:

 * non-devel packages that include .pc files
 * any virtual -devel package names
 * the dependencies on other packages, which provide .pc files


=> 1:control-center-2.25.2-4.fc11.i386 (control-center-2.25.2-4.fc11.src.rpm)
    /usr/share/pkgconfig/gnome-default-applications.pc
    /usr/share/pkgconfig/gnome-keybindings.pc
    REQUIRES: gnome-icon-theme
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info
    REQUIRES: gtk2-engines
    REQUIRES: gtk2-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: atk-devel
    REQUIRES: gtk-doc
    REQUIRES: glib2-devel
    REQUIRES: libXrandr-devel
    REQUIRES: pango-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: fontconfig-devel
    REQUIRES: libXft-devel
    REQUIRES: libXext-devel
    REQUIRES: libXcomposite-devel
    REQUIRES: libXfixes-devel
    REQUIRES: libXcursor-devel
    REQUIRES: libXi-devel
    REQUIRES: libXinerama-devel

=> 1:emacs-el-22.3-2.fc11.i386 (emacs-22.3-2.fc11.src.rpm)
    /usr/share/pkgconfig/emacs.pc

=> 1:xorg-x11-font-utils-7.2-6.fc10.i386 (xorg-x11-font-utils-7.2-6.fc10.src.rpm)
    /usr/lib/pkgconfig/fontutil.pc

=> avahi-sharp-0.6.22-13.fc11.i386 (avahi-0.6.22-13.fc11.src.rpm)
    /usr/lib/pkgconfig/avahi-sharp.pc
    REQUIRES: libgdiplus-devel

=> avahi-ui-sharp-0.6.22-13.fc11.i386 (avahi-0.6.22-13.fc11.src.rpm)
    /usr/lib/pkgconfig/avahi-ui-sharp.pc
    REQUIRES: avahi-sharp
    REQUIRES: libgdiplus-devel

=> bodr-8-1.fc9.noarch (bodr-8-1.fc9.src.rpm)
    /usr/share/pkgconfig/bodr.pc

=> chemical-mime-data-0.1.94-3.fc8.noarch (chemical-mime-data-0.1.94-3.fc8.src.rpm)
    /usr/share/pkgconfig/chemical-mime-data.pc
    REQUIRES: shared-mime-info

=> compiz-bcop-0.7.8-1.fc11.noarch (compiz-bcop-0.7.8-1.fc11.src.rpm)
    /usr/share/pkgconfig/bcop.pc

=> deskbar-applet-2.25.1-5.fc11.i386 (deskbar-applet-2.25.1-5.fc11.src.rpm)
    /usr/lib/pkgconfig/deskbar-applet.pc
    REQUIRES: pygtk2-devel
    REQUIRES: pygobject2-devel
    REQUIRES: glib2-devel
    REQUIRES: pycairo-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: fontconfig-devel
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info
    REQUIRES: gnome-icon-theme
    REQUIRES: gtk2-engines
    REQUIRES: gtk2-devel
    REQUIRES: atk-devel
    REQUIRES: gtk-doc
    REQUIRES: libXrandr-devel
    REQUIRES: pango-devel
    REQUIRES: libXft-devel
    REQUIRES: libXext-devel
    REQUIRES: libXcomposite-devel
    REQUIRES: libXfixes-devel
    REQUIRES: libXcursor-devel
    REQUIRES: libXi-devel
    REQUIRES: libXinerama-devel
    REQUIRES: gnome-python2-desktop

=> flumotion-0.4.2-7.fc11.i386 (flumotion-0.4.2-7.fc11.src.rpm)
    /usr/lib/pkgconfig/flumotion.pc
    REQUIRES: gstreamer-python
    REQUIRES: pygtk2-devel
    REQUIRES: pygobject2-devel
    REQUIRES: glib2-devel
    REQUIRES: pycairo-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: fontconfig-devel
    REQUIRES: gstreamer-devel
    REQUIRES: libxml2-devel
    REQUIRES: check-devel

=> freehdl-0.0.6-2.fc10.i386 (freehdl-0.0.6-2.fc10.src.rpm)
    /usr/lib/pkgconfig/freehdl.pc

=> gmime-sharp-2.4.3-2.fc11.i386 (gmime-2.4.3-2.fc11.src.rpm)
    /usr/lib/pkgconfig/gmime-sharp-2.4.pc
    REQUIRES: libgdiplus-devel

=> gnome-doc-utils-stylesheets-0.14.0-4.fc11.noarch (gnome-doc-utils-0.14.0-4.fc11.src.rpm)
    /usr/share/pkgconfig/gnome-doc-utils.pc
    /usr/share/pkgconfig/xml2po.pc
    REQUIRES: libxml2-devel

=> gnome-icon-theme-2.24.0-1.fc10.noarch (gnome-icon-theme-2.24.0-1.fc10.src.rpm)
    /usr/share/pkgconfig/gnome-icon-theme.pc

=> gnome-mime-data-2.18.0-3.fc10.noarch (gnome-mime-data-2.18.0-3.fc10.src.rpm)
    /usr/share/pkgconfig/gnome-mime-data-2.0.pc

=> gnome-python2-desktop-2.24.0-5.fc11.i386 (gnome-python2-desktop-2.24.0-5.fc11.src.rpm)
    /usr/lib/pkgconfig/gnome-python-desktop-2.0.pc
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info

=> gnome-python2-extras-2.19.1-26.fc11.i386 (gnome-python2-extras-2.19.1-26.fc11.src.rpm)
    /usr/lib/pkgconfig/gnome-python-extras-2.0.pc
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info

=> gnome-screensaver-2.25.1-2.fc11.i386 (gnome-screensaver-2.25.1-2.fc11.src.rpm)
    /usr/lib/pkgconfig/gnome-screensaver.pc
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info
    REQUIRES: gnome-icon-theme
    REQUIRES: gtk2-engines
    REQUIRES: gtk2-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: atk-devel
    REQUIRES: gtk-doc
    REQUIRES: glib2-devel
    REQUIRES: libXrandr-devel
    REQUIRES: pango-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: fontconfig-devel
    REQUIRES: libXft-devel
    REQUIRES: libXext-devel
    REQUIRES: libXcomposite-devel
    REQUIRES: libXfixes-devel
    REQUIRES: libXcursor-devel
    REQUIRES: libXi-devel
    REQUIRES: libXinerama-devel

=> gstreamer-python-0.10.12-2.fc11.i386 (gstreamer-python-0.10.12-2.fc11.src.rpm)
    PROVIDES: gstreamer-python-devel
    /usr/lib/pkgconfig/gst-python-0.10.pc
    REQUIRES: pygtk2-devel
    REQUIRES: pygobject2-devel
    REQUIRES: glib2-devel
    REQUIRES: pycairo-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: fontconfig-devel
    REQUIRES: gstreamer-devel
    REQUIRES: libxml2-devel
    REQUIRES: check-devel

=> gtk-doc-1.11-2.fc11.noarch (gtk-doc-1.11-2.fc11.src.rpm)
    /usr/share/pkgconfig/gtk-doc.pc

=> gtk-sharp2-gapi-2.12.5-1.fc11.i386 (gtk-sharp2-2.12.5-1.fc11.src.rpm)
    /usr/lib/pkgconfig/gapi-2.0.pc

=> gtk2-engines-2.17.1-1.fc11.i386 (gtk2-engines-2.17.1-1.fc11.src.rpm)
    /usr/lib/pkgconfig/gtk-engines-2.pc
    REQUIRES: gtk2-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: atk-devel
    REQUIRES: gtk-doc
    REQUIRES: glib2-devel
    REQUIRES: libXrandr-devel
    REQUIRES: pango-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: fontconfig-devel
    REQUIRES: libXft-devel
    REQUIRES: libXext-devel
    REQUIRES: libXcomposite-devel
    REQUIRES: libXfixes-devel
    REQUIRES: libXcursor-devel
    REQUIRES: libXi-devel
    REQUIRES: libXinerama-devel

=> icon-naming-utils-0.8.7-1.fc10.noarch (icon-naming-utils-0.8.7-1.fc10.src.rpm)
    /usr/share/pkgconfig/icon-naming-utils.pc

=> libXaw-compat-1.0.4-3.fc10.i386 (libXaw-1.0.4-3.fc10.src.rpm)
    /usr/lib/pkgconfig/xaw6.pc

=> nfs-utils-lib-1.1.4-1.fc10.i386 (nfs-utils-lib-1.1.4-1.fc10.src.rpm)
    /usr/lib/pkgconfig/libnfsidmap.pc
    /usr/lib/pkgconfig/librpcsecgss.pc

=> notify-python-0.1.1-5.fc11.i386 (notify-python-0.1.1-5.fc11.src.rpm)
    /usr/lib/pkgconfig/notify-python.pc

=> pygoocanvas-0.10.0-3.fc11.i386 (pygoocanvas-0.10.0-3.fc11.src.rpm)
    /usr/lib/pkgconfig/pygoocanvas.pc
    REQUIRES: pygtk2-devel
    REQUIRES: pygobject2-devel
    REQUIRES: glib2-devel
    REQUIRES: pycairo-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: fontconfig-devel

=> python-gtkextra-1.1.0-3.fc10.i386 (python-gtkextra-1.1.0-3.fc10.src.rpm)
    /usr/lib/pkgconfig/python-gtkextra.pc

=> samba-common-3.2.5-0.23.fc11.i386 (samba-3.2.5-0.23.fc11.src.rpm)
    /usr/lib/pkgconfig/netapi.pc

=> shared-mime-info-0.51-5.fc11.i386 (shared-mime-info-0.51-5.fc11.src.rpm)
    /usr/share/pkgconfig/shared-mime-info.pc

=> tomboy-0.13.1-5.fc11.i386 (tomboy-0.13.1-5.fc11.src.rpm)
    /usr/lib/pkgconfig/tomboy-addins.pc
    REQUIRES: libgdiplus-devel
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info
    REQUIRES: gnome-icon-theme
    REQUIRES: gtk2-engines
    REQUIRES: gtk2-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: atk-devel
    REQUIRES: gtk-doc
    REQUIRES: glib2-devel
    REQUIRES: libXrandr-devel
    REQUIRES: pango-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: fontconfig-devel
    REQUIRES: libXft-devel
    REQUIRES: libXext-devel
    REQUIRES: libXcomposite-devel
    REQUIRES: libXfixes-devel
    REQUIRES: libXcursor-devel
    REQUIRES: libXi-devel
    REQUIRES: libXinerama-devel
    REQUIRES: xorg-x11-font-utils

=> ustr-debug-1.0.4-7.fc10.i386 (ustr-1.0.4-7.fc10.src.rpm)
    /usr/lib/pkgconfig/ustr-debug.pc
    REQUIRES: ustr-devel

=> xcb-proto-1.2-3.fc11.noarch (xcb-proto-1.2-3.fc11.src.rpm)
    /usr/share/pkgconfig/xcb-proto.pc

=> xorg-x11-xbitmaps-1.0.1-6.fc10.i386 (xorg-x11-xbitmaps-1.0.1-6.fc10.src.rpm)
    PROVIDES: xbitmaps-devel
    /usr/lib/pkgconfig/xbitmaps.pc



From pertusus at free.fr  Mon Dec  8 13:13:07 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 14:13:07 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <493D1662.4050105@redhat.com>
References: <20081205195914.GB3227@free.fr> <493CDA30.7030909@redhat.com>
	<20081208112919.GC2611@free.fr> <493D1662.4050105@redhat.com>
Message-ID: <20081208131307.GF2611@free.fr>

On Mon, Dec 08, 2008 at 01:43:14PM +0100, Marcela Maslanova wrote:
> > 
> No, inotify is set to watch /etc/crontab even in case it's created after
> start of daemon.

But without watching /etc with inotify, how do you do it? In my 
experiments if a file doesn't exist, inotify_add_watch errors out.

> Yes, I set watch on /etc/cron.d/, so it's checking all changes in this
> directory.

Indeed. Seems that I was fooled by the doc, IN_CLOSE_WRITE seems to also 
watch for files closed inside a directory. I'll be able to simplify
the fcron watch code, then, thanks.

> How many times is lstat touching the disc? I suppose you are lstat'ing,
> only when you are creating the watch?

Yes. But the watch are recreated everytime the program is rerun, which
is done everytime something changes. If the C program was integrated
in a bigger C program instead of being launched from a shell script 
(that also relaunches the configuration), previous watches could be 
reused. In any case fcron is different from cronie, since (in the current 
state) all the config is recreated even if only one file change. Maybe 
cronie may have something more fine grained.

--
Pat



From mmaslano at redhat.com  Mon Dec  8 13:20:37 2008
From: mmaslano at redhat.com (Marcela Maslanova)
Date: Mon, 08 Dec 2008 14:20:37 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081208131307.GF2611@free.fr>
References: <20081205195914.GB3227@free.fr>
	<493CDA30.7030909@redhat.com>	<20081208112919.GC2611@free.fr>
	<493D1662.4050105@redhat.com> <20081208131307.GF2611@free.fr>
Message-ID: <493D1F25.6030400@redhat.com>

Patrice Dumas wrote:
> On Mon, Dec 08, 2008 at 01:43:14PM +0100, Marcela Maslanova wrote:
>> No, inotify is set to watch /etc/crontab even in case it's created after
>> start of daemon.
> 
> But without watching /etc with inotify, how do you do it? In my 
> experiments if a file doesn't exist, inotify_add_watch errors out.
> 
But inotify can watch files or directories. The watch is set on
/etc/crontab = SYSCRONTAB.
>> Yes, I set watch on /etc/cron.d/, so it's checking all changes in this
>> directory.
> 
> Indeed. Seems that I was fooled by the doc, IN_CLOSE_WRITE seems to also 
> watch for files closed inside a directory. I'll be able to simplify
> the fcron watch code, then, thanks.
> 
>> How many times is lstat touching the disc? I suppose you are lstat'ing,
>> only when you are creating the watch?
> 
> Yes. But the watch are recreated everytime the program is rerun, which
> is done everytime something changes. If the C program was integrated
> in a bigger C program instead of being launched from a shell script 
> (that also relaunches the configuration), previous watches could be 
> reused. In any case fcron is different from cronie, since (in the current 
> state) all the config is recreated even if only one file change. Maybe 
> cronie may have something more fine grained.
> 
In this case is using lstat ok.
> --
> Pat
> 


-- 
Marcela Ma?l??ov?
BaseOS team Brno



From sgallagh at redhat.com  Mon Dec  8 13:30:44 2008
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Mon, 08 Dec 2008 08:30:44 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <493C5D7A.101@gmail.com>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812070954.31864.sgrubb@redhat.com>	<87k5ac9cat.fsf@sheridan.bigo.ensc.de>	<200812071151.38419.sgrubb@redhat.com>	<1228690989.3923.9.camel@naomi.s4.naomi.abartlet.net>	<1228691121.3370.28.camel@localhost.localdomain>	<1228691364.3311.66.camel@localhost.localdomain>
	<493C5D7A.101@gmail.com>
Message-ID: <493D2184.2000702@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Les Mikesell wrote:
> Is attempting an access that the kernel routinely prevents considered a
> violation?  That is, if I type 'file /etc/*' on such a system should I
> expect the black helicopters to start firing?  I don't see how accesses
> that are denied matter to anyone - or why anyone running the
> shadow-tools utility without permission to access the relevant files
> should bother anyone either.
> 

Actually, yes. There are environments in which an administrator may set
up heuristics to determine whether a user is attempting to probe the
system for vulnerability. In the systems like this I've seen, one very
common action to note is failed attempts by users to execute processes
in /sbin or /usr/sbin. Seeing the same user attempt to execute every
binary in one of those folders could be a clear sign that they are
probing for misconfigurations to take advantage of.
- --

- --------------------
Stephen Gallagher
RHCE 804006346421761
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk9IYQACgkQeiVVYja6o6MO1wCff+vaJmpxwa5E42xu2kO6qSYf
J0cAoKLOkEC/eCj2A4Z8EuVjhk+vn2pZ
=4CYt
-----END PGP SIGNATURE-----



From sgallagh at redhat.com  Mon Dec  8 13:44:49 2008
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Mon, 08 Dec 2008 08:44:49 -0500
Subject: Seahorse is orphaned?
In-Reply-To: <1228141066.3391.6.camel@localhost.localdomain>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
	<1228141066.3391.6.camel@localhost.localdomain>
Message-ID: <493D24D1.6050202@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias Clasen wrote:
> On Mon, 2008-12-01 at 16:45 +0530, Debarshi Ray wrote:
>> I just noticed that the 'seahorse' package is orphaned [1] although
>> Matthias and others seem to be taking care of it for some time. So is
>> the package really orphaned or is this just an oversight?
>>
> 
> Hmm, funny. I've asked Tomas Bzatek to take it. He's the maintainer of
> gnome-keyring-manager, and we are going to obsolete g-k-m in favour of
> seahorse anyway...
> 
> 
> Matthias
> 

Would it be possible to get a name-change on seahorse? It's a great
utility, but the name "seahorse" doesn't do anything at all to indicate
what the program does.

If a user is looking for a way to manage their keyring, how would they
ever know to install a package called "seahorse"?

Is there a really compelling reason why it couldn't just be renamed to
something like gnome-keyring2?

- --

- --------------------
Stephen Gallagher
RHCE 804006346421761
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk9JNEACgkQeiVVYja6o6NtbACaAkyy+UYofZ95chs+7+rYP93B
ipEAoJgajKvIxXbVJPEnUQ0wNRg55zif
=k2NZ
-----END PGP SIGNATURE-----



From pbrobinson at gmail.com  Mon Dec  8 14:01:08 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Mon, 8 Dec 2008 15:01:08 +0100
Subject: Seahorse is orphaned?
In-Reply-To: <493D24D1.6050202@redhat.com>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
	<1228141066.3391.6.camel@localhost.localdomain>
	<493D24D1.6050202@redhat.com>
Message-ID: <5256d0b0812080601h50f4f3f7q71f43c8f76749231@mail.gmail.com>

>> On Mon, 2008-12-01 at 16:45 +0530, Debarshi Ray wrote:
>>> I just noticed that the 'seahorse' package is orphaned [1] although
>>> Matthias and others seem to be taking care of it for some time. So is
>>> the package really orphaned or is this just an oversight?
>>>
>>
>> Hmm, funny. I've asked Tomas Bzatek to take it. He's the maintainer of
>> gnome-keyring-manager, and we are going to obsolete g-k-m in favour of
>> seahorse anyway...
>>
>>
>> Matthias
>>
>
> Would it be possible to get a name-change on seahorse? It's a great
> utility, but the name "seahorse" doesn't do anything at all to indicate
> what the program does.
>
> If a user is looking for a way to manage their keyring, how would they
> ever know to install a package called "seahorse"?
>
> Is there a really compelling reason why it couldn't just be renamed to
> something like gnome-keyring2?

I guess that a rename would need to be taken upstream. I don't see why
it can't have a description like Transmission or any of the others do
in the .desktop to make it more descriptive. Transmission is listed as
"Transmission Bittorrent client". So you could make it "Seahorse
password and encrpytion manager" or something.

Peter



From pertusus at free.fr  Mon Dec  8 14:04:53 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 15:04:53 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <493D1F25.6030400@redhat.com>
References: <20081205195914.GB3227@free.fr> <493CDA30.7030909@redhat.com>
	<20081208112919.GC2611@free.fr> <493D1662.4050105@redhat.com>
	<20081208131307.GF2611@free.fr> <493D1F25.6030400@redhat.com>
Message-ID: <20081208140453.GG2611@free.fr>

On Mon, Dec 08, 2008 at 02:20:37PM +0100, Marcela Maslanova wrote:
> > 
> But inotify can watch files or directories. The watch is set on
> /etc/crontab = SYSCRONTAB.

Sure, but in case it doesn't exist, inotify_add_watch will error out.
My guess is that if /etc/crontab doesn't exist, cronie reverts to
inotify_enabled = 0, and that's why I saw cronie looking every minute at
/etc/cron.d.

I have simplified the program and used the same masks than cronie at
http://cvs.fedoraproject.org/viewvc/rpms/fcron/devel/fcron_config_modified.c?revision=1.2&view=markup 
Maybe you could implement SYSCONFDIR watching like I did to enable
inotify even if /etc/crontab or /etc/cron.d is missing and watch for
their creation by watching /etc.

In fedora, not having /etc/crontab or /etc/cron.d present should
be very rare, but in other setups this may happen.

If I have time, I'll try to see logs when /etc/crontab or /etc/cron.d 
are not present, since cronie should state it in that case.

--
Pat



From bruno at wolff.to  Mon Dec  8 14:30:43 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 8 Dec 2008 08:30:43 -0600
Subject: Can luks in fedora 10 , encrypt using a combination of keys
	and passphrase
In-Reply-To: <493CDD9A.60706@redhat.com>
References: <493CCACC.1010707@redhat.com> <20081208072734.GA9119@wolff.to>
	<493CCD37.1000803@redhat.com> <20081208074257.GA11244@wolff.to>
	<493CDD9A.60706@redhat.com>
Message-ID: <20081208143043.GA19176@wolff.to>

On Mon, Dec 08, 2008 at 14:10:58 +0530,
  Huzaifa Sidhpurwala <huzaifas at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Yep,
> I am wondering if i can have one slot filled by a passphrase and the
> second one by a key, do you know if that is possible?

There is an encrypted copy of the disk key in each slot. The key for each
slot appears to be a string. It can be entered as a passphrass or a key
file. That much is clear from the cryptsetup documentation. You had
mentioned a public key system before, but I don't think that makes much
sense to use. The key file allows you to use keys with lots of entropy, but
the advantage to that is somewhat negated if the users will have passphrases
of their choosing that they use to get at the disks.



From marc_schwartz at comcast.net  Mon Dec  8 14:56:43 2008
From: marc_schwartz at comcast.net (Marc Schwartz)
Date: Mon, 08 Dec 2008 08:56:43 -0600
Subject: Can luks in fedora 10 ,
	encrypt using a combination of keys and passphrase
References: <493CCACC.1010707@redhat.com> <20081208072734.GA9119@wolff.to>
	<493CCD37.1000803@redhat.com> <20081208074257.GA11244@wolff.to>
	<493CDD9A.60706@redhat.com> <20081208143043.GA19176@wolff.to>
Message-ID: <m3oczmyatw.fsf@comcast.net>

Bruno Wolff III <bruno at wolff.to> writes:

> On Mon, Dec 08, 2008 at 14:10:58 +0530,
>   Huzaifa Sidhpurwala <huzaifas at redhat.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Yep,
>> I am wondering if i can have one slot filled by a passphrase and the
>> second one by a key, do you know if that is possible?
>
> There is an encrypted copy of the disk key in each slot. The key for each
> slot appears to be a string. It can be entered as a passphrass or a key
> file. That much is clear from the cryptsetup documentation. You had
> mentioned a public key system before, but I don't think that makes much
> sense to use. The key file allows you to use keys with lots of entropy, but
> the advantage to that is somewhat negated if the users will have passphrases
> of their choosing that they use to get at the disks.

The dm-crypt/LUKS model has a *single* key that actually does the
underlying encryption/decryption.

The passphrase entered by the user, unlocks access to the key so that
encryption/decryption takes place. 

You can have up to 8 passphrases I believe, one of which should be an
Admin key and should not be shared. These can vary, though you can have
the same passphrase in more than one slot which some have suggested as a
backup of the primary passphrase.

The advantage over other models, besides being cross-platform, is that
you can have multiple access keys with a single encryption key. That
way, you can disable one passphrase, without compromising the access of
others or having to re-encrypt the whole partition with a new key.

LUKS does support the use of a USB key, though I have not used it
myself. More info here:

  http://www.saout.de/tikiwiki/tiki-index.php?page=LUKSFaq

and there are probably other references available via Google searches.

HTH,

Marc Schwartz



From notting at redhat.com  Mon Dec  8 15:10:51 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 8 Dec 2008 10:10:51 -0500
Subject: package seeking new owner: jed
In-Reply-To: <b401d2530812060103h5e60a461q5dd810d53da0a71@mail.gmail.com>
References: <20081205210210.GA19180@nostromo.devel.redhat.com>
	<b401d2530812060103h5e60a461q5dd810d53da0a71@mail.gmail.com>
Message-ID: <20081208151051.GA28585@nostromo.devel.redhat.com>

Rakesh Pandit (rakesh at fedoraproject.org) said: 
> 2008/12/6 Bill Nottingham <notting at redhat.com>:
> > I don't really use it any more, so I figure I might as well give
> > the opportunity to maintain it to someone who does. Has had one
> > actual bug (FTBFS) filed in the past four years.
> 
> Looks cool, will take care, in case no one is interested.

Released in pkgdb, feel free to grab it. Thanks!

Bill



From davej at redhat.com  Mon Dec  8 14:44:26 2008
From: davej at redhat.com (Dave Jones)
Date: Mon, 8 Dec 2008 09:44:26 -0500
Subject: Enabling the memory controller for F11
In-Reply-To: <20081208062952.GG13333@balbir.in.ibm.com>
References: <20081208062952.GG13333@balbir.in.ibm.com>
Message-ID: <20081208144426.GA2993@redhat.com>

On Mon, Dec 08, 2008 at 11:59:52AM +0530, Balbir Singh wrote:
 > Hi,
 > 
 > Its me again with a request to enable the memory controller for F11.
 > 2.6.28-rc1 got rid of the cgroup member in struct page and thus the
 > overhead w.r.t. having it enabled on 32 bit systems. As we move into
 > the F11 cycle, I would request enablement of the memory controller.
 > 
 > Please let me know if you need more information.
 
Can you send a diff of the config options, (or just tell me which
ones you'd like to set to =y/=m).

Thanks,

	Dave

-- 
http://www.codemonkey.org.uk



From james at fedoraproject.org  Mon Dec  8 15:25:30 2008
From: james at fedoraproject.org (James Antill)
Date: Mon, 08 Dec 2008 10:25:30 -0500
Subject: Work needed, how you can help!
In-Reply-To: <20081208140234.9a7ca66d.mschwendt@gmail.com>
References: <1228684966.3370.22.camel@localhost.localdomain>
	<20081208140234.9a7ca66d.mschwendt@gmail.com>
Message-ID: <1228749930.26618.255.camel@code.and.org>

On Mon, 2008-12-08 at 14:02 +0100, Michael Schwendt wrote:

> => ustr-debug-1.0.4-7.fc10.i386 (ustr-1.0.4-7.fc10.src.rpm)
>     /usr/lib/pkgconfig/ustr-debug.pc
>     REQUIRES: ustr-devel

 This is essentially the -devel package with all the debugging turned
on. I guess I could name it ustr-debug-devel if we really have to
(although having a ustr-debug-devel without a ustr-debug seems a little
weird).

-- 
James Antill <james at fedoraproject.org>
Fedora



From balbir at linux.vnet.ibm.com  Mon Dec  8 15:25:42 2008
From: balbir at linux.vnet.ibm.com (Balbir Singh)
Date: Mon, 8 Dec 2008 20:55:42 +0530
Subject: Enabling the memory controller for F11
In-Reply-To: <20081208144426.GA2993@redhat.com>
References: <20081208062952.GG13333@balbir.in.ibm.com>
	<20081208144426.GA2993@redhat.com>
Message-ID: <20081208152542.GO13333@balbir.in.ibm.com>

* Dave Jones <davej at redhat.com> [2008-12-08 09:44:26]:

> On Mon, Dec 08, 2008 at 11:59:52AM +0530, Balbir Singh wrote:
>  > Hi,
>  > 
>  > Its me again with a request to enable the memory controller for F11.
>  > 2.6.28-rc1 got rid of the cgroup member in struct page and thus the
>  > overhead w.r.t. having it enabled on 32 bit systems. As we move into
>  > the F11 cycle, I would request enablement of the memory controller.
>  > 
>  > Please let me know if you need more information.
> 
> Can you send a diff of the config options, (or just tell me which
> ones you'd like to set to =y/=m).
>

Dave, I tried taking a diff against current -git, but I get a lot of
new configs and I don't want the diff to suggest any other config
option. Here is the option we need to enable the memory resource
controller

CONFIG_CGROUP_MEM_RES_CTLR, it depends on CONFIG_RESOURCE_COUNTERS
which is already enabled.
 

-- 
	Balbir



From konrad at tylerc.org  Mon Dec  8 15:31:54 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 8 Dec 2008 07:31:54 -0800
Subject: Problem importing packages
In-Reply-To: <1228732287.29271.35.camel@PB3.Linux>
References: <1228732287.29271.35.camel@PB3.Linux>
Message-ID: <200812080731.54948.konrad@tylerc.org>

On Monday 08 December 2008 02:31:27 am Paul wrote:
> Hi,
>
> Has something changed for importing to rawhide?
>
> I've just rebuild mono-2.2 preview 2 and am trying to upload it using
>
> ./cvs-import.sh ~/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm
>
> and all I get back out is an annoying error
>
> ERROR: Package /home/paul/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm
> does not look like a source RPM package
>
> Any ideas on what is causing this?
>
> TTFN
>
> Paul

Generally pre-release versions are Version: 2.2 and Release: 0.8.pre2%{?dist} 
as described in 
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From sgrubb at redhat.com  Mon Dec  8 15:38:42 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 8 Dec 2008 10:38:42 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <604aa7910812071529h4e14eff7l55614033eeddddd0@mail.gmail.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812070954.31864.sgrubb@redhat.com>
	<604aa7910812071529h4e14eff7l55614033eeddddd0@mail.gmail.com>
Message-ID: <200812081038.43323.sgrubb@redhat.com>

On Sunday 07 December 2008 06:29:47 pm Jeff Spaleta wrote:
> I still come back to one thing. ?Could the file permissions be
> implemented differently so that CAPP compliance could be a system
> install time choice, instead of being expressed in the configuration
> of all installs?

Just wanted to let you know I am thinking about this. I need to think though  
what this does to our project and how to make sure we still get the right 
outcome.

-Steve



From davej at redhat.com  Mon Dec  8 15:39:33 2008
From: davej at redhat.com (Dave Jones)
Date: Mon, 8 Dec 2008 10:39:33 -0500
Subject: Enabling the memory controller for F11
In-Reply-To: <20081208152542.GO13333@balbir.in.ibm.com>
References: <20081208062952.GG13333@balbir.in.ibm.com>
	<20081208144426.GA2993@redhat.com>
	<20081208152542.GO13333@balbir.in.ibm.com>
Message-ID: <20081208153933.GB2993@redhat.com>

On Mon, Dec 08, 2008 at 08:55:42PM +0530, Balbir Singh wrote:
 
 > Dave, I tried taking a diff against current -git, but I get a lot of
 > new configs and I don't want the diff to suggest any other config
 > option. Here is the option we need to enable the memory resource
 > controller
 > 
 > CONFIG_CGROUP_MEM_RES_CTLR, it depends on CONFIG_RESOURCE_COUNTERS
 > which is already enabled.
 
Ok, enabled.

Thanks,

	Dave

-- 
http://www.codemonkey.org.uk



From j.w.r.degoede at hhs.nl  Mon Dec  8 15:47:32 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 08 Dec 2008 16:47:32 +0100
Subject: FAmSCo elections only open to ambassadors?
Message-ID: <493D4194.1070804@hhs.nl>

Hi All,

Today I went to do my duty and vote, and much to my surprise I could not vote 
for the FAmSCo election. Now that is probably something which has been 
discussed before and I just missed, but still let me express my surprise about 
this.

How is it that anyone which is member of any group in Fedora including 
translators and ambassadors get to vote for FesCo, which is effectively the 
developers steering committee now a days. Yet only ambassadors get to vote who 
gets on FAmSCo ??

Don't get me wrong I think that people who contribute to Fedora by doing 
marketing in the broadest sense of the word, or by doing translations, as such 
have earned every right to influence future development of Fedora. But how is 
it that the people who are building the distro, do not get to influence how the 
distro is represented to the world by our Ambassadors?

Regards,

Hans



From rstrode at redhat.com  Mon Dec  8 15:45:08 2008
From: rstrode at redhat.com (Ray Strode)
Date: Mon, 08 Dec 2008 10:45:08 -0500
Subject: libgnome-devel depends on esound-devel
In-Reply-To: <493C6727.5020701@codewiz.org>
References: <493C6727.5020701@codewiz.org>
Message-ID: <493D4104.7090906@redhat.com>

Bernie Innocenti wrote:
> Any idea why?  Can we drop this dependency?
>   
Probably for historical reasons.  Mind filing a bug?

--Ray



From jreiser at BitWagon.com  Mon Dec  8 15:45:44 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Mon, 08 Dec 2008 07:45:44 -0800
Subject: Enabling the memory controller for F11
In-Reply-To: <20081208062952.GG13333@balbir.in.ibm.com>
References: <20081208062952.GG13333@balbir.in.ibm.com>
Message-ID: <493D4128.8050402@BitWagon.com>

> [Please] enable the memory controller for F11.

Please give a URL to a description of what it does, what are the benefits
(to users, developers, administrators, ...), and what are the costs.
Searching is tedious, and difficult to know when to stop.

-- 



From mschwendt at gmail.com  Mon Dec  8 15:46:54 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 8 Dec 2008 16:46:54 +0100
Subject: Work needed, how you can help!
In-Reply-To: <1228749930.26618.255.camel@code.and.org>
References: <1228684966.3370.22.camel@localhost.localdomain>
	<20081208140234.9a7ca66d.mschwendt@gmail.com>
	<1228749930.26618.255.camel@code.and.org>
Message-ID: <20081208164654.79443601.mschwendt@gmail.com>

On Mon, 08 Dec 2008 10:25:30 -0500, James wrote:

> > => ustr-debug-1.0.4-7.fc10.i386 (ustr-1.0.4-7.fc10.src.rpm)
> >     /usr/lib/pkgconfig/ustr-debug.pc
> >     REQUIRES: ustr-devel
> 
>  This is essentially the -devel package with all the debugging turned
> on. I guess I could name it ustr-debug-devel if we really have to
> (although having a ustr-debug-devel without a ustr-debug seems a little
> weird).

How would that be weird? I can imagine things like a-devel package that
specifies an interface without any main package to depend on.



From mclasen at redhat.com  Mon Dec  8 15:50:08 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 08 Dec 2008 10:50:08 -0500
Subject: Seahorse is orphaned?
In-Reply-To: <493D24D1.6050202@redhat.com>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
	<1228141066.3391.6.camel@localhost.localdomain>
	<493D24D1.6050202@redhat.com>
Message-ID: <1228751408.3539.7.camel@localhost.localdomain>

On Mon, 2008-12-08 at 08:44 -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Matthias Clasen wrote:
> > On Mon, 2008-12-01 at 16:45 +0530, Debarshi Ray wrote:
> >> I just noticed that the 'seahorse' package is orphaned [1] although
> >> Matthias and others seem to be taking care of it for some time. So is
> >> the package really orphaned or is this just an oversight?
> >>
> > 
> > Hmm, funny. I've asked Tomas Bzatek to take it. He's the maintainer of
> > gnome-keyring-manager, and we are going to obsolete g-k-m in favour of
> > seahorse anyway...
> > 
> > 
> > Matthias
> > 
> 
> Would it be possible to get a name-change on seahorse? It's a great
> utility, but the name "seahorse" doesn't do anything at all to indicate
> what the program does.
> 
> If a user is looking for a way to manage their keyring, how would they
> ever know to install a package called "seahorse"?
> 
> Is there a really compelling reason why it couldn't just be renamed to
> something like gnome-keyring2?

If you want the package name changed, you'll have to take it upstream,
since our policy is to follow the upstream name for package names.

But I don't think it is that bad. The package has

Name        : seahorse 
Summary     : A GNOME application for managing encryption keys
Description :
Seahorse is a graphical interface for managing and using encryption
keys. It also integrates with nautilus, gedit and other places for
encryption operations.

And the desktop file has

Name=Passwords and Encryption Keys
Comment=Manage your passwords and encryption keys





From mschwendt at gmail.com  Mon Dec  8 16:01:13 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 8 Dec 2008 17:01:13 +0100
Subject: New conflicts (Re: rawhide report: 20081207 changes)
In-Reply-To: <20081207154448.E25B31F81D6@releng2.fedora.phx.redhat.com>
References: <20081207154448.E25B31F81D6@releng2.fedora.phx.redhat.com>
Message-ID: <20081208170113.8215cbc5.mschwendt@gmail.com>

All new conflicts except these have been entered into bugzilla:

kdebase3-3.5.10-2.fc10.i386  in  rawhide-development-i386
  File conflict with: kdesdk-4.1.80-3.fc11.i386
     /usr/share/icons/hicolor/128x128/apps/kate.png
     /usr/share/icons/hicolor/16x16/apps/kate.png
     /usr/share/icons/hicolor/22x22/apps/kate.png
     /usr/share/icons/hicolor/32x32/apps/kate.png
     /usr/share/icons/hicolor/48x48/apps/kate.png
     /usr/share/icons/hicolor/64x64/apps/kate.png

kdesdk-4.1.80-3.fc11.i386  in  rawhide-development-i386
  File conflict with: kdebase3-3.5.10-2.fc10.i386
     /usr/share/icons/hicolor/128x128/apps/kate.png
     /usr/share/icons/hicolor/16x16/apps/kate.png
     /usr/share/icons/hicolor/22x22/apps/kate.png
     /usr/share/icons/hicolor/32x32/apps/kate.png
     /usr/share/icons/hicolor/48x48/apps/kate.png
     /usr/share/icons/hicolor/64x64/apps/kate.png



From paul at all-the-johnsons.co.uk  Mon Dec  8 16:03:00 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Mon, 08 Dec 2008 16:03:00 +0000
Subject: Problem importing packages
In-Reply-To: <20081208135446.ce04525e.mschwendt@gmail.com>
References: <1228732287.29271.35.camel@PB3.Linux>
	<20081208135446.ce04525e.mschwendt@gmail.com>
Message-ID: <1228752180.7485.3.camel@PB3.Linux>

Hi,

> > Any ideas on what is causing this?
> 
> cvs-import.sh is a shell script. Search for the error message and
> try the comments manually. What do you get for...?
> rpm -qp --qf "%{SOURCERPM}" ~/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm

(unknown type)

That's all it says!

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/b4cc140a/attachment.sig>

From rawhide at fedoraproject.org  Mon Dec  8 16:05:13 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon,  8 Dec 2008 16:05:13 +0000 (UTC)
Subject: rawhide report: 20081208 changes
Message-ID: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>

Compose started at Mon Dec  8 06:01:06 UTC 2008

New package checkdns
        A Domain Name Server analysis and reporting tool
New package constantine
        Platform Constants for Java
New package electric
        Sophisticated Java based VLSI CAD System
New package perl-Data-TreeDumper
        Improved replacement for Data::Dumper
New package perl-Test-Signature
        Automated SIGNATURE testing
New package php-pear-Date-Holidays-USA
        Driver based class to calculate holidays in USA
New package supybot-fedora
        Plugin for Supybot to interact with Fedora services
New package supybot-koji
        Plugin for Supybot to interact with Koji instances
New package thebridge
        ILink/EchoLink compatible conference bridge
Updated Packages:

R2spec-2.5.1-6.fc11
-------------------
* Sun Dec  7 17:00:00 2008 Pingou <pingou-at-pingoured.fr> 2.5.1-6
- Correct the third sed

* Sun Dec  7 17:00:00 2008 Pingou <pingou-at-pingoured.fr> 2.5.1-5
- Add the new sed to change the ~

* Sun Dec  7 17:00:00 2008 Pingou <pingou-at-pingoured.fr> 2.5.1-4
- Remove the Patch0

* Fri Dec  5 17:00:00 2008 Pingou <pingou-at-pingoured.fr> 2.5.1-3
- Apply patch for copy of the sources


alchemist-1.0.37-6.fc11
-----------------------
* Sun Dec  7 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.37-6
- Fix for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.37-5
- Rebuild for Python 2.6


arp-scan-1.7-2.fc10
-------------------
* Tue Nov 11 17:00:00 2008 Itamar Reis Peixoto <itamar at ispbrasil.com.br> 1.7-2
- no luck with cvs commit, reimporting new SRPM version via cvs-import.sh

* Tue Nov 11 17:00:00 2008 Itamar Reis Peixoto <itamar at ispbrasil.com.br> 1.7-1
- upgrade to new version


beecrypt-4.1.2-18.fc11
----------------------
* Sun Dec  7 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 4.1.2-18
- Rebuild for python 2.6 and libtool 2.2


brltty-3.10-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.10-2
- Rebuild for Python 2.6


ccsm-0.7.8-1.fc11
-----------------
* Sun Dec  7 17:00:00 2008 Mohd Izhar Firdaus Ismail <mohd.izhar.firdaus at gmail.com> 0.7.8-1
- 0.7.8 update


cjkunifonts-0.2.20080216.1-10.fc11
----------------------------------
* Sun Dec  7 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> - 0.2.20080216.1-10.fc11
- Don't umask before fc-cache.
- Add -f to fc-cache.


cohoba-0.0.4-7.fc11
-------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.0.4-7
- Rebuild for Python 2.6


collectd-4.5.1-2.fc11
---------------------
* Sun Dec  7 17:00:00 2008 Alan Pevec <apevec at redhat.com> 4.5.1-2.1
- fix subpackages, bz# 475093

* Sun Nov 30 17:00:00 2008 Alan Pevec <apevec at redhat.com> 4.5.1-2
- workaround for https://bugzilla.redhat.com/show_bug.cgi?id=468067


compiz-0.7.8-8.fc11
-------------------
* Sun Dec  7 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.7.8-8
- Add 'obs' to default plugin list 
- Improve glx_tfp check


duplicity-0.5.03-1.fc11
-----------------------
* Sun Dec  7 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 0.5.03-1
- Upgrade to 0.5.03


fuse-zip-0.2.6-5.fc11
---------------------
* Sun Dec  7 17:00:00 2008 Rakesh Pandit <rakesh at fedoraproject.org> 0.2.6-5
- fixed debug info package


ganglia-3.1.1-2.fc11
--------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 3.1.1-2
- Rebuild for Python 2.6


gdal-1.6.0-0.2.rc4.fc11
-----------------------

gnome-settings-daemon-2.25.2-4.fc11
-----------------------------------
* Sun Dec  7 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> - 2.25.2-4
- Add gnome-settings-daemon-2.24.1-umask.patch


gramps-3.0.4-1.fc11
-------------------
* Sun Dec  7 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 3.0.4-1
- Update to 3.0.4


greadelf-1.0-2.fc11
-------------------
* Mon Dec  8 17:00:00 2008 Parag Nemade <panemade at gmail.com>- 1.0-2
- Add versioned requires for elfinfo


gtk-vnc-0.3.8-1.fc11
--------------------
* Sun Dec  7 17:00:00 2008 Daniel P. Berrange <berrange at redhat.com> - 0.3.8-1.fc11
- Update to 0.3.8 release


hamster-applet-2.24.2-3.fc11
----------------------------
* Sun Dec  7 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.24.2-3
- Rebuild for Python 2.6


ifstat-1.1-8.fc10
-----------------

iverilog-0.9.20081118-1.fc11
----------------------------
* Sun Dec  7 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> 0.9.20081118-1
- new snapshot release upstream.


jd-2.1.0-0.1.svn2551_trunk.fc11
-------------------------------
* Mon Dec  8 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2551


kernel-2.6.28-0.114.rc7.git5.fc11
---------------------------------
* Mon Dec  8 17:00:00 2008 Dave Airlie <airlied at redhat.com>
- modesetting: rebase radeon patch


mapserver-5.2.1-2.fc11
----------------------
* Sun Dec  7 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> 5.2.1-2
- enable agg render engine
- enable fribidi renderer
- build require agg-devel fribidi-devel

* Mon Dec  1 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> 5.2.1-1
- new stable upstream


python-boto-1.5c-1.fc11
-----------------------
* Sun Dec  7 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 1.5c-1
- Upgrade to 1.5c


python-iniparse-0.2.4-1.fc11
----------------------------
* Sun Dec  7 17:00:00 2008 Tim Lauridsen <timlau at fedoraproject.org> - 0.2.4-1
- Release 0.2.4:
-   Updated to work with Python-2.6 (Python-2.4 and 2.5 are still supported)
-   Support for files opened in unicode mode
-   Fixed Python-3.0 compatibility warnings
-   Minor API cleanup


qdevelop-0.26.1-2.fc11
----------------------
* Sun Dec  7 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 0.26.1-2
- Removed optional requires
- Patch to avoid segfault at startup


scigraphica-2.1.0-7.fc11
------------------------
* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.0-7
- Rebuild for Python 2.6


terminus-font-4.28-1.fc11
-------------------------
* Sun Sep 21 18:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 4.28-1
- Update to upstream's 4.28 release.
- Add -dv1, -ge1, -ij1 patches for more general appeal in cyrillic world.
- Add notes for framebuffer console to terminus-font-console.README.fedora.


tkcvs-8.2-1.fc11
----------------
* Sun Dec  7 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 8.2-1
- mew release 8.2


tor-0.2.0.32-1.fc11
-------------------
* Sun Dec  7 17:00:00 2008 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.2.0.32-1
- updated to 0.2.0.32
- removed -setgroups patch; supplementary groups are now set upstream


veusz-1.2.1-1.fc11
------------------
* Sun Dec  7 17:00:00 2008 Jeremy Sanders <jeremysanders at jeremysanders.net> - 1.2.1-1
- Update to Veusz 1.2.1
- Fix location of COPYING file for about dialog


vinagre-2.24.2-1.fc10
---------------------
* Fri Dec  5 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2-1
- Update to 2.24.2, fixing an insecure string handling issue


wput-0.6.1-4.fc10
-----------------

xfsprogs-2.10.2-1.fc11
----------------------
* Sun Dec  7 17:00:00 2008 Eric Sandeen <sandeen at redhat.com> 2.10.2-1
- New upstream release, bugfix only.


Summary:
Added Packages: 9
Removed Packages: 0
Modified Packages: 35
Broken deps for i386
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.i386 requires libpython2.5.so.1.0
	ScientificPython-qt-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.i386 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	avahi-ui-sharp-0.6.22-13.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.i386 requires libspectrum.so.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-gui-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.i386 requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rdflib-2.4.0-7.fc10.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.i386 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ScientificPython-qt-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.x86_64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	avahi-ui-sharp-0.6.22-13.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.x86_64 requires libspectrum.so.5()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.x86_64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	muine-devel-0.8.10-3.fc11.i386 requires pkgconfig(gtk-sharp-2.0)
	muine-devel-0.8.10-3.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.x86_64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.x86_64 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.x86_64 requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	ScientificPython-2.6.1-1.fc10.ppc requires libpython2.5.so.1.0
	ScientificPython-qt-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.ppc requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	avahi-ui-sharp-0.6.22-13.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc requires libspectrum.so.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.ppc requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	muine-devel-0.8.10-3.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.ppc requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tomboy-0.13.1-5.fc11.ppc requires pkgconfig(gtk-sharp-2.0)
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	ScientificPython-2.6.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ScientificPython-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	ScientificPython-qt-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	ScientificPython-tk-2.6.1-1.fc10.ppc64 requires python(abi) = 0:2.5
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc64 requires libspectrum.so.5()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-3.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sugar-toolkit-0.83.2-3.fc11.ppc64 requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From foss.mailinglists at gmail.com  Mon Dec  8 16:06:37 2008
From: foss.mailinglists at gmail.com (=?UTF-8?B?IlNhbmthcnNoYW4gKOCmuOCmmeCnjeCmleCmsOCnjeCmt+Cmoyki?=)
Date: Mon, 08 Dec 2008 21:36:37 +0530
Subject: Seahorse is orphaned?
In-Reply-To: <5256d0b0812080601h50f4f3f7q71f43c8f76749231@mail.gmail.com>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>	<1228141066.3391.6.camel@localhost.localdomain>	<493D24D1.6050202@redhat.com>
	<5256d0b0812080601h50f4f3f7q71f43c8f76749231@mail.gmail.com>
Message-ID: <493D460D.6020809@gmail.com>

Peter Robinson wrote:

> I guess that a rename would need to be taken upstream. I don't see why
> it can't have a description like Transmission or any of the others do
> in the .desktop to make it more descriptive. Transmission is listed as
> "Transmission Bittorrent client". So you could make it "Seahorse
> password and encrpytion manager" or something.

That might just turn out to be fun translating across the languages :)


-- 

http://www.gutenberg.net - Fine literature digitally re-published
http://www.plos.org - Public Library of Science
http://www.creativecommons.org - Flexible copyright for creative work




From mclasen at redhat.com  Mon Dec  8 16:15:14 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 08 Dec 2008 11:15:14 -0500
Subject: Work needed, how you can help!
In-Reply-To: <20081208140234.9a7ca66d.mschwendt@gmail.com>
References: <1228684966.3370.22.camel@localhost.localdomain>
	<20081208140234.9a7ca66d.mschwendt@gmail.com>
Message-ID: <1228752914.3539.10.camel@localhost.localdomain>

On Mon, 2008-12-08 at 14:02 +0100, Michael Schwendt wrote:
> On Sun, 07 Dec 2008 13:22:46 -0800, Jesse wrote:
> 
> > The work needed is for somebody to examine all the packages in rawhide
> > that provide .pc files and ensure proper placement of them based on the
> > review guideline.  This will likely require interaction with the
> > packages maintainer(s) so the first step should probably be to produce a
> > list of packages that ship .pc in a non -devel package and send the list
> > (sorted by maintainer) to here so that we can discuss and pick off
> > items.
> 
> Here are some different details. The following list shows:
> 
>  * non-devel packages that include .pc files
>  * any virtual -devel package names
>  * the dependencies on other packages, which provide .pc files
> 
> 
> => 1:control-center-2.25.2-4.fc11.i386 (control-center-2.25.2-4.fc11.src.rpm)
>     /usr/share/pkgconfig/gnome-default-applications.pc
>     /usr/share/pkgconfig/gnome-keybindings.pc
>     REQUIRES: gnome-icon-theme
>     REQUIRES: gnome-mime-data
>     REQUIRES: shared-mime-info
>     REQUIRES: gtk2-engines
>     REQUIRES: gtk2-devel
>     REQUIRES: libX11-devel
>     REQUIRES: libXdmcp-devel
>     REQUIRES: xorg-x11-proto-devel
>     REQUIRES: mesa-libGL-devel
>     REQUIRES: libXau-devel
>     REQUIRES: libxcb-devel
>     REQUIRES: atk-devel
>     REQUIRES: gtk-doc
>     REQUIRES: glib2-devel
>     REQUIRES: libXrandr-devel
>     REQUIRES: pango-devel
>     REQUIRES: cairo-devel
>     REQUIRES: freetype-devel
>     REQUIRES: pixman-devel
>     REQUIRES: libpng-devel
>     REQUIRES: libXrender-devel
>     REQUIRES: fontconfig-devel
>     REQUIRES: libXft-devel
>     REQUIRES: libXext-devel
>     REQUIRES: libXcomposite-devel
>     REQUIRES: libXfixes-devel
>     REQUIRES: libXcursor-devel
>     REQUIRES: libXi-devel
>     REQUIRES: libXinerama-devel

What do you mean here, exactly ? Yes, control-center contains those 2 pc
files, but they have no requires whatsoever, so they should certainly
not pull in any devel packages.



From mschwendt at gmail.com  Mon Dec  8 16:17:00 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 8 Dec 2008 17:17:00 +0100
Subject: Problem importing packages
In-Reply-To: <1228752180.7485.3.camel@PB3.Linux>
References: <1228732287.29271.35.camel@PB3.Linux>
	<20081208135446.ce04525e.mschwendt@gmail.com>
	<1228752180.7485.3.camel@PB3.Linux>
Message-ID: <20081208171700.32fc7250.mschwendt@gmail.com>

On Mon, 08 Dec 2008 16:03:00 +0000, Paul wrote:

> Hi,
> 
> > > Any ideas on what is causing this?
> > 
> > cvs-import.sh is a shell script. Search for the error message and
> > try the comments manually. What do you get for...?
> > rpm -qp --qf "%{SOURCERPM}" ~/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm
> 
> (unknown type)
> 
> That's all it says!

So, then that's an incompatibility introduced with whatever version
of RPM you've used here.

This breaks cvs-import.sh, which excepts above query to return

  (none)

for source rpms.

Temporarily you can comment out the source rpm check in cvs-import.sh
as a work-around. The script needs to be fixed. Or RPM needs to revert
the change and print "(none)" again.



From notting at redhat.com  Mon Dec  8 16:21:07 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 8 Dec 2008 11:21:07 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812081038.43323.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812070954.31864.sgrubb@redhat.com>
	<604aa7910812071529h4e14eff7l55614033eeddddd0@mail.gmail.com>
	<200812081038.43323.sgrubb@redhat.com>
Message-ID: <20081208162107.GB29696@nostromo.devel.redhat.com>

Steve Grubb (sgrubb at redhat.com) said: 
> On Sunday 07 December 2008 06:29:47 pm Jeff Spaleta wrote:
> > I still come back to one thing. ?Could the file permissions be
> > implemented differently so that CAPP compliance could be a system
> > install time choice, instead of being expressed in the configuration
> > of all installs?
> 
> Just wanted to let you know I am thinking about this. I need to think though  
> what this does to our project and how to make sure we still get the right 
> outcome.

The issue with doing this outside of the packages themselves is that you
then lose all the built-in audting (used here generally) support -
database verification, verification against package files, etc. Not to
mention it makes upgrade handling entertaining.

Bill



From notting at redhat.com  Mon Dec  8 16:24:10 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 8 Dec 2008 11:24:10 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <20081207015944.GC569180@hiwaay.net>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812052029.45500.sgrubb@redhat.com>
	<1228542924.4814.33.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<20081207015944.GC569180@hiwaay.net>
Message-ID: <20081208162410.GC29696@nostromo.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> Then later, Steve Grubb <sgrubb at redhat.com> said:
> > > So "cat >> /etc/shadow" is audited?
> >
> > Of course.
> 
> So cat will have to be setuid root so it can audit?  What about echo,
> bash, perl, etc.?
> 
> This is absurd.

As stated earlier, that's done by auditing of the access to the
file itself.

Bill



From dominik at greysector.net  Mon Dec  8 16:44:14 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 8 Dec 2008 17:44:14 +0100
Subject: rawhide report: 20081208 changes
In-Reply-To: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
Message-ID: <20081208164414.GA12760@mokona.greysector.net>

On Monday, 08 December 2008 at 17:05, Rawhide Report wrote:
> Compose started at Mon Dec  8 06:01:06 UTC 2008
[...]
> arp-scan-1.7-2.fc10
> -------------------
> * Tue Nov 11 17:00:00 2008 Itamar Reis Peixoto <itamar at ispbrasil.com.br> 1.7-2
> - no luck with cvs commit, reimporting new SRPM version via cvs-import.sh

What was the problem that you had? cvs-import.sh shouldn't be used for updating.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From mw_triad at users.sourceforge.net  Mon Dec  8 16:46:25 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 08 Dec 2008 10:46:25 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <ghf0it$j5h$1@ger.gmane.org>
References: <49393DE3.1080707@redhat.com>	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>	<4939A673.3090907@gmail.com>	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>	<1228555748.4211.2.camel@hughsie-work.lan>	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>	<1228592200.3417.7.camel@localhost.localdomain>	<16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>	<493AF806.5040804@gmail.com>
	<ghf0it$j5h$1@ger.gmane.org>
Message-ID: <ghjj11$94s$1@ger.gmane.org>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> Not sure it is something you want to copy, but I've had Mac laptops
>> refuse to start system updates because the battery was too low - and I
>> think even cell phones do that too.
> 
> PackageKit (at least gnome-packagekit, it might not be implemented yet in
> kpackagekit) won't check for updates at all if you're on battery.

KPackageKit apparently does... at least, it did last night.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
   -- from a story by Feech



From mschwendt at gmail.com  Mon Dec  8 16:43:02 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 8 Dec 2008 17:43:02 +0100
Subject: Work needed, how you can help!
In-Reply-To: <1228752914.3539.10.camel@localhost.localdomain>
References: <1228684966.3370.22.camel@localhost.localdomain>
	<20081208140234.9a7ca66d.mschwendt@gmail.com>
	<1228752914.3539.10.camel@localhost.localdomain>
Message-ID: <20081208174302.27db19fc.mschwendt@gmail.com>

On Mon, 08 Dec 2008 11:15:14 -0500, Matthias wrote:

> > Here are some different details. The following list shows:
> > 
> >  * non-devel packages that include .pc files
> >  * any virtual -devel package names
> >  * the dependencies on other packages, which provide .pc files
> > 
> > 
> > => 1:control-center-2.25.2-4.fc11.i386 (control-center-2.25.2-4.fc11.src.rpm)
> >     /usr/share/pkgconfig/gnome-default-applications.pc
> >     /usr/share/pkgconfig/gnome-keybindings.pc
> >     REQUIRES: gnome-icon-theme
> >     REQUIRES: gnome-mime-data
> >     REQUIRES: shared-mime-info
> >     REQUIRES: gtk2-engines
> >     REQUIRES: gtk2-devel
> >     REQUIRES: libX11-devel
> >     REQUIRES: libXdmcp-devel
> >     REQUIRES: xorg-x11-proto-devel
> >     REQUIRES: mesa-libGL-devel
> >     REQUIRES: libXau-devel
> >     REQUIRES: libxcb-devel
> >     REQUIRES: atk-devel
> >     REQUIRES: gtk-doc
> >     REQUIRES: glib2-devel
> >     REQUIRES: libXrandr-devel
> >     REQUIRES: pango-devel
> >     REQUIRES: cairo-devel
> >     REQUIRES: freetype-devel
> >     REQUIRES: pixman-devel
> >     REQUIRES: libpng-devel
> >     REQUIRES: libXrender-devel
> >     REQUIRES: fontconfig-devel
> >     REQUIRES: libXft-devel
> >     REQUIRES: libXext-devel
> >     REQUIRES: libXcomposite-devel
> >     REQUIRES: libXfixes-devel
> >     REQUIRES: libXcursor-devel
> >     REQUIRES: libXi-devel
> >     REQUIRES: libXinerama-devel
> 
> What do you mean here, exactly ? Yes, control-center contains those 2 pc
> files, but they have no requires whatsoever, so they should certainly
> not pull in any devel packages.
 
The control-center dependency-chain includes -devel packages.

Above list of "REQUIRES" shows all the packages in the dep-chain,
which include .pc files. They are pulled in by RPM's new pkgconfig(foo)
auto-dependencies most likely.

Notice "gtk2-engines" in above list and the separate report for it in my
original mail. It's the culprit. It "Requires: pkgconfig(gtk+-2.0)", which
pulls in gtk2-devel into control-center's dep-chain.



From balbir at linux.vnet.ibm.com  Mon Dec  8 16:51:52 2008
From: balbir at linux.vnet.ibm.com (Balbir Singh)
Date: Mon, 8 Dec 2008 22:21:52 +0530
Subject: Enabling the memory controller for F11
In-Reply-To: <493D4128.8050402@BitWagon.com>
References: <20081208062952.GG13333@balbir.in.ibm.com>
	<493D4128.8050402@BitWagon.com>
Message-ID: <20081208165152.GQ13333@balbir.in.ibm.com>

* John Reiser <jreiser at BitWagon.com> [2008-12-08 07:45:44]:

> > [Please] enable the memory controller for F11.
> 
> Please give a URL to a description of what it does, what are the benefits
> (to users, developers, administrators, ...), and what are the costs.
> Searching is tedious, and difficult to know when to stop.
> 

Hi, John,

Documentation/controllers/memory.txt provides extensive details and
the help text also provides information about the config and its use
case and benefits and tradeoffs, along with boot time options.


-- 
	Balbir



From nicu_fedora at nicubunu.ro  Mon Dec  8 16:52:38 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Mon, 08 Dec 2008 18:52:38 +0200
Subject: FAmSCo elections only open to ambassadors?
In-Reply-To: <493D4194.1070804@hhs.nl>
References: <493D4194.1070804@hhs.nl>
Message-ID: <493D50D6.3020700@nicubunu.ro>

Hans de Goede wrote:
> 
> Don't get me wrong I think that people who contribute to Fedora by doing 
> marketing in the broadest sense of the word, or by doing translations, 
> as such have earned every right to influence future development of 
> Fedora. But how is it that the people who are building the distro, do 
> not get to influence how the distro is represented to the world by our 
> Ambassadors?

I am not an Ambassador so I can't vote there but I don't have any 
problem with that, from the mission and goals, it seems like it is an 
administrative organization and it make sense for the vote to be closed 
to its members:
http://fedoraproject.org/wiki/Ambassadors/SteeringCommittee#Mission_and_Goals

Also, the Ambassadors are an easy to join group, I believe a number of 
developers are registered as Ambassadors.

-- 
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 city-fan.org  Mon Dec  8 16:54:18 2008
From: paul at city-fan.org (Paul Howarth)
Date: Mon, 08 Dec 2008 16:54:18 +0000
Subject: Work needed, how you can help!
In-Reply-To: <1228752914.3539.10.camel@localhost.localdomain>
References: <1228684966.3370.22.camel@localhost.localdomain>	<20081208140234.9a7ca66d.mschwendt@gmail.com>
	<1228752914.3539.10.camel@localhost.localdomain>
Message-ID: <493D513A.6000505@city-fan.org>

Matthias Clasen wrote:
> On Mon, 2008-12-08 at 14:02 +0100, Michael Schwendt wrote:
>> On Sun, 07 Dec 2008 13:22:46 -0800, Jesse wrote:
>>
>>> The work needed is for somebody to examine all the packages in rawhide
>>> that provide .pc files and ensure proper placement of them based on the
>>> review guideline.  This will likely require interaction with the
>>> packages maintainer(s) so the first step should probably be to produce a
>>> list of packages that ship .pc in a non -devel package and send the list
>>> (sorted by maintainer) to here so that we can discuss and pick off
>>> items.
>> Here are some different details. The following list shows:
>>
>>  * non-devel packages that include .pc files
>>  * any virtual -devel package names
>>  * the dependencies on other packages, which provide .pc files
>>
>>
>> => 1:control-center-2.25.2-4.fc11.i386 (control-center-2.25.2-4.fc11.src.rpm)
>>     /usr/share/pkgconfig/gnome-default-applications.pc
>>     /usr/share/pkgconfig/gnome-keybindings.pc
>>     REQUIRES: gnome-icon-theme
>>     REQUIRES: gnome-mime-data
>>     REQUIRES: shared-mime-info
>>     REQUIRES: gtk2-engines
>>     REQUIRES: gtk2-devel
>>     REQUIRES: libX11-devel
>>     REQUIRES: libXdmcp-devel
>>     REQUIRES: xorg-x11-proto-devel
>>     REQUIRES: mesa-libGL-devel
>>     REQUIRES: libXau-devel
>>     REQUIRES: libxcb-devel
>>     REQUIRES: atk-devel
>>     REQUIRES: gtk-doc
>>     REQUIRES: glib2-devel
>>     REQUIRES: libXrandr-devel
>>     REQUIRES: pango-devel
>>     REQUIRES: cairo-devel
>>     REQUIRES: freetype-devel
>>     REQUIRES: pixman-devel
>>     REQUIRES: libpng-devel
>>     REQUIRES: libXrender-devel
>>     REQUIRES: fontconfig-devel
>>     REQUIRES: libXft-devel
>>     REQUIRES: libXext-devel
>>     REQUIRES: libXcomposite-devel
>>     REQUIRES: libXfixes-devel
>>     REQUIRES: libXcursor-devel
>>     REQUIRES: libXi-devel
>>     REQUIRES: libXinerama-devel
> 
> What do you mean here, exactly ? Yes, control-center contains those 2 pc
> files, but they have no requires whatsoever, so they should certainly
> not pull in any devel packages.

control-center has a dependency on libgnome-2.so.0, provided by libgnome.

libgnome has a dependency on fedora-gnome-theme.

fedora-gnome-theme has a dependency on fedora-icon-theme.

fedora-icon-theme has a dependency on gnome-themes.

gnome-themes has a dependency on gtk2-engines.

gtk2-engines includes a .pc file with "Requires: gtk+-2.0".

Result: list of dependencies as above.

Paul.



From mclasen at redhat.com  Mon Dec  8 16:55:21 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 08 Dec 2008 11:55:21 -0500
Subject: Work needed, how you can help!
In-Reply-To: <20081208174302.27db19fc.mschwendt@gmail.com>
References: <1228684966.3370.22.camel@localhost.localdomain>
	<20081208140234.9a7ca66d.mschwendt@gmail.com>
	<1228752914.3539.10.camel@localhost.localdomain>
	<20081208174302.27db19fc.mschwendt@gmail.com>
Message-ID: <1228755321.3539.15.camel@localhost.localdomain>

On Mon, 2008-12-08 at 17:43 +0100, Michael Schwendt wrote:

>  
> The control-center dependency-chain includes -devel packages.
> 
> Above list of "REQUIRES" shows all the packages in the dep-chain,
> which include .pc files. They are pulled in by RPM's new pkgconfig(foo)
> auto-dependencies most likely.
> 
> Notice "gtk2-engines" in above list and the separate report for it in my
> original mail. It's the culprit. It "Requires: pkgconfig(gtk+-2.0)", which
> pulls in gtk2-devel into control-center's dep-chain.

Ah, ok. That makes sense. The pc files in control-center are innocent,
then.



From surenkarapetyan at gmail.com  Mon Dec  8 17:05:09 2008
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Mon, 08 Dec 2008 21:05:09 +0400
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812060745.37122.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812052029.45500.sgrubb@redhat.com>	<1228542924.4814.33.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
Message-ID: <493D53C5.9060206@gmail.com>

Steve Grubb wrote:
> On Saturday 06 December 2008 00:55:24 Jesse Keating wrote:
>   
>>  These are required to be this way for our Common Criteria evaluations.
>>
>> Is the thought here that if the code can be executed by a non-root user,
>> the audit of the code would have to be far more strict?
>>     
>
> No, it has more to do with the fact that we have to audit all attempts to 
> modify trusted databases - in this case, shadow. No one can use these tools 
> since they do not have the permissions required to be successful. So, we 
> remove the ability to use these tools so that we don't have to audit it. 
>
> IOW, if we open the permissions, we need to make these become setuid root so 
> that we send audit events saying they failed.
>   
No you don't, cause you said yourself filesystem-level auditing is still
done.
So if someone tries to use usermod to modify /etc/passwd and hasn't the
permissions it takes, it will be logged.
usermod is just another tool to modify /etc/passwd, ...
With exactly the same reasoning You could chmod 750 /bin/vi
>
>   
>> I'm just curious what added security you really get.
>>     
>
> Its not so much a security thing as much as its a certification thing. An 
> ordinary user cannot possibly use these tools since they do not have the 
> requisite permissions.
>
> -Steve
>
>   
I understand that there may be many people who want that certification
thing, but it's just another special use-case for Fedora.
And as we don't make everyone's desktop run free-ipa servers just
because "modern operating systems must have directory servers", we also
shouldn't make everyone's usermod 750 just because there may be some
companies with some policy to use only certified software.
So I think the best way to satisfy the requirements for certification is
with separate packages/scripts/options.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/b53f64d4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/b53f64d4/attachment.sig>

From lesmikesell at gmail.com  Mon Dec  8 17:27:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 08 Dec 2008 11:27:06 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <493D2184.2000702@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812070954.31864.sgrubb@redhat.com>	<87k5ac9cat.fsf@sheridan.bigo.ensc.de>	<200812071151.38419.sgrubb@redhat.com>	<1228690989.3923.9.camel@naomi.s4.naomi.abartlet.net>	<1228691121.3370.28.camel@localhost.localdomain>	<1228691364.3311.66.camel@localhost.localdomain>	<493C5D7A.101@gmail.com>
	<493D2184.2000702@redhat.com>
Message-ID: <493D58EA.40205@gmail.com>

Stephen Gallagher wrote:
>
> Les Mikesell wrote:
>> Is attempting an access that the kernel routinely prevents considered a
>> violation?  That is, if I type 'file /etc/*' on such a system should I
>> expect the black helicopters to start firing?  I don't see how accesses
>> that are denied matter to anyone - or why anyone running the
>> shadow-tools utility without permission to access the relevant files
>> should bother anyone either.
>>
> 
> Actually, yes. There are environments in which an administrator may set
> up heuristics to determine whether a user is attempting to probe the
> system for vulnerability. In the systems like this I've seen, one very
> common action to note is failed attempts by users to execute processes
> in /sbin or /usr/sbin. Seeing the same user attempt to execute every
> binary in one of those folders could be a clear sign that they are
> probing for misconfigurations to take advantage of.

But shouldn't the effort go toward making sure that there are no 
vulnerabilities to take advantage of at all?  If they aren't setuid, one 
binary can't do anything that any other binary/interpreter can do.  I 
could understand tracking anything setuid but why bother with anything 
else?  You can access (or fail to access) all the same files/devices the 
same way with shell redirection.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Mon Dec  8 17:31:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 08 Dec 2008 11:31:49 -0600
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <493D53C5.9060206@gmail.com>
References: <1228519621.22587.19.camel@localhost.localdomain>	<200812052029.45500.sgrubb@redhat.com>	<1228542924.4814.33.camel@localhost.localdomain>	<200812060745.37122.sgrubb@redhat.com>
	<493D53C5.9060206@gmail.com>
Message-ID: <493D5A05.8040109@gmail.com>

Suren Karapetyan wrote:
> Steve Grubb wrote:
>
>> IOW, if we open the permissions, we need to make these become setuid root so 
>> that we send audit events saying they failed.
>>   
> No you don't, cause you said yourself filesystem-level auditing is still
> done.
> So if someone tries to use usermod to modify /etc/passwd and hasn't the
> permissions it takes, it will be logged.
> usermod is just another tool to modify /etc/passwd, ...
> With exactly the same reasoning You could chmod 750 /bin/vi

And, of course, /bin/bash which is equally capable of modifying files.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From a.badger at gmail.com  Mon Dec  8 17:47:15 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 08 Dec 2008 09:47:15 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <493C462B.4070607@gmail.com>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<493C462B.4070607@gmail.com>
Message-ID: <493D5DA3.7010408@gmail.com>

Les Mikesell wrote:

> Is there some shortage of names?  Why can't a new and incompatible
> language be given a different name so people don't try to use it with
> the old and different code?
> 

Before we go too far down the argument of whether we need one or two
python interpreters in Fedora we need to see what the nature of the
problems are.  Python-2.6 plus the from __future__ import * stuff gets
us something very close to compatibile with python-3.0.  Python-2.7 and
python-3.1 are supposed to be even closer.  The last time I tested, it
was possible to turn on the from __future__ import * features on a file
by file basis.  So -- if the compatibility of python-3 and python-2.6+
are good enough Fedora could run python-3 and python-2 targeted
upstreams together under python-2.6+.  We need to gather experience
trying to do this before we know, though.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/7595f483/attachment.sig>

From debarshi.ray at gmail.com  Mon Dec  8 18:06:26 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 8 Dec 2008 23:36:26 +0530
Subject: FAmSCo elections only open to ambassadors?
In-Reply-To: <493D50D6.3020700@nicubunu.ro>
References: <493D4194.1070804@hhs.nl> <493D50D6.3020700@nicubunu.ro>
Message-ID: <3170f42f0812081006p33f8a09dr42c1f8960bb4d579@mail.gmail.com>

> Also, the Ambassadors are an easy to join group, I believe a number of
> developers are registered as Ambassadors.

This is a very bad argument. Just because it might be 'easy' to join a
group does not mean that one can join it and forget about the
responsibilities that come with it. So it is wrong to tell someone
that since it is 'easy' to become an Ambassador he should become one
merely for the sake of being able to vote.

It is way beyond my knowledge and abilities to comment on how easy it
is and whether non-Ambassadors should be able to vote or not, but I
feel that this is not a correct argument.

Regards,
Debarshi



From cra at WPI.EDU  Mon Dec  8 17:57:17 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Dec 2008 12:57:17 -0500
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812061252.26557.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812060745.37122.sgrubb@redhat.com>
	<1228582591.4814.37.camel@localhost.localdomain>
	<200812061252.26557.sgrubb@redhat.com>
Message-ID: <20081208175717.GC17609@angus.ind.WPI.EDU>

On Sat, Dec 06, 2008 at 12:52:26PM -0500, Steve Grubb wrote:
> An unprivileged user cannot successfully use this utility. Just like tcpdump 
> can't be used.

Wrong.  tcpdump can certainly read a capture file and parse it without 
any special privs.



From pmatilai at laiskiainen.org  Mon Dec  8 18:17:49 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 8 Dec 2008 20:17:49 +0200 (EET)
Subject: Problem importing packages
In-Reply-To: <20081208171700.32fc7250.mschwendt@gmail.com>
References: <1228732287.29271.35.camel@PB3.Linux>
	<20081208135446.ce04525e.mschwendt@gmail.com>
	<1228752180.7485.3.camel@PB3.Linux>
	<20081208171700.32fc7250.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0812082015550.25887@turre.koti.laiskiainen.org>

On Mon, 8 Dec 2008, Michael Schwendt wrote:

> On Mon, 08 Dec 2008 16:03:00 +0000, Paul wrote:
>
>> Hi,
>>
>>>> Any ideas on what is causing this?
>>>
>>> cvs-import.sh is a shell script. Search for the error message and
>>> try the comments manually. What do you get for...?
>>> rpm -qp --qf "%{SOURCERPM}" ~/rpmbuild/SRPMS/mono-2.2-8.pre2.fc11.src.rpm
>>
>> (unknown type)
>>
>> That's all it says!
>
> So, then that's an incompatibility introduced with whatever version
> of RPM you've used here.
>
> This breaks cvs-import.sh, which excepts above query to return
>
>  (none)
>
> for source rpms.
>
> Temporarily you can comment out the source rpm check in cvs-import.sh
> as a work-around. The script needs to be fixed. Or RPM needs to revert
> the change and print "(none)" again.

This is unintentional breakage in rpm 4.6.0-rc2, I'll pull the fix to 
Fedora tomorrow (getting a bit late for today)

 	- Panu -



From rjones at redhat.com  Mon Dec  8 18:33:34 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 8 Dec 2008 18:33:34 +0000
Subject: rawhide report: 20081208 changes
In-Reply-To: <20081208164414.GA12760@mokona.greysector.net>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
	<20081208164414.GA12760@mokona.greysector.net>
Message-ID: <20081208183334.GA29491@thinkpad>

On Mon, Dec 08, 2008 at 05:44:14PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 08 December 2008 at 17:05, Rawhide Report wrote:
> > Compose started at Mon Dec  8 06:01:06 UTC 2008
> [...]
> > arp-scan-1.7-2.fc10
> > -------------------
> > * Tue Nov 11 17:00:00 2008 Itamar Reis Peixoto <itamar at ispbrasil.com.br> 1.7-2
> > - no luck with cvs commit, reimporting new SRPM version via cvs-import.sh
> 
> What was the problem that you had? cvs-import.sh shouldn't be used for updating.

It shouldn't?  I've updated packages in the past using cvs-import.sh,
although since I worked out the purpose of the 'sources' file and
'make upload FILE=foo' I haven't needed to recently.  But I didn't
think it did any harm to use cvs-import.sh.

BTW, is this stuff really documented anywhere?  I have tended to learn
it by osmosis, deduction and reading the horribly complicated rules in
Makefile.common.

Rich.



From lesmikesell at gmail.com  Mon Dec  8 18:35:04 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 08 Dec 2008 12:35:04 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <493D5DA3.7010408@gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com>
Message-ID: <493D68D8.2000308@gmail.com>

Toshio Kuratomi wrote:
> 
>> Is there some shortage of names?  Why can't a new and incompatible
>> language be given a different name so people don't try to use it with
>> the old and different code?
>>
> 
> Before we go too far down the argument of whether we need one or two
> python interpreters in Fedora we need to see what the nature of the
> problems are.  Python-2.6 plus the from __future__ import * stuff gets
> us something very close to compatibile with python-3.0.  Python-2.7 and
> python-3.1 are supposed to be even closer.  The last time I tested, it
> was possible to turn on the from __future__ import * features on a file
> by file basis.  So -- if the compatibility of python-3 and python-2.6+
> are good enough Fedora could run python-3 and python-2 targeted
> upstreams together under python-2.6+.  We need to gather experience
> trying to do this before we know, though.

The problem I see here is that even if you decide that you can manage a 
cutover for everything included/upstream in fedora, it is a bad idea to 
assume that users are ready and willing to do the same with their own 
code on the same day - or that they will know not to update until they 
can.  You'll probably cover most of the cases if you can update mailman, 
rhythmbox, yum and the system* tools on the same day, but you never 
know.  And what is the backout strategy for someone whose apps are broken?

I just don't get why any sane person, especially anyone familiar with 
computer languages, would ever want to give something that is not the 
same the same name.  Does anyone know how the developer(s) manage this 
themselves?  I have to think they are keeping multiple concurrent 
versions installed (and that that is the only reasonable approach).

-- 
   Les Mikesell
     lesmikesell at gmail.com





From nicolas.mailhot at laposte.net  Mon Dec  8 18:40:01 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 08 Dec 2008 19:40:01 +0100
Subject: rawhide report: 20081208 changes
In-Reply-To: <20081208183334.GA29491@thinkpad>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
	<20081208164414.GA12760@mokona.greysector.net>
	<20081208183334.GA29491@thinkpad>
Message-ID: <1228761601.20728.3.camel@arekh.okg>

Le lundi 08 d?cembre 2008 ? 18:33 +0000, Richard W.M. Jones a ?crit :
>  
> > What was the problem that you had? cvs-import.sh shouldn't be used for updating.
> 
> It shouldn't?  

There is a cabal that insists cvs-import.sh is "dangerous". Those same
people find perfectly normal that packagers regularly make mistakes with
direct cvs use, including pushing the wrong version of files to users
and wasting tens of minutes battling cvs tags.

I say, just use the method that works for you and ignore naysayers.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/f7bc9fba/attachment.sig>

From tibbs at math.uh.edu  Mon Dec  8 18:40:46 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 08 Dec 2008 12:40:46 -0600
Subject: rawhide report: 20081208 changes
In-Reply-To: <20081208183334.GA29491@thinkpad>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
	<20081208164414.GA12760@mokona.greysector.net>
	<20081208183334.GA29491@thinkpad>
Message-ID: <ufazlj6qzm9.fsf@epithumia.math.uh.edu>

>>>>> "RWMJ" == Richard W M Jones <rjones at redhat.com> writes:

RWMJ> It shouldn't?

You can use it for that, but it's a bad idea.

The point of keeping packages in an SCM is to enable multiple people
to work on a package.  If you keep your sources elsewhere and only
touch CVS by using cvs-import.sh to basically overwrite everything
with your SRPM then you wipe out any work that someone else did.

 - J<



From jkeating at redhat.com  Mon Dec  8 18:45:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 08 Dec 2008 10:45:13 -0800
Subject: rawhide report: 20081208 changes
In-Reply-To: <ufazlj6qzm9.fsf@epithumia.math.uh.edu>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
	<20081208164414.GA12760@mokona.greysector.net>
	<20081208183334.GA29491@thinkpad>
	<ufazlj6qzm9.fsf@epithumia.math.uh.edu>
Message-ID: <1228761913.3545.1.camel@localhost.localdomain>

On Mon, 2008-12-08 at 12:40 -0600, Jason L Tibbitts III wrote:
> >>>>> "RWMJ" == Richard W M Jones <rjones at redhat.com> writes:
> 
> RWMJ> It shouldn't?
> 
> You can use it for that, but it's a bad idea.
> 
> The point of keeping packages in an SCM is to enable multiple people
> to work on a package.  If you keep your sources elsewhere and only
> touch CVS by using cvs-import.sh to basically overwrite everything
> with your SRPM then you wipe out any work that someone else did.
> 
>  - J<

Except that you get shown the diff before you can commit it, and you can
back out if there have been any changes.

I use cvs-import all the time as hardly anybody ever touches my
packages, and it's far easier to just call the script to do the work for
me.  Responsible usage of cvs-import.sh is fine, irresponsible use of it
(just like with anything else, like cvs direct) is not fine.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/e0928acb/attachment.sig>

From jkeating at redhat.com  Mon Dec  8 18:47:26 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 08 Dec 2008 10:47:26 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <493D68D8.2000308@gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com>  <493D68D8.2000308@gmail.com>
Message-ID: <1228762046.3545.2.camel@localhost.localdomain>

> On Mon, 2008-12-08 at 12:35 -0600, Les Mikesell wrote:
> 
> I just don't get why any sane person, especially anyone familiar with 
> computer languages, would ever want to give something that is not the 
> same the same name.  Does anyone know how the developer(s) manage this 
> themselves?  I have to think they are keeping multiple concurrent 
> versions installed (and that that is the only reasonable approach).

I'm pretty certain that if you look at any language, they've all faced
similar scenarios, major version upgrades that may in fact not be
forward no backward compatible.  People have dealt with it and moved on.
No language is perfect.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/1f20c067/attachment.sig>

From konrad at tylerc.org  Mon Dec  8 18:51:40 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 8 Dec 2008 10:51:40 -0800
Subject: rawhide report: 20081208 changes
In-Reply-To: <20081208183334.GA29491@thinkpad>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
	<20081208164414.GA12760@mokona.greysector.net>
	<20081208183334.GA29491@thinkpad>
Message-ID: <200812081051.40704.konrad@tylerc.org>

On Monday 08 December 2008 10:33:34 am Richard W.M. Jones wrote:
> On Mon, Dec 08, 2008 at 05:44:14PM +0100, Dominik 'Rathann' Mierzejewski 
wrote:
> > On Monday, 08 December 2008 at 17:05, Rawhide Report wrote:
> > > Compose started at Mon Dec  8 06:01:06 UTC 2008
> >
> > [...]
> >
> > > arp-scan-1.7-2.fc10
> > > -------------------
> > > * Tue Nov 11 17:00:00 2008 Itamar Reis Peixoto
> > > <itamar at ispbrasil.com.br> 1.7-2 - no luck with cvs commit, reimporting
> > > new SRPM version via cvs-import.sh
> >
> > What was the problem that you had? cvs-import.sh shouldn't be used for
> > updating.
>
> It shouldn't?  I've updated packages in the past using cvs-import.sh,
> although since I worked out the purpose of the 'sources' file and
> 'make upload FILE=foo' I haven't needed to recently.  But I didn't
> think it did any harm to use cvs-import.sh.
>
> BTW, is this stuff really documented anywhere?  I have tended to learn
> it by osmosis, deduction and reading the horribly complicated rules in
> Makefile.common.
>
> Rich.

By "this stuff" do you mean sources and the various make targets? Try "make 
help" for some of those. There are only a couple files in each branch of cvs, 
it's easy to figure out what each one does (especially if you pay attention 
to the initial cvs-import.sh script's output).

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From tibbs at math.uh.edu  Mon Dec  8 18:58:10 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 08 Dec 2008 12:58:10 -0600
Subject: rawhide report: 20081208 changes
In-Reply-To: <1228761913.3545.1.camel@localhost.localdomain>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
	<20081208164414.GA12760@mokona.greysector.net>
	<20081208183334.GA29491@thinkpad>
	<ufazlj6qzm9.fsf@epithumia.math.uh.edu>
	<1228761913.3545.1.camel@localhost.localdomain>
Message-ID: <ufaprk2qyt9.fsf@epithumia.math.uh.edu>

>>>>> "JK" == Jesse Keating <jkeating at redhat.com> writes:

JK> Except that you get shown the diff before you can commit it, and
JK> you can back out if there have been any changes.

I'm glad it does that now, but of course you would expect there to be
changes since the only reason you'd be importing a new package is if
you changed something.  So to avoid the situation I described, you'd
have to inspect those diffs and make sure that there's nothing
unexpected in there.  And yes, I've had changes I made to another
package (license tag fixes) wiped out by someone using cvs-import.sh
and not inspecting the diffs closely enough.

 - J<



From lesmikesell at gmail.com  Mon Dec  8 19:03:25 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 08 Dec 2008 13:03:25 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <1228762046.3545.2.camel@localhost.localdomain>
References: <49393DE3.1080707@redhat.com>	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>	<493D5DA3.7010408@gmail.com>
	<493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
Message-ID: <493D6F7D.7060501@gmail.com>

Jesse Keating wrote:
>> On Mon, 2008-12-08 at 12:35 -0600, Les Mikesell wrote:
>>
>> I just don't get why any sane person, especially anyone familiar with 
>> computer languages, would ever want to give something that is not the 
>> same the same name.  Does anyone know how the developer(s) manage this 
>> themselves?  I have to think they are keeping multiple concurrent 
>> versions installed (and that that is the only reasonable approach).
> 
> I'm pretty certain that if you look at any language, they've all faced
> similar scenarios, major version upgrades that may in fact not be
> forward no backward compatible.  People have dealt with it and moved on.
> No language is perfect.

But where the change was anything more than a bugfix they dealt with it 
by permitting the old/new languages to run in parallel until everyone 
had time to make the necessary changes.  And in the old days of static 
compiled binaries and versioned libraries it didn't make such a big 
difference since you could keep running your old versions even if the 
current compiler couldn't build them.   That doesn't work with 
interpreted languages and massive plugin usage - everything has to be 
versioned together or kept in separate namespaces.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Mon Dec  8 19:04:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 08 Dec 2008 11:04:12 -0800
Subject: rawhide report: 20081208 changes
In-Reply-To: <ufaprk2qyt9.fsf@epithumia.math.uh.edu>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
	<20081208164414.GA12760@mokona.greysector.net>
	<20081208183334.GA29491@thinkpad>
	<ufazlj6qzm9.fsf@epithumia.math.uh.edu>
	<1228761913.3545.1.camel@localhost.localdomain>
	<ufaprk2qyt9.fsf@epithumia.math.uh.edu>
Message-ID: <1228763052.3545.3.camel@localhost.localdomain>

On Mon, 2008-12-08 at 12:58 -0600, Jason L Tibbitts III wrote:
> I'm glad it does that now, but of course you would expect there to be
> changes since the only reason you'd be importing a new package is if
> you changed something.  So to avoid the situation I described, you'd
> have to inspect those diffs and make sure that there's nothing
> unexpected in there.  And yes, I've had changes I made to another
> package (license tag fixes) wiped out by someone using cvs-import.sh
> and not inspecting the diffs closely enough.

Which if they're not looking closely enough with cvs-import.sh, they're
not going to look closely enough when they copy the .spec from the
upstream repo into pkg-cvs.  The problem is with the maintainer, not the
tool.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/5e1bd05e/attachment.sig>

From pertusus at free.fr  Mon Dec  8 19:51:38 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 20:51:38 +0100
Subject: rawhide report: 20081208 changes
In-Reply-To: <20081208183334.GA29491@thinkpad>
References: <20081208160513.6751E1F81D6@releng2.fedora.phx.redhat.com>
	<20081208164414.GA12760@mokona.greysector.net>
	<20081208183334.GA29491@thinkpad>
Message-ID: <20081208195138.GC2882@free.fr>

On Mon, Dec 08, 2008 at 06:33:34PM +0000, Richard W.M. Jones wrote:
> 
> BTW, is this stuff really documented anywhere?  I have tended to learn
> it by osmosis, deduction and reading the horribly complicated rules in
> Makefile.common.

It is documented in
http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo
and use of cvs-import.sh is covered in
http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#Import_of_complete_src.rpm_packages

--
Pat



From kevin.kofler at chello.at  Mon Dec  8 20:15:50 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 08 Dec 2008 21:15:50 +0100
Subject: The looming Python 3(000) monster
References: <49393DE3.1080707@redhat.com>	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>	<4939A673.3090907@gmail.com>	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>	<1228555748.4211.2.camel@hughsie-work.lan>	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>	<1228592200.3417.7.camel@localhost.localdomain>	<16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>	<493AF806.5040804@gmail.com>
	<ghf0it$j5h$1@ger.gmane.org> <ghjj11$94s$1@ger.gmane.org>
Message-ID: <ghjv9m$n64$1@ger.gmane.org>

Matthew Woehlke wrote:
> KPackageKit apparently does... at least, it did last night.

Then why didn't you file a bug?

Our default setup is NOT to do that, but KPackageKit sometimes forgets that
setting for whatever reason. It just did that for me too. It's clearly a
bug.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec  8 20:32:22 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 08 Dec 2008 21:32:22 +0100
Subject: use fcron as default scheduler in Fedora?
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr>
Message-ID: <ghk08m$ru3$1@ger.gmane.org>

Patrice Dumas wrote:
> If there is none, it uses /bin/vi. In fact I have sone a bit of
> investigations and it uses, in pathnames.h _PATH_VI which is defined in
> /usr/invlude/paths.h.
> 
> So it is a missing dependency, in my opinion.

No it's not. People may want to use an actually usable editor and not have
their system polluted with this relict of history.

I guess I should file bugs against cvs, sudo and fcron which all have
unnecessary Requires on vim-minimal.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec  8 20:42:43 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 08 Dec 2008 21:42:43 +0100
Subject: The looming Python 3(000) monster
References: <49393DE3.1080707@redhat.com>	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>	<4939A673.3090907@gmail.com>	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>	<1228555748.4211.2.camel@hughsie-work.lan>	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>	<1228592200.3417.7.camel@localhost.localdomain>	<16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>	<493AF806.5040804@gmail.com>
	<ghf0it$j5h$1@ger.gmane.org> <ghjj11$94s$1@ger.gmane.org>
	<ghjv9m$n64$1@ger.gmane.org>
Message-ID: <ghk0s3$u93$1@ger.gmane.org>

I wrote:

> Matthew Woehlke wrote:
>> KPackageKit apparently does... at least, it did last night.
> 
> Then why didn't you file a bug?
> 
> Our default setup is NOT to do that, but KPackageKit sometimes forgets
> that setting for whatever reason. It just did that for me too. It's
> clearly a bug.

I just filed https://bugzilla.redhat.com/show_bug.cgi?id=475303 . We will
try to figure out what's going wrong.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec  8 20:51:35 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 08 Dec 2008 21:51:35 +0100
Subject: Work needed, how you can help!
References: <1228684966.3370.22.camel@localhost.localdomain>
	<20081208140234.9a7ca66d.mschwendt@gmail.com>
	<1228749930.26618.255.camel@code.and.org>
	<20081208164654.79443601.mschwendt@gmail.com>
Message-ID: <ghk1cn$u93$2@ger.gmane.org>

Michael Schwendt wrote:

> On Mon, 08 Dec 2008 10:25:30 -0500, James wrote:
>>  This is essentially the -devel package with all the debugging turned
>> on. I guess I could name it ustr-debug-devel if we really have to
>> (although having a ustr-debug-devel without a ustr-debug seems a little
>> weird).
> 
> How would that be weird? I can imagine things like a-devel package that
> specifies an interface without any main package to depend on.

In fact we already have such packages: template-only C++ libraries. As
templates need to be instantiated from their headers, they have all their
code inlined in headers and no actual libraries. See eigen-devel,
eigen2-devel, gmm-devel for some examples.

        Kevin Kofler



From lesmikesell at gmail.com  Mon Dec  8 20:54:00 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 08 Dec 2008 14:54:00 -0600
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <ghk08m$ru3$1@ger.gmane.org>
References: <20081205195914.GB3227@free.fr>	<1228507530.3275.53.camel@localhost.localdomain>	<20081205201621.GC3227@free.fr>
	<493CD84F.6010309@redhat.com>	<20081208111231.GB2611@free.fr>
	<ghk08m$ru3$1@ger.gmane.org>
Message-ID: <493D8968.4050707@gmail.com>

Kevin Kofler wrote:
> Patrice Dumas wrote:
>> If there is none, it uses /bin/vi. In fact I have sone a bit of
>> investigations and it uses, in pathnames.h _PATH_VI which is defined in
>> /usr/invlude/paths.h.
>>
>> So it is a missing dependency, in my opinion.
> 
> No it's not. People may want to use an actually usable editor and not have
> their system polluted with this relict of history.
> 
> I guess I should file bugs against cvs, sudo and fcron which all have
> unnecessary Requires on vim-minimal.

I'd argue that vi should be a requirement on any unix-like system, just 
in case it is visted by a unix administrator that is also a relic of 
history.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mw_triad at users.sourceforge.net  Mon Dec  8 20:55:57 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 08 Dec 2008 14:55:57 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <ghjv9m$n64$1@ger.gmane.org>
References: <49393DE3.1080707@redhat.com>	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>	<4939A673.3090907@gmail.com>	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>	<1228555748.4211.2.camel@hughsie-work.lan>	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>	<1228592200.3417.7.camel@localhost.localdomain>	<16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>	<493AF806.5040804@gmail.com>	<ghf0it$j5h$1@ger.gmane.org>
	<ghjj11$94s$1@ger.gmane.org> <ghjv9m$n64$1@ger.gmane.org>
Message-ID: <ghk1ku$ts$1@ger.gmane.org>

Kevin Kofler wrote:
> Matthew Woehlke wrote:
>> KPackageKit apparently does... at least, it did last night.
> 
> Then why didn't you file a bug?
> 
> Our default setup is NOT to do that, but KPackageKit sometimes forgets that
> setting for whatever reason. It just did that for me too. It's clearly a
> bug.

Because it's only "clearly a bug" to you? I don't particularly mind if 
my computer wants to tell me there are updates when I'm running on 
battery. If I wasn't reading this thread, I never would have thought 
anything of it.

I don't object to treating it as a bug, it's just that this behavior 
doesn't bother me :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
   -- from a story by Feech



From mw_triad at users.sourceforge.net  Mon Dec  8 21:10:13 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 08 Dec 2008 15:10:13 -0600
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <ghk08m$ru3$1@ger.gmane.org>
References: <20081205195914.GB3227@free.fr>	<1228507530.3275.53.camel@localhost.localdomain>	<20081205201621.GC3227@free.fr>
	<493CD84F.6010309@redhat.com>	<20081208111231.GB2611@free.fr>
	<ghk08m$ru3$1@ger.gmane.org>
Message-ID: <ghk2fl$4ri$1@ger.gmane.org>

Kevin Kofler wrote:
> Patrice Dumas wrote:
>> If there is none, it uses /bin/vi. In fact I have sone a bit of
>> investigations and it uses, in pathnames.h _PATH_VI which is defined in
>> /usr/invlude/paths.h.
>>
>> So it is a missing dependency, in my opinion.
> 
> No it's not. People may want to use an actually usable editor and not have
> their system polluted with this relict of history.

I use, exclusively, kate-based editors (usually kwrite, but also Kate 
and KDevelop), and... <drumroll please> vim. Granted I just went and dug 
up vim-enhanced last night (not installed by the KDE spin by default, 
bleh), but I object to the classification of /bin/vi as a "relic of 
history" and not "an actually usable editor". (vim-minimal is perfect 
for most editing of things in /etc, thank you very much! Including 
crontabs...)

> I guess I should file bugs against cvs, sudo and fcron which all have
> unnecessary Requires on vim-minimal.

I'd consider a system with no 'vi' to be broken :-). /bin/vi seems to be 
the lowest common denominator for a TUI editor on *nix systems.

Obviously, /bin/vi isn't necessarily Bram Moolenaar's VIM, but it's 
always close enough to be more-or-less usable (where the "more-or-less" 
almost invariably relates to how well it handles the arrow keys).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
   -- from a story by Feech



From kevin.kofler at chello.at  Mon Dec  8 21:23:54 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 08 Dec 2008 22:23:54 +0100
Subject: The looming Python 3(000) monster
References: <49393DE3.1080707@redhat.com>	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>	<4939A673.3090907@gmail.com>	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>	<1228555748.4211.2.camel@hughsie-work.lan>	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>	<1228592200.3417.7.camel@localhost.localdomain>	<16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>	<493AF806.5040804@gmail.com>	<ghf0it$j5h$1@ger.gmane.org>
	<ghjj11$94s$1@ger.gmane.org> <ghjv9m$n64$1@ger.gmane.org>
	<ghk1ku$ts$1@ger.gmane.org>
Message-ID: <ghk39a$2q1$3@ger.gmane.org>

Matthew Woehlke wrote:
> Because it's only "clearly a bug" to you? I don't particularly mind if
> my computer wants to tell me there are updates when I'm running on
> battery. If I wasn't reading this thread, I never would have thought
> anything of it.

Oh, sorry, I lost track of the context. Reporting updates while on battery
isn't obviously a bug, automatically getting updates installed without
being asked (which somebody mentioned elsewhere on the lists, though I'm
not sure it was in reference to KPackageKit or to something else) is (and
that's what the bug I filed against KPackageKit is about). I'm sorry for
the confusion, it's me who got all mixed up.

Still, AFAIK gnome-packagekit doesn't check for updates while on battery and
it may well be that future kpackagekit releases won't do it either, at
least by default. But it is more a missing feature than a bug.

        Kevin Kofler



From dennisml at conversis.de  Mon Dec  8 21:35:13 2008
From: dennisml at conversis.de (Dennis J.)
Date: Mon, 08 Dec 2008 22:35:13 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <ghk08m$ru3$1@ger.gmane.org>
References: <20081205195914.GB3227@free.fr>	<1228507530.3275.53.camel@localhost.localdomain>	<20081205201621.GC3227@free.fr>
	<493CD84F.6010309@redhat.com>	<20081208111231.GB2611@free.fr>
	<ghk08m$ru3$1@ger.gmane.org>
Message-ID: <493D9311.6020109@conversis.de>

On 12/08/2008 09:32 PM, Kevin Kofler wrote:
> Patrice Dumas wrote:
>> If there is none, it uses /bin/vi. In fact I have sone a bit of
>> investigations and it uses, in pathnames.h _PATH_VI which is defined in
>> /usr/invlude/paths.h.
>>
>> So it is a missing dependency, in my opinion.
>
> No it's not. People may want to use an actually usable editor and not have
> their system polluted with this relict of history.
>
> I guess I should file bugs against cvs, sudo and fcron which all have
> unnecessary Requires on vim-minimal.

That's probably a good idea not so much because vi is a "relic of history" 
but simply because it's not a good idea to require a specific editor simply 
because the package contains a config file. Virtually every app out there 
contains config files so imagine if all of them depended on the editor of 
the package maintainers choice. If at all then the dependency should be a 
virtual one so the user can choose to install his/her prefered editor.

Regards,
   Dennis



From pertusus at free.fr  Mon Dec  8 21:38:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 22:38:30 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <ghk08m$ru3$1@ger.gmane.org>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
Message-ID: <20081208213830.GA2885@free.fr>

On Mon, Dec 08, 2008 at 09:32:22PM +0100, Kevin Kofler wrote:
> 
> No it's not. People may want to use an actually usable editor and not have
> their system polluted with this relict of history.
> 
> I guess I should file bugs against cvs, sudo and fcron which all have
> unnecessary Requires on vim-minimal.

This is in order to always have a fallback. Anybody can use anything as
EDITOR, but one has to have a default. vi is not a bad choice, it is
POSIX, unless I am not recalling correctly, and it is small.

--
Pat



From pertusus at free.fr  Mon Dec  8 21:42:02 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 8 Dec 2008 22:42:02 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <493D9311.6020109@conversis.de>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<493D9311.6020109@conversis.de>
Message-ID: <20081208214202.GB2885@free.fr>

On Mon, Dec 08, 2008 at 10:35:13PM +0100, Dennis J. wrote:
> On 12/08/2008 09:32 PM, Kevin Kofler wrote:
>> Patrice Dumas wrote:
>>> If there is none, it uses /bin/vi. In fact I have sone a bit of
>>> investigations and it uses, in pathnames.h _PATH_VI which is defined in
>>> /usr/invlude/paths.h.
>>>
>>> So it is a missing dependency, in my opinion.
>>
>> No it's not. People may want to use an actually usable editor and not have
>> their system polluted with this relict of history.
>>
>> I guess I should file bugs against cvs, sudo and fcron which all have
>> unnecessary Requires on vim-minimal.
>
> That's probably a good idea not so much because vi is a "relic of 
> history" but simply because it's not a good idea to require a specific 
> editor simply because the package contains a config file. Virtually every 
> app out there contains config files so imagine if all of them depended on 
> the editor of the package maintainers choice. If at all then the 
> dependency should be a virtual one so the user can choose to install 
> his/her prefered editor.

Those application have vi as a fallback default because they call it
somehow (at least fcrontab in fcron). I guess it is also the case of
sudoedit, and I also guess that it is the fallback for cvs commit
messages too. So those packages doesn't 'require a specific  editor
simply because the package contains a config file'. They call, at
runtime an editor specified by the EDITOR env variable and fallback to
vi.

--
Pat



From vonbrand at inf.utfsm.cl  Mon Dec  8 21:42:17 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 08 Dec 2008 18:42:17 -0300
Subject: The looming Python 3(000) monster
In-Reply-To: <493D68D8.2000308@gmail.com>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<493C462B.4070607@gmail.com> <493D5DA3.7010408@gmail.com>
	<493D68D8.2000308@gmail.com>
Message-ID: <200812082142.mB8LgHJb019504@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:

[...]

> I just don't get why any sane person, especially anyone familiar with
> computer languages, would ever want to give something that is not the
> same the same name.  Does anyone know how the developer(s) manage this
> themselves?  I have to think they are keeping multiple concurrent
> versions installed (and that that is the only reasonable approach).

You mean like C? There was plain K&R C, then futzing around with lint, then
several popular C extensions, then along came ANSI C (C89), then C99; all the
while there were all sorts of "interesting" GCC extensions included,
changed, retracted, added in the standard or replaced in it by a completely
different way of doing the same thing...
-- 
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 mw_triad at users.sourceforge.net  Mon Dec  8 22:01:47 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 08 Dec 2008 16:01:47 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <ghk39a$2q1$3@ger.gmane.org>
References: <49393DE3.1080707@redhat.com>	<493990E5.3060408@gmail.com>	<6c0fb78f193bc424830b5ca2a1a06af0.squirrel@mail.jcomserv.net>	<4939A275.1070603@gmail.com>	<604aa7910812051356y5d7b939ak170d021555d980c2@mail.gmail.com>	<4939A673.3090907@gmail.com>	<604aa7910812051507r58c1358dtf9481521e0243f81@mail.gmail.com>	<1228555748.4211.2.camel@hughsie-work.lan>	<604aa7910812061131n6051a6f2o3cdc66af6bddeb44@mail.gmail.com>	<1228592200.3417.7.camel@localhost.localdomain>	<16de708d0812061336g150bf01aje9966c95f197773@mail.gmail.com>	<493AF806.5040804@gmail.com>	<ghf0it$j5h$1@ger.gmane.org>	<ghjj11$94s$1@ger.gmane.org>
	<ghjv9m$n64$1@ger.gmane.org>	<ghk1ku$ts$1@ger.gmane.org>
	<ghk39a$2q1$3@ger.gmane.org>
Message-ID: <ghk5gb$en6$2@ger.gmane.org>

Kevin Kofler wrote:
> Matthew Woehlke wrote:
>> Because it's only "clearly a bug" to you? I don't particularly mind if
>> my computer wants to tell me there are updates when I'm running on
>> battery. If I wasn't reading this thread, I never would have thought
>> anything of it.
> 
> Oh, sorry, I lost track of the context. Reporting updates while on battery
> isn't obviously a bug, automatically getting updates installed without
> being asked (which somebody mentioned elsewhere on the lists, though I'm
> not sure it was in reference to KPackageKit or to something else) is (and
> that's what the bug I filed against KPackageKit is about). I'm sorry for
> the confusion, it's me who got all mixed up.
> 
> Still, AFAIK gnome-packagekit doesn't check for updates while on battery and
> it may well be that future kpackagekit releases won't do it either, at
> least by default. But it is more a missing feature than a bug.

Ah, ok. Maybe I should actually go read the bug you filed, then I'd 
realize we were miscommunicating :-). Sorry for the mix-up.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
   -- from a story by Feech



From triad at df.lth.se  Mon Dec  8 22:08:51 2008
From: triad at df.lth.se (Linus Walleij)
Date: Mon, 08 Dec 2008 23:08:51 +0100
Subject: cgroups etc (WAS: Re: Enabling the memory controller for F11)
In-Reply-To: <493D4128.8050402@BitWagon.com>
References: <20081208062952.GG13333@balbir.in.ibm.com>
	<493D4128.8050402@BitWagon.com>
Message-ID: <1228774131.3023.14.camel@fecusia>

m?n 2008-12-08 klockan 07:45 -0800 skrev John Reiser:

> > [Please] enable the memory controller for F11.
> 
> Please give a URL to a description of what it does,

Memory controllers rock:
http://lxr.linux.no/linux/Documentation/controllers/memory.txt

Lots of links there in the end.

On servers memory cgroups taken together with the existing CPU slicing
cgroups and affinity cgroups enables the same stuff that Solaris "zones"
(http://en.wikipedia.org/wiki/Solaris_Containers) does, more or less,
but actually better because it's more fine-grained and doesn't need you
to configure an entire virtual machine.

Instead of limiting this one virtual machine, the cgroups features make
it possible to limit this one group of processes, without any
virtualization overhead. I guess you could combine it with User Mode
Linux if you want real, constrained virtualization.

cgroups are really a core killer feature in Linux, just that the rest of
the world doesn't quite know yet, nor do userspace know quite how to
handle all the nice cgroups, but much is happening right now.

Even if servers is what most cgroup authors probably have in mind, they
are equally useful to desktops and embedded systems.

Linus



From ssorce at redhat.com  Mon Dec  8 22:19:26 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Mon, 08 Dec 2008 17:19:26 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <1228762046.3545.2.camel@localhost.localdomain>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com>  <493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
Message-ID: <1228774767.25085.141.camel@localhost.localdomain>

On Mon, 2008-12-08 at 10:47 -0800, Jesse Keating wrote:
> > On Mon, 2008-12-08 at 12:35 -0600, Les Mikesell wrote:
> > 
> > I just don't get why any sane person, especially anyone familiar with 
> > computer languages, would ever want to give something that is not the 
> > same the same name.  Does anyone know how the developer(s) manage this 
> > themselves?  I have to think they are keeping multiple concurrent 
> > versions installed (and that that is the only reasonable approach).
> 
> I'm pretty certain that if you look at any language, they've all faced
> similar scenarios, major version upgrades that may in fact not be
> forward no backward compatible.  People have dealt with it and moved on.
> No language is perfect.

Never seen C/C++ break backward compatibility on a scale like Python 3.0
will.
And they are compiled, where the impact is 100 fold less than for
interpreted languages ...

I would personally strongly consider having 2.x and 3.0 parallel
installable ...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From berrange at redhat.com  Mon Dec  8 22:53:39 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 8 Dec 2008 22:53:39 +0000
Subject: cgroups etc (WAS: Re: Enabling the memory controller for F11)
In-Reply-To: <1228774131.3023.14.camel@fecusia>
References: <20081208062952.GG13333@balbir.in.ibm.com>
	<493D4128.8050402@BitWagon.com> <1228774131.3023.14.camel@fecusia>
Message-ID: <20081208225339.GB4951@redhat.com>

On Mon, Dec 08, 2008 at 11:08:51PM +0100, Linus Walleij wrote:
> m?n 2008-12-08 klockan 07:45 -0800 skrev John Reiser:
> 
> > > [Please] enable the memory controller for F11.
> > 
> > Please give a URL to a description of what it does,
> 
> Memory controllers rock:
> http://lxr.linux.no/linux/Documentation/controllers/memory.txt
> 
> Lots of links there in the end.
> 
> On servers memory cgroups taken together with the existing CPU slicing
> cgroups and affinity cgroups enables the same stuff that Solaris "zones"
> (http://en.wikipedia.org/wiki/Solaris_Containers) does, more or less,
> but actually better because it's more fine-grained and doesn't need you
> to configure an entire virtual machine.
> 
> Instead of limiting this one virtual machine, the cgroups features make
> it possible to limit this one group of processes, without any
> virtualization overhead. I guess you could combine it with User Mode
> Linux if you want real, constrained virtualization.
> 
> cgroups are really a core killer feature in Linux, just that the rest of
> the world doesn't quite know yet, nor do userspace know quite how to
> handle all the nice cgroups, but much is happening right now.

The libvirt LXC driver provides container based virtualization that
is using the memory, dev and cpu shares cgroup controllers. It is
intended to allow lightweight resource isolation of processes, and/or
a full OS container to be managed using the same APIs & tools as
used for full machine virtualization like Xen/KVM/UML.

Daniel
-- 
|: Red Hat, Engineering, London   -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 vonbrand at inf.utfsm.cl  Mon Dec  8 23:10:06 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 08 Dec 2008 20:10:06 -0300
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <ghk08m$ru3$1@ger.gmane.org>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
Message-ID: <200812082310.mB8NA6uS021344@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> Patrice Dumas wrote:
> > If there is none, it uses /bin/vi. In fact I have sone a bit of
> > investigations and it uses, in pathnames.h _PATH_VI which is defined in
> > /usr/invlude/paths.h.
> > 
> > So it is a missing dependency, in my opinion.
> 
> No it's not. People may want to use an actually usable editor and not have
> their system polluted with this relict of history.

Flamewar alert!

[vi(1) is actually a /very/ usable editor. I believe some standard or other
 requires its presence; in fact, it is one of the things you can depend on
 finding on any Unixy system.]
-- 
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 lesmikesell at gmail.com  Mon Dec  8 23:12:46 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 08 Dec 2008 17:12:46 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <200812082142.mB8LgHJb019504@laptop14.inf.utfsm.cl>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<493C462B.4070607@gmail.com> <493D5DA3.7010408@gmail.com>
	<493D68D8.2000308@gmail.com>
	<200812082142.mB8LgHJb019504@laptop14.inf.utfsm.cl>
Message-ID: <493DA9EE.2070108@gmail.com>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
> [...]
> 
>> I just don't get why any sane person, especially anyone familiar with
>> computer languages, would ever want to give something that is not the
>> same the same name.  Does anyone know how the developer(s) manage this
>> themselves?  I have to think they are keeping multiple concurrent
>> versions installed (and that that is the only reasonable approach).
> 
> You mean like C? There was plain K&R C, then futzing around with lint, then
> several popular C extensions, then along came ANSI C (C89), then C99; all the
> while there were all sorts of "interesting" GCC extensions included,
> changed, retracted, added in the standard or replaced in it by a completely
> different way of doing the same thing...

And yet, in all that time, I never had a problem continuing to run a 
previously working C program even in the extremely rare cases where an 
updated compiler wouldn't build a new copy.  Python doesn't work that way.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From pertusus at free.fr  Mon Dec  8 23:20:09 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Dec 2008 00:20:09 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
Message-ID: <20081208232009.GD2885@free.fr>

On Mon, Dec 08, 2008 at 02:12:57PM -0900, Jeff Spaleta wrote:
> On Mon, Dec 8, 2008 at 12:38 PM, Patrice Dumas <pertusus at free.fr> wrote:
> > This is in order to always have a fallback. Anybody can use anything as
> > EDITOR, but one has to have a default. vi is not a bad choice, it is
> > POSIX, unless I am not recalling correctly, and it is small.
> 
> 
> Should all possible fallbacks be hard requirements? Isn't it better to

No, the rule should just be about things working, as a rule of thumb,
and depending on the package, either in a chroot, or together with 
@core (with exception for package that have too much possible
requirements, like fonts needed by some packages).

> have a number of competing packages provide an editor and provide a
> virtual editor provides, have one of those installed editors set as
> the default system editor via the EDITOR variable and then have all
> packages which need an editor require the virtual editor provides
> instead of a specific editor?
> 
> That way anyone can build a spin or do an install using any
> appropriate available editor package which provides the editor virtual
> provides as policy and tastes dictate.

Indeed, this would be possible, and certainly preferrable. Though in
general using the environment like is asking for trouble, this is what
is in upstream currently.

--
Pat



From poelstra at redhat.com  Tue Dec  9 00:23:14 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 08 Dec 2008 16:23:14 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-12-08 
Message-ID: <493DBA72.3070806@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-dec-08

Please make corrections and clarifications to the wiki page.

== Meeting Summary ==
* Fedora 11 schedule approved last week by FESCo
* Need to create trac tickets for each Fedora 11 milestone
* Resigning Fedora 8 and Fedora 9 packages as a result of intrusion
** Focusing on Fedora 9
** f13 will bring question to the board about skipping Fedora 8 since it 
goes EOL in less than a month
* Growing the release engineering team
** Consider different meeting times to accommodate other timezones
** Use FUDCon to explain overall processes
** Help new people get started with basic tickets
* dgilmore to meet with f13 and lmacken to talk about how updates for 
secondary arch will go out

== IRC Transcript ==



From robert at fedoraproject.org  Tue Dec  9 00:25:40 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Tue, 9 Dec 2008 01:25:40 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
Message-ID: <20081209002540.GA25637@hurricane.linuxnetz.de>

Good evening everybody,

I've unluckily several points and issues, I'm trying to get solved for even
for a longer time now (depending on the point on my list), but nobody in
and around the Fedora Project seems or don't want to care about that. I am
also annoyed, that I have to write such an e-mail, but the following really
is, what Fedora makes sucking for me.

Ah, and now first of all to the guys who will surely answer "use Ubuntu",
"choose another distribution", "you're sucking as well" or similar: Go, run
and die in a fire - immediately! I know, that this e-mail will make me the
bogeyman for many of you, but that hopefully and luckily moves out Thorsten
for a short time of his usual position while taking the seat myself... ;-)

Well, we had the intrusion into the servers of the Fedora Project. That is
now nearly 4 months ago. I remember to the words of our dear Fedora Project
leader, who made us believing with the sentence "We will continue to keep
the Fedora community notified of any updates." - but nothing happend after
that. We all are still waiting for final report about the intrusion into
the servers of the Fedora Project! Yes, we can: Open Source, but unluckily
no Open Communication! Even the communication during the intrusion time was
worse, e-mails to the Infrastructure team and to our Fedora Project leader
got not really answered (or just when reasking and bugging) when asking for
the issue and details even when it was mostly clear, that we're no longer
really men about ourself - the intrusion.

Our German translation is only quantitative, not qualitative. And the worse
thing is, the team leader of the German translation team finds the current
position and its current status okay. That's wrong and never should happen.
If a German person is not able to understand the context of a translated
sentence, the phrase should not be commited. Many people are even not re-
reading the tsentence whether it has any meaning after the translation. But
our team leader says, quantitative translation is okay. Ugly grammar and
spelling issues are another thing; seems too much to re-read or to use a
spellchecker before commiting - our teamleader says, that everything must
fast go to upstream...great! I now know lots of German speaking people (in
their mother tongue), which use Fedora only in English - including myself -
to avoid the must of reading that horrible German. Surely, we can fix that,
but if always people are working against, that does not help. Unluckily,
language translations don't make it that often into Fedora updates during
the lifetime of a Fedora release. So mostly, a broken translation is kept
there for the whole release. But it's okay to be only quantitative and not
qualitative, our team leader of the German translation project prays.

Oh, we've the Live CD for a long time now. Did anybody use that medium on a
slower, older computer? Surely not. Otherwise you would have noticed, that
the Live CD is very slow there. The USB stick/variant may be fast, but the
CD which we're now promoting at our download page better and more that the
installation DVD, is IMHO not a good store sign as it is just slow. It even
has not a localisation - folks, not the whole world is speaking english,
just there is America on the worldmap! I know people from fairs, which are
really frusted by their first try with a Live CD as it was just English.
Yes, we maybe can create a spin, but these ones, we cannot offer on the FTP
and HTTP mirrors, because Fedora is already too big. On the other hand, the
issue of a non-US keyboard layout when trying to generate a localized
version of the Live medium is still not fixed. There were some tries to
solve that on LinuxTag 2008, but as far as I know, afterwards nobody again
cared about and it went down. Remembering, that promoting our so cool Live
CDs does not help in areas where the Internet is slow and old, I'm doing
hereby, too. I don't want to remember, that the Fedora 8 Live media even
killed crypted swap partitions...really a nice feature. By the way, does it
do that still?

Yeah, Anaconda got a bigger rewrite for Fedora 10 and took care of the old
and often claimed issue, that the user needs to know the URL of a mirror in
order to install Fedora via netinstall. But now, the screen got completely
ripped out or is (if it really still exists, which I don't believe) too
good hidden somewhere. Instead of that, somebody - that must have been an
American - made the "repo=" option for the command line prompt if somebody
wants to specify a local mirror. Urgs! At that point, no non-US keyboard
layout is loaded! I now have to type something like "repo?http?--my.local-
mirror-fedora-something-" or so on my non-US keyboard. Folks, the worldmap
not only has American people with a US keyboard layout out there, even if
some people think so. Even the "repo=xxx" is worse documented, but yes, who
cares? Just me as it seems somehow...

In order to support the RPM Fusion (former Livna) project, I tried to
install the mirrormanager serverlist on a RHEL 4 with python 2.3 and having
suexec in httpd enabled - and poorly failed. Mirrormanager is worse up to
not documented at all and only focussed to RHEL 5+. So for a not really
mirrormanager specific person it is nearly impossible to run mirrormanager
serverlist in a secured/hardend environment out of the box without taking
much action. Luckily I got support for several python 2.3 specific issues
by a mirror admin and by the webteam leader - unluckily not so much help by
the developer of mirrormanager who caused the stuff...I'm still getting a
zombie process after a request by the *.wsgi which is surely no feature.

Pushing packages into Fedora still takes ages in form of days or weeks. And
this unluckily and especially also for security updates. The reason for
this seems to be Bodhi, as the updates are usually happening very fast on
EPEL which hasn't Bodhi. For EPEL it normally just takes hours, for Fedora
mostly multiple days up to a week. I know, what I'm talking about here, I
am co-maintaining phpMyAdmin which has more holes that a swiss cheese; the
EPEL people know very well, what I'm talking about, too. I also had a lot
of other security updates for other packages during 2008 and EPEL is always
faster there, why Fedora is so slow? There must be a real reason, why we do
not get rid of this for a long time now...and I would like to see this same
good or even well in Fedora as in EPEL - or do we have to kill bodhi first?

Hmmm, the "Merge Reviews" that somewhere have been declared as blockers
for Fedora 7 (!) are still not done. It AFAIK was said somewhen, that not
reviewed packages are getting removed from Fedora. This did not happen for
anything, yet. The "Merge Reviews" are sometimes also blocked by Red Hat
employees for very base/core packages by just refusing the Fedora Packaging
guidelines, because it's the packager of the package. This can't be case!
The Red Hat people have to follow the Fedora packaging guidelines and rules
same as the Fedora folks - without any exception! If you would like to know
which packages and people I'm talking about, have a look to Bugzilla and
search for the bug reports I'm watching via Cc - there are lots of examples
out there...without wanting to blame somebody special here on the list. But
this has to be solved, the reviews need to be done, and the Red Hat people
sitting on some base/core packages, must follow the Fedora rules same and
without any refusing as they currently do. BTW, why is nobody controlling
the success of the "Merge Reviews"? Shouldn't somebody watch this and tell
us all the progress inside of e.g. the weekly Fedora newsletter or so?

Oh, did I mention, that RPM 4.6, our dear big change in RPM at Fedora for
years now is still buggy and so? When reading the article about a review of
Fedora 10 by pro-linux.de (http://www.pro-linux.de/berichte/fedora10.html),
I had to notice, that our dear rpm.org developers still did not get rid of
the "hanging rpm" now must be solved by killing the RPM processes, removing
the /var/lib/rpm/__* and rebuilding the rpmdb. Putting the (now cheap) oil
into the fire would be a solution: rpm5.org solved the above mentioned very
annoying issue already years ago. But yes I know, some yum developing and
supporting individuals don't like the rpm5.org project by other individuals
even not honoring their work, but even not backporting the fixes, developed
there to solve old problems. I don't know of any "feature" in rpm.org, that
is not already in rpm5.org; why do we put double efforts with so much delay
in rpm.org when rpm5.org already has done the work? And before I know hear
some derogatives about rpm5.org people: You're always getting the echo for
what you did, but unluckily you often do not always remember to what you
did or say before - and that AFAIK applies to all rpm5.org people related
personal issues. And if we are now RPM; are there advantages of having some
kinds of an APT API?

PackageKit, another broken software which is in a pre-bleeding edge state I
would say. PackageKit is resizing windows during installation or updating
of packages; it's resizing and thus hopping the window if I e.g. select a
package or if I click around inside of the application. That's something,
which proves, that there is no usability for end users yet. That's IMHO
more worse than alpha - but we're shipping it with releases, yay. And the
related GNOME tray utility is also slow and usually is behind the current
action...that's packagekitd, yes? One of these utilities also often blocks
the usage of yum with saying, that another application currently holds the
lock. Why are we locking something when not performing a writing action on
the RPM database? That seems to be mis-engineered very well. Independent of
that, PackageKit is somehow slow, has issues that it doesn't understand
always where it is or whether an action is already completed. Oh and it
kills my Firefox nicely during package updating, well-well done. Some more
experiences about the broken-ness are mentioned in the review of Fedora 10
on pro-linux.de (http://www.pro-linux.de/berichte/fedora10.html). Why do we
ship such software? Only because we're bleeding edge and want to beat the
guys of Ubuntu?

When talking about PackageKit, DBUS is another issue. The recent DBUS pkg
update broke PackageKit stuff - thanks to our cool QA. And clever as we
are, we did not revoke the update and we also did not push a fixed package
really immediately out after to solve this. I know, that many of the
desktop people actually love DBUS, but it is horrible stuff, which can
break down much things with lacking QA like in this case. Did you desktop
people ever think about, that DBUS is not the perfect choice for a server
system and Fedora is some kind of preview of RHEL? Yes, Fedora is not the
playground of Red Hat, but on the other hand, Fedora is - why else is Red
Hat putting efforts into Fedora if they wouldn't benefit? I really can only
hope here, that Red Hat removes much of the DBUS breakage and dumbness for
the next RHEL release and that less DBUS linked packages are making it into
there...

And as we're cool, we need a daemon for everything: packagekitd, dbusd, hal
daemon, mcstransd, setroubleshootd, yum-updatesd - yay. And nearly every of
this daemons is written in the memory consuming python and has nice memory
leaks or other breakdown bugs. mcstransd is still slower for me (even after
the speedup somebody of the SELinux guys did) as previous implementation
without the daemon. But yes, we need daemons; restorecond would now be just
another example. I think, there's much more which can be solved without a
daemon and at least without memory-wasting worse written python. I'm aware,
that python is the Red Hat internal defacto default and that scripting is
much more faster rather coding low-level C. But lets waste ressources as
e.g. kerneloops daemon does which always consumes a bit of CPU and thus not
increases the consuming of energy in a positive way. But hey, let's create
another daemon to monitor where we're wasting and leaking memory...

Plymouth is nice - sometimes. Why did we put so much effort into that? It
does not work with many graphic cards and it doesn't make things really
faster for me. You also forgot to put a message somewhere, that hitting ESC
can abort that thing and showing the regular messages instead. But this is
what is "usability" called, when putting such an information not onto the
screen. Maybe plymouth is faster as previous stuff, possible. But compared
with the work of Arjan van de Ven, Linux developer at Intel and author of
PowerTOP, it's still slow. He's booting up an Asus EeePC within 5 seconds;
with plymouth it anyway takes a multiple of that for me. But yes, plymouth
looks nice to end users and we like to waste time for that.

When already being on booting: Does somebody remember to the Ubuntu stuff
we really needed some releases ago? I'm talking about upstart, the event
driven/based init system we've been hot to. And now? We're using the compat
mode and that's it. Everything else uses just the same compatibility mode
and AFAIK nothing in Fedora uses the "advantages" of upstart. But yes, we
are bleeding edge with that. Did it make sense? No. But we wanted it. Okay.
Why the hell did we need a event driven/based init system so much, if we
still are not using any features of it and replacing the old init skeleton
by the new things? I thought, we're bleeding edge? Looks like we only need
to have the latest sharp razor, but we're never using it for cutting. Is
upstream of upstart still alive? And is there any forward development some
where in the world?

Fedora EMEA e.V. also seems to be a mostly dead tree. Of course we have
founded the association as legal vehicle. But it would be nice to see where
my money, my membership fee, the 128 Euro per year are spent to. I now
could assume, that the money is just collected and nothing happens or some
guys of the board are buying and eating ice cream with, but I really hope
that's not true. Fedora EMEA e.V. really needs to communicate a bit more to
its members what they're doing and how the money is handled. Organisation
is lacking much transparency and about their activities. AFAIK, a mailing
list for the members of Fedora EMEA e.V. was created, I think it never was
used yet. 128 Euro per year is IMHO too much for the current level of what
seems to happen with the money. And for that money I could support the Free
Software Foundation Europe (FSFE) with multiple membership fees per year.
And sorry, just one cool bathrobe isn't a good reason for spending 128 Euro
away per year. Without enough transparency and communication, it's like
throwing the money out of the window of my room.

If you're reading this, you've hopefully read all I wrote above. The main
issue is, that all of the issues are known (if you try to tell me something
else you're either blind and deaf-mute or you don't care about Fedora that
much) - to their leader/owner and to others inside of the Fedora Project.
But nobody really follows, is having a look to these issues and problems or
even takes care of it...why? I think, this should be the job of the Fedora
Project leader, shouldn't it? I don't want to blame neither Paul nor Max in
this e-mail, I think everybody of us needs to be more sensitive to issues
around the Fedora Project and needs to take more care before developing or
forking something. And things exist, we don't need to re-invent always the
wheel just because it's cool and bleeding edge. More work to get patches to
upstream and so would avoid some of the pseudo-forks on Fedora Hosted as
well. We definately need Open Communication, not only Open Source. But as
it seems, even Fedora Talk didn't help that until now. So maybe the "f" of
Free spech got lost somewhere in the latest slogan redesign?

Oh...I'm really sorry now, that I used the phrase "bleeding edge" together
with "Fedora" and that I called "Fedora" as "bleeding edge". I already got
dispraised multiple times by individuals (eg. as part of the Fedora website
team), that I think, Fedora is bleeding edge. If you've really read all of
my irony, frustration, comments and suggestions above, you should have to
agree with me, that Fedora is "bleeding edge". Fedora is far away from
stable, it's a sharp razor with many edges where somebody can be easily cut
with - and that's why we mostly like it.

My points above are what Fedora makes sucking for me - or why I am NOT
Fedora! At least I'm thinking that. Maybe you're thinking about my e-mail
before replying. I would also like to hear comments (even private ones) by
the affected parts of the Fedora Project. Thanks for taking the time.


Greetings,
  Robert



From robert at fedoraproject.org  Tue Dec  9 00:33:21 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Tue, 9 Dec 2008 01:33:21 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <20081209003321.GA14689@hurricane.linuxnetz.de>

On Tue, 09 Dec 2008, Robert Scheck wrote:
> My points above are what Fedora makes sucking for me - or why I am NOT
> Fedora! At least I'm thinking that.

Oh...and to be clear, I currently do not have any plans to leave Fedora.
It's still my favourite Linux distribution :) And I really would like to
see the things getting better...thus such an e-mail.


Greetings,
  Robert



From stlwrt at gmail.com  Tue Dec  9 00:41:50 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Tue, 9 Dec 2008 02:41:50 +0200
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <d25f375f0812081641l3b8df93m54728fe80e380094@mail.gmail.com>

I agree to most of the letter, especially python daemons stuff and
plymouth, but do you know any better OS/distro? I've tried many and
fedora is one of the best things around, unless you want to spend all
your spare time maintaining custom LFS system.

On Tue, Dec 9, 2008 at 2:25 AM, Robert Scheck <robert at fedoraproject.org> wrote:
> Good evening everybody,
>
> I've unluckily several points and issues, I'm trying to get solved for even
> for a longer time now (depending on the point on my list), but nobody in
> and around the Fedora Project seems or don't want to care about that. I am
> also annoyed, that I have to write such an e-mail, but the following really
> is, what Fedora makes sucking for me.
>
> Ah, and now first of all to the guys who will surely answer "use Ubuntu",
> "choose another distribution", "you're sucking as well" or similar: Go, run
> and die in a fire - immediately! I know, that this e-mail will make me the
> bogeyman for many of you, but that hopefully and luckily moves out Thorsten
> for a short time of his usual position while taking the seat myself... ;-)
>
> Well, we had the intrusion into the servers of the Fedora Project. That is
> now nearly 4 months ago. I remember to the words of our dear Fedora Project
> leader, who made us believing with the sentence "We will continue to keep
> the Fedora community notified of any updates." - but nothing happend after
> that. We all are still waiting for final report about the intrusion into
> the servers of the Fedora Project! Yes, we can: Open Source, but unluckily
> no Open Communication! Even the communication during the intrusion time was
> worse, e-mails to the Infrastructure team and to our Fedora Project leader
> got not really answered (or just when reasking and bugging) when asking for
> the issue and details even when it was mostly clear, that we're no longer
> really men about ourself - the intrusion.
>
> Our German translation is only quantitative, not qualitative. And the worse
> thing is, the team leader of the German translation team finds the current
> position and its current status okay. That's wrong and never should happen.
> If a German person is not able to understand the context of a translated
> sentence, the phrase should not be commited. Many people are even not re-
> reading the tsentence whether it has any meaning after the translation. But
> our team leader says, quantitative translation is okay. Ugly grammar and
> spelling issues are another thing; seems too much to re-read or to use a
> spellchecker before commiting - our teamleader says, that everything must
> fast go to upstream...great! I now know lots of German speaking people (in
> their mother tongue), which use Fedora only in English - including myself -
> to avoid the must of reading that horrible German. Surely, we can fix that,
> but if always people are working against, that does not help. Unluckily,
> language translations don't make it that often into Fedora updates during
> the lifetime of a Fedora release. So mostly, a broken translation is kept
> there for the whole release. But it's okay to be only quantitative and not
> qualitative, our team leader of the German translation project prays.
>
> Oh, we've the Live CD for a long time now. Did anybody use that medium on a
> slower, older computer? Surely not. Otherwise you would have noticed, that
> the Live CD is very slow there. The USB stick/variant may be fast, but the
> CD which we're now promoting at our download page better and more that the
> installation DVD, is IMHO not a good store sign as it is just slow. It even
> has not a localisation - folks, not the whole world is speaking english,
> just there is America on the worldmap! I know people from fairs, which are
> really frusted by their first try with a Live CD as it was just English.
> Yes, we maybe can create a spin, but these ones, we cannot offer on the FTP
> and HTTP mirrors, because Fedora is already too big. On the other hand, the
> issue of a non-US keyboard layout when trying to generate a localized
> version of the Live medium is still not fixed. There were some tries to
> solve that on LinuxTag 2008, but as far as I know, afterwards nobody again
> cared about and it went down. Remembering, that promoting our so cool Live
> CDs does not help in areas where the Internet is slow and old, I'm doing
> hereby, too. I don't want to remember, that the Fedora 8 Live media even
> killed crypted swap partitions...really a nice feature. By the way, does it
> do that still?
>
> Yeah, Anaconda got a bigger rewrite for Fedora 10 and took care of the old
> and often claimed issue, that the user needs to know the URL of a mirror in
> order to install Fedora via netinstall. But now, the screen got completely
> ripped out or is (if it really still exists, which I don't believe) too
> good hidden somewhere. Instead of that, somebody - that must have been an
> American - made the "repo=" option for the command line prompt if somebody
> wants to specify a local mirror. Urgs! At that point, no non-US keyboard
> layout is loaded! I now have to type something like "repo?http?--my.local-
> mirror-fedora-something-" or so on my non-US keyboard. Folks, the worldmap
> not only has American people with a US keyboard layout out there, even if
> some people think so. Even the "repo=xxx" is worse documented, but yes, who
> cares? Just me as it seems somehow...
>
> In order to support the RPM Fusion (former Livna) project, I tried to
> install the mirrormanager serverlist on a RHEL 4 with python 2.3 and having
> suexec in httpd enabled - and poorly failed. Mirrormanager is worse up to
> not documented at all and only focussed to RHEL 5+. So for a not really
> mirrormanager specific person it is nearly impossible to run mirrormanager
> serverlist in a secured/hardend environment out of the box without taking
> much action. Luckily I got support for several python 2.3 specific issues
> by a mirror admin and by the webteam leader - unluckily not so much help by
> the developer of mirrormanager who caused the stuff...I'm still getting a
> zombie process after a request by the *.wsgi which is surely no feature.
>
> Pushing packages into Fedora still takes ages in form of days or weeks. And
> this unluckily and especially also for security updates. The reason for
> this seems to be Bodhi, as the updates are usually happening very fast on
> EPEL which hasn't Bodhi. For EPEL it normally just takes hours, for Fedora
> mostly multiple days up to a week. I know, what I'm talking about here, I
> am co-maintaining phpMyAdmin which has more holes that a swiss cheese; the
> EPEL people know very well, what I'm talking about, too. I also had a lot
> of other security updates for other packages during 2008 and EPEL is always
> faster there, why Fedora is so slow? There must be a real reason, why we do
> not get rid of this for a long time now...and I would like to see this same
> good or even well in Fedora as in EPEL - or do we have to kill bodhi first?
>
> Hmmm, the "Merge Reviews" that somewhere have been declared as blockers
> for Fedora 7 (!) are still not done. It AFAIK was said somewhen, that not
> reviewed packages are getting removed from Fedora. This did not happen for
> anything, yet. The "Merge Reviews" are sometimes also blocked by Red Hat
> employees for very base/core packages by just refusing the Fedora Packaging
> guidelines, because it's the packager of the package. This can't be case!
> The Red Hat people have to follow the Fedora packaging guidelines and rules
> same as the Fedora folks - without any exception! If you would like to know
> which packages and people I'm talking about, have a look to Bugzilla and
> search for the bug reports I'm watching via Cc - there are lots of examples
> out there...without wanting to blame somebody special here on the list. But
> this has to be solved, the reviews need to be done, and the Red Hat people
> sitting on some base/core packages, must follow the Fedora rules same and
> without any refusing as they currently do. BTW, why is nobody controlling
> the success of the "Merge Reviews"? Shouldn't somebody watch this and tell
> us all the progress inside of e.g. the weekly Fedora newsletter or so?
>
> Oh, did I mention, that RPM 4.6, our dear big change in RPM at Fedora for
> years now is still buggy and so? When reading the article about a review of
> Fedora 10 by pro-linux.de (http://www.pro-linux.de/berichte/fedora10.html),
> I had to notice, that our dear rpm.org developers still did not get rid of
> the "hanging rpm" now must be solved by killing the RPM processes, removing
> the /var/lib/rpm/__* and rebuilding the rpmdb. Putting the (now cheap) oil
> into the fire would be a solution: rpm5.org solved the above mentioned very
> annoying issue already years ago. But yes I know, some yum developing and
> supporting individuals don't like the rpm5.org project by other individuals
> even not honoring their work, but even not backporting the fixes, developed
> there to solve old problems. I don't know of any "feature" in rpm.org, that
> is not already in rpm5.org; why do we put double efforts with so much delay
> in rpm.org when rpm5.org already has done the work? And before I know hear
> some derogatives about rpm5.org people: You're always getting the echo for
> what you did, but unluckily you often do not always remember to what you
> did or say before - and that AFAIK applies to all rpm5.org people related
> personal issues. And if we are now RPM; are there advantages of having some
> kinds of an APT API?
>
> PackageKit, another broken software which is in a pre-bleeding edge state I
> would say. PackageKit is resizing windows during installation or updating
> of packages; it's resizing and thus hopping the window if I e.g. select a
> package or if I click around inside of the application. That's something,
> which proves, that there is no usability for end users yet. That's IMHO
> more worse than alpha - but we're shipping it with releases, yay. And the
> related GNOME tray utility is also slow and usually is behind the current
> action...that's packagekitd, yes? One of these utilities also often blocks
> the usage of yum with saying, that another application currently holds the
> lock. Why are we locking something when not performing a writing action on
> the RPM database? That seems to be mis-engineered very well. Independent of
> that, PackageKit is somehow slow, has issues that it doesn't understand
> always where it is or whether an action is already completed. Oh and it
> kills my Firefox nicely during package updating, well-well done. Some more
> experiences about the broken-ness are mentioned in the review of Fedora 10
> on pro-linux.de (http://www.pro-linux.de/berichte/fedora10.html). Why do we
> ship such software? Only because we're bleeding edge and want to beat the
> guys of Ubuntu?
>
> When talking about PackageKit, DBUS is another issue. The recent DBUS pkg
> update broke PackageKit stuff - thanks to our cool QA. And clever as we
> are, we did not revoke the update and we also did not push a fixed package
> really immediately out after to solve this. I know, that many of the
> desktop people actually love DBUS, but it is horrible stuff, which can
> break down much things with lacking QA like in this case. Did you desktop
> people ever think about, that DBUS is not the perfect choice for a server
> system and Fedora is some kind of preview of RHEL? Yes, Fedora is not the
> playground of Red Hat, but on the other hand, Fedora is - why else is Red
> Hat putting efforts into Fedora if they wouldn't benefit? I really can only
> hope here, that Red Hat removes much of the DBUS breakage and dumbness for
> the next RHEL release and that less DBUS linked packages are making it into
> there...
>
> And as we're cool, we need a daemon for everything: packagekitd, dbusd, hal
> daemon, mcstransd, setroubleshootd, yum-updatesd - yay. And nearly every of
> this daemons is written in the memory consuming python and has nice memory
> leaks or other breakdown bugs. mcstransd is still slower for me (even after
> the speedup somebody of the SELinux guys did) as previous implementation
> without the daemon. But yes, we need daemons; restorecond would now be just
> another example. I think, there's much more which can be solved without a
> daemon and at least without memory-wasting worse written python. I'm aware,
> that python is the Red Hat internal defacto default and that scripting is
> much more faster rather coding low-level C. But lets waste ressources as
> e.g. kerneloops daemon does which always consumes a bit of CPU and thus not
> increases the consuming of energy in a positive way. But hey, let's create
> another daemon to monitor where we're wasting and leaking memory...
>
> Plymouth is nice - sometimes. Why did we put so much effort into that? It
> does not work with many graphic cards and it doesn't make things really
> faster for me. You also forgot to put a message somewhere, that hitting ESC
> can abort that thing and showing the regular messages instead. But this is
> what is "usability" called, when putting such an information not onto the
> screen. Maybe plymouth is faster as previous stuff, possible. But compared
> with the work of Arjan van de Ven, Linux developer at Intel and author of
> PowerTOP, it's still slow. He's booting up an Asus EeePC within 5 seconds;
> with plymouth it anyway takes a multiple of that for me. But yes, plymouth
> looks nice to end users and we like to waste time for that.
>
> When already being on booting: Does somebody remember to the Ubuntu stuff
> we really needed some releases ago? I'm talking about upstart, the event
> driven/based init system we've been hot to. And now? We're using the compat
> mode and that's it. Everything else uses just the same compatibility mode
> and AFAIK nothing in Fedora uses the "advantages" of upstart. But yes, we
> are bleeding edge with that. Did it make sense? No. But we wanted it. Okay.
> Why the hell did we need a event driven/based init system so much, if we
> still are not using any features of it and replacing the old init skeleton
> by the new things? I thought, we're bleeding edge? Looks like we only need
> to have the latest sharp razor, but we're never using it for cutting. Is
> upstream of upstart still alive? And is there any forward development some
> where in the world?
>
> Fedora EMEA e.V. also seems to be a mostly dead tree. Of course we have
> founded the association as legal vehicle. But it would be nice to see where
> my money, my membership fee, the 128 Euro per year are spent to. I now
> could assume, that the money is just collected and nothing happens or some
> guys of the board are buying and eating ice cream with, but I really hope
> that's not true. Fedora EMEA e.V. really needs to communicate a bit more to
> its members what they're doing and how the money is handled. Organisation
> is lacking much transparency and about their activities. AFAIK, a mailing
> list for the members of Fedora EMEA e.V. was created, I think it never was
> used yet. 128 Euro per year is IMHO too much for the current level of what
> seems to happen with the money. And for that money I could support the Free
> Software Foundation Europe (FSFE) with multiple membership fees per year.
> And sorry, just one cool bathrobe isn't a good reason for spending 128 Euro
> away per year. Without enough transparency and communication, it's like
> throwing the money out of the window of my room.
>
> If you're reading this, you've hopefully read all I wrote above. The main
> issue is, that all of the issues are known (if you try to tell me something
> else you're either blind and deaf-mute or you don't care about Fedora that
> much) - to their leader/owner and to others inside of the Fedora Project.
> But nobody really follows, is having a look to these issues and problems or
> even takes care of it...why? I think, this should be the job of the Fedora
> Project leader, shouldn't it? I don't want to blame neither Paul nor Max in
> this e-mail, I think everybody of us needs to be more sensitive to issues
> around the Fedora Project and needs to take more care before developing or
> forking something. And things exist, we don't need to re-invent always the
> wheel just because it's cool and bleeding edge. More work to get patches to
> upstream and so would avoid some of the pseudo-forks on Fedora Hosted as
> well. We definately need Open Communication, not only Open Source. But as
> it seems, even Fedora Talk didn't help that until now. So maybe the "f" of
> Free spech got lost somewhere in the latest slogan redesign?
>
> Oh...I'm really sorry now, that I used the phrase "bleeding edge" together
> with "Fedora" and that I called "Fedora" as "bleeding edge". I already got
> dispraised multiple times by individuals (eg. as part of the Fedora website
> team), that I think, Fedora is bleeding edge. If you've really read all of
> my irony, frustration, comments and suggestions above, you should have to
> agree with me, that Fedora is "bleeding edge". Fedora is far away from
> stable, it's a sharp razor with many edges where somebody can be easily cut
> with - and that's why we mostly like it.
>
> My points above are what Fedora makes sucking for me - or why I am NOT
> Fedora! At least I'm thinking that. Maybe you're thinking about my e-mail
> before replying. I would also like to hear comments (even private ones) by
> the affected parts of the Fedora Project. Thanks for taking the time.
>
>
> Greetings,
>  Robert
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
http://scwlab.com



From jspaleta at gmail.com  Mon Dec  8 23:12:57 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 8 Dec 2008 14:12:57 -0900
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081208213830.GA2885@free.fr>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
Message-ID: <604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>

On Mon, Dec 8, 2008 at 12:38 PM, Patrice Dumas <pertusus at free.fr> wrote:
> This is in order to always have a fallback. Anybody can use anything as
> EDITOR, but one has to have a default. vi is not a bad choice, it is
> POSIX, unless I am not recalling correctly, and it is small.


Should all possible fallbacks be hard requirements? Isn't it better to
have a number of competing packages provide an editor and provide a
virtual editor provides, have one of those installed editors set as
the default system editor via the EDITOR variable and then have all
packages which need an editor require the virtual editor provides
instead of a specific editor?

That way anyone can build a spin or do an install using any
appropriate available editor package which provides the editor virtual
provides as policy and tastes dictate.

-jef



From jamundso at gmail.com  Tue Dec  9 02:13:10 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Mon, 8 Dec 2008 20:13:10 -0600
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
Message-ID: <6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>

On Mon, Dec 8, 2008 at 5:12 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Mon, Dec 8, 2008 at 12:38 PM, Patrice Dumas <pertusus at free.fr> wrote:
>> This is in order to always have a fallback. Anybody can use anything as
>> EDITOR, but one has to have a default. vi is not a bad choice, it is
>> POSIX, unless I am not recalling correctly, and it is small.
>
>
> Should all possible fallbacks be hard requirements? Isn't it better to
> have a number of competing packages provide an editor and provide a
> virtual editor provides, have one of those installed editors set as
> the default system editor via the EDITOR variable and then have all
> packages which need an editor require the virtual editor provides
> instead of a specific editor?
>
> That way anyone can build a spin or do an install using any
> appropriate available editor package which provides the editor virtual
> provides as policy and tastes dictate.
>
> -jef
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Hmm, sounds familiar... oh, right, the alternatives man page.

       It is possible for several programs  fulfilling  the  same  or  similar
       functions  to  be  installed  on a single system at the same time.  For
       example, many systems have several  text  editors  installed  at  once.
       This gives choice to the users of a system, allowing each to use a dif-
       ferent editor, if desired, but makes it difficult for a program to make
       a  good choice of editor to invoke if the user has not specified a par-
       ticular preference.

       The alternatives system aims to solve this problem.

jerry

-- 
Store in cool, dry place. Rotate stock.



From jspaleta at gmail.com  Mon Dec  8 22:23:07 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 8 Dec 2008 13:23:07 -0900
Subject: Seahorse is orphaned?
In-Reply-To: <1228751408.3539.7.camel@localhost.localdomain>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
	<1228141066.3391.6.camel@localhost.localdomain>
	<493D24D1.6050202@redhat.com>
	<1228751408.3539.7.camel@localhost.localdomain>
Message-ID: <604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>

On Mon, Dec 8, 2008 at 6:50 AM, Matthias Clasen <mclasen at redhat.com> wrote:
> Name        : seahorse
> Summary     : A GNOME application for managing encryption keys
> Description :
> Seahorse is a graphical interface for managing and using encryption
> keys. It also integrates with nautilus, gedit and other places for
> encryption operations.
>
> And the desktop file has
>
> Name=Passwords and Encryption Keys
> Comment=Manage your passwords and encryption keys

I'm not sure this answers the underlying question concerning how to
find useful packages where the name is not indicative of the
functionality.  It's a hard but generally important question.

Assuming seahorse is not installed on the system can you describe how
you expect typical desktop users who need the functionality that
seahorse provides to find it and install it without knowing the
package name before hand? A screencast of you pretending to be a user
installing searching for and installing seahorse would be interesting
to watch.

Once installed how do users know where to look in the menus to find it?


-jef



From jspaleta at gmail.com  Mon Dec  8 19:58:54 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 8 Dec 2008 10:58:54 -0900
Subject: More PATH fallout. Who decided this was a good idea?
In-Reply-To: <200812081038.43323.sgrubb@redhat.com>
References: <1228519621.22587.19.camel@localhost.localdomain>
	<200812070954.31864.sgrubb@redhat.com>
	<604aa7910812071529h4e14eff7l55614033eeddddd0@mail.gmail.com>
	<200812081038.43323.sgrubb@redhat.com>
Message-ID: <604aa7910812081158l57b69f91v7230f51286cd9bdf@mail.gmail.com>

On Mon, Dec 8, 2008 at 6:38 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> Just wanted to let you know I am thinking about this. I need to think though
> what this does to our project and how to make sure we still get the right
> outcome.

Cool beans.

Fedora as a project is pulled in a lot of different, competing
directions, the more modular we can be, the better able this project
can be as a platform for a wider range of well defined but
non-compatible usage cases embodies as a selection of Spins or
kickstart files.

The CAPP capability stuff you are doing is just one example among
many.  While I personally don't grok the full value of CAPP, I can
totally see the capability as part of the Fedora platform being really
attractive aspect of Fedora coupled with our appliance-tools feature
for someone in the business of  building appliances .  Being able to
build appliance images which are CAPP certifiable might be a great
thing for a number of business entities that I would personally never
need to do business with for my computing needs.

Correct me if I'm wrong, but is CAPP certification primarily going to
be a server oriented feature? If that's the case, you should probably
get feedback from the newly ordained server SIG about alternative
implementation approaches. I'm most definitely not going to be a
consumer of CAPP certification, so my feedback on implementation
choices isn't going to be as valuable as those in your core
target..which I imagine is server admins.

-jef



From jonstanley at gmail.com  Tue Dec  9 02:36:00 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Mon, 8 Dec 2008 21:36:00 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>

As Jeff noted in his email after I started composing this, this is
very rambling.  I've attempted to reply to every point in this mail
that I feel I'm qualified to. Maybe we could split this out into major
sub-threads?

On Mon, Dec 8, 2008 at 7:25 PM, Robert Scheck <robert at fedoraproject.org> wrote:
> Good evening everybody,
>
> I've unluckily several points and issues, I'm trying to get solved for even
> for a longer time now (depending on the point on my list), but nobody in
> and around the Fedora Project seems or don't want to care about that. I am
> also annoyed, that I have to write such an e-mail, but the following really
> is, what Fedora makes sucking for me.

I'll reply where I feel I'm qualified here.

> Ah, and now first of all to the guys who will surely answer "use Ubuntu",
> "choose another distribution", "you're sucking as well" or similar: Go, run
> and die in a fire - immediately! I know, that this e-mail will make me the
> bogeyman for many of you, but that hopefully and luckily moves out Thorsten
> for a short time of his usual position while taking the seat myself... ;-)

Nah, this sort of feedback is extremely valuable, and I'm really happy
that you took the time to write it.  Without honest, frank feedback
about where we're going wrong, there's nothing that we can do to
improve.

> Well, we had the intrusion into the servers of the Fedora Project. That is
> now nearly 4 months ago. I remember to the words of our dear Fedora Project
> leader, who made us believing with the sentence "We will continue to keep
> the Fedora community notified of any updates." - but nothing happend after
> that. We all are still waiting for final report about the intrusion into
> the servers of the Fedora Project! Yes, we can: Open Source, but unluckily
> no Open Communication! Even the communication during the intrusion time was
> worse, e-mails to the Infrastructure team and to our Fedora Project leader
> got not really answered (or just when reasking and bugging) when asking for
> the issue and details even when it was mostly clear, that we're no longer
> really men about ourself - the intrusion.

I have no firsthand knowledge of this beyond what anybody else does.
However, there is likely still an investigation ongoing into what
happened. As such, it would be inappropriate to share information
about it until law enforcement is complete with their work (which they
are not known to be fast about), and the lawyers say what's OK to
share without spoiling any possible litigation.

> Our German translation is only quantitative, not qualitative. And the worse
> thing is, the team leader of the German translation team finds the current
> position and its current status okay. That's wrong and never should happen.
> If a German person is not able to understand the context of a translated
> sentence, the phrase should not be commited. Many people are even not re-
> reading the tsentence whether it has any meaning after the translation. But
> our team leader says, quantitative translation is okay. Ugly grammar and
> spelling issues are another thing; seems too much to re-read or to use a
> spellchecker before commiting - our teamleader says, that everything must
> fast go to upstream...great! I now know lots of German speaking people (in
> their mother tongue), which use Fedora only in English - including myself -
> to avoid the must of reading that horrible German. Surely, we can fix that,
> but if always people are working against, that does not help. Unluckily,
> language translations don't make it that often into Fedora updates during
> the lifetime of a Fedora release. So mostly, a broken translation is kept
> there for the whole release. But it's okay to be only quantitative and not
> qualitative, our team leader of the German translation project prays.

Unfortunately, I am one of those people that only speaks American
English. However, if I were German and being forced to read phrases
that I didn't understand because they were translated poorly, I'd
attempt to correct the translation. If the local leader feels this is
OK, I would take the matter to FLSCo, and attempt to assume the leader
role yourself (if you have the time and desire to do so).  If you
don't have the time, find someone else who shares your views, and work
with them.

> Oh, we've the Live CD for a long time now. Did anybody use that medium on a
> slower, older computer? Surely not. Otherwise you would have noticed, that
> the Live CD is very slow there. The USB stick/variant may be fast, but the

CD's are as slow as the reader, which is agonizingly slow on any
computer, not really restricted to older ones.  Obviously newer
computers would probably have faster drives, more RAM, etc, and I've
found various LiveCD's acceptable on newer hardware. I unfortunately
don't have anything to test on that would be considered "older
hardware" - I did before I moved to a tiny apartment, but that stuff
had to stay behind :)

> CD which we're now promoting at our download page better and more that the
> installation DVD, is IMHO not a good store sign as it is just slow. It even
> has not a localisation - folks, not the whole world is speaking english,

I agree that this is unfortunate, and also note that Ubuntu does a
better job than we do in this area, with a menu to select the language
when booting the Live CD. Maybe something that could be worked on.  If
you have experience, feel free to pitch in! I've not engaged in a
comparison between the Ubuntu Live CD and ours, however I'm assuming
that they sacrifice a lot of functionality on the Live CD in order to
have room for the various languages. Everything is a trade-off,
unfortunately.

> just there is America on the worldmap! I know people from fairs, which are
> really frusted by their first try with a Live CD as it was just English.
> Yes, we maybe can create a spin, but these ones, we cannot offer on the FTP
> and HTTP mirrors, because Fedora is already too big. On the other hand, the

What can be offered is a torrent, not ideal but better than nothing.

> issue of a non-US keyboard layout when trying to generate a localized
> version of the Live medium is still not fixed. There were some tries to
> solve that on LinuxTag 2008, but as far as I know, afterwards nobody again
> cared about and it went down. Remembering, that promoting our so cool Live
> CDs does not help in areas where the Internet is slow and old, I'm doing

In what way does it not help?

> hereby, too. I don't want to remember, that the Fedora 8 Live media even
> killed crypted swap partitions...really a nice feature. By the way, does it
> do that still?

I'm not familiar with that.

> Yeah, Anaconda got a bigger rewrite for Fedora 10 and took care of the old
> and often claimed issue, that the user needs to know the URL of a mirror in
> order to install Fedora via netinstall. But now, the screen got completely
> ripped out or is (if it really still exists, which I don't believe) too
> good hidden somewhere. Instead of that, somebody - that must have been an
> American - made the "repo=" option for the command line prompt if somebody
> wants to specify a local mirror. Urgs! At that point, no non-US keyboard
> layout is loaded! I now have to type something like "repo?http?--my.local-
> mirror-fedora-something-" or so on my non-US keyboard. Folks, the worldmap
> not only has American people with a US keyboard layout out there, even if
> some people think so. Even the "repo=xxx" is worse documented, but yes, who
> cares? Just me as it seems somehow...

I certainly don't think that, even though I'm an American.  This
really falls into the area of usability and QA.  Most of our QA
contributors are in the US, and I didn't have as much time as I would
have liked this time around due to $DAYJOB constraints.  However, my
local mirror is set up in MirrorManager, such that it gets delivered
to me first in mirrorlists, so I likely wouldn't have noticed this
anyway, unfortuantely.
'
> In order to support the RPM Fusion (former Livna) project, I tried to
> install the mirrormanager serverlist on a RHEL 4 with python 2.3 and having
> suexec in httpd enabled - and poorly failed. Mirrormanager is worse up to
> not documented at all and only focussed to RHEL 5+. So for a not really

MirrorManager was designed for use in Fedora Infrastructure, which
happens to run on RHEL5.  No one ever claimed that it was possible to
run it on RHEL4, however efforts were made to get it working for you.

> mirrormanager specific person it is nearly impossible to run mirrormanager
> serverlist in a secured/hardend environment out of the box without taking
> much action. Luckily I got support for several python 2.3 specific issues

If I recall, you were attempting to make it do things that it was not
ever designed or purported to be able to do.

> by a mirror admin and by the webteam leader - unluckily not so much help by
> the developer of mirrormanager who caused the stuff...I'm still getting a
> zombie process after a request by the *.wsgi which is surely no feature.

Note that the author of MM (Matt Domsch), while I don't like to speak
for him, is not a python guru, just a "normal" python programmer.  You
received help from python gurus.  Also, MM was our first TurboGears
app in infrastructure, and there are surely bugs with it. Matt
graciously accepts patches.

> Pushing packages into Fedora still takes ages in form of days or weeks. And
> this unluckily and especially also for security updates. The reason for

Package pushes continue to b e a manual process. However, the last
package that I pushed took less than 24 hours.


> not get rid of this for a long time now...and I would like to see this same
> good or even well in Fedora as in EPEL - or do we have to kill bodhi first?

No need to kill bodhi, simply implement a signing server in a secure fashion.

> without any refusing as they currently do. BTW, why is nobody controlling
> the success of the "Merge Reviews"? Shouldn't somebody watch this and tell
> us all the progress inside of e.g. the weekly Fedora newsletter or so?

This sounds like a perfect opportunity for you to assume a leadership
role within the community (the second one so far in this mail!).
Fedora is a culture of contribution, if you notice problems such as
this, then it is entirely within your power to fix it. You need to
find a likeminded group of folks, and proceed to implement a solution.

> Oh, did I mention, that RPM 4.6, our dear big change in RPM at Fedora for

I can't really comment on this.
>
> PackageKit, another broken software which is in a pre-bleeding edge state I

Again, I can't really comment on this except for the last part.  We
are not wanting to "beat" Ubuntu to anything - there's not an arms
race here or anything like that.  We are simply normally the first to
adopt

> When talking about PackageKit, DBUS is another issue. The recent DBUS pkg
> update broke PackageKit stuff - thanks to our cool QA. And clever as we

Unfortunately I don't think that I can tell from bodhi what the
initial request for this particular update was, testing or stable.  I
suspect stable, since it was a security update, and it was pushed
within 2 hours of the update being submitted.  Therefore, there was no
opportunity for QA. However, QA is an area where we are desperately
lacking resources. Help is welcome there.

> And as we're cool, we need a daemon for everything: packagekitd, dbusd, hal
> daemon, mcstransd, setroubleshootd, yum-updatesd - yay. And nearly every of

You are free to turn them off if you find that you don't need them.
How else would you suggest we implement these services?

> Plymouth is nice - sometimes. Why did we put so much effort into that? It
> does not work with many graphic cards and it doesn't make things really
> faster for me. You also forgot to put a message somewhere, that hitting ESC

Please file a bug about that and see where it goes.

> When already being on booting: Does somebody remember to the Ubuntu stuff
> we really needed some releases ago? I'm talking about upstart, the event
> driven/based init system we've been hot to. And now? We're using the compat
> mode and that's it. Everything else uses just the same compatibility mode

Ubuntu also simply uses the compatibility mode.  Some features of
upstart to enable us to make more use of it did not make it into 0.5,
so we're continuing in compatibility mode.  Casey Dahlin could shed
more light on this.

> Fedora EMEA e.V. also seems to be a mostly dead tree. Of course we have
> founded the association as legal vehicle. But it would be nice to see where

Interesting, I thought that it was going well.  Perhaps you should ask
FAmSCo to enlighten us here?

>
> If you're reading this, you've hopefully read all I wrote above. The main
> issue is, that all of the issues are known (if you try to tell me something
> else you're either blind and deaf-mute or you don't care about Fedora that
> much) - to their leader/owner and to others inside of the Fedora Project.

There are several issues noted above where *you* could be the
leader/owner if you wanted to be, and I would encourage that, and will
help in any way that I can.

> But nobody really follows, is having a look to these issues and problems or
> even takes care of it...why? I think, this should be the job of the Fedora
> Project leader, shouldn't it? I don't want to blame neither Paul nor Max in
> this e-mail, I think everybody of us needs to be more sensitive to issues

I really don't think that the FPL could possibly personally oversee
each and every thing that goes on in Fedora, his job is to make sure
overall things are going in the right direction.  However, I expect
Paul to respond to this once he's had a chance to digest it (note that
this response has taken me over an hour to write).

> well. We definately need Open Communication, not only Open Source. But as
> it seems, even Fedora Talk didn't help that until now. So maybe the "f" of
> Free spech got lost somewhere in the latest slogan redesign?

Communication is an area where any distributed organization could
undoubtedly do better. Fedora is no exception. This was recently
mentioned in the election townhalls, for instance.

> Oh...I'm really sorry now, that I used the phrase "bleeding edge" together
> with "Fedora" and that I called "Fedora" as "bleeding edge". I already got
> dispraised multiple times by individuals (eg. as part of the Fedora website
> team), that I think, Fedora is bleeding edge. If you've really read all of

I think that Fedora is "the best of what works today", and that
involves being on the leading edge of advancement in the FOSS
community. Does this mean that a little blood is necessarily shed from
time to time?  Absolutely.  However, it also doesn't mean Fedora is
hemorrhaging :)

> the affected parts of the Fedora Project. Thanks for taking the time.

I'd like to thank you for taking the time to write this!



From pemboa at gmail.com  Mon Dec  8 22:36:16 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 8 Dec 2008 16:36:16 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <1228774767.25085.141.camel@localhost.localdomain>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<493C462B.4070607@gmail.com> <493D5DA3.7010408@gmail.com>
	<493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
Message-ID: <16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>

On Mon, Dec 8, 2008 at 4:19 PM, Simo Sorce <ssorce at redhat.com> wrote:
> On Mon, 2008-12-08 at 10:47 -0800, Jesse Keating wrote:
>> > On Mon, 2008-12-08 at 12:35 -0600, Les Mikesell wrote:
>> >
>> > I just don't get why any sane person, especially anyone familiar with
>> > computer languages, would ever want to give something that is not the
>> > same the same name.  Does anyone know how the developer(s) manage this
>> > themselves?  I have to think they are keeping multiple concurrent
>> > versions installed (and that that is the only reasonable approach).
>>
>> I'm pretty certain that if you look at any language, they've all faced
>> similar scenarios, major version upgrades that may in fact not be
>> forward no backward compatible.  People have dealt with it and moved on.
>> No language is perfect.
>
> Never seen C/C++ break backward compatibility on a scale like Python 3.0
> will.
> And they are compiled, where the impact is 100 fold less than for
> interpreted languages ...
>
> I would personally strongly consider having 2.x and 3.0 parallel
> installable ...


Isn't Python designed to be parallel installable?


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jspaleta at gmail.com  Tue Dec  9 03:13:07 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 8 Dec 2008 18:13:07 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
Message-ID: <604aa7910812081913s40e29ef1w1be9d37bdad6ae39@mail.gmail.com>

On Mon, Dec 8, 2008 at 5:36 PM, Jon Stanley <jonstanley at gmail.com> wrote:
> As Jeff noted in his email after I started composing this, this is
> very rambling.  I've attempted to reply to every point in this mail
> that I feel I'm qualified to. Maybe we could split this out into major
> sub-threads?

If we continue to try to hold a discussion about each of
these...topics... in a single thread.. it will be utter fail.
Different people are domain experts for different issues in the
original mail.. I'm honestly not going to bother trying to do what you
did by addressing everything in a single email. I doubt most mail
servers would allow the 10 Mb text file which would result.

-jef



From bpepple at fedoraproject.org  Mon Dec  8 21:06:19 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 08 Dec 2008 16:06:19 -0500
Subject: Package Review Stats for the week ending December  7, 2008
Message-ID: <1228770379.5346.3.camel@localhost.localdomain>

Top four FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending December 7th, 2008
were Parag AN(????), Jason Tibbitts, Michael Schwendt, and Patrice
Dumas.  Below is the number of completed package reviews done.

Parag AN(????) - 16
Jason Tibbitts - 3
Michael Schwendt - 3
Patrice Dumas - 3
Brian Pepple - 2
Lubomir Kundrak - 2
manuel wolfshant - 2
Adam Jackson - 1
Jarod Wilson - 1
Jerry James - 1
Jesse Keating - 1
Mamoru Tasaka - 1
Michal Fabry - 1
Rafa? Psota - 1
Wart - 1
Xavier Lamien - 1

Total reviews: 40

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/720757d9/attachment.sig>

From kevin.kofler at chello.at  Tue Dec  9 03:55:33 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 09 Dec 2008 04:55:33 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
Message-ID: <ghkq7m$46p$1@ger.gmane.org>

Jon Stanley wrote:
> I agree that this is unfortunate, and also note that Ubuntu does a
> better job than we do in this area, with a menu to select the language
> when booting the Live CD. Maybe something that could be worked on.  If
> you have experience, feel free to pitch in! I've not engaged in a
> comparison between the Ubuntu Live CD and ours, however I'm assuming
> that they sacrifice a lot of functionality on the Live CD in order to
> have room for the various languages. Everything is a trade-off,
> unfortunately.

I can't speak for the GNOME Live CD, but as far as the KDE Live CD is
concerned, there's no way we can fit in all the kde-l10n-* packages and
still fit on a CD. We'd have to make it a DVD and that would screw over the
people with older computers (which is what another of Robert's complaints
was about). So there's a tradeoff between supporting older computers or
translations.

> No need to kill bodhi, simply implement a signing server in a secure
> fashion.

Well, Jesse Keating recently said the signing server won't solve all the
issues by itself, because one of the problems is that each push takes about
24 hours to complete. We would get one push per day with automated signing,
but no more, unless Bodhi gets optimized somehow (but it isn't immediately
obvious how). But I don't think killing Bodhi is the solution nor even an
option.

>> When talking about PackageKit, DBUS is another issue. The recent DBUS pkg
>> update broke PackageKit stuff - thanks to our cool QA. And clever as we
> 
> Unfortunately I don't think that I can tell from bodhi what the
> initial request for this particular update was, testing or stable.  I
> suspect stable, since it was a security update, and it was pushed
> within 2 hours of the update being submitted.  Therefore, there was no
> opportunity for QA. However, QA is an area where we are desperately
> lacking resources. Help is welcome there.

Well, the problem here is that the update was rushed to stable when:
* the update touches a core system component which is relied on by our
update system among many other things,
* the update is not one of those obvious security fixes like preventing a
buffer overflow, it is a policy change (and thus much more likely to break
things),
* the policy crackdown is on local communication, not remote. This means:
- it is more likely to break the system and as such needs testing and
- the hole it fixes is at most a local privilege escalation, and finally
* the issue has been public for over a month! What is one more week of
testing going to change?

I think we need to be more careful with certain types of security updates,
and better let them get some QA even if it means the fix gets delayed.
Completely breaking the updates means many users will never get any updates
anymore (because they don't know how to fix their system - there's a
PackageKit update queued, but how are they going to get it without a
working PackageKit? You can't expect them to know what su -c "yum upgrade"
is), including critical security fixes. Is a low-priority security update
worth that? At the very least the maintainer should actually test the
update before rushing it out, which I strongly doubt he did because
PackageKit not working is something everybody should notice. (But I don't
think that's sufficient, I think the update should have stayed in
updates-testing for a week. And ideally both should have happened, the
maintainer should have tested it first, and only when actually working
pushed it to testing.)

If I'm not mistaken, there's also a problem with how our "security team
approval" process works, because the security update requests all show up
as requests for testing first, then the security team approves them and
queues them for stable, so the maintainer has to explicitly tell them not
to do that if he wants the update to get some testing first.

Oh, and it wasn't pushed within 2 hours of being submitted, the date you see
is the "Date released", not the "Date submitted". Normally "Date released"
is the date and time the update gets pushed, but the 2 hours of difference
are because the "Date released" gets set earlier in the pushing process
than the "pushed to stable" comment. If you look at
https://bugzilla.redhat.com/show_bug.cgi?id=474895 you'll see it took 32
hours to get the update pushed. It is impossible for an update to be pushed
within 2 hours of submission because the push alone takes about 24 hours.

        Kevin Kofler



From jkeating at redhat.com  Tue Dec  9 04:04:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 08 Dec 2008 20:04:14 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghkq7m$46p$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
Message-ID: <1228795454.3863.2.camel@localhost.localdomain>

On Tue, 2008-12-09 at 04:55 +0100, Kevin Kofler wrote:
> push alone takes about 24 hours.

Not quite that long.  It's somewhere on the order of 6~ hours to
complete.  What I claimed is that with this kind of turn around, i
wouldn't expect there to be any more than one push per 24 hours, mostly
because I have to sleep at some point, and mirrors have to have time to
sync up before we flood them with more changes.

The rate of change in our updates repos is highly disturbing.  new
packages + tonnes of updates == huge amount of churn to consume.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/9e79dec8/attachment.sig>

From lesmikesell at gmail.com  Tue Dec  9 04:54:01 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 08 Dec 2008 22:54:01 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <d25f375f0812081641l3b8df93m54728fe80e380094@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<d25f375f0812081641l3b8df93m54728fe80e380094@mail.gmail.com>
Message-ID: <493DF9E9.1000909@gmail.com>

Pavel Shevchuk wrote:
> I agree to most of the letter, especially python daemons stuff and
> plymouth, but do you know any better OS/distro? I've tried many and
> fedora is one of the best things around, unless you want to spend all
> your spare time maintaining custom LFS system.

Better for what?  RHEL/Centos is better for many-year stability.  Ubuntu 
is better for 'just working' most of the time.  But the one that seems 
to have gone missing is one clearly evolving towards the 'next' RHEL.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From jkeating at redhat.com  Tue Dec  9 04:54:57 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 08 Dec 2008 20:54:57 -0800
Subject: Seahorse is orphaned?
In-Reply-To: <604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
	<1228141066.3391.6.camel@localhost.localdomain>
	<493D24D1.6050202@redhat.com>
	<1228751408.3539.7.camel@localhost.localdomain>
	<604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>
Message-ID: <1228798497.3863.4.camel@localhost.localdomain>

On Mon, 2008-12-08 at 13:23 -0900, Jeff Spaleta wrote:
> 
> Assuming seahorse is not installed on the system can you describe how
> you expect typical desktop users who need the functionality that
> seahorse provides to find it and install it without knowing the
> package name before hand? A screencast of you pretending to be a user
> installing searching for and installing seahorse would be interesting
> to watch.

If they searched for keys or encryption keys or password keys or
anything else in the description or summary they'd find the package,
regardless of it's name.  How does one find say liferea to read RSS
feeds?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/540f36b3/attachment.sig>

From ob.system at gmail.com  Tue Dec  9 05:47:17 2008
From: ob.system at gmail.com (Oscar Victorio Calixto Bacho)
Date: Mon, 8 Dec 2008 23:47:17 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghkq7m$46p$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
Message-ID: <6a28481b0812082147n2f763d72jfcf9008fbb4cfda4@mail.gmail.com>

2008/12/8 Kevin Kofler <kevin.kofler at chello.at>

>
> Well, the problem here is that the update was rushed to stable when:
> * the update touches a core system component which is relied on by our
> update system among many other things,
> * the update is not one of those obvious security fixes like preventing a
> buffer overflow, it is a policy change (and thus much more likely to break
> things),
> * the policy crackdown is on local communication, not remote. This means:
> - it is more likely to break the system and as such needs testing and
> - the hole it fixes is at most a local privilege escalation, and finally
> * the issue has been public for over a month! What is one more week of
> testing going to change?
>
> I think we need to be more careful with certain types of security updates,
> and better let them get some QA even if it means the fix gets delayed.
> Completely breaking the updates means many users will never get any updates
> anymore (because they don't know how to fix their system - there's a
> PackageKit update queued, but how are they going to get it without a
> working PackageKit? You can't expect them to know what su -c "yum upgrade"
> is), including critical security fixes. Is a low-priority security update
> worth that? At the very least the maintainer should actually test the
> update before rushing it out, which I strongly doubt he did because
> PackageKit not working is something everybody should notice. (But I don't
> think that's sufficient, I think the update should have stayed in
> updates-testing for a week. And ideally both should have happened, the
> maintainer should have tested it first, and only when actually working
> pushed it to testing.)
>
>        Kevin Kofler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
 Richard your comments
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/4f2b2d67/attachment.htm>

From jkeating at redhat.com  Tue Dec  9 06:15:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 08 Dec 2008 22:15:12 -0800
Subject: New project, for fun and excitement: Offtrac!
Message-ID: <1228803312.3863.20.camel@localhost.localdomain>

So today I was looking at a ToDo item, which was create milestones in
the rel-eng trac instance for the Fedora 11 release cycle, and fill
those milestones up with tickets.  I thought to myself, that's a lot of
web clicking to do, there has to be an easier way!

Well there is and there isn't.  I wanted to programatically create the
milestones and tickets, and it turns out there are no existing command
line tools to do this.  I was told that I could just use the trac python
module and do it directly on the server writing my own client.

Well sure, that would work, but how useful is that to the many project
owners at fedorahosted.org ?  Not very.

Thankfully there is an xmlrpc plugin for Trac, that exposes a few things
via xmlrpc.  This means any client computer can connect over xmlrpc and
do things such as create milestones, and tickets, and get info of
existing things.

Of course, there are no well known pre-written clients to do this.

Enter Offtrac!  https://fedorahosted.org/offtrac/

Offtrac is my attempt at creating a python library for interacting with
trac via xmlrpc.  I've also created a reference application that makes
use of this library, configured for the Fedora Hosted environment.

What it does right now:
 * Query existing tickets
 * List existing milestones
 * Get information about particular tickets
 * Get information about particular milestones
 * Create new tickets
 * Create new milestones

All authenticated! (via https)

There are lots more things that could be done, just look at all the fun
listed here: https://fedorahosted.org/rel-eng/xmlrpc


I'm looking for folks that would like to extend what I have, and help me
to make the library more like a library.  It's only my second attempt at
an API and well I'm not great at it (:

I'm also looking for folks that would like to extend the fedora-hosted
client, and to start looking at doing things like "make tag-request"
from your pkg-cvs checkouts.

If you want to join the fun, find me on freenode IRC as "f13", or just
start mailing patches to me and we'll take it from there.

Have fun!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/19ffceb8/attachment.sig>

From jkeating at redhat.com  Tue Dec  9 06:27:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 08 Dec 2008 22:27:17 -0800
Subject: New project, for fun and excitement: Offtrac!
In-Reply-To: <1228803312.3863.20.camel@localhost.localdomain>
References: <1228803312.3863.20.camel@localhost.localdomain>
Message-ID: <1228804037.3863.24.camel@localhost.localdomain>

On Mon, 2008-12-08 at 22:15 -0800, Jesse Keating wrote:
> 
> Offtrac is my attempt at creating a python library for interacting with
> trac via xmlrpc.  I've also created a reference application that makes
> use of this library, configured for the Fedora Hosted environment.
> 
> What it does right now:
>  * Query existing tickets
>  * List existing milestones
>  * Get information about particular tickets
>  * Get information about particular milestones
>  * Create new tickets
>  * Create new milestones
> 
> All authenticated! (via https)

I should mention that offtrac (and fedora-hosted.py) only works with
Trac environments that enable the xmlrpc plugin.  We just started
testing this plugin in the Fedora Hosted environment, and it hasn't been
fully integrated into our config management control.  The only projects
I know of with it enabled are rel-eng, pungi, and offtrac.  If you want
to enable xmlrpc in your project space to enable offtrac use with it,
file a ticket in fedora-infrastructure (or again find me on IRC) and
we'll take care of it.  If things go well, we'll consider making the
xmlrpc plugin a default for hosted projects.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081208/31dbbb4b/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Dec  9 06:35:56 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 09 Dec 2008 07:35:56 +0100
Subject: New project, for fun and excitement: Offtrac!
In-Reply-To: <1228804037.3863.24.camel@localhost.localdomain>
References: <1228803312.3863.20.camel@localhost.localdomain>
	<1228804037.3863.24.camel@localhost.localdomain>
Message-ID: <1228804556.15234.1.camel@arekh.okg>

      * Le lundi 08 d?cembre 2008 ? 22:27 -0800, Jesse Keating a ?crit :

> I should mention that offtrac (and fedora-hosted.py) only works with
> Trac environments that enable the xmlrpc plugin. 

I thought the attraction with trac is it was supposed to be simple.

Do you intend to bolt on all the bugzilla features on it too?
Would not it be simpler if fedorahosted used bugzilla like everyone
else?

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/d333bdf5/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Dec  9 06:42:10 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 09 Dec 2008 07:42:10 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228795454.3863.2.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<1228795454.3863.2.camel@localhost.localdomain>
Message-ID: <1228804930.15234.2.camel@arekh.okg>

Le lundi 08 d?cembre 2008 ? 20:04 -0800, Jesse Keating a ?crit :
> On Tue, 2008-12-09 at 04:55 +0100, Kevin Kofler wrote:
> > push alone takes about 24 hours.
> 
> Not quite that long.  It's somewhere on the order of 6~ hours to
> complete.  What I claimed is that with this kind of turn around, i
> wouldn't expect there to be any more than one push per 24 hours, mostly
> because I have to sleep at some point, and mirrors have to have time to
> sync up before we flood them with more changes.
> 
> The rate of change in our updates repos is highly disturbing.  new
> packages + tonnes of updates == huge amount of churn to consume.

That's what you get when you let people claim "the Fedora way is to push
everything to every branches at once"

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/5d519fdb/attachment.sig>

From jspaleta at gmail.com  Tue Dec  9 06:57:38 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 8 Dec 2008 21:57:38 -0900
Subject: Seahorse is orphaned?
In-Reply-To: <1228798497.3863.4.camel@localhost.localdomain>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
	<1228141066.3391.6.camel@localhost.localdomain>
	<493D24D1.6050202@redhat.com>
	<1228751408.3539.7.camel@localhost.localdomain>
	<604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>
	<1228798497.3863.4.camel@localhost.localdomain>
Message-ID: <604aa7910812082257l3aed0063q543050b6fecbb8f1@mail.gmail.com>

2008/12/8 Jesse Keating <jkeating at redhat.com>:
> If they searched for keys or encryption keys or password keys or
> anything else in the description or summary they'd find the package,
> regardless of it's name.  How does one find say liferea to read RSS
> feeds?


I don't know... I've personally read so many freshmeat.net daily
summaries over the years that I recognize way to many project names.
I personally seldom do a search description or summary search. I can
usually find what I'm looking for by package name.  And if I can't
find it in the menus after I install it, I rpm -ql the package, find
the desktop file and then grep it looking for the menu entry info.  I
do things the absolute wrong way.

-jef



From ivazqueznet at gmail.com  Tue Dec  9 07:21:57 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 09 Dec 2008 02:21:57 -0500
Subject: New project, for fun and excitement: Offtrac!
In-Reply-To: <1228804556.15234.1.camel@arekh.okg>
References: <1228803312.3863.20.camel@localhost.localdomain>
	<1228804037.3863.24.camel@localhost.localdomain>
	<1228804556.15234.1.camel@arekh.okg>
Message-ID: <1228807317.15367.85.camel@ignacio.lan>

On Tue, 2008-12-09 at 07:35 +0100, Nicolas Mailhot wrote:
> * Le lundi 08 d?cembre 2008 ? 22:27 -0800, Jesse Keating a ?crit :
> 
> > I should mention that offtrac (and fedora-hosted.py) only works with
> > Trac environments that enable the xmlrpc plugin. 
> 
> I thought the attraction with trac is it was supposed to be simple.
> 
> Do you intend to bolt on all the bugzilla features on it too?
> Would not it be simpler if fedorahosted used bugzilla like everyone
> else?

I'm really curious to hear why you think activating XML-RPC support in
Trac suddenly turns it into Bugzilla, other than "they both have
XML-RPC".

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/071c35b6/attachment.sig>

From nicu_fedora at nicubunu.ro  Tue Dec  9 07:47:32 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Tue, 09 Dec 2008 09:47:32 +0200
Subject: FAmSCo elections only open to ambassadors?
In-Reply-To: <3170f42f0812081006p33f8a09dr42c1f8960bb4d579@mail.gmail.com>
References: <493D4194.1070804@hhs.nl> <493D50D6.3020700@nicubunu.ro>
	<3170f42f0812081006p33f8a09dr42c1f8960bb4d579@mail.gmail.com>
Message-ID: <493E2294.7050908@nicubunu.ro>

Debarshi Ray wrote:
>> Also, the Ambassadors are an easy to join group, I believe a number of
>> developers are registered as Ambassadors.
> 
> This is a very bad argument. Just because it might be 'easy' to join a
> group does not mean that one can join it and forget about the
> responsibilities that come with it. So it is wrong to tell someone
> that since it is 'easy' to become an Ambassador he should become one
> merely for the sake of being able to vote.

Read it as "the barrier to join the Ambassadors is very low": 
http://fedoraproject.org/wiki/Ambassadors/3SimpleQuestion

The actual requirement are a little higher (this is why I have not 
joined it), but not excessive for anyone that wants the right to vote:
http://fedoraproject.org/wiki/Ambassadors/Join

> It is way beyond my knowledge and abilities to comment on how easy it
> is and whether non-Ambassadors should be able to vote or not, but I
> feel that this is not a correct argument.


-- 
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 rc040203 at freenet.de  Tue Dec  9 07:42:02 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 09 Dec 2008 08:42:02 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228804930.15234.2.camel@arekh.okg>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<1228795454.3863.2.camel@localhost.localdomain>
	<1228804930.15234.2.camel@arekh.okg>
Message-ID: <1228808522.30957.11206.camel@beck.corsepiu.local>

On Tue, 2008-12-09 at 07:42 +0100, Nicolas Mailhot wrote:
> Le lundi 08 d?cembre 2008 ? 20:04 -0800, Jesse Keating a ?crit :
> > On Tue, 2008-12-09 at 04:55 +0100, Kevin Kofler wrote:
> > > push alone takes about 24 hours.
> > 
> > Not quite that long.  It's somewhere on the order of 6~ hours to
> > complete.  What I claimed is that with this kind of turn around, i
> > wouldn't expect there to be any more than one push per 24 hours, mostly
> > because I have to sleep at some point, and mirrors have to have time to
> > sync up before we flood them with more changes.
> > 
> > The rate of change in our updates repos is highly disturbing.  new
> > packages + tonnes of updates == huge amount of churn to consume.
> 
> That's what you get when you let people claim "the Fedora way is to push
> everything to every branches at once"

Though there is some truth in what you say, wrt. new packages, IMO, not
doing so would contradict the purposes of Fedora.

However, I feel there is are other factors, which esp. show in
time-frames like the current one (shortly after a release):
- Maintainers are working off the back-logs the release freezes have
caused.
- Maintainers are fixing bugs, which managed to make it into
Fedora-10-final and now are hitting users.

Ralf






From hughsient at gmail.com  Tue Dec  9 08:21:47 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 09 Dec 2008 08:21:47 +0000
Subject: PackageKit and the recent DBus problems
Message-ID: <1228810907.3409.26.camel@hughsie-work.lan>

I've prepared an F10 update of PackageKit, gnome-packagekit and
kpackagekit that has the DBus fixes (both of them) and will not have any
dependency issues caused by mirrors having different versions of an
update:

https://admin.fedoraproject.org/updates/PackageKit-0.3.12-1.fc10,gnome-packagekit-0.3.12-1.fc10,kpackagekit-0.3.1-9.fc10

I'm also going to update F9 to the same versions, but I'm just waiting
for PK to be pulled into the buildroot so I can build GPK and KPK and
then submit an update:

https://fedorahosted.org/rel-eng/ticket/1125

Over the last two days we've all been working really hard on fixing up
all the projects after the DBus update. I know personally I'm closing a
duplicate bugzilla every 30 minutes.

One thing that is limiting me is the delay from creating an update, and
then pushing it to a mirror. "Status: pending" seems to be the bane of
my life right now.

Is there any plan to make this process quicker?

Richard.




From nicolas.mailhot at laposte.net  Tue Dec  9 08:33:16 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 9 Dec 2008 09:33:16 +0100 (CET)
Subject: New project, for fun and excitement: Offtrac!
In-Reply-To: <1228807317.15367.85.camel@ignacio.lan>
References: <1228803312.3863.20.camel@localhost.localdomain>
	<1228804037.3863.24.camel@localhost.localdomain>
	<1228804556.15234.1.camel@arekh.okg>
	<1228807317.15367.85.camel@ignacio.lan>
Message-ID: <c30d5faa91f9fff4d65ce6a3fb3eae50.squirrel@arekh.dyndns.org>



Le Mar 9 d?cembre 2008 08:21, Ignacio Vazquez-Abrams a ?crit :

> I'm really curious to hear why you think activating XML-RPC support in
> Trac suddenly turns it into Bugzilla, other than "they both have
> XML-RPC".

It was more "if we now devote resources enhancing track I'm going to
request all the missing features that make my life miserable with it,
which will probably turn it into another bugzilla"

-- 
Nicolas Mailhot



From bernie at codewiz.org  Tue Dec  9 08:49:42 2008
From: bernie at codewiz.org (Bernie Innocenti)
Date: Tue, 09 Dec 2008 03:49:42 -0500
Subject: libgnome-devel depends on esound-devel
In-Reply-To: <493D4104.7090906@redhat.com>
References: <493C6727.5020701@codewiz.org> <493D4104.7090906@redhat.com>
Message-ID: <493E3126.9050106@codewiz.org>

Ray Strode wrote:
> Bernie Innocenti wrote:
>> Any idea why?  Can we drop this dependency?
> Probably for historical reasons.  Mind filing a bug?

Done, thanks.

  https://bugzilla.redhat.com/show_bug.cgi?id=475442

-- 
   // Bernie Innocenti - http://www.codewiz.org/
 \X/  Sugar Labs       - http://www.sugarlabs.org/



From pertusus at free.fr  Tue Dec  9 08:54:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Dec 2008 09:54:30 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
Message-ID: <20081209085430.GB3833@free.fr>

On Mon, Dec 08, 2008 at 08:13:10PM -0600, Jerry Amundson wrote:
> >
> 
> Hmm, sounds familiar... oh, right, the alternatives man page.
> 
>        It is possible for several programs  fulfilling  the  same  or  similar
>        functions  to  be  installed  on a single system at the same time.  For
>        example, many systems have several  text  editors  installed  at  once.
>        This gives choice to the users of a system, allowing each to use a dif-
>        ferent editor, if desired, but makes it difficult for a program to make
>        a  good choice of editor to invoke if the user has not specified a par-
>        ticular preference.
> 
>        The alternatives system aims to solve this problem.

Not really. The alternatives system is useful if
* the different applications have compatible command line options
* the setting makes sense as a system-wide setting, not as a user
  setting.

--
Pat



From balbir at linux.vnet.ibm.com  Tue Dec  9 08:58:30 2008
From: balbir at linux.vnet.ibm.com (Balbir Singh)
Date: Tue, 9 Dec 2008 14:28:30 +0530
Subject: cgroups etc (WAS: Re: Enabling the memory controller for F11)
In-Reply-To: <1228774131.3023.14.camel@fecusia>
References: <20081208062952.GG13333@balbir.in.ibm.com>
	<493D4128.8050402@BitWagon.com> <1228774131.3023.14.camel@fecusia>
Message-ID: <20081209085830.GB4383@balbir.in.ibm.com>

* Linus Walleij <triad at df.lth.se> [2008-12-08 23:08:51]:

> m?n 2008-12-08 klockan 07:45 -0800 skrev John Reiser:
> 
> > > [Please] enable the memory controller for F11.
> > 
> > Please give a URL to a description of what it does,
> 
> Memory controllers rock:
> http://lxr.linux.no/linux/Documentation/controllers/memory.txt
>

Thanks! Good to know
 
> Lots of links there in the end.
> 
> On servers memory cgroups taken together with the existing CPU slicing
> cgroups and affinity cgroups enables the same stuff that Solaris "zones"
> (http://en.wikipedia.org/wiki/Solaris_Containers) does, more or less,
> but actually better because it's more fine-grained and doesn't need you
> to configure an entire virtual machine.
> 
> Instead of limiting this one virtual machine, the cgroups features make
> it possible to limit this one group of processes, without any
> virtualization overhead. I guess you could combine it with User Mode
> Linux if you want real, constrained virtualization.
> 
> cgroups are really a core killer feature in Linux, just that the rest of
> the world doesn't quite know yet, nor do userspace know quite how to
> handle all the nice cgroups, but much is happening right now.
> 

Yes a core killer feature and we have libcgroup to help
program/control from userspace. We already the package in F10.

> Even if servers is what most cgroup authors probably have in mind, they
> are equally useful to desktops and embedded systems.

-- 
	Balbir



From pertusus at free.fr  Tue Dec  9 08:59:23 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Dec 2008 09:59:23 +0100
Subject: PackageKit and the recent DBus problems
In-Reply-To: <1228810907.3409.26.camel@hughsie-work.lan>
References: <1228810907.3409.26.camel@hughsie-work.lan>
Message-ID: <20081209085923.GC3833@free.fr>

On Tue, Dec 09, 2008 at 08:21:47AM +0000, Richard Hughes wrote:
> 
> One thing that is limiting me is the delay from creating an update, and
> then pushing it to a mirror. "Status: pending" seems to be the bane of
> my life right now.
> 
> Is there any plan to make this process quicker?

Jesse explained in a recent thread I launched why more than a push per
day was not really doable currently with the time compose takes.

--
Pat



From nikolay at vladimiroff.com  Tue Dec  9 09:00:44 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Tue, 9 Dec 2008 11:00:44 +0200
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
Message-ID: <a2e85ed0812090100o347e9e2j293310f7f85d82ca@mail.gmail.com>

2008/12/9 Jerry Amundson <jamundso at gmail.com>:
> On Mon, Dec 8, 2008 at 5:12 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
>> On Mon, Dec 8, 2008 at 12:38 PM, Patrice Dumas <pertusus at free.fr> wrote:
>>> This is in order to always have a fallback. Anybody can use anything as
>>> EDITOR, but one has to have a default. vi is not a bad choice, it is
>>> POSIX, unless I am not recalling correctly, and it is small.
>>
>>
>> Should all possible fallbacks be hard requirements? Isn't it better to
>> have a number of competing packages provide an editor and provide a
>> virtual editor provides, have one of those installed editors set as
>> the default system editor via the EDITOR variable and then have all
>> packages which need an editor require the virtual editor provides
>> instead of a specific editor?
>>
>> That way anyone can build a spin or do an install using any
>> appropriate available editor package which provides the editor virtual
>> provides as policy and tastes dictate.
>>
>> -jef
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
> Hmm, sounds familiar... oh, right, the alternatives man page.
>
>       It is possible for several programs  fulfilling  the  same  or  similar
>       functions  to  be  installed  on a single system at the same time.  For
>       example, many systems have several  text  editors  installed  at  once.
>       This gives choice to the users of a system, allowing each to use a dif-
>       ferent editor, if desired, but makes it difficult for a program to make
>       a  good choice of editor to invoke if the user has not specified a par-
>       ticular preference.
>
>       The alternatives system aims to solve this problem.
>
> jerry
>
> --
> Store in cool, dry place. Rotate stock.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

I really don't understand whats the problem with vi. It works, it's
small and it's the most common editor(in terms of availability not
usage). Even busybox has vi(or something that behaves like vi). It's
not like it's eating your precious hard disk or baby koalas. Vi is
also good for your health. You can always depend on vi to be there and
to work. It's not that I'm starting some "my editor is the best
flamewar". I'm just saying use whatever you want, but leave vi alone.
It likes to be the standard editor.

Best Regards,
Nikolay Vladimirov



From mschwendt at gmail.com  Tue Dec  9 09:49:55 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 9 Dec 2008 10:49:55 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I am
 NOT Fedora
In-Reply-To: <ghkq7m$46p$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
Message-ID: <20081209104955.55a363b2.mschwendt@gmail.com>

On Tue, 09 Dec 2008 04:55:33 +0100, Kevin wrote:

> I think we need to be more careful with certain types of security updates,
> and better let them get some QA even if it means the fix gets delayed.

QA ... reminds me to ask once more:

Where can I learn more about the thing referred to as "Fedora QA"?
Who is it? What do they do?

fedora-qa-list is dead since Aug 2007 and has never seen more than
IRC meeting announcements.

https://fedoraproject.org/wiki/SIGs/QA  is in a desolate state and seems
not to be connected to the people that call themselves "Fedora QA".

Fedora has a serious problem with updates that are pushed out to "stable"
directly. Originally we've had a guideline to use updates-testing for
a few days.

I'm also surprised to find discrepancies between Rawhide (just 1-2 weeks
before F10 release) and F10 final. Such as a non-working PulseAudio.
After every reboot, the mixer settings get messed up. Sometimes the
PulseAudio mixer is not available at all. And worse, simple playback of
audio files in Rhythmbox and Audacious (or even previews on the desktop)
suffer from interruptions. Not so in earlier Rawhide. The pulseaudio
changelog is not included in the package, and the RPM %changelog
contains vague comments like:

  - Backport another two fixes from current git master
  - Backport another fix from current git master
  - Backport a couple of fixes from current git master



From rodd at clarkson.id.au  Tue Dec  9 09:57:01 2008
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 09 Dec 2008 20:57:01 +1100
Subject: Server SIG - work areas
In-Reply-To: <1228141690.3451.65.camel@beta>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta>
Message-ID: <1228816621.1673.6.camel@moose>

On Mon, 2008-12-01 at 16:28 +0200, Basil Mohamed Gohar wrote:

> Signed-up for the list.  This all sounds great for a start, Dan.  I'm
> sure it'll develop more over time, as long as we're flexible enough to
> allow for that.

Signed up too.

I will however preface that the single most important 'feature' I want
on a server is long term support.

I love Fedora, and on the desktop I'm more than happy to juggle to
constant updates and the re-installs that come every six months or so.

However, on the server, I don't want to be doing this.  I want to know
that the httpd server I set up will still be getting update 3, 4 or 5
years out.  As such I don't use fedora for servers currently.  (I
usually use CentOS).

However, making sure that fedora is doing what I need it to do on the
server is important because fedora is the basis for RHEL (is the basis
for CentOS).

R.
> 
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From pertusus at free.fr  Tue Dec  9 10:02:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Dec 2008 11:02:30 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081209104955.55a363b2.mschwendt@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
Message-ID: <20081209100229.GD3833@free.fr>

On Tue, Dec 09, 2008 at 10:49:55AM +0100, Michael Schwendt wrote:
> On Tue, 09 Dec 2008 04:55:33 +0100, Kevin wrote:
> 
> > I think we need to be more careful with certain types of security updates,
> > and better let them get some QA even if it means the fix gets delayed.
> 
> QA ... reminds me to ask once more:
> 
> Where can I learn more about the thing referred to as "Fedora QA"?
> Who is it? What do they do?

Unless I have missed something, currently there is no QA done. One
reason is that bodhi pushes already take one day, and adding some QA
would delay even more. Verifying duplicate provides would be, in my
opinio, the first thing to add.

More offline QA could be done, though. Currently I am not even sure that
never checking scripts are sent. There is the FTBFS stuff, however, and
broken dependencies are reported.

> Fedora has a serious problem with updates that are pushed out to "stable"
> directly. Originally we've had a guideline to use updates-testing for
> a few days.

Sometime it is better to push directly to stable, when the package is
already broken, when it is a security fix, or for packages with few
users.

--
Pat



From pertusus at free.fr  Tue Dec  9 10:04:03 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Dec 2008 11:04:03 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081209100229.GD3833@free.fr>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr>
Message-ID: <20081209100403.GE3833@free.fr>

On Tue, Dec 09, 2008 at 11:02:30AM +0100, Patrice Dumas wrote:
> 
> More offline QA could be done, though. Currently I am not even sure that
> never checking scripts are sent. There is the FTBFS stuff, however, and

I meant 'I am not even sure that n-ver checking scripts are sent'.

--
Pat



From kwade at redhat.com  Tue Dec  9 10:19:59 2008
From: kwade at redhat.com (Karsten Wade)
Date: Tue, 9 Dec 2008 02:19:59 -0800
Subject: Feature proposal: Community Translation Tool
In-Reply-To: <1227742714.2822.19.camel@choeger5.umpa.netz>
References: <1227742714.2822.19.camel@choeger5.umpa.netz>
Message-ID: <20081209101959.GG9280@calliope.phig.org>

On Thu, Nov 27, 2008 at 12:38:34AM +0100, Christoph H?ger wrote:
> 
> Those tools could be integrated in a way that users could poll on
> translations on a "yeah, that sounds good" basis if there already exists
> a translation. Also the client could be offered/configured based on the
> locale selected at install time.
> 
> Any ideas why that should not work / starting points to implement?

Make sure that the steps include having the user's contribution under
the CLA.  This might be as simple as a click-through agreement, but is
essential.

- Karsten
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/a14f9aaa/attachment.sig>

From sundaram at fedoraproject.org  Tue Dec  9 10:24:48 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Dec 2008 15:54:48 +0530
Subject: The looming Python 3(000) monster
In-Reply-To: <493DA9EE.2070108@gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com>	<493D68D8.2000308@gmail.com>	<200812082142.mB8LgHJb019504@laptop14.inf.utfsm.cl>
	<493DA9EE.2070108@gmail.com>
Message-ID: <493E4770.2000709@fedoraproject.org>

Les Mikesell wrote:

> 
> And yet, in all that time, I never had a problem continuing to run a 
> previously working C program even in the extremely rare cases where an 
> updated compiler wouldn't build a new copy.  Python doesn't work that way.

New major versions of GCC have almost always resulted in a few C 
programs within the distribution needing to be updated to work with it. 
You might not have to run it this much but any major distribution 
certainly would have. It is not a python specific problem though python 
does change more often than C does.

Rahul




From dan at danny.cz  Tue Dec  9 10:27:00 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 09 Dec 2008 11:27:00 +0100
Subject: nautilus depends on a lot of stuff via gvfs
Message-ID: <1228818420.3626.52.camel@eagle.danny.cz>

Hi,

I was trying to remove samba-winbind (plus the rest of samba, because I
don't need it and samba represents MBs of updates and tens of MB of used
space) from my F-10 machine and found out that it will remove nautilus
too.

Removing:
 samba-winbind                      i386         3.2.5-0.23.fc10            installed         7.9 M
Removing for dependencies:
 gnome-vfs2-smb                     i386         2.24.0-3.fc10              installed          28 k
 gvfs-smb                           i386         1.0.2-3.fc10               installed         255 k
 hal-cups-utils                     i386         0.6.17-4.fc10              installed         100 k
 libsmbclient                       i386         3.2.5-0.23.fc10            installed         3.8 M
 nautilus                           i386         2.24.1-3.fc10              installed          13 M
 samba-client                       i386         3.2.5-0.23.fc10            installed          27 M
 samba-common                       i386         3.2.5-0.23.fc10            installed          29 M
 system-config-printer              i386         1.0.9-1.fc10               installed         1.6 M
 system-config-printer-libs         i386         1.0.9-1.fc10               installed         2.8 M

The problem is that nautilus has hard dependencies on many (all?) gvfs
modules. Trying to remove libgphoto2 has similar effects.

So my proposal is to split nautilus into nautilus-core, that will
contains the content of the current nautilus package, and nautilus
"meta" package that will contains all the dependencies plus dependency
on nautilus-core. This solution will install all the deps as today, but
leave the option to remove the unnecessary packages afterwards.

Only 3 packages will be affected with this split
nautilus-devel
nautilus-python
seahorse-plugins
and they should be made to depend on nautilus-core instead of nautilus.

I will file a bug with the proposed change to nautilus spec file.


		Dan




From berrange at redhat.com  Tue Dec  9 10:33:36 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 9 Dec 2008 10:33:36 +0000
Subject: The looming Python 3(000) monster
In-Reply-To: <493E4770.2000709@fedoraproject.org>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<493C462B.4070607@gmail.com> <493D5DA3.7010408@gmail.com>
	<493D68D8.2000308@gmail.com>
	<200812082142.mB8LgHJb019504@laptop14.inf.utfsm.cl>
	<493DA9EE.2070108@gmail.com> <493E4770.2000709@fedoraproject.org>
Message-ID: <20081209103336.GB15102@redhat.com>

On Tue, Dec 09, 2008 at 03:54:48PM +0530, Rahul Sundaram wrote:
> Les Mikesell wrote:
> 
> >
> >And yet, in all that time, I never had a problem continuing to run a 
> >previously working C program even in the extremely rare cases where an 
> >updated compiler wouldn't build a new copy.  Python doesn't work that way.
> 
> New major versions of GCC have almost always resulted in a few C 
> programs within the distribution needing to be updated to work with it. 
> You might not have to run it this much but any major distribution 
> certainly would have. It is not a python specific problem though python 
> does change more often than C does.

This is not a comparable scenario. The new GCC releases are identifying
bugs which always existed in your code, not changing the language. As
such once you fix the bugs, your code continues to work on old & new
GCC just fine. The equivalent scenario would be a new GLibC release
which changed a bunch of APIs you were using, making it impossible to
write code which works on both old & new at new.  Even then, the linker
provides version scripts which allow you to provide multiple definitions
of the same ELF symbol so you can maintain ABI compatability across old
and new version even if you changed API contracts.

Daniel
-- 
|: Red Hat, Engineering, London   -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 dan at danny.cz  Tue Dec  9 10:41:27 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 09 Dec 2008 11:41:27 +0100
Subject: Server SIG - work areas
In-Reply-To: <1228816621.1673.6.camel@moose>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta>  <1228816621.1673.6.camel@moose>
Message-ID: <1228819287.3626.62.camel@eagle.danny.cz>


Rodd Clarkson p??e v ?t 09. 12. 2008 v 20:57 +1100:
> On Mon, 2008-12-01 at 16:28 +0200, Basil Mohamed Gohar wrote:
> 
> > Signed-up for the list.  This all sounds great for a start, Dan.  I'm
> > sure it'll develop more over time, as long as we're flexible enough to
> > allow for that.
> 
> Signed up too.
> 
> I will however preface that the single most important 'feature' I want
> on a server is long term support.
> 

See the FAQ - there will be no "long term support" for Fedora

> I love Fedora, and on the desktop I'm more than happy to juggle to
> constant updates and the re-installs that come every six months or so.
> 
> However, on the server, I don't want to be doing this.  I want to know
> that the httpd server I set up will still be getting update 3, 4 or 5
> years out.  As such I don't use fedora for servers currently.  (I
> usually use CentOS).
> 
> However, making sure that fedora is doing what I need it to do on the
> server is important because fedora is the basis for RHEL (is the basis
> for CentOS).

But there is one way, how to achieve similar goal - make EPEL more
complete. Because you probably know how is RHEL created - it is a subset
of one Fedora release. Then add the remaining packages via EPEL and you
have Fedora with long term support.


		Dan




From kwade at redhat.com  Tue Dec  9 10:42:29 2008
From: kwade at redhat.com (Karsten Wade)
Date: Tue, 9 Dec 2008 02:42:29 -0800
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1228128814.3451.40.camel@beta>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com> <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
	<1228128134.3451.36.camel@beta> <1228128814.3451.40.camel@beta>
Message-ID: <20081209104229.GH9280@calliope.phig.org>

On Mon, Dec 01, 2008 at 12:53:34PM +0200, Basil Mohamed Gohar wrote:
> 
> Should I present this idea to the docs project, pending the agreement of
> most, if not all, those involved in this discussion?  I'm mulling the
> idea of even heading it, if no one else is more appropriate for the
> task...

That is definitely the right attitude, thanks.  "Better man pages" was
on the list of Red Hat's various technical writing teams since
... 1999?  The problem is resources -- it is a huge task for a small
group of people to wade through.

As Rahul pointed out, mitwi is an example of working to make man pages
accessible from a documentation site without manual intervention.  It
came from a goal of putting a simpler (wiki) interface in front of man
pages, with automagic conversion behind the scenes.

But even with the easiest tools we can muster, it is still a giant cat
herding effort to get packagers behind man page improvements.  What is
needed is that can-do attitude, followed by the actual doing, of
course. :)

- Karsten
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/c0d175e5/attachment.sig>

From pertusus at free.fr  Tue Dec  9 10:48:58 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Dec 2008 11:48:58 +0100
Subject: Server SIG - work areas
In-Reply-To: <1228819287.3626.62.camel@eagle.danny.cz>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
Message-ID: <20081209104858.GG3833@free.fr>

On Tue, Dec 09, 2008 at 11:41:27AM +0100, Dan Hor?k wrote:
> 
> But there is one way, how to achieve similar goal - make EPEL more
> complete. Because you probably know how is RHEL created - it is a subset
> of one Fedora release. Then add the remaining packages via EPEL and you
> have Fedora with long term support.

It is not the same. Fedora with LTS would be going from bleeding edge to
stability, RHEL+EPEL is always stability. And the release schedules are
very different, there are meny times when the next RHEL release is too
distant in the future, so some intermediate fedora release being LTS
would be different from RHEL+EPEL in this perspective too.

--
Pat



From opensource at till.name  Tue Dec  9 10:48:51 2008
From: opensource at till.name (Till Maas)
Date: Tue, 09 Dec 2008 11:48:51 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I am
 NOT Fedora
Message-ID: <200812091149.02184.opensource@till.name>

On Tue December 9 2008, Michael Schwendt wrote:

> I'm also surprised to find discrepancies between Rawhide (just 1-2 weeks
> before F10 release) and F10 final. Such as a non-working PulseAudio.
> After every reboot, the mixer settings get messed up. Sometimes the
> PulseAudio mixer is not available at all. And worse, simple playback of
> audio files in Rhythmbox and Audacious (or even previews on the desktop)
> suffer from interruptions.

This is something that hit me, too. While F10 was not released, I booted a 
live medium several times and sound worked there better than with F8 (A 
soundcard I considered dead started working again), but then after I install 
F10 Gold, I experience the same problems as you. 

Regards,
Till


-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/68805907/attachment.sig>

From kwade at redhat.com  Tue Dec  9 11:06:06 2008
From: kwade at redhat.com (Karsten Wade)
Date: Tue, 9 Dec 2008 03:06:06 -0800
Subject: FAmSCo elections only open to ambassadors?
In-Reply-To: <493D4194.1070804@hhs.nl>
References: <493D4194.1070804@hhs.nl>
Message-ID: <20081209110606.GI9280@calliope.phig.org>

On Mon, Dec 08, 2008 at 04:47:32PM +0100, Hans de Goede wrote:
> Hi All,
>
> Today I went to do my duty and vote, and much to my surprise I could not 
> vote for the FAmSCo election. Now that is probably something which has 
> been discussed before and I just missed, but still let me express my 
> surprise about this.
>
> How is it that anyone which is member of any group in Fedora including  
> translators and ambassadors get to vote for FesCo, which is effectively 
> the developers steering committee now a days. Yet only ambassadors get to 
> vote who gets on FAmSCo ??

Actually, FESCo has a *much* wider mandate:

* Sets the entire technical direction for the distro
* Oversees all technical SIGs
* Runs the feature process
* And much more

In fact, it _used_ to be that only a small group of people had the
rights to vote for FESCo.  Some of us argued successfully against that
because of the wide influence that FESCo has over all contributors.
The FESCo election was then opened to anyone with fedora_cla *and*
membership in one other group, iirc.

This overarching influence and control for the entire project is
simply not the case with the small sub-projects -- L10n, Docs,
Marketing, Ambassadors, and so on.

I don't see any real problem with the smaller groups having that level
of autonomy to decide solely within their group who their leaders are.

If you want to vote for that leadership, it is simply required that
you spend some time as a member of that group.  All of us who are not
"developers" are greatly, greatly affected by FESCo decisions.  The
smaller sub-project steering committees have no where near the affect
that FESCo has.

Should any smaller group's influence grow to be enough that it does
affect everyone, it would make sense to widen the voting to include
other groups.  For example, considering how much hassle we in Docs
cause L10n each release, I would be in favor of including translators
as voters in future Docs steering committee elections.  But I wouldn't
expect the reverse, for the same reasons as above.

- Karsten
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/1fba909d/attachment.sig>

From abu_hurayrah at hidayahonline.org  Tue Dec  9 11:20:18 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Tue, 09 Dec 2008 13:20:18 +0200
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081209104229.GH9280@calliope.phig.org>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com> <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
	<1228128134.3451.36.camel@beta> <1228128814.3451.40.camel@beta>
	<20081209104229.GH9280@calliope.phig.org>
Message-ID: <1228821618.4861.83.camel@beta>

On Tue, 2008-12-09 at 02:42 -0800, Karsten Wade wrote:
> On Mon, Dec 01, 2008 at 12:53:34PM +0200, Basil Mohamed Gohar wrote:
> > 
> > Should I present this idea to the docs project, pending the agreement of
> > most, if not all, those involved in this discussion?  I'm mulling the
> > idea of even heading it, if no one else is more appropriate for the
> > task...
> 
> That is definitely the right attitude, thanks.  "Better man pages" was
> on the list of Red Hat's various technical writing teams since
> ... 1999?  The problem is resources -- it is a huge task for a small
> group of people to wade through.
> 
> As Rahul pointed out, mitwi is an example of working to make man pages
> accessible from a documentation site without manual intervention.  It
> came from a goal of putting a simpler (wiki) interface in front of man
> pages, with automagic conversion behind the scenes.
> 
> But even with the easiest tools we can muster, it is still a giant cat
> herding effort to get packagers behind man page improvements.  What is
> needed is that can-do attitude, followed by the actual doing, of
> course. :)
> 
> - Karsten
Karsten,

So, do I need to take any formal steps to move forward?

This would be my most significant involvement with Fedora if I do take
it up to some degree.   Not being a significant developer (aside from
PHP), this is about the best way I can contribute back to the project
right now.

My idea is that at least I can kick-off a sustainable system that could
work to fill-in the missing man pages and establish a culture within the
already existing upstream-positive culture of Fedora to contribute back
man pages as well as general patches & code.  Having a wiki-like or
other system in place to work on man pages would be a great way for
upstream to verify & even contribute back to their own pages (think
something like Launchpad, but focused just on documentation).

Okay, so back to my main point: is there an official step I have to take
to start an initiative like this?



From mschwendt at gmail.com  Tue Dec  9 11:25:54 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 9 Dec 2008 12:25:54 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <20081209100229.GD3833@free.fr>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr>
Message-ID: <20081209122554.c177370e.mschwendt@gmail.com>

On Tue, 9 Dec 2008 11:02:30 +0100, Patrice wrote:

> > Fedora has a serious problem with updates that are pushed out to "stable"
> > directly. Originally we've had a guideline to use updates-testing for
> > a few days.
> 
> Sometime it is better to push directly to stable, when the package is
> already broken, when it is a security fix, 

... and if you find out that dependencies are broken because of a rushed
update, you need to wait a day before the problem can be corrected with
the next time-consuming push. It's better to prevent issues like that. We
currently can check remote repositories. Contrary to the FUD spread by
some people, plain repoclosure doesn't run for hours. For stuff released
into the "stable" repo it would be too late, however.

> or for packages with few users.

... which have even less reason to be pushed to "stable" quickly rather
than spending a few days in updates-testing first. :) Even such packages
can cause chaos and disturb SONAME Provides, for example. Recently, we've
had a case where an update accidentally obsoleted packages in a different
namespace. Or watch this one: https://bugzilla.redhat.com/473182

I know you'd like to be able to push to repositories immediately
without any release management, but for Fedora's users that would be
one step closer to the infamous dumping ground of packages.



From belegdol at gmail.com  Tue Dec  9 11:29:54 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 09 Dec 2008 12:29:54 +0100
Subject: arial narrow is broken since Fedora 8
Message-ID: <493E56B2.7060101@gmail.com>

Hi,

first of all I'd like to apologise for cross-posting this to this list,
but the bugs I filed at rhbz [1] and freedesktop bugzilla [2] did not
seem to attract enough attention.
The problem is as follows: IIRC in Fedora 8 timeframe it was decided to
allow more font substyles than the 4 basic bold, italic, bold italic and
normal. As a fallout of this, Arial Narrow font started to be treated as
a substyle of Arial. Nice idea altogether, but the problem is that now
applications (with the notable exceptions of firefox and KDE's
systemsettings) do not seem to be able to distinguish between arial and
arial narrow. KDE's font selector displays four styles, gtk font
selector displays 8 styles, with each of the basic ones being displayed
twice (no difference whichever of the two is selected), openoffice does
not work either. All in all, all documents which were using arial narrow
now refuse to render properly. Is there anything we could do to work
around this issue? Some sort of quirk?

Regards,
Julian

[1] https://bugzilla.redhat.com/show_bug.cgi?id=466678
[2] https://bugs.freedesktop.org/show_bug.cgi?id=13416



From sven at lank.es  Tue Dec  9 12:03:00 2008
From: sven at lank.es (Sven Lankes)
Date: Tue, 9 Dec 2008 13:03:00 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081209100229.GD3833@free.fr>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr>
Message-ID: <20081209120300.GJ14496@killefiz>

On Tue, Dec 09, 2008 at 11:02:30AM +0100, Patrice Dumas wrote:

> Sometime it is better to push directly to stable, when the package is
> already broken, when it is a security fix, or for packages with few
> users.

Which then leads to the question, why a broken package was pushed to
stable in the first place.

We should try to get the bohdi-karma-mechanism more popular. I have
updates-testing activated on both my F10 machines but I haven't set a
single karma-point yet. The reason is that it's not easy after a day or
two to review that last updates and send a +1 on them if I have used
them and they didn't break.

Maybe a small gui tool showing the latest testing-updates and allowing
to send (positive) bohdi-karma would encourage more people to actually
send the karma which in turn would encourage developers to use
updates-testing more.

-- 
sven === jabber/xmpp: sven at lankes.net



From mschmidt at redhat.com  Tue Dec  9 12:04:09 2008
From: mschmidt at redhat.com (Michal Schmidt)
Date: Tue, 9 Dec 2008 13:04:09 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <20081209130409.283584eb@brian.englab.brq.redhat.com>

On Tue, 9 Dec 2008 01:25:40 +0100
Robert Scheck <robert at fedoraproject.org> wrote:

> [PackageKit] kills my Firefox nicely during package updating,
> well-well done.

Running instances of Firefox always break when the Firefox package is
being updated. It does not matter what you use for the update (rpm,
yum, PK). This is not PackageKit's fault.

Michal



From nicolas.mailhot at laposte.net  Tue Dec  9 12:25:33 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 9 Dec 2008 13:25:33 +0100 (CET)
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493E56B2.7060101@gmail.com>
References: <493E56B2.7060101@gmail.com>
Message-ID: <b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>



Le Mar 9 d?cembre 2008 12:29, Julian Sikorski a ?crit :
> IIRC in Fedora 8 timeframe it was decided
> to
> allow more font substyles than the 4 basic bold, italic, bold italic
> and normal

This was not decided in Fedora 8 this is how modern TrueType/OpenType
fonts work. Fonts have not been limited to 4 faces for a long time, we
at most decided to stop pretending it was the case.

(Here is a MS paper on the subject in case you still think it is a
Fedora-ism
http://blogs.msdn.com/text/archive/2007/04/23/wpf-font-selection-model.aspx
)

> All in all, all documents which were using arial
> narrow
> now refuse to render properly. Is there anything we could do to work
> around this issue? Some sort of quirk?

Workarounds are not sustainable given the problem is generic not
limited to this font and people working on workarounds do not spend
time working on the actual long-term fix.

Please make the necessary noise in upstream bug trackers to make them
fix their handling of modern fonts. You have at least some references
to existing open bugs here
http://fedoraproject.org/wiki/Known_fonts_and_text_bugs

Fixing font selection is the first item in
http://fedoraproject.org/wiki/Desktop/Whiteboards/BetterFonts

I have no idea on the resources the Desktop Team intends to spend on
this whiteboard, or if it is even one of their priorities. But anyway,
fixing stuff QT or KDE-side should be done by QT or KDE people.

Best regards,

-- 
Nicolas Mailhot



From mspevack at redhat.com  Tue Dec  9 12:27:30 2008
From: mspevack at redhat.com (Max Spevack)
Date: Tue, 9 Dec 2008 13:27:30 +0100 (CET)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <alpine.LFD.2.00.0812091306550.3183@localhost.localdomain>

On Tue, 9 Dec 2008, Robert Scheck wrote:

> 128 Euro per year is IMHO too much for the current level of what seems 
> to happen with the money. And for that money I could support the Free 
> Software Foundation Europe (FSFE) with multiple membership fees per 
> year. And sorry, just one cool bathrobe isn't a good reason for 
> spending 128 Euro away per year. Without enough transparency and 
> communication, it's like throwing the money out of the window of my 
> room.

As I mentioned in another email (just to Ambassadors list), there are a 
couple of points I'd like to make:

(1) Since I started as the FPL in February 2006, I've tracked the money 
spent on Fedora publicly on the Fedora wiki not because I needed to or 
because someone told me to, but because I believed it was the right 
thing to do.  That's almost 3 full years of total financial 
transparency.  The money given to Fedora EMEA e.V. is a small piece of 
that budget, and it is repoted along with everything else.  I can't 
think of another Linux distro that is as transparent with its finances 
as we are.

(2) I never understood why the membership fees are anything other than 
nominal.  The purpose of a legal entity like Fedora EMEA e.V. is *not* 
to collect money from Fedora contributors, but to serve as a legal 
entity that can hold onto resources from Red Hat (freeing us from having 
to spend resources in a 3-month window or watching them vanish) as well 
as to hold resources from other organizations that want to contribute 
directly to Fedora without having to contribute to Red Hat.

> But nobody really follows, is having a look to these issues and 
> problems or even takes care of it...why? I think, this should be the 
> job of the Fedora Project leader, shouldn't it? I don't want to blame 
> neither Paul nor Max in this e-mail, I think everybody of us needs to 
> be more sensitive to issues around the Fedora Project and needs to 
> take more care before developing or forking something.

There has long been a difficult balance between the overall day to day 
leadership of the Fedora Project, and the manner in which specific 
technical decisions are made.  Many of the things you mentioned in your 
initial email fall into the latter category.

I won't speak for Paul, but for me, I always knew that it would be 
inappropriate for me to try to micromanage individual technical pieces 
of Fedora, because that wasn't my expertise.  So I never tried to, and 
instead tried to make it clear that FESCO and other engineering leaders 
within Fedora take that on.

Looking back, I think that things have ended up going well enough, but I 
definitely could have done a better job in that area of my old FPL job.

Recognizing this weakness was part of what led me to advocate for the 
creation of a Fedora Engineering Manager position (which Spot holds) at 
the same time that we brought in Paul to take over as the Fedora Project 
Leader.

If the FPL is Fedora's "CEO" then the FEM is Fedora's "CTO".  I also 
don't want to speak for Spot, but I think that it would be very 
appropriate for him to give a talk at FUDCon that represents his view of 
what Fedora's roadmap and critical path are from an engineering 
perspective in 2009.  Maybe that should be the keynote, actually, since 
Paul gave the "Fedora State of the Union" in Boston back in June.

I could write a few more paragraphs, but I think I've said enough for 
one email.

--Max



From stickster at gmail.com  Tue Dec  9 12:31:01 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Tue, 9 Dec 2008 07:31:01 -0500
Subject: [Ambassadors] What Fedora makes sucking for me - or why I am
	NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <20081209123101.GA6150@localhost.localdomain>

On Tue, Dec 09, 2008 at 01:25:40AM +0100, Robert Scheck wrote:
> Well, we had the intrusion into the servers of the Fedora Project. That is
> now nearly 4 months ago. I remember to the words of our dear Fedora Project
> leader, who made us believing with the sentence "We will continue to keep
> the Fedora community notified of any updates." - but nothing happend after
> that. We all are still waiting for final report about the intrusion into
> the servers of the Fedora Project! Yes, we can: Open Source, but unluckily
> no Open Communication! Even the communication during the intrusion time was
> worse, e-mails to the Infrastructure team and to our Fedora Project leader
> got not really answered (or just when reasking and bugging) when asking for
> the issue and details even when it was mostly clear, that we're no longer
> really men about ourself - the intrusion.

The communications I've made thus far about the intrusion are the sum
total of what we've been able to report with certainty and as fact.
This is a rather complex situation made worse because the intrusion
affected both Fedora and our sponsor, Red Hat.  As I've indicated in
my most recent statement about the intrusion, it is my intention to
produce a detailed report as soon as we can.  I continue to be in
contact with the security and executive teams within Red Hat about
this matter on a regular basis.

I'm sorry these communications can't fall more in line with your
expectations, but rest assured the matter has not been, and will not
be, forgotten.  Mike McGrath and I plan to sit down at FUDCon to talk
about our response and communications plan for future incidents.  If,
heaven forbid, we ever suffer another intrusion, we want the community
to know in advance what to expect in the way of announcements.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/9e8ba59b/attachment.sig>

From trond.danielsen at gmail.com  Tue Dec  9 12:42:34 2008
From: trond.danielsen at gmail.com (Trond Danielsen)
Date: Tue, 9 Dec 2008 13:42:34 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081127175309.GI20204@inocybe.teonanacatl.org>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
	<20081127162328.GA8714@amd.home.annexia.org>
	<409676c70811270912q21f099e1p36ba2a6b5bb6e6d1@mail.gmail.com>
	<20081127175309.GI20204@inocybe.teonanacatl.org>
Message-ID: <409676c70812090442x237476a5ped3db5cba1ef41cd@mail.gmail.com>

2008/11/27 Todd Zullinger <tmz at pobox.com>:
> Trond Danielsen wrote:
>> Last time I checked both man and info pages are available though the
>> gnome yelp browser. That already provide a convenient and searchable
>> interface for both experienced and inexperienced users.
>
> Check again. :)
>
> This seems to be broken on F10 at least, and possibly F9 as well -- it
> has been a while since I checked on F9.  Mat?j filed this bug earlier
> today: https://bugzilla.redhat.com/show_bug.cgi?id=473257

That is only a problem if you try to launch the yelp browser from the
command launcher. If you start it from the command line or by clicking
on the system menu browsing man pages work just fine.

However, the point I was trying to make is that a unified interface
that provide access to both info pages, man pages and gnome help files
(XML).

-- 
Trond Danielsen



From dan at danny.cz  Tue Dec  9 12:51:47 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 09 Dec 2008 13:51:47 +0100
Subject: Server SIG - work areas
In-Reply-To: <20081209104858.GG3833@free.fr>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
	<20081209104858.GG3833@free.fr>
Message-ID: <1228827107.3626.73.camel@eagle.danny.cz>


Patrice Dumas p??e v ?t 09. 12. 2008 v 11:48 +0100:
> On Tue, Dec 09, 2008 at 11:41:27AM +0100, Dan Hor?k wrote:
> > 
> > But there is one way, how to achieve similar goal - make EPEL more
> > complete. Because you probably know how is RHEL created - it is a subset
> > of one Fedora release. Then add the remaining packages via EPEL and you
> > have Fedora with long term support.
> 
> It is not the same. Fedora with LTS would be going from bleeding edge to
> stability, RHEL+EPEL is always stability. And the release schedules are
> very different, there are meny times when the next RHEL release is too
> distant in the future, so some intermediate fedora release being LTS
> would be different from RHEL+EPEL in this perspective too.

Yes, it is not the same. And the delay between the Fedora release and
corresponding RHEL release is also important, but it is the best you can
get with the current resources.


		Dan




From sgallagh at redhat.com  Tue Dec  9 12:53:09 2008
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Tue, 09 Dec 2008 07:53:09 -0500
Subject: Seahorse is orphaned?
In-Reply-To: <1228798497.3863.4.camel@localhost.localdomain>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>	<1228141066.3391.6.camel@localhost.localdomain>	<493D24D1.6050202@redhat.com>	<1228751408.3539.7.camel@localhost.localdomain>	<604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>
	<1228798497.3863.4.camel@localhost.localdomain>
Message-ID: <493E6A35.1080308@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Keating wrote:
> On Mon, 2008-12-08 at 13:23 -0900, Jeff Spaleta wrote:
>> Assuming seahorse is not installed on the system can you describe how
>> you expect typical desktop users who need the functionality that
>> seahorse provides to find it and install it without knowing the
>> package name before hand? A screencast of you pretending to be a user
>> installing searching for and installing seahorse would be interesting
>> to watch.
> 
> If they searched for keys or encryption keys or password keys or
> anything else in the description or summary they'd find the package,
> regardless of it's name.  How does one find say liferea to read RSS
> feeds?
> 
> 

FWIW, I only discovered both Seahorse and Liferea (back in F9) because
someone recommended them to me.

Performing a 'yum search encryption' yields 52 replies, 'yum search
keys' yields 80 replies, and 'yum search keyring' yields 24 replies;
none of which are seahorse. In the first two searches, the
signal-to-noise ratio is just too high, and in the last search (the most
useful one), seahorse doesn't show up.

Similarly, 'yum search rss' returns 39 results, and liferea doesn't
necessarily stand out (though it's a bit more obvious than seahorse).

- --

- --------------------
Stephen Gallagher
RHCE 804006346421761
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk+ajUACgkQeiVVYja6o6OfLwCdESjLwcZaDcE/hBY5S2d3J2U6
/lUAn2yk6cp+0ercDXhypT8lHkgspWkR
=BbUf
-----END PGP SIGNATURE-----



From fedora at matbooth.co.uk  Tue Dec  9 13:00:05 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 9 Dec 2008 13:00:05 +0000
Subject: Server SIG - work areas
In-Reply-To: <20081209104858.GG3833@free.fr>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
	<20081209104858.GG3833@free.fr>
Message-ID: <9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>

On Tue, Dec 9, 2008 at 10:48 AM, Patrice Dumas <pertusus at free.fr> wrote:
> On Tue, Dec 09, 2008 at 11:41:27AM +0100, Dan Hor?k wrote:
>>
>> But there is one way, how to achieve similar goal - make EPEL more
>> complete. Because you probably know how is RHEL created - it is a subset
>> of one Fedora release. Then add the remaining packages via EPEL and you
>> have Fedora with long term support.
>
> It is not the same. Fedora with LTS would be going from bleeding edge to
> stability, RHEL+EPEL is always stability.
>

I don't think I understand this statement. Actually creating each RHEL
release from a release of Fedora isn't going from bleeding edge to
stability?



-- 
Mat Booth
www.matbooth.co.uk



From fedora at matbooth.co.uk  Tue Dec  9 13:02:16 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 9 Dec 2008 13:02:16 +0000
Subject: Server SIG - work areas
In-Reply-To: <9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
	<20081209104858.GG3833@free.fr>
	<9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>
Message-ID: <9497e9990812090502v40665382sf157e54783286033@mail.gmail.com>

On Tue, Dec 9, 2008 at 1:00 PM, Mat Booth <fedora at matbooth.co.uk> wrote:
> On Tue, Dec 9, 2008 at 10:48 AM, Patrice Dumas <pertusus at free.fr> wrote:
>> On Tue, Dec 09, 2008 at 11:41:27AM +0100, Dan Hor?k wrote:
>>>
>>> But there is one way, how to achieve similar goal - make EPEL more
>>> complete. Because you probably know how is RHEL created - it is a subset
>>> of one Fedora release. Then add the remaining packages via EPEL and you
>>> have Fedora with long term support.
>>
>> It is not the same. Fedora with LTS would be going from bleeding edge to
>> stability, RHEL+EPEL is always stability.
>>
>
> I don't think I understand this statement. Actually creating each RHEL
> release from a release of Fedora isn't going from bleeding edge to
> stability?
>

Sorry for replying to myself, but another thought occurred after I hit
send: Maybe I don't understand *why* you need bleeding edge if what
you want is stability...


-- 
Mat Booth
www.matbooth.co.uk



From christoph.wickert at googlemail.com  Tue Dec  9 13:02:34 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 09 Dec 2008 14:02:34 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <alpine.LFD.2.00.0812091306550.3183@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<alpine.LFD.2.00.0812091306550.3183@localhost.localdomain>
Message-ID: <1228827754.4444.46.camel@wicktop.localdomain>

Am Dienstag, den 09.12.2008, 13:27 +0100 schrieb Max Spevack:

> (2) I never understood why the membership fees are anything other than 
> nominal.  The purpose of a legal entity like Fedora EMEA e.V. is *not* 
> to collect money from Fedora contributors, but to serve as a legal 
> entity that can hold onto resources from Red Hat [...]

+ 1-1-11

That's exactly what I said half a year ago [1], but I felt I got flamed
for this opinion by some people (at least by one person) from the NPO.

Regards,
Christoph


[1] in the "EMEA Membership Questione (was: Einladung / Invitation)"
thread started on May 8th



From johannbg at hi.is  Tue Dec  9 13:06:58 2008
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Tue, 09 Dec 2008 13:06:58 +0000
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <20081209120300.GJ14496@killefiz>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<ghkq7m$46p$1@ger.gmane.org>	<20081209104955.55a363b2.mschwendt@gmail.com>	<20081209100229.GD3833@free.fr>
	<20081209120300.GJ14496@killefiz>
Message-ID: <493E6D72.9020605@hi.is>

Sven Lankes wrote:
> On Tue, Dec 09, 2008 at 11:02:30AM +0100, Patrice Dumas wrote:
>
>   
>> Sometime it is better to push directly to stable, when the package is
>> already broken, when it is a security fix, or for packages with few
>> users.
>>     
>
> Which then leads to the question, why a broken package was pushed to
> stable in the first place.
>
> We should try to get the bohdi-karma-mechanism more popular. I have
> updates-testing activated on both my F10 machines but I haven't set a
> single karma-point yet. The reason is that it's not easy after a day or
> two to review that last updates and send a +1 on them if I have used
> them and they didn't break.
>
> Maybe a small gui tool showing the latest testing-updates and allowing
> to send (positive) bohdi-karma would encourage more people to actually
> send the karma which in turn would encourage developers to use
> updates-testing more.
>
>   
First of all this falls on to testers...

Developers should spend their time developing.
Testers should spend their time testing that's what we are here for.

And please developers redirect all QA/Test related mail to that 
"accidentally" falls on to this list
to the test-list where testers and QA resides ( Developers should be 
subscribed to that list to ).

Secondly a small bodhi voting gui does not cut it.
Testers need know what to test to ensure that the component behaves as 
it should
so you need an application that...

A)  Fetches the test case  for a component and
B)  Has the ability to log in and vote in bodhi.

I suppose I can add that to my TODO list since i'm going to developer
( and hopefully others as well ) the "Fedora-Bug-Reporting" application
( Would not be surprised if it ends up being a full blown 
fedora-test-suite. ) 
Let's see how easy  to learn python really is :)

This all hangs on the "QA namespace"  where each component will be listed
with info how to test what to report etc.. More on this will be posted 
to this list
( and ofcourse the test-list ) when we have working examples on the wiki.

There is work on the way to address several QA issues.
( Mostly in the implementation discussion stage at this point )

Expected results 2+ releases from now.

For those that did not know this is our wiki page..
http://fedoraproject.org/wiki/QA

Will Woods ( wwoods ) is the "Commander in chief"
of QA and the Bug Hunters squad ( we should form a band )

The fedora-test list is "our" mailing list.

We hang on #fedora-qa

We usually hold meetings 1600 UTC on Wednesdays .

Previous meetings info can be found here

http://fedoraproject.org/wiki/QA/Meetings
and here
http://wwoods.fedorapeople.org/fedora-qa/

JBG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/5a253598/attachment.vcf>

From belegdol at gmail.com  Tue Dec  9 13:15:22 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 09 Dec 2008 14:15:22 +0100
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>
References: <493E56B2.7060101@gmail.com>
	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>
Message-ID: <493E6F6A.3060806@gmail.com>

Nicolas Mailhot pisze:
> 
> Le Mar 9 d?cembre 2008 12:29, Julian Sikorski a ?crit :
>> IIRC in Fedora 8 timeframe it was decided
>> to
>> allow more font substyles than the 4 basic bold, italic, bold italic
>> and normal
> 
> This was not decided in Fedora 8 this is how modern TrueType/OpenType
> fonts work. Fonts have not been limited to 4 faces for a long time, we
> at most decided to stop pretending it was the case.
> 
> (Here is a MS paper on the subject in case you still think it is a
> Fedora-ism
> http://blogs.msdn.com/text/archive/2007/04/23/wpf-font-selection-model.aspx
> )
> 
>> All in all, all documents which were using arial
>> narrow
>> now refuse to render properly. Is there anything we could do to work
>> around this issue? Some sort of quirk?
> 
> Workarounds are not sustainable given the problem is generic not
> limited to this font and people working on workarounds do not spend
> time working on the actual long-term fix.
> 
> Please make the necessary noise in upstream bug trackers to make them
> fix their handling of modern fonts. You have at least some references
> to existing open bugs here
> http://fedoraproject.org/wiki/Known_fonts_and_text_bugs
> 
> Fixing font selection is the first item in
> http://fedoraproject.org/wiki/Desktop/Whiteboards/BetterFonts
> 
> I have no idea on the resources the Desktop Team intends to spend on
> this whiteboard, or if it is even one of their priorities. But anyway,
> fixing stuff QT or KDE-side should be done by QT or KDE people.
> 
> Best regards,
> 

I'm not claiming it's Fedora-ism, sorry if it sounded this way. I only
mean that in Fedora 7 arial narrow was displayed properly, and later it
ceased to be so.
I added a comment to freedesktop bug #18725, I'm not sure if it's the
right one. Please let me know if you have places more proper to report
this (or maybe what precisely could be the source of the problem).

Regards,
Julian



From stickster at gmail.com  Tue Dec  9 13:16:24 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Tue, 9 Dec 2008 08:16:24 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <alpine.LFD.2.00.0812091306550.3183@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<alpine.LFD.2.00.0812091306550.3183@localhost.localdomain>
Message-ID: <20081209131624.GB4580@localhost.localdomain>

On Tue, Dec 09, 2008 at 01:27:30PM +0100, Max Spevack wrote:
> On Tue, 9 Dec 2008, Robert Scheck wrote:
>
>> But nobody really follows, is having a look to these issues and  
>> problems or even takes care of it...why? I think, this should be the  
>> job of the Fedora Project leader, shouldn't it? I don't want to blame  
>> neither Paul nor Max in this e-mail, I think everybody of us needs to  
>> be more sensitive to issues around the Fedora Project and needs to  
>> take more care before developing or forking something.
>
> There has long been a difficult balance between the overall day to day  
> leadership of the Fedora Project, and the manner in which specific  
> technical decisions are made.  Many of the things you mentioned in your  
> initial email fall into the latter category.
>
> I won't speak for Paul, but for me, I always knew that it would be  
> inappropriate for me to try to micromanage individual technical pieces  
> of Fedora, because that wasn't my expertise.  So I never tried to, and  
> instead tried to make it clear that FESCO and other engineering leaders  
> within Fedora take that on.

For whatever it's worth, I've taken much the same position.  Having an
FPL who is an engineering micromanager would, I think, be an enormous
detriment to the project and would be a disincentive for our many
technically-minded contributors to solve problems in creative ways.

> Looking back, I think that things have ended up going well enough, but I  
> definitely could have done a better job in that area of my old FPL job.

I'm not sure that's the case, Max.  "More" is not the same as "better"
-- I'm absolutely confident you could have done *more* technical
management as the FPL, but that wouldn't have led to you doing a
better job in my opinion.

Engineers tend, by and large, to be heavily Type A personalities:
ego-driven, controlling, and detail-oriented.  (I'm not speaking about
Max or anyone in particular, just generalizing.)  All these traits are
very beneficial for problem solving and creating technical
advancements.  But in a manager they can be a heavy albatross, because
the same people you're managing react poorly to those very behaviors!

To me, creating an environment where people can solve these problems,
and solving them oneself, are very different goals.

> Recognizing this weakness was part of what led me to advocate for the  
> creation of a Fedora Engineering Manager position (which Spot holds) at  
> the same time that we brought in Paul to take over as the Fedora Project  
> Leader.
>
> If the FPL is Fedora's "CEO" then the FEM is Fedora's "CTO".  I also  
> don't want to speak for Spot, but I think that it would be very  
> appropriate for him to give a talk at FUDCon that represents his view of  
> what Fedora's roadmap and critical path are from an engineering  
> perspective in 2009.  Maybe that should be the keynote, actually, since  
> Paul gave the "Fedora State of the Union" in Boston back in June.

Indeed, I've been thinking a lot lately about using some time at
FUDCon for a Fedora leadership summit, so Spot and I, in collaboration
with Fedora Program Manager John Poelstra (the third side of the
managerial triangle in Fedora, if you will), can better articulate a
vision and roadmap for Fedora 12 and beyond.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/96929304/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Dec  9 13:25:59 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 9 Dec 2008 14:25:59 +0100 (CET)
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493E6F6A.3060806@gmail.com>
References: <493E56B2.7060101@gmail.com>
	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>
	<493E6F6A.3060806@gmail.com>
Message-ID: <db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>



Le Mar 9 d?cembre 2008 14:15, Julian Sikorski a ?crit :

> I added a comment to freedesktop bug #18725, I'm not sure if it's the
> right one.

It's not the right one, and again please spend your energy lobbying
for a long term-fix in *every* upstream bugzilla instead of muddying
waters by asking to a return to the good old days which won't happen
as the technical context changed.

I know it's more work for you.

Life sucks.

-- 
Nicolas Mailhot



From ivazqueznet at gmail.com  Tue Dec  9 13:32:09 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 09 Dec 2008 08:32:09 -0500
Subject: New project, for fun and excitement: Offtrac!
In-Reply-To: <c30d5faa91f9fff4d65ce6a3fb3eae50.squirrel@arekh.dyndns.org>
References: <1228803312.3863.20.camel@localhost.localdomain>
	<1228804037.3863.24.camel@localhost.localdomain>
	<1228804556.15234.1.camel@arekh.okg>
	<1228807317.15367.85.camel@ignacio.lan>
	<c30d5faa91f9fff4d65ce6a3fb3eae50.squirrel@arekh.dyndns.org>
Message-ID: <1228829530.15367.95.camel@ignacio.lan>

On Tue, 2008-12-09 at 09:33 +0100, Nicolas Mailhot wrote:
> 
> Le Mar 9 d?cembre 2008 08:21, Ignacio Vazquez-Abrams a ?crit :
> 
> > I'm really curious to hear why you think activating XML-RPC support in
> > Trac suddenly turns it into Bugzilla, other than "they both have
> > XML-RPC".
> 
> It was more "if we now devote resources enhancing track I'm going to
> request all the missing features that make my life miserable with it,
> which will probably turn it into another bugzilla"

Ah, okay. That I understand ;)

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/21338eca/attachment.sig>

From pertusus at free.fr  Tue Dec  9 13:57:25 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Dec 2008 14:57:25 +0100
Subject: Server SIG - work areas
In-Reply-To: <9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
	<20081209104858.GG3833@free.fr>
	<9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>
Message-ID: <20081209135725.GC2594@free.fr>

On Tue, Dec 09, 2008 at 01:00:05PM +0000, Mat Booth wrote:
> 
> I don't think I understand this statement. Actually creating each RHEL
> release from a release of Fedora isn't going from bleeding edge to
> stability?

The creation of RHEL from fedora is going from bleeding edge to
stability, but RHEL is always stable. And following that move can only
be done for one fedora release, and not easily since RHEL in fact uses
more than one release (this was illustrated a lot on previous threads)
and then the move is not really public, and therefore not easy to follow.

That being said, I agree that for the fedora release that becomes more
or less RHEL there is much less relevance of a fedora LTS.

--
Pat



From belegdol at gmail.com  Tue Dec  9 14:02:39 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 09 Dec 2008 15:02:39 +0100
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>
	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>
Message-ID: <493E7A7F.8010601@gmail.com>

Nicolas Mailhot pisze:
> 
> Le Mar 9 d?cembre 2008 14:15, Julian Sikorski a ?crit :
> 
>> I added a comment to freedesktop bug #18725, I'm not sure if it's the
>> right one.
> 
> It's not the right one, and again please spend your energy lobbying
> for a long term-fix in *every* upstream bugzilla instead of muddying
> waters by asking to a return to the good old days which won't happen
> as the technical context changed.
> 
> I know it's more work for you.
> 
> Life sucks.
> 
Which is the right one then? I think openoffice issue 79878 could be a
good choice, but I'm not sure about freedesktop one. I'm not that
interested in others, since my document work is mainly done in oo.o.
Besides, I guess that fontconfig needs to work properly before anything
else will, right?

Regards,
Julian



From sundaram at fedoraproject.org  Tue Dec  9 14:04:40 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Dec 2008 19:34:40 +0530
Subject: Seahorse is orphaned?
In-Reply-To: <493E6A35.1080308@redhat.com>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>	<1228141066.3391.6.camel@localhost.localdomain>	<493D24D1.6050202@redhat.com>	<1228751408.3539.7.camel@localhost.localdomain>	<604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>	<1228798497.3863.4.camel@localhost.localdomain>
	<493E6A35.1080308@redhat.com>
Message-ID: <493E7AF8.8030303@fedoraproject.org>

Stephen Gallagher wrote:

> Performing a 'yum search encryption' yields 52 replies, 'yum search
> keys' yields 80 replies, and 'yum search keyring' yields 24 replies;
> none of which are seahorse. In the first two searches, the
> signal-to-noise ratio is just too high, and in the last search (the most
> useful one), seahorse doesn't show up.

"keyring" is probably not that term many end users would use though. A 
bug report to add that to the summary might be appropriate neverthless.

Rahul



From pertusus at free.fr  Tue Dec  9 14:12:39 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Dec 2008 15:12:39 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081209122554.c177370e.mschwendt@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr>
	<20081209122554.c177370e.mschwendt@gmail.com>
Message-ID: <20081209141239.GD2594@free.fr>

On Tue, Dec 09, 2008 at 12:25:54PM +0100, Michael Schwendt wrote:
> On Tue, 9 Dec 2008 11:02:30 +0100, Patrice wrote:
> 
> > Sometime it is better to push directly to stable, when the package is
> > already broken, when it is a security fix, 
> 
> ... and if you find out that dependencies are broken because of a rushed
> update, you need to wait a day before the problem can be corrected with
> the next time-consuming push. It's better to prevent issues like that. We
> currently can check remote repositories. Contrary to the FUD spread by
> some people, plain repoclosure doesn't run for hours. For stuff released
> into the "stable" repo it would be too late, however.

I agree, I think that some QA should already be done even if pushes are
long, but in an automated way.

> > or for packages with few users.
> 
> ... which have even less reason to be pushed to "stable" quickly rather
> than spending a few days in updates-testing first. :) Even such packages
> can cause chaos and disturb SONAME Provides, for example. Recently, we've
> had a case where an update accidentally obsoleted packages in a different
> namespace. Or watch this one: https://bugzilla.redhat.com/473182

Fully agreed. That's why I think that multiple obsolete and provides
should be catched automatically. But I don't think that much more QA is
needed. In my opinion checking missing deps, mutiple
provides/obsoletes, unattended conflicts and n-ver should be done
automaticaly and block autoamtically packages (with a whitelist for
provides/obsoletes that are meant to be shared). But otherwise how
testing is done and how bodhi is used should be left to the packagers.

> I know you'd like to be able to push to repositories immediately
> without any release management, but for Fedora's users that would be
> one step closer to the infamous dumping ground of packages.

That's not my opinion. I think that packagers should be able to chose
what suits their userbase better, taking into account fedora as a whole.
In most cases I left the updates sit in bodhi until I get the automatic
mail.


As a side note, I don't think that the dumping ground effect is that
much linked with the number of days in bodhi, rather to uncareful 
packagers and lack of consideration for integration, uncareful use of 
unstable upstream and push from rawhide too early.

--
Pat



From sundaram at fedoraproject.org  Tue Dec  9 14:16:13 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Dec 2008 19:46:13 +0530
Subject: The looming Python 3(000) monster
In-Reply-To: <20081209103336.GB15102@redhat.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com>	<493D68D8.2000308@gmail.com>	<200812082142.mB8LgHJb019504@laptop14.inf.utfsm.cl>	<493DA9EE.2070108@gmail.com>
	<493E4770.2000709@fedoraproject.org>
	<20081209103336.GB15102@redhat.com>
Message-ID: <493E7DAD.3070209@fedoraproject.org>

Daniel P. Berrange wrote:
> 
> This is not a comparable scenario. The new GCC releases are identifying
> bugs which always existed in your code, not changing the language. As
> such once you fix the bugs, your code continues to work on old & new
> GCC just fine. 

It is not the exact same scenaro but we are talking about backward 
compatibility of languages in general. If new GCC breaks my C code or a 
new Python interpretor breaks my python code, it is still breaking what 
was working before. C specification is not breakfast reading so almost 
everybody just go with what a compiler like GCC supports.

Isn't a similar situation responsible for

https://fedoraproject.org/wiki/Common_F10_bugs#DNS_Resolver_not_Reliable

Rahul



From sundaram at fedoraproject.org  Tue Dec  9 14:21:33 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Dec 2008 19:51:33 +0530
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <493E6D72.9020605@hi.is>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<ghkq7m$46p$1@ger.gmane.org>	<20081209104955.55a363b2.mschwendt@gmail.com>	<20081209100229.GD3833@free.fr>	<20081209120300.GJ14496@killefiz>
	<493E6D72.9020605@hi.is>
Message-ID: <493E7EED.6010607@fedoraproject.org>

J?hann B. Gu?mundsson wrote:

> First of all this falls on to testers...
> 
> Developers should spend their time developing.
> Testers should spend their time testing that's what we are here for.

There is no such clear separation possible. Developers should be testing 
their code and their packages as well. Handing this entirely off to 
another set of people, whether it is a QA team or somebody else, is just 
shifting blame.  QA team or a additional set of people are just 
complimenting the testing that the developers themselves should have done.

Rahul



From choeger at cs.tu-berlin.de  Tue Dec  9 14:25:12 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Tue, 09 Dec 2008 15:25:12 +0100
Subject: no GnomePasswordDialog for python?
Message-ID: <1228832712.3031.4.camel@choeger5.umpa.netz>

Hi, 

that goes to devel, as it could be either a packaging error or a feature
request ;)

Is it true that there is currently no way (either pyGtk or gnome-python)
to access the standard gnome password dialog with python?
I can see alot of related defs in /usr/share/pygtk/2.0/defs/ui.defs but
the python module only has a GnomePasswordRemember class.
That seems to be no moving target as upstream development is quiet for
years on that files, but where is the GnomePasswordDialog class (that
e.g. is constructed by password_dialog_new() in that ui.def)?

any clue?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/ac6892c1/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Dec  9 14:26:22 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 9 Dec 2008 15:26:22 +0100 (CET)
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493E7A7F.8010601@gmail.com>
References: <493E56B2.7060101@gmail.com>
	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>
	<493E6F6A.3060806@gmail.com>
	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>
	<493E7A7F.8010601@gmail.com>
Message-ID: <14bae52d8da7c7ba39b36567fdde86d3.squirrel@arekh.dyndns.org>



Le Mar 9 d?cembre 2008 15:02, Julian Sikorski a ?crit :

> Which is the right one then? I think openoffice issue 79878 could be a
> good choice,

If you only care about OO.o this is the right one, but that won't fix
KDE and friends.

> but I'm not sure about freedesktop one. I'm not that
> interested in others, since my document work is mainly done in oo.o.
> Besides, I guess that fontconfig needs to work properly before
> anything else will, right?

Fontconfig does work properly today. What does not work is apps that
assume there are only 4 font faces possible and can not handle what
fontconfig returns them for modern fonts.

http://www.openoffice.org/issues/show_bug.cgi?id=79878#desc27

-- 
Nicolas Mailhot



From ssorce at redhat.com  Tue Dec  9 14:27:29 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 09 Dec 2008 09:27:29 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <493E7DAD.3070209@fedoraproject.org>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com>	<493D68D8.2000308@gmail.com>
	<200812082142.mB8LgHJb019504@laptop14.inf.utfsm.cl>
	<493DA9EE.2070108@gmail.com> <493E4770.2000709@fedoraproject.org>
	<20081209103336.GB15102@redhat.com>
	<493E7DAD.3070209@fedoraproject.org>
Message-ID: <1228832849.8219.13.camel@localhost.localdomain>

On Tue, 2008-12-09 at 19:46 +0530, Rahul Sundaram wrote:
> Daniel P. Berrange wrote:
> > 
> > This is not a comparable scenario. The new GCC releases are identifying
> > bugs which always existed in your code, not changing the language. As
> > such once you fix the bugs, your code continues to work on old & new
> > GCC just fine. 
> 
> It is not the exact same scenaro but we are talking about backward 
> compatibility of languages in general. If new GCC breaks my C code or a 
> new Python interpretor breaks my python code, it is still breaking what 
> was working before. C specification is not breakfast reading so almost 
> everybody just go with what a compiler like GCC supports.
> 
> Isn't a similar situation responsible for
> 
> https://fedoraproject.org/wiki/Common_F10_bugs#DNS_Resolver_not_Reliable

I hope you realize the difference between a few programs not *compiling*
anymore, but that keep working no problem.
And *all* programs not running, until you fix them, *and* all the
modules not yet converted you depend on, including C bindings which are
not exactly breakfast coding for python programmers...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From linville at redhat.com  Tue Dec  9 14:32:16 2008
From: linville at redhat.com (John W. Linville)
Date: Tue, 9 Dec 2008 09:32:16 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <20081209143215.GC3395@redhat.com>

On Tue, Dec 09, 2008 at 01:25:40AM +0100, Robert Scheck wrote:
> Good evening everybody,
> 
> I've unluckily several points and issues, I'm trying to get solved for even
> for a longer time now (depending on the point on my list), but nobody in
> and around the Fedora Project seems or don't want to care about that. I am
> also annoyed, that I have to write such an e-mail, but the following really
> is, what Fedora makes sucking for me.

Wireless wasn't on the list -- hooray!!!!

Sorry, just needed some humor...

John
-- 
John W. Linville
linville at redhat.com



From belegdol at gmail.com  Tue Dec  9 14:37:21 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 09 Dec 2008 15:37:21 +0100
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <14bae52d8da7c7ba39b36567fdde86d3.squirrel@arekh.dyndns.org>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>	<493E7A7F.8010601@gmail.com>
	<14bae52d8da7c7ba39b36567fdde86d3.squirrel@arekh.dyndns.org>
Message-ID: <493E82A1.1040408@gmail.com>

Nicolas Mailhot pisze:
> 
> Le Mar 9 d?cembre 2008 15:02, Julian Sikorski a ?crit :
> 
>> Which is the right one then? I think openoffice issue 79878 could be a
>> good choice,
> 
> If you only care about OO.o this is the right one, but that won't fix
> KDE and friends.
> 
>> but I'm not sure about freedesktop one. I'm not that
>> interested in others, since my document work is mainly done in oo.o.
>> Besides, I guess that fontconfig needs to work properly before
>> anything else will, right?
> 
> Fontconfig does work properly today. What does not work is apps that
> assume there are only 4 font faces possible and can not handle what
> fontconfig returns them for modern fonts.
> 
> http://www.openoffice.org/issues/show_bug.cgi?id=79878#desc27
> 
If I remember correctly, a while ago you told me that gtk font selector
should be working correctly as well. The thing is that it does show
"extraordinary" typefaces for let's say DejaVu LGC Sans, but for Arial
the list is pretty much busted - please see the screenshot I attached to
the Red Hat bug #466678 (mentioned in the first email). Which software
could be responsible for this? I suspected fontconfig.

Regards,
Julian



From nicolas.mailhot at laposte.net  Tue Dec  9 14:50:58 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 9 Dec 2008 15:50:58 +0100 (CET)
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493E82A1.1040408@gmail.com>
References: <493E56B2.7060101@gmail.com>
	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>
	<493E6F6A.3060806@gmail.com>
	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>
	<493E7A7F.8010601@gmail.com>
	<14bae52d8da7c7ba39b36567fdde86d3.squirrel@arekh.dyndns.org>
	<493E82A1.1040408@gmail.com>
Message-ID: <c236b46d4f039f7d9714831982e33374.squirrel@arekh.dyndns.org>



Le Mar 9 d?cembre 2008 15:37, Julian Sikorski a ?crit :

> If I remember correctly, a while ago you told me that gtk font
> selector
> should be working correctly as well. The thing is that it does show
> "extraordinary" typefaces for let's say DejaVu LGC Sans, but for Arial
> the list is pretty much busted - please see the screenshot I attached
> to
> the Red Hat bug #466678 (mentioned in the first email). Which software
> could be responsible for this? I suspected fontconfig.

The freely accessible arial you find on the web is an old version that
does not declare the same stuff as modern versions. Microsoft does not
update it anymore.

Having a way to tell fontconfig "this is an old font with missing
modern metadata, here is the info which is missing" so it's treated
the same way as modern fonts is the object of the freedesktop bug
you've already commented on.

-- 
Nicolas Mailhot



From sundaram at fedoraproject.org  Tue Dec  9 14:52:11 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Dec 2008 20:22:11 +0530
Subject: The looming Python 3(000) monster
In-Reply-To: <1228832849.8219.13.camel@localhost.localdomain>
References: <49393DE3.1080707@redhat.com>	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>	<493D5DA3.7010408@gmail.com>	<493D68D8.2000308@gmail.com>	<200812082142.mB8LgHJb019504@laptop14.inf.utfsm.cl>	<493DA9EE.2070108@gmail.com>
	<493E4770.2000709@fedoraproject.org>	<20081209103336.GB15102@redhat.com>	<493E7DAD.3070209@fedoraproject.org>
	<1228832849.8219.13.camel@localhost.localdomain>
Message-ID: <493E861B.7050705@fedoraproject.org>

Simo Sorce wrote:

> I hope you realize the difference between a few programs not *compiling*
> anymore, but that keep working no problem.

Sure but that is a side effect of interpreted (python) vs compiled ( C) 
code and not the strength of backward compatibility of a language. When 
it comes to Free software within a Fedora environment which is supposed 
to be self hosting, working but not compiling code is certainly a issue 
as well.

Rahul



From hughsient at gmail.com  Tue Dec  9 14:53:03 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 09 Dec 2008 14:53:03 +0000
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <1228834384.6701.15.camel@hughsie-work.lan>

On Tue, 2008-12-09 at 01:25 +0100, Robert Scheck wrote:
> PackageKit is resizing windows during installation or updating
> of packages; it's resizing and thus hopping the window if I e.g. select a
> package or if I click around inside of the application. That's something,
> which proves, that there is no usability for end users yet.

If you file a bug I'll fix it.

>  And the
> related GNOME tray utility is also slow and usually is behind the current
> action...that's packagekitd, yes?

gnome-packagekit if you are on GNOME, kpackagekit if you are on KDE. Did
you file a bug about it being slow? It's very fast on my system.

> One of these utilities also often blocks
> the usage of yum with saying, that another application currently holds the
> lock. Why are we locking something when not performing a writing action on
> the RPM database? That seems to be mis-engineered very well.

It only locks the database when there is an active yum transaction
running. I can assure you you don't want two things playing with the
rpmdb at once.

> Independent of that, PackageKit is somehow slow

Not a very useful comment.

> has issues that it doesn't understand
> always where it is or whether an action is already completed. Oh and it
> kills my Firefox nicely during package updating, well-well done.

"kills my firefox" also doesn't seem a great error report. It might help
lower your blood pressure if you filed bugs in bugzilla. Sounds like a
bug in firefox to me.

> When talking about PackageKit, DBUS is another issue. The recent DBUS pkg
> update broke PackageKit stuff - thanks to our cool QA. And clever as we
> are, we did not revoke the update and we also did not push a fixed package
> really immediately out after to solve this.

> I know, that many of the
> desktop people actually love DBUS, but it is horrible stuff, which can
> break down much things with lacking QA like in this case.

The DBus update broke applications not conforming 100% to the spec.
Unfortunately this update was pushed directly into stable (not
updates-testing) and so nobody got a chance to test it. We're all fixing
applications as fast as we can.

> Did you desktop
> people ever think about, that DBUS is not the perfect choice for a server
> system and Fedora is some kind of preview of RHEL?

DBus works very well on a server.

> Yes, Fedora is not the
> playground of Red Hat, but on the other hand, Fedora is - why else is Red
> Hat putting efforts into Fedora if they wouldn't benefit? I really can only
> hope here, that Red Hat removes much of the DBUS breakage and dumbness for
> the next RHEL release and that less DBUS linked packages are making it into
> there...

Maybe you should apply for a job at Red Hat, and then you can give some
opinions on what Red Hat chooses to do with RHEL. I'll tell you a little
secret: RHEL 6 is still going to include DBus.

> And as we're cool, we need a daemon for everything: packagekitd, dbusd, hal
> daemon, mcstransd, setroubleshootd, yum-updatesd - yay. And nearly every of
> this daemons is written in the memory consuming python

packagekitd, dbus and hal are written in C.

> I'm aware,
> that python is the Red Hat internal defacto default

Erm, unless I missed the memo, there is no "Red Hat internal defacto
default"...

> and that scripting is
> much more faster rather coding low-level C. But lets waste ressources as
> e.g. kerneloops daemon does which always consumes a bit of CPU and thus not
> increases the consuming of energy in a positive way. But hey, let's create
> another daemon to monitor where we're wasting and leaking memory...

I don't think this is a reasoned argument, sorry. To be honest, I think
you need to write much shorter, to the point emails. Ranting doesn't
have much affect on anything, whilst filing bugs and getting involved
upstream does.

Richard.




From belegdol at gmail.com  Tue Dec  9 14:48:48 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 09 Dec 2008 15:48:48 +0100
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493E82A1.1040408@gmail.com>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>	<493E7A7F.8010601@gmail.com>	<14bae52d8da7c7ba39b36567fdde86d3.squirrel@arekh.dyndns.org>
	<493E82A1.1040408@gmail.com>
Message-ID: <493E8550.9010404@gmail.com>

Julian Sikorski pisze:
> Nicolas Mailhot pisze:
>> Le Mar 9 d?cembre 2008 15:02, Julian Sikorski a ?crit :
>>
>>> Which is the right one then? I think openoffice issue 79878 could be a
>>> good choice,
>> If you only care about OO.o this is the right one, but that won't fix
>> KDE and friends.
>>
>>> but I'm not sure about freedesktop one. I'm not that
>>> interested in others, since my document work is mainly done in oo.o.
>>> Besides, I guess that fontconfig needs to work properly before
>>> anything else will, right?
>> Fontconfig does work properly today. What does not work is apps that
>> assume there are only 4 font faces possible and can not handle what
>> fontconfig returns them for modern fonts.
>>
>> http://www.openoffice.org/issues/show_bug.cgi?id=79878#desc27
>>
> If I remember correctly, a while ago you told me that gtk font selector
> should be working correctly as well. The thing is that it does show
> "extraordinary" typefaces for let's say DejaVu LGC Sans, but for Arial
> the list is pretty much busted - please see the screenshot I attached to
> the Red Hat bug #466678 (mentioned in the first email). Which software
> could be responsible for this? I suspected fontconfig.
> 
> Regards,
> Julian
> 

Hmm, I did some more testing and it really seems that something gets
messed up at the point at which arial is merged with arial narrow. If
you launch gedit with LANG=C, and go to font selection, you will get the
following:
http://belegdol.fedorapeople.org/gtkfontselen.png
Selecting narrow will get you narrow typeface, but something is clearly
wrong there. On the other hand, in pl_PL locale:
http://belegdol.fedorapeople.org/gtkfontselpl.png
entries are duplicated and none of the displayed ones will select the
narrow typeface. I suspect something is wrong with the font as well, but
if per-font quirks are out of question, I suppose there is a proper way
to fix the problem.

Regards,
Julian



From nicolas.mailhot at laposte.net  Tue Dec  9 15:02:46 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 9 Dec 2008 16:02:46 +0100 (CET)
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493E8550.9010404@gmail.com>
References: <493E56B2.7060101@gmail.com>
	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>
	<493E6F6A.3060806@gmail.com>
	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>
	<493E7A7F.8010601@gmail.com>
	<14bae52d8da7c7ba39b36567fdde86d3.squirrel@arekh.dyndns.org>
	<493E82A1.1040408@gmail.com> <493E8550.9010404@gmail.com>
Message-ID: <8424b9f95651d2d4605046cbac353d58.squirrel@arekh.dyndns.org>



Le Mar 9 d?cembre 2008 15:48, Julian Sikorski a ?crit :
>

> Hmm, I did some more testing and it really seems that something gets
> messed up at the point at which arial is merged with arial narrow.

Just open a bug @gnome.org then, putting
fedora-fonts-bugs-list at redhat.com in CC.

-- 
Nicolas Mailhot



From belegdol at gmail.com  Tue Dec  9 15:01:24 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 09 Dec 2008 16:01:24 +0100
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <c236b46d4f039f7d9714831982e33374.squirrel@arekh.dyndns.org>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>	<493E7A7F.8010601@gmail.com>	<14bae52d8da7c7ba39b36567fdde86d3.squirrel@arekh.dyndns.org>	<493E82A1.1040408@gmail.com>
	<c236b46d4f039f7d9714831982e33374.squirrel@arekh.dyndns.org>
Message-ID: <493E8844.3080002@gmail.com>

Nicolas Mailhot pisze:
> 
> Le Mar 9 d?cembre 2008 15:37, Julian Sikorski a ?crit :
> 
>> If I remember correctly, a while ago you told me that gtk font
>> selector
>> should be working correctly as well. The thing is that it does show
>> "extraordinary" typefaces for let's say DejaVu LGC Sans, but for Arial
>> the list is pretty much busted - please see the screenshot I attached
>> to
>> the Red Hat bug #466678 (mentioned in the first email). Which software
>> could be responsible for this? I suspected fontconfig.
> 
> The freely accessible arial you find on the web is an old version that
> does not declare the same stuff as modern versions. Microsoft does not
> update it anymore.
> 
> Having a way to tell fontconfig "this is an old font with missing
> modern metadata, here is the info which is missing" so it's treated
> the same way as modern fonts is the object of the freedesktop bug
> you've already commented on.
> 
So I picked the right bug after all :) Anyway, I removed the
msttcorefonts package and tried copying over arial from my windows
install did not help here. Well, I guess you meant that MS does not
update arial at all, not just the freely available version.

Julian



From notting at redhat.com  Tue Dec  9 15:12:06 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 9 Dec 2008 10:12:06 -0500
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
Message-ID: <20081209151206.GA13238@nostromo.devel.redhat.com>

Jerry Amundson (jamundso at gmail.com) said: 
>        It is possible for several programs  fulfilling  the  same  or  similar
>        functions  to  be  installed  on a single system at the same time.  For
>        example, many systems have several  text  editors  installed  at  once.
>        This gives choice to the users of a system, allowing each to use a dif-
>        ferent editor, if desired, but makes it difficult for a program to make
>        a  good choice of editor to invoke if the user has not specified a par-
>        ticular preference.
> 
>        The alternatives system aims to solve this problem.

Not for something like $EDITOR, which is a per-user setting anyway.

I'm not sure why a dependency on vim-minimal is truly that bad.

Bill



From jamundso at gmail.com  Tue Dec  9 15:19:40 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Tue, 9 Dec 2008 09:19:40 -0600
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081209151206.GA13238@nostromo.devel.redhat.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
Message-ID: <6d06ce20812090719u67a667c7oa14ad8fb4c4d0653@mail.gmail.com>

On Tue, Dec 9, 2008 at 9:12 AM, Bill Nottingham <notting at redhat.com> wrote:
> Jerry Amundson (jamundso at gmail.com) said:
>>        It is possible for several programs  fulfilling  the  same  or  similar
>>        functions  to  be  installed  on a single system at the same time.  For
>>        example, many systems have several  text  editors  installed  at  once.
>>        This gives choice to the users of a system, allowing each to use a dif-
>>        ferent editor, if desired, but makes it difficult for a program to make
>>        a  good choice of editor to invoke if the user has not specified a par-
>>        ticular preference.
>>
>>        The alternatives system aims to solve this problem.
>
> Not for something like $EDITOR, which is a per-user setting anyway.

Good point.

> I'm not sure why a dependency on vim-minimal is truly that bad.

Me neither. I love vi.

jerry

-- 
Store in cool, dry place. Rotate stock.



From johannbg at hi.is  Tue Dec  9 15:20:35 2008
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Tue, 09 Dec 2008 15:20:35 +0000
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <493E7EED.6010607@fedoraproject.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<ghkq7m$46p$1@ger.gmane.org>	<20081209104955.55a363b2.mschwendt@gmail.com>	<20081209100229.GD3833@free.fr>	<20081209120300.GJ14496@killefiz>	<493E6D72.9020605@hi.is>
	<493E7EED.6010607@fedoraproject.org>
Message-ID: <493E8CC3.7030307@hi.is>

Rahul Sundaram wrote:
> J?hann B. Gu?mundsson wrote:
>
>> First of all this falls on to testers...
>>
>> Developers should spend their time developing.
>> Testers should spend their time testing that's what we are here for.
>
> There is no such clear separation possible. Developers should be 
> testing their code and their packages as well. Handing this entirely 
> off to another set of people, whether it is a QA team or somebody 
> else, is just shifting blame.  QA team or a additional set of people 
> are just complimenting the testing that the developers themselves 
> should have done.
>
> Rahul
>
Rahul you do see the flaw in this logic right?

For a developer to be able to test his code he needs to test on all 
possible scenarios
hw and sw related repeated times the n option ( if any ) his application 
can do.

Even in the perfect "my little pony" world
where  there are million developers around a single component
with all the time in the world at their disposal which they then could

Document their code ( since him/they are the only one truly qualified to 
do so )
Triage and respond to the reports
( Well there should not be any but if so unlikely it were, he/they are 
the only one truly qualified to do so )
Test before release to the end user(s)

It STILL would fall into the hands of the QA to double check if he/they 
missed something..

If the blame belongs somewhere than it is with the QA to have released 
it to the end user in
the first place and THAT'S what I'm aiming at improving taking the QA on 
the QA :)
but it will take time!.

But I do agree with you that it would help if he/they have 
updates-testing enabled to test their
component that is if they are actually developing and using it on Fedora 
GA release..

In reality we need more devs..

JBG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/ecbaf083/attachment.vcf>

From rawhide at fedoraproject.org  Tue Dec  9 15:27:42 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue,  9 Dec 2008 15:27:42 +0000 (UTC)
Subject: rawhide report: 20081209 changes
Message-ID: <20081209152742.63B281F81E0@releng2.fedora.phx.redhat.com>

Compose started at Tue Dec  9 06:01:06 UTC 2008

New package gnuplot-py
        Python interface to Gnuplot
New package gnurobots
        A robot programming game
New package perl-B-Utils
        Helper functions for op tree manipulation
New package python-openoffice
        Python libraries for interacting with OpenOffice.org
New package soundmodem
        Soundcard Packet Radio Modem
New package svxlink
        Repeater controller and EchoLink (simplex or repeater)
New package wol
        Wake On Lan client
Updated Packages:

AcetoneISO2-2.0.3-0.1.RC1.fc11
------------------------------
* Mon Dec  8 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.0.3-0.1.RC1
- 2.0.3RC1


PolicyKit-0.9-4.fc11
--------------------
* Mon Dec  8 17:00:00 2008 David Zeuthen <davidz at redhat.com> - 0.9-4.fc11
- D-Bus policy fix (fd.o #18948)


R-BufferedMatrix-1.4.0-2.fc11
-----------------------------
* Mon Dec  1 17:00:00 2008 Pingou <pingoufc4 at yahoo.fr> 1.4.0-2
- Change own directory -- #473617


R-affyio-1.10.0-3.fc11
----------------------
* Sun Nov 30 17:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.10.0-3
- Own the folder libs -- #473618

* Thu Nov 20 17:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.10.0-2
- Correct the Source0


ScientificPython-2.6.1-5.fc11
-----------------------------
* Mon Dec  8 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.6.1-5
- Fix netcdf in lib64

* Mon Dec  8 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.6.1-4
- Remove obsolete patch

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.6.1-3
- Rebuild for Python 2.6

* Tue Sep  2 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.6.1-2
- Include /usr/include/python%{pyver}/Scientific directory


akonadi-1.0.80-3.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0.80-3
- restore Requires: mysql-server


amarok-2.0-1.fc11
-----------------
* Fri Dec  5 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 2.0-1
- amarok-2.0 (final, first cut)


at-spi-1.25.2-4.fc11
--------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.25.2-4
- Reduce unused direct deps


bluez-4.22-1.fc11
-----------------
* Mon Dec  8 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.22-1
- Update to 4.22


bluez-gnome-1.8-12.fc11
-----------------------
* Mon Dec  8 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-12
- Fix build

* Mon Dec  8 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-11
- More GPS devices

* Mon Dec  8 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-10
- Add another GPS device


compiz-0.7.8-9.fc11
-------------------
* Mon Dec  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.7.8-9
- Remove direct rendering check for now


control-center-2.25.2-6.fc11
----------------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-6
- Rebuild to reduce pkg-config-induced dependency bloat

* Mon Dec  8 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.2-5
- Add patch to support multiple enrollment stages in the about-me
  capplet


eel2-2.25.1-3.fc11
------------------
* Mon Dec  8 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.1-3
- Fix slideshows (bug 474876)


eigen2-2.0-0.5.beta2.fc11
-------------------------
* Mon Dec  8 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 2.0-0.5.beta2
- eigen-2.0-beta2
- (re)enable buildtime test


fcron-3.0.4-5.fc11
------------------
* Mon Dec  8 17:00:00 2008 Patrice Dumas <pertusus[AT]free[DOT]fr> 3.0.4-5
- simplify fcron_watch_config.c thanks to watching example in cronie
    and also wait for cron.d instead of erroring
  - dont provide %{_sysconfdir}/cron.d, since fcron_watch_config may
    not be started


gmp-4.2.4-3.fc11
----------------
* Mon Dec  8 17:00:00 2008 Ivana Varekova <varekova at redhat.com> 4.2.4-3
- remove useless option (#475073)


gnome-doc-utils-0.14.0-7.fc11
-----------------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.14.0-7
- Fight pkg-config-induced dependency bloat


gnome-games-extra-data-2.24.0-3
-------------------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-3
- Own some directories (#474648)

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Tweak %summary


gnome-themes-2.25.2-2.fc11
--------------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-2
- BR gtk2-engines-devel


gtk-sharp2-2.12.5-2.fc11
------------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.12.5-2
- Rebuild to fix pkg-config autoprovides


gtk2-engines-2.17.1-2.fc11
--------------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.17.1-2
- Add a -devel package to trim excessive pkg-config autodeps


kadu-0.6.5-1.fc11
-----------------
* Wed Dec  3 17:00:00 2008 Micha?? Bentkowski <mr.ecik at gmail.com> - 0.6.5-1
- 0.6.5
- Lots of changes:
-    some modules are now considered default,
-    some others are disabled,
-    some no longer exists,
-    some changed name,
- Parameter "--with=opt" given to rpmbuild makes kadu build to
  /opt instead of /usr (useful feature in testing)
- Kadu now uses qt4
- Lots of Obsoletes/Provides to prevent breaking updates
- Etc.


kchmviewer-4.0-2.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Patrice Dumas <pertusus at free.fr> 4.0-2
- reenable kde support


kdebase3-3.5.10-3.fc11
----------------------
* Mon Dec  8 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.5.10-3
- omit kate.png conflicts (w/kdesdk42)

* Wed Oct  8 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 3.5.10-2.1
- add upstream patch to support decimal comma in the minicli calculator


kernel-2.6.28-0.121.rc7.git5.fc11
---------------------------------

libarchive-2.5.903a-1.fc11
--------------------------
* Mon Dec  8 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> 2.5.903a-1
- Update to 2.5.903a


libiphone-0.1.0-6.20081201git8c3a01e.fc11
-----------------------------------------
* Fri Dec  5 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.1.0-6.git8c3a01e
- Fix devel dependency

* Fri Dec  5 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.1.0-5.git8c3a01e
- Fix gnutls check for new rawhide version

* Fri Dec  5 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.1.0-4.git8c3a01e
- Rebuild for pkgconfig


logwatch-7.3.6-37.fc11
----------------------
* Mon Dec  8 17:00:00 2008 Ivana Varekova <varekova at redhat.com> 7.3.6-37
- fix zz-disk_space script (#474810)


man-pages-3.15-1.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 3.15-1
- update to 3.15


man-pages-cs-0.17.20080113-5.fc11
---------------------------------
* Mon Dec  8 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 0.17.20080113-5
- update another part of coreutils man-pages (patches are from Kamil Dudka)


ncl-5.0.0-15.fc11
-----------------
* Mon Dec  8 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 5.0.0-15
- Try changing the udunits path in config/Project


nntpgrab-0.4.0-2.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Erik van Pienbroek <info at nntpgrab.nl> - 0.4.0-2
- Updated summary
- The PHP scripts don't need to be part of the core-libs subpackage, but
  of the web subpackage
- Install the NNTPGrab server when the meta-package 'nntpgrab' is installed
- Drop an obsolete Requires


ochusha-0.5.99.69-0.4.cvs20081209T1330.fc11
-------------------------------------------
* Tue Dec  9 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


openser-1.3.4-1.fc11
--------------------
* Mon Dec  8 17:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 1.3.4-1
- Ver. 1.3.4
- Added sysconfig-file


perl-Alien-wxWidgets-0.42-1.fc11
--------------------------------
* Mon Dec  8 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.42-1
- 0.42


perl-HTML-FormFu-0.03007-1.fc11
-------------------------------
* Mon Dec  8 17:00:00 2008 Iain Arnell <iarnell at gmail.com> 0.03007-1
- update to 030007


perl-Wx-0.89-1.fc11
-------------------
* Mon Dec  8 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.89-1
- 0.89


pkgconfig-0.23-6.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1:0.23-6
- Remove a patch that is no longer necessary and causes more
  problems than it solves (#224148)
- Include Requires.private in --print-requires (#426106)


pm-utils-1.2.3-1.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 1.2.3-1
- Update to 1.2.3
- Removed 55battery, 50ntpd, and 65alsa hooks


portaudio-19-6.fc11
-------------------
* Sun Dec  7 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 19-6
- Add a patch by Kevin Kofler to make non mmap alsa (and thus pulseaudio) work
  (bz 445644)


quota-3.16-8.fc11
-----------------
* Mon Dec  8 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 1:3.16-8
- fix documentation inconsistency (now rpc(3) instead of 
  rpc(3N) in rquotad manpage) (#474836)


remoot-0.9-4.fc11
-----------------
* Mon Dec  8 17:00:00 2008 Fabian Affolter <fabian at bernewireless.net> - 0.9-4
- Changed summary


rlog-1.4-3.fc11
---------------
* Mon Dec  8 17:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 1.4-3
- Fixed url (BZ# 472665)


sdljava-0.9.1-10.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.9.1-10
- Fixed unowned /usr/share/sdljava dir in the -demo package (bz 474604)


seahorse-plugins-2.25.1-2.fc11
------------------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.25.1-2
- Own some directories (#474040)


selinux-policy-3.6.1-8.fc11
---------------------------
* Mon Dec  8 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-8
- Fix sudo setting of user keys


sugar-toolkit-0.83.2-4.fc11
---------------------------
* Fri Dec  5 17:00:00 2008 Peter Robinson<pbrobinson at gmail.com> - 0.83.2-4
- Rebuild for python 2.6


sysvinit-2.86-26
----------------
* Mon Dec  8 17:00:00 2008 Bill Nottingham <notting at redhat.com> - 2.86-26
- document readlink() behavior in pidof (#201317)
- fix potential issue in utmpdmp (#473485)

* Wed Oct  1 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 2.86-25
- rediff patches (#464940)
- remove change_console, it's no longer needed with plymouth


telepathy-salut-0.3.6-2.fc11
----------------------------
* Mon Dec  8 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.3.6-2
- Enable OLPC support code. It is not used unless a client explicitely requests them.


tomboy-0.13.1-6.fc11
--------------------
* Mon Dec  8 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.13.1-6
- Rebuild for pkg-config deps


totem-pl-parser-2.25.1-1.fc11
-----------------------------
* Mon Dec  8 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.1-1
- Update to 2.25.1


unbound-1.1.1-4.fc11
--------------------
* Mon Dec  8 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 1.1.1-4
- Added Requires: for selinux-policy >= 3.5.13-33 for proper SElinux rules.


wordpress-mu-2.6.5-1.fc11
-------------------------
* Mon Dec  1 17:00:00 2008 Bret McMillan <bretm at redhat.com> - 2.6.5-1
- Update to 2.6.5
- http://wordpress.org/development/2008/11/wordpress-265/
- http://ocaoimh.ie/2008/11/25/wordpress-mu-265/
- Fixes 1 XSS security issue, 3 bugs


wordwarvi-0.23-2.fc11
---------------------
* Mon Dec  8 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.23-2
- Fix wordwarvi crashing when used with a portaudio which has been patched to
  work with pulseaudio (rh 445644)


yum-3.2.20-7.fc11
-----------------
* Mon Dec  8 17:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 3.2.20-7
- merge patch from upstream and remove now old obsoletes patch


Summary:
Added Packages: 7
Removed Packages: 0
Modified Packages: 55
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.i386 requires libspectrum.so.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-gui-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.i386 requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rdflib-2.4.0-7.fc10.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.x86_64 requires libspectrum.so.5()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.x86_64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.x86_64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc requires libspectrum.so.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.ppc requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-gui-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc64 requires libspectrum.so.5()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-gui-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From hughsient at gmail.com  Tue Dec  9 15:39:09 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 09 Dec 2008 15:39:09 +0000
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209130409.283584eb@brian.englab.brq.redhat.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<20081209130409.283584eb@brian.englab.brq.redhat.com>
Message-ID: <1228837149.6701.19.camel@hughsie-work.lan>

On Tue, 2008-12-09 at 13:04 +0100, Michal Schmidt wrote:
> Running instances of Firefox always break when the Firefox package is
> being updated.

Do we know why? Is there a bug open?

Richard.




From sundaram at fedoraproject.org  Tue Dec  9 15:43:33 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Dec 2008 21:13:33 +0530
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <493E8CC3.7030307@hi.is>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<ghkq7m$46p$1@ger.gmane.org>	<20081209104955.55a363b2.mschwendt@gmail.com>	<20081209100229.GD3833@free.fr>	<20081209120300.GJ14496@killefiz>	<493E6D72.9020605@hi.is>	<493E7EED.6010607@fedoraproject.org>
	<493E8CC3.7030307@hi.is>
Message-ID: <493E9225.1090609@fedoraproject.org>

J?hann B. Gu?mundsson wrote:

> For a developer to be able to test his code he needs to test on all 
> possible scenarios
> hw and sw related repeated times the n option ( if any ) his application 
> can do.

That's too idealistic. Developers should develop as well as test to the 
extend it is feasible.

> It STILL would fall into the hands of the QA to double check if he/they 
> missed something..

Sure but like I said, this is a complimentary effort.

> If the blame belongs somewhere than it is with the QA to have released 
> it to the end user in > the first place and THAT'S what I'm aiming at improving taking the QA on 
> the QA :) > but it will take time!.

The responsibility isn't just with the QA team. It is primarily with the 
developers. QA is just helping. I applaud your efforts to improve that 
team but don't assume blame for everything.

> But I do agree with you that it would help if he/they have 
> updates-testing enabled to test their
> component that is if they are actually developing and using it on Fedora 
> GA release..

It would also help, if people didn't just bypass the testing repository 
altogether even for security updates as the dbus security update fiasco 
has just taught us, yet again.

> In reality we need more devs..

Yeah, we need more of everything.

Rahul



From jkeating at redhat.com  Tue Dec  9 15:49:43 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 09 Dec 2008 07:49:43 -0800
Subject: New project, for fun and excitement: Offtrac!
In-Reply-To: <1228804556.15234.1.camel@arekh.okg>
References: <1228803312.3863.20.camel@localhost.localdomain>
	<1228804037.3863.24.camel@localhost.localdomain>
	<1228804556.15234.1.camel@arekh.okg>
Message-ID: <1228837783.3863.27.camel@localhost.localdomain>

On Tue, 2008-12-09 at 07:35 +0100, Nicolas Mailhot wrote:
> 
> Do you intend to bolt on all the bugzilla features on it too?
> Would not it be simpler if fedorahosted used bugzilla like everyone
> else?

Bugzilla doesn't give us easy to use milestones, nor source tracking,
nor a wiki, nor an rss feed of the project, nor a tie into the Fedora
accounts system.  So moving to bugzilla isn't really progress.

What I'm trying to do here is make some aspects of using trac easier for
folks, not just project owners but people who file tickets in track,
like say for package tagging requests, or blocks, or...

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/6d732e88/attachment.sig>

From seg at haxxed.com  Tue Dec  9 16:23:22 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 09 Dec 2008 10:23:22 -0600
Subject: Unowned directories
In-Reply-To: <200811290123.53933.MathStuf@gmail.com>
References: <200811290123.53933.MathStuf@gmail.com>
Message-ID: <1228839802.4683.120.camel@localhost.localdomain>

On Sat, 2008-11-29 at 01:23 -0500, Ben Boeckel wrote:
> I got rid of things that seemed like 
> false positives (things under /tmp, /var/cache, and /dev/.udev).

Exclude all of /dev, it is dynamically generated by udev. If you
'cat /proc/mounts' you'll find that it is in fact a tmpfs, though it is
not entered in to /etc/mtab so it does not show in 'mount'.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/ec35c0b6/attachment.sig>

From walters at verbum.org  Tue Dec  9 16:27:42 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 9 Dec 2008 11:27:42 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209130409.283584eb@brian.englab.brq.redhat.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<20081209130409.283584eb@brian.englab.brq.redhat.com>
Message-ID: <faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>

On Tue, Dec 9, 2008 at 7:04 AM, Michal Schmidt <mschmidt at redhat.com> wrote:
> On Tue, 9 Dec 2008 01:25:40 +0100
> Robert Scheck <robert at fedoraproject.org> wrote:
>
>> [PackageKit] kills my Firefox nicely during package updating,
>> well-well done.
>
> Running instances of Firefox always break when the Firefox package is
> being updated. It does not matter what you use for the update (rpm,
> yum, PK). This is not PackageKit's fault.

In general, any software can break when a running copy has its files
swapped out from under it.  XULRunner-based apps exacerbate this flaw
in the package system because they use versioned directories.

But it's not Firefox's fault either.  Think about icons, glade files,
etc. that might be included in software.

It's something that really needs to be fixed in yum/rpm.  Windows has
a notion of "update this file after reboot", which might be the way to
go.



From enrico.scholz at informatik.tu-chemnitz.de  Tue Dec  9 16:29:38 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 09 Dec 2008 17:29:38 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081209151206.GA13238@nostromo.devel.redhat.com> (Bill
	Nottingham's message of "Tue, 9 Dec 2008 10:12:06 -0500")
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
Message-ID: <87prk1pb0t.fsf@fc5.bigo.ensc.de>

Bill Nottingham <notting at redhat.com> writes:

> I'm not sure why a dependency on vim-minimal is truly that bad.

Because this kind of dependencies (features which do not belong to
package's core functionality) are always bad.  Cron can be used
completely without any kind of editor; e.g. when jobs are installed
by cfengine.

Perhaps we should add 'Requires: cfengine' instead of? ;)


Enrico



From walters at verbum.org  Tue Dec  9 16:30:24 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 9 Dec 2008 11:30:24 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228834384.6701.15.camel@hughsie-work.lan>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
Message-ID: <faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>

On Tue, Dec 9, 2008 at 9:53 AM, Richard Hughes <hughsient at gmail.com> wrote:
>
> The DBus update broke applications not conforming 100% to the spec.
> Unfortunately this update was pushed directly into stable (not
> updates-testing) and so nobody got a chance to test it.

Just to be clear, the direct push into stable is my fault; not Red
Hat's or other DBus developers or anyone else's.  I had originally
listed it for updates-testing, but then changed the update to security
and in a moment of total stupidity also changed the listing for
stable.



From dr.diesel at gmail.com  Tue Dec  9 16:31:14 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Tue, 9 Dec 2008 11:31:14 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<20081209130409.283584eb@brian.englab.brq.redhat.com>
	<faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>
Message-ID: <2a28d2ab0812090831o799d6f47vfa72e3d49dda02d9@mail.gmail.com>

On Tue, Dec 9, 2008 at 11:27 AM, Colin Walters <walters at verbum.org> wrote:

> On Tue, Dec 9, 2008 at 7:04 AM, Michal Schmidt <mschmidt at redhat.com>
> wrote:
> > On Tue, 9 Dec 2008 01:25:40 +0100
> > Robert Scheck <robert at fedoraproject.org> wrote:
> >
> >
>
> It's something that really needs to be fixed in yum/rpm.  Windows has
> a notion of "update this file after reboot", which might be the way to
> go.
>  <https://www.redhat.com/mailman/listinfo/fedora-devel-list>


Please, lets not reboot to update Firefox, or anything!



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/4ed439eb/attachment.htm>

From walters at verbum.org  Tue Dec  9 16:32:30 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 9 Dec 2008 11:32:30 -0500
Subject: no GnomePasswordDialog for python?
In-Reply-To: <1228832712.3031.4.camel@choeger5.umpa.netz>
References: <1228832712.3031.4.camel@choeger5.umpa.netz>
Message-ID: <faa16b610812090832u6d630781hafd2368c70524578@mail.gmail.com>

2008/12/9 Christoph H?ger <choeger at cs.tu-berlin.de>:
> Hi,
>
> that goes to devel, as it could be either a packaging error or a feature
> request ;)

In the big picture, you should check out:

http://live.gnome.org/GObjectIntrospection/

The pybank bindings need work, but basically you should almost never
hit binding limitations again.



From a.badger at gmail.com  Tue Dec  9 16:54:48 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 09 Dec 2008 08:54:48 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz>	<493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com>	<493D68D8.2000308@gmail.com>	<1228762046.3545.2.camel@localhost.localdomain>	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
Message-ID: <493EA2D8.90200@gmail.com>

Arthur Pemberton wrote:
> On Mon, Dec 8, 2008 at 4:19 PM, Simo Sorce <ssorce at redhat.com> wrote:
>> I would personally strongly consider having 2.x and 3.0 parallel
>> installable ...
> 
> 
> Isn't Python designed to be parallel installable?
> 
> 
Yes it is.  We just want to avoid having to do that if possible because
it could be very painful to do so.

Here's the fear:

python2.x
  - python-libfoo-2.0
    - spiffy-app-1.2

python3.x
  - python-libfoo-2.1
    - excellent-app-1.1

python-libfoo-2.0 uses the 2.x API.  python-libfoo-2.1 uses the
python-3.x API.  In order to get spiffy-app and excellent-app into the
distro we need to have both python2.x and python3.x versions of the
library installed.

Now a security fix is released for python-libfoo-2.1.  Does that also
affect python-libfoo-2.0?  Can we backport the fix or are the py2.x and
py3.x versions too different?  Do we need to have more python coders
available to fix these errors?

Here's the ideal (For Fedora, once again, this does not address
mpdehaan's concerns):

python2.6
  - python-libfoo-2.1 (with from __future__ import *)
  - spiffy-app-1.2
  - excellent-app-1.1 (with from __future__ import *)

If this is possible we can maintain one version of python and one
version of the library.  The apps can both consume the library even
though one was coded for python-3.x and the other was coded for python-2.x.

Is this going to be possible or will deepseated assumptions in the new
language prevent this?  That's something we can't know for sure until we
actually start trying to run code in mixed mode like this.  Some people
had great luck with this earlier in the year[1]_ but I think there were
changes to the stdlibrary since then and I didn't trust that the author
had done a thorough job with the unicode/string/bytes testing.

So let me reiterate:

* python-3.x will not be in Fedora-11 unless it becomes obvious in the
next few weeks that we absolutely must be running it for the next release.
* we need more experience with python-2.6+ & python-3 compatibility
before we decide whether parallel versions of python are necessary.

.. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/e9ead7de/attachment.sig>

From lesmikesell at gmail.com  Tue Dec  9 17:23:43 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 09 Dec 2008 11:23:43 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
Message-ID: <493EA99F.4020400@gmail.com>

Colin Walters wrote:
> On Tue, Dec 9, 2008 at 9:53 AM, Richard Hughes <hughsient at gmail.com> wrote:
>> The DBus update broke applications not conforming 100% to the spec.
>> Unfortunately this update was pushed directly into stable (not
>> updates-testing) and so nobody got a chance to test it.
> 
> Just to be clear, the direct push into stable is my fault; not Red
> Hat's or other DBus developers or anyone else's.  I had originally
> listed it for updates-testing, but then changed the update to security
> and in a moment of total stupidity also changed the listing for
> stable.

People make mistakes - which is the point of having procedures in place 
to catch them.  Is there any way some additional checks can be imposed 
before things hit the public repos?


-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Tue Dec  9 17:31:12 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 09 Dec 2008 11:31:12 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<20081209130409.283584eb@brian.englab.brq.redhat.com>
	<faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>
Message-ID: <493EAB60.7040400@gmail.com>

Colin Walters wrote:
> On Tue, Dec 9, 2008 at 7:04 AM, Michal Schmidt <mschmidt at redhat.com> wrote:
>> On Tue, 9 Dec 2008 01:25:40 +0100
>> Robert Scheck <robert at fedoraproject.org> wrote:
>>
>>> [PackageKit] kills my Firefox nicely during package updating,
>>> well-well done.
>> Running instances of Firefox always break when the Firefox package is
>> being updated. It does not matter what you use for the update (rpm,
>> yum, PK). This is not PackageKit's fault.
> 
> In general, any software can break when a running copy has its files
> swapped out from under it.  XULRunner-based apps exacerbate this flaw
> in the package system because they use versioned directories.

Errr... versioned directories should make it possible to keep the old 
one running, not the other way around.  Removing a still-needed 
directory is the problem.

> But it's not Firefox's fault either.  Think about icons, glade files,
> etc. that might be included in software.
> 
> It's something that really needs to be fixed in yum/rpm.  Windows has
> a notion of "update this file after reboot", which might be the way to
> go.

Unix normally gets away with live updates because any currently open 
files remain accessible until the last close.  However, in this age of 
extensive plugins and modules with runtime loading, you either have to 
make sure they are all versioned like shared libraries should be or you 
kill the app that needs them.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Tue Dec  9 17:31:25 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 08:31:25 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081209143215.GC3395@redhat.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<20081209143215.GC3395@redhat.com>
Message-ID: <604aa7910812090931n22811460m6b337e25c7d0137c@mail.gmail.com>

On Tue, Dec 9, 2008 at 5:32 AM, John W. Linville <linville at redhat.com> wrote:
> Wireless wasn't on the list -- hooray!!!!
>
> Sorry, just needed some humor...

I could add it. I ran into my first residential wireless
network...managed by an apple airport something or other..which I
could not connect to. I gave up and had a glorious 5 days in Florida
without ever touching email.  So really I guess I should be thankful
that wireless didn't work flawlessly for me that week.

-jef



From jkeating at redhat.com  Tue Dec  9 17:34:36 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 09 Dec 2008 09:34:36 -0800
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <87prk1pb0t.fsf@fc5.bigo.ensc.de>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<87prk1pb0t.fsf@fc5.bigo.ensc.de>
Message-ID: <1228844076.3863.30.camel@localhost.localdomain>

On Tue, 2008-12-09 at 17:29 +0100, Enrico Scholz wrote:
> 
> Because this kind of dependencies (features which do not belong to
> package's core functionality) are always bad.  Cron can be used
> completely without any kind of editor; e.g. when jobs are installed
> by cfengine.
> 
> Perhaps we should add 'Requires: cfengine' instead of? ;)

It works just fine until you try to use the functionality that looks up
$EDITOR, finds none and tries to fall back to vi, and doesn't find it
and crashes.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/c77e2797/attachment.sig>

From jspaleta at gmail.com  Tue Dec  9 17:34:25 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 08:34:25 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
Message-ID: <604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>

On Tue, Dec 9, 2008 at 7:30 AM, Colin Walters <walters at verbum.org> wrote:
> Just to be clear, the direct push into stable is my fault; not Red
> Hat's or other DBus developers or anyone else's.  I had originally
> listed it for updates-testing, but then changed the update to security
> and in a moment of total stupidity also changed the listing for
> stable.

Thoughts on prevention or mediation ideas that would help when people
make this sort of mistake?

-jef



From walters at verbum.org  Tue Dec  9 17:43:38 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 9 Dec 2008 12:43:38 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
Message-ID: <faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>

On Tue, Dec 9, 2008 at 12:34 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Tue, Dec 9, 2008 at 7:30 AM, Colin Walters <walters at verbum.org> wrote:
>> Just to be clear, the direct push into stable is my fault; not Red
>> Hat's or other DBus developers or anyone else's.  I had originally
>> listed it for updates-testing, but then changed the update to security
>> and in a moment of total stupidity also changed the listing for
>> stable.
>
> Thoughts on prevention or mediation ideas that would help when people
> make this sort of mistake?

I think the simplest would have requiring pushes direct to stable for
core packages (defining "core" as "anything installed by default on
the Desktop or Service livecd images") need some sort of signoff,
possibly from multiple people.



From joe at nall.com  Tue Dec  9 17:53:07 2008
From: joe at nall.com (Joe Nall)
Date: Tue, 9 Dec 2008 11:53:07 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493EA99F.4020400@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<493EA99F.4020400@gmail.com>
Message-ID: <146471EC-B02B-47B6-9C67-D9ADE3C12839@nall.com>


On Dec 9, 2008, at 11:23 AM, Les Mikesell wrote:

> Colin Walters wrote:
>> On Tue, Dec 9, 2008 at 9:53 AM, Richard Hughes  
>> <hughsient at gmail.com> wrote:
>>> The DBus update broke applications not conforming 100% to the spec.
>>> Unfortunately this update was pushed directly into stable (not
>>> updates-testing) and so nobody got a chance to test it.
>> Just to be clear, the direct push into stable is my fault; not Red
>> Hat's or other DBus developers or anyone else's.  I had originally
>> listed it for updates-testing, but then changed the update to  
>> security
>> and in a moment of total stupidity also changed the listing for
>> stable.
>
> People make mistakes - which is the point of having procedures in  
> place to catch them.  Is there any way some additional checks can be  
> imposed before things hit the public repos?

Just remember that policies and procedures have a cost. That cost can  
be deployment latency (whined about frequently), effort to update (how  
many packages are way behind upstream) or test burden on an  
understaffed QA/test team. TANSTAFL.

joe



From jspaleta at gmail.com  Tue Dec  9 17:58:54 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 08:58:54 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
Message-ID: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>

On Tue, Dec 9, 2008 at 8:43 AM, Colin Walters <walters at verbum.org> wrote:
> I think the simplest would have requiring pushes direct to stable for
> core packages (defining "core" as "anything installed by default on
> the Desktop or Service livecd images") need some sort of signoff,
> possibly from multiple people.

Did you really have to use the word "core"?  I think everything on the
Desktop live image is probably way too broad.  Does all Desktop Live
functionality need to be protected? Or do we need to safeguard package
updating functionality specifically?

 -jef



From enrico.scholz at informatik.tu-chemnitz.de  Tue Dec  9 18:01:11 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 09 Dec 2008 19:01:11 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <1228844076.3863.30.camel@localhost.localdomain> (Jesse Keating's
	message of "Tue, 09 Dec 2008 09:34:36 -0800")
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<87prk1pb0t.fsf@fc5.bigo.ensc.de>
	<1228844076.3863.30.camel@localhost.localdomain>
Message-ID: <87ljupp6s8.fsf@fc5.bigo.ensc.de>

Jesse Keating <jkeating at redhat.com> writes:

>> Because this kind of dependencies (features which do not belong to
>> package's core functionality) are always bad.  Cron can be used
>> completely without any kind of editor; e.g. when jobs are installed
>> by cfengine.
>
> It works just fine until you try to use the functionality that looks up
> $EDITOR, finds none and tries to fall back to vi, and doesn't find it
> and crashes.

Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
installed a proper behavior.


Enrico



From bpepple at fedoraproject.org  Tue Dec  9 18:01:18 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 09 Dec 2008 13:01:18 -0500
Subject: Plan for tomorrows (20081209) FESCO meeting
Message-ID: <1228845678.25672.11.camel@localhost.localdomain>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Wednesday at 17:00
UTC (13:00 EST) in #fedora-meeting on irc.freenode.org:

/topic FESCo-Meeting -- sponsor nomination -- Jose Matos (jamatos)

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/DNSSEC

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/Python_2.6

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/Fingerprint

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/TightVNC

/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.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/fffa8bc0/attachment.sig>

From jkeating at redhat.com  Tue Dec  9 18:07:56 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 09 Dec 2008 10:07:56 -0800
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <87ljupp6s8.fsf@fc5.bigo.ensc.de>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<87prk1pb0t.fsf@fc5.bigo.ensc.de>
	<1228844076.3863.30.camel@localhost.localdomain>
	<87ljupp6s8.fsf@fc5.bigo.ensc.de>
Message-ID: <1228846076.3863.31.camel@localhost.localdomain>

On Tue, 2008-12-09 at 19:01 +0100, Enrico Scholz wrote:
> Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
> installed a proper behavior.

I don't disagree, but until the package does that, it should require
vim-minimal to avoid the crash.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/f9b05afb/attachment.sig>

From lesmikesell at gmail.com  Tue Dec  9 18:12:13 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 09 Dec 2008 12:12:13 -0600
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <87ljupp6s8.fsf@fc5.bigo.ensc.de>
References: <20081205195914.GB3227@free.fr>	<1228507530.3275.53.camel@localhost.localdomain>	<20081205201621.GC3227@free.fr>
	<493CD84F.6010309@redhat.com>	<20081208111231.GB2611@free.fr>
	<ghk08m$ru3$1@ger.gmane.org>	<20081208213830.GA2885@free.fr>	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>	<20081209151206.GA13238@nostromo.devel.redhat.com>	<87prk1pb0t.fsf@fc5.bigo.ensc.de>	<1228844076.3863.30.camel@localhost.localdomain>
	<87ljupp6s8.fsf@fc5.bigo.ensc.de>
Message-ID: <493EB4FD.7080908@gmail.com>

Enrico Scholz wrote:
> Jesse Keating <jkeating at redhat.com> writes:
> 
>>> Because this kind of dependencies (features which do not belong to
>>> package's core functionality) are always bad.  Cron can be used
>>> completely without any kind of editor; e.g. when jobs are installed
>>> by cfengine.
>> It works just fine until you try to use the functionality that looks up
>> $EDITOR, finds none and tries to fall back to vi, and doesn't find it
>> and crashes.
> 
> Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
> installed a proper behavior.

Doesn't ubunutu have a scheme where trying to execute a missing program 
suggests the package you need to install to get it?  That's even better 
behavior.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From tmraz at redhat.com  Tue Dec  9 18:17:29 2008
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 09 Dec 2008 19:17:29 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <1228846076.3863.31.camel@localhost.localdomain>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<87prk1pb0t.fsf@fc5.bigo.ensc.de>
	<1228844076.3863.30.camel@localhost.localdomain>
	<87ljupp6s8.fsf@fc5.bigo.ensc.de>
	<1228846076.3863.31.camel@localhost.localdomain>
Message-ID: <1228846649.3506.103.camel@vespa.frost.loc>

On Tue, 2008-12-09 at 10:07 -0800, Jesse Keating wrote:
> On Tue, 2008-12-09 at 19:01 +0100, Enrico Scholz wrote:
> > Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
> > installed a proper behavior.
> 
> I don't disagree, but until the package does that, it should require
> vim-minimal to avoid the crash.
$ crontab -e
/bin/sh: /bin/vi: No such file or directory
crontab: "/bin/vi" exited with status 127

Is this unacceptable behavior? I don't think so. But of course the
message could be even improved. Much better than making cronie depending
on any editor.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From sundaram at fedoraproject.org  Tue Dec  9 18:25:20 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Dec 2008 23:55:20 +0530
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <493EB4FD.7080908@gmail.com>
References: <20081205195914.GB3227@free.fr>	<1228507530.3275.53.camel@localhost.localdomain>	<20081205201621.GC3227@free.fr>	<493CD84F.6010309@redhat.com>	<20081208111231.GB2611@free.fr>	<ghk08m$ru3$1@ger.gmane.org>	<20081208213830.GA2885@free.fr>	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>	<20081209151206.GA13238@nostromo.devel.redhat.com>	<87prk1pb0t.fsf@fc5.bigo.ensc.de>	<1228844076.3863.30.camel@localhost.localdomain>	<87ljupp6s8.fsf@fc5.bigo.ensc.de>
	<493EB4FD.7080908@gmail.com>
Message-ID: <493EB810.8020302@fedoraproject.org>

Les Mikesell wrote:
> Enrico Scholz wrote:
>> Jesse Keating <jkeating at redhat.com> writes:
>>
>>>> Because this kind of dependencies (features which do not belong to
>>>> package's core functionality) are always bad.  Cron can be used
>>>> completely without any kind of editor; e.g. when jobs are installed
>>>> by cfengine.
>>> It works just fine until you try to use the functionality that looks up
>>> $EDITOR, finds none and tries to fall back to vi, and doesn't find it
>>> and crashes.
>>
>> Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
>> installed a proper behavior.
> 
> Doesn't ubunutu have a scheme where trying to execute a missing program 
> suggests the package you need to install to get it?  That's even better 
> behavior.

That only works in a shell. Not in all programs. However this has been 
implemented already in PackageKit and the patches send upstream so 
everybody can take advantage of it.

http://blogs.gnome.org/hughsie/2008/12/05/command-not-found/

Rahul



From jkeating at redhat.com  Tue Dec  9 18:28:10 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 09 Dec 2008 10:28:10 -0800
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <1228846649.3506.103.camel@vespa.frost.loc>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<87prk1pb0t.fsf@fc5.bigo.ensc.de>
	<1228844076.3863.30.camel@localhost.localdomain>
	<87ljupp6s8.fsf@fc5.bigo.ensc.de>
	<1228846076.3863.31.camel@localhost.localdomain>
	<1228846649.3506.103.camel@vespa.frost.loc>
Message-ID: <1228847290.3863.32.camel@localhost.localdomain>

On Tue, 2008-12-09 at 19:17 +0100, Tomas Mraz wrote:
> $ crontab -e
> /bin/sh: /bin/vi: No such file or directory
> crontab: "/bin/vi" exited with status 127
> 
> Is this unacceptable behavior? I don't think so. But of course the
> message could be even improved. Much better than making cronie
> depending
> on any editor.

That looks like a crash to me.  My immediate response would be "If you
need vi, why the hell didn't you require vi?!"  Imagine the case where
the user running this isn't the admin of the system.  What can they do
now?  Nothing.  Dead in the water.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/07321faa/attachment.sig>

From lesmikesell at gmail.com  Tue Dec  9 18:10:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 09 Dec 2008 12:10:02 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <146471EC-B02B-47B6-9C67-D9ADE3C12839@nall.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<493EA99F.4020400@gmail.com>
	<146471EC-B02B-47B6-9C67-D9ADE3C12839@nall.com>
Message-ID: <493EB47A.8060904@gmail.com>

Joe Nall wrote:

>>>> The DBus update broke applications not conforming 100% to the spec.
>>>> Unfortunately this update was pushed directly into stable (not
>>>> updates-testing) and so nobody got a chance to test it.
>>> Just to be clear, the direct push into stable is my fault; not Red
>>> Hat's or other DBus developers or anyone else's.  I had originally
>>> listed it for updates-testing, but then changed the update to security
>>> and in a moment of total stupidity also changed the listing for
>>> stable.
>>
>> People make mistakes - which is the point of having procedures in 
>> place to catch them.  Is there any way some additional checks can be 
>> imposed before things hit the public repos?
> 
> Just remember that policies and procedures have a cost. That cost can be 
> deployment latency (whined about frequently), effort to update (how many 
> packages are way behind upstream) or test burden on an understaffed 
> QA/test team. TANSTAFL.

You'd think that the leading edge software developers building things 
that are so important to push out to the public might be able to come up 
with some automated tests that would not impose more human time but 
would at least catch system-killing changes.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Tue Dec  9 18:33:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 09 Dec 2008 12:33:02 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
Message-ID: <493EB9DE.6000507@gmail.com>

Jeff Spaleta wrote:
> On Tue, Dec 9, 2008 at 8:43 AM, Colin Walters <walters at verbum.org> wrote:
>> I think the simplest would have requiring pushes direct to stable for
>> core packages (defining "core" as "anything installed by default on
>> the Desktop or Service livecd images") need some sort of signoff,
>> possibly from multiple people.
> 
> Did you really have to use the word "core"?  I think everything on the
> Desktop live image is probably way too broad.  Does all Desktop Live
> functionality need to be protected? Or do we need to safeguard package
> updating functionality specifically?

Anything that is likely to be difficult/impossible to recover from 
deserves special consideration, but really the process should just make 
it difficult to skip the updates-testing step.  If something is 
important enough security-wise that it can't spend the usual amount of 
time in testing then it is important enough to get at least a couple of 
people to agree that it is both necessary and safe.   If things that 
have been in testing for some time break then you are sort-of justified 
in blaming someone else...

But, as I've mentioned before, I think you'd get much better public 
participation in testing if yum could do repeatable updates.  That is, 
I'm only interested in testing exactly the update that I will later do 
on my own more critical machine(s) and I'm not interested enough to 
maintain my own mirrored repository which is currently the only way to 
get exactly the same set of programs installed on 2 different machines 
at different times.  I'd probably dedicate a test machine or at least a 
vmware image and I suspect many others would too if they knew they could 
reproduce what they were testing with a simple update command on the 
more important machines.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Tue Dec  9 18:12:40 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 09:12:40 -0900
Subject: Seahorse is orphaned?
In-Reply-To: <493E7AF8.8030303@fedoraproject.org>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
	<1228141066.3391.6.camel@localhost.localdomain>
	<493D24D1.6050202@redhat.com>
	<1228751408.3539.7.camel@localhost.localdomain>
	<604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>
	<1228798497.3863.4.camel@localhost.localdomain>
	<493E6A35.1080308@redhat.com> <493E7AF8.8030303@fedoraproject.org>
Message-ID: <604aa7910812091012j65358e73o6dc594c48ab8b111@mail.gmail.com>

On Tue, Dec 9, 2008 at 5:04 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> "keyring" is probably not that term many end users would use though. A bug
> report to add that to the summary might be appropriate neverthless.

You know what I would absolutely LOVE? I would love to be able to get
a data dump of what searches terms people are using in PK and which
search terms result in which packages being selected for install (not
the deps, the packages manually selected from the search results).
That would give us a comprehensive picture of how difficult the
package collection is to search, and if there are some areas in the
collection more difficult to search for than others.  If our package
management was implemented as a web service instead of a client
interface, that sort of thing would be cake to generate.. it would be
in the service logs.

Then again, if it were a web service then we could also open up
keyword tagging so that individual service users could add
supplimental keywords to refine searches without polluting the summary
or description namespace and without having to push updates to adjust
text strings before people could benefit.

-jef



From behdad at behdad.org  Tue Dec  9 18:36:37 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 09 Dec 2008 13:36:37 -0500
Subject: Stalled "Merge Reviews" (Re: What Fedora makes sucking for me - or
 why I am NOT Fedora
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <493EBAB5.3010209@behdad.org>

Robert Scheck wrote:

> Hmmm, the "Merge Reviews" that somewhere have been declared as blockers
> for Fedora 7 (!) are still not done. It AFAIK was said somewhen, that not
> reviewed packages are getting removed from Fedora. This did not happen for
> anything, yet. The "Merge Reviews" are sometimes also blocked by Red Hat
> employees for very base/core packages by just refusing the Fedora Packaging
> guidelines, because it's the packager of the package. This can't be case!
> The Red Hat people have to follow the Fedora packaging guidelines and rules
> same as the Fedora folks - without any exception! If you would like to know
> which packages and people I'm talking about, have a look to Bugzilla and
> search for the bug reports I'm watching via Cc - there are lots of examples
> out there...without wanting to blame somebody special here on the list. But
> this has to be solved, the reviews need to be done, and the Red Hat people
> sitting on some base/core packages, must follow the Fedora rules same and
> without any refusing as they currently do. BTW, why is nobody controlling
> the success of the "Merge Reviews"? Shouldn't somebody watch this and tell
> us all the progress inside of e.g. the weekly Fedora newsletter or so?

Your messages lists so many different issues (user-oriented, community,
project leadership, technical, etc, etc) that makes it hard to see what you
are implying.  And in most cases you do not offer a feasible solution, if at
all.  I reply as a Red Hat employee on this one as I didn't see anyone else do.

First, it's not like you wake up in the morning and boot your Fedora and it
pops up a message saying "Merge reviews are not fixied, shutting system
down."??  What's the problem really, other than some cruft left in Bugzilla?

If you were implying that the unreviewed packages should have been removed
from Fedora, go ahead, remove cairo, fontconfig, freetype, pango, and vte.

If you are implying that as their maintainer, I must incorporate the merge
reviews and close them, no thank you, I don't mind not maintaining anything in
Fedora, and I certainly didn't block anyone from making progress in the merge
reviews.  When you say "The Red Hat people have to follow the Fedora packaging
guidelines and rules same as the Fedora folks", does it mean that Fedora
should feel free to decide what *I* work on, when it doesn't decide what
"other Fedora folks" work on?  That doesn't feel right.

Not sure what your point was, other than making your long email even longer

behdad



From jspaleta at gmail.com  Tue Dec  9 18:43:33 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 09:43:33 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493EB9DE.6000507@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
Message-ID: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>

On Tue, Dec 9, 2008 at 9:33 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> But, as I've mentioned before, I think you'd get much better public
> participation in testing if yum could do repeatable updates.  That is, I'm
> only interested in testing exactly the update that I will later do on my own
> more critical machine(s) and I'm not interested enough to maintain my own
> mirrored repository which is currently the only way to get exactly the same
> set of programs installed on 2 different machines at different times.

Do you mean.... we require all the mirrors to hold all version of all
updates for a release cycle?

-jef



From pemboa at gmail.com  Tue Dec  9 19:05:31 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 9 Dec 2008 13:05:31 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <493EA2D8.90200@gmail.com>
References: <49393DE3.1080707@redhat.com> <corn06xveo.ln2@ppp1053.in.ipex.cz>
	<493C462B.4070607@gmail.com> <493D5DA3.7010408@gmail.com>
	<493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
Message-ID: <16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>

2008/12/9 Toshio Kuratomi <a.badger at gmail.com>:
> Arthur Pemberton wrote:
>> On Mon, Dec 8, 2008 at 4:19 PM, Simo Sorce <ssorce at redhat.com> wrote:
>>> I would personally strongly consider having 2.x and 3.0 parallel
>>> installable ...
>>
>>
>> Isn't Python designed to be parallel installable?
>>
>>
> Yes it is.  We just want to avoid having to do that if possible because
> it could be very painful to do so.
>
> Here's the fear:
>
> python2.x
>  - python-libfoo-2.0
>    - spiffy-app-1.2
>
> python3.x
>  - python-libfoo-2.1
>    - excellent-app-1.1
>
> python-libfoo-2.0 uses the 2.x API.  python-libfoo-2.1 uses the
> python-3.x API.  In order to get spiffy-app and excellent-app into the
> distro we need to have both python2.x and python3.x versions of the
> library installed.
>
> Now a security fix is released for python-libfoo-2.1.  Does that also
> affect python-libfoo-2.0?  Can we backport the fix or are the py2.x and
> py3.x versions too different?  Do we need to have more python coders
> available to fix these errors?
>
> Here's the ideal (For Fedora, once again, this does not address
> mpdehaan's concerns):
>
> python2.6
>  - python-libfoo-2.1 (with from __future__ import *)
>  - spiffy-app-1.2
>  - excellent-app-1.1 (with from __future__ import *)
>
> If this is possible we can maintain one version of python and one
> version of the library.  The apps can both consume the library even
> though one was coded for python-3.x and the other was coded for python-2.x.
>
> Is this going to be possible or will deepseated assumptions in the new
> language prevent this?  That's something we can't know for sure until we
> actually start trying to run code in mixed mode like this.  Some people
> had great luck with this earlier in the year[1]_ but I think there were
> changes to the stdlibrary since then and I didn't trust that the author
> had done a thorough job with the unicode/string/bytes testing.
>
> So let me reiterate:
>
> * python-3.x will not be in Fedora-11 unless it becomes obvious in the
> next few weeks that we absolutely must be running it for the next release.
> * we need more experience with python-2.6+ & python-3 compatibility
> before we decide whether parallel versions of python are necessary.
>
> .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
>
> -Toshio


Well again. Some people (like Toshio) seem to have a grasp on the
matter. All this banter hasn't produced anything more of use. How
about forming a temp SIG to take care of this trusting they do the
right thing?



-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From james at fedoraproject.org  Tue Dec  9 19:06:44 2008
From: james at fedoraproject.org (James Antill)
Date: Tue, 09 Dec 2008 14:06:44 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
Message-ID: <1228849604.30987.31.camel@code.and.org>

On Tue, 2008-12-09 at 09:43 -0900, Jeff Spaleta wrote:
> On Tue, Dec 9, 2008 at 9:33 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> > But, as I've mentioned before, I think you'd get much better public
> > participation in testing if yum could do repeatable updates.  That is, I'm
> > only interested in testing exactly the update that I will later do on my own
> > more critical machine(s) and I'm not interested enough to maintain my own
> > mirrored repository which is currently the only way to get exactly the same
> > set of programs installed on 2 different machines at different times.
> 
> Do you mean.... we require all the mirrors to hold all version of all
> updates for a release cycle?

 Yes, that's the only sane way to do it. yum-debug-dump /
yum-debug-restore will somewhat do the above, if the repo. has the old
versions available. However Fedora only has the latest, so the only real
alternative is creating a new repo. of somekind ... at which point you
might as well just do a local mirror.

-- 
James Antill <james at fedoraproject.org>
Fedora



From walters at verbum.org  Tue Dec  9 19:17:06 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 9 Dec 2008 14:17:06 -0500
Subject: testing request
Message-ID: <faa16b610812091117i161377ddpcfb744cda16b613e@mail.gmail.com>

Hi, I could use some testing, please add karma once all of these are
installed together, you've rebooted, and verified that PackageKit
works.

https://admin.fedoraproject.org/updates/dbus-1.2.8-1.fc10

Should use in combination with:

https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11043
https://admin.fedoraproject.org/updates/PackageKit-0.3.12-1.fc10,gnome-packagekit-0.3.12-1.fc10,kpackagekit-0.3.1-9.fc10

FC9:

https://admin.fedoraproject.org/updates/dbus-1.2.8-1.fc9
https://admin.fedoraproject.org/updates/F9/FEDORA-2008-11058
https://admin.fedoraproject.org/updates/F9/FEDORA-2008-11037

Thanks, and I greatly apologize for the pain so far.  It's not over
for me though.



From jspaleta at gmail.com  Tue Dec  9 19:23:54 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 10:23:54 -0900
Subject: Stalled "Merge Reviews" (Re: What Fedora makes sucking for me -
	or why I am NOT Fedora
In-Reply-To: <493EBAB5.3010209@behdad.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EBAB5.3010209@behdad.org>
Message-ID: <604aa7910812091123r2a763004k9bdc7bff70604cfa@mail.gmail.com>

On Tue, Dec 9, 2008 at 9:36 AM, Behdad Esfahbod <behdad at behdad.org> wrote:
> Not sure what your point was, other than making your long email even longer


I think the point is to..politely..remind us the merge reviews should
be completed.  Taking away more than that is probably not worthwhile.
I think we can all agree that we'd like the merges done.  The question
before us is, and has been, how do we motivate people to do that work?
 I'm just as culpable as anyone... I haven't even completed all the
reviews I started.

-jef



From orcanbahri at yahoo.com  Tue Dec  9 19:46:58 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Tue, 9 Dec 2008 11:46:58 -0800 (PST)
Subject: Stalled "Merge Reviews" (Re: What Fedora makes sucking for me -
	or why I am NOT Fedora
In-Reply-To: <493EBAB5.3010209@behdad.org>
Message-ID: <387131.49706.qm@web32808.mail.mud.yahoo.com>

--- On Tue, 12/9/08, Behdad Esfahbod wrote:
> 
> First, it's not like you wake up in the morning and
> boot your Fedora and it
> pops up a message saying "Merge reviews are not
> fixied, shutting system
> down."??  What's the problem really, other than
> some cruft left in Bugzilla?
> 
> If you were implying that the unreviewed packages should
> have been removed
> from Fedora, go ahead, remove cairo, fontconfig, freetype,
> pango, and vte.
> 

I have been thinking about this issue lately. Right now, if someone makes a new package (s)he has to throw it into a pool of ~800 other packages waiting for an assignee and hope that someone will notice the package.
Approximately half of these packages are "Merge Reviews".

- I joined the community this September. Nowhere in the guidelines I saw the definition of a "Merge Review". I had to ask people at #fedora-devel to figure that out.

- Out of the 8 "Merge Review"s I have done so far, only 1 maintainer cared to reply and fix the issues. Some "Merge Reviews", that I have done, only ask for changing 1-2 lines in the SPEC file. 

>From my experience, I can tell that there is an apparent dismissal on the "Merge Review" packages by the maintainers. How can we accelerate this process? A review consists of two main contributors. A reviewer and a maintainer. Here are some suggestions:

1- Finding the Reviewer: Whenever someone decides to contribute to Fedora, (s)he should be encouraged to do at least one "Merge Review". It would be fruitful if this is put in the guidelines and the sponsors check this before approving someone's sponsorship.

If some contributor does a "Merge Review", his/her packages should be pushed upward on the Review Requests list[1]. That way they'll have a better chance to get reviewed. I think this will encourage some people to do "Merge Reviews".

2- What can be done to force these maintainers to fix their packages? If a maintainer has an ongoing "Merge Review" with a "package review" flag set to "?", (s)he shall not file a new "Review Request" until that "Merge Review" is resolved. If a reviewer takes time to make a full review, the maintainer should at least respect that, or more harshly, should be made to respect that.

As I said there are ~800 packages awaiting a reviewer, and this number is not decreasing. An action should be taken soon.
-Orcan

[1] http://tinyurl.com/fedora-rev-req


      



From limb at jcomserv.net  Tue Dec  9 20:03:56 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 9 Dec 2008 14:03:56 -0600 (CST)
Subject: Stalled "Merge Reviews" (Re: What Fedora makes sucking for me 
 - or why I am NOT Fedora
In-Reply-To: <387131.49706.qm@web32808.mail.mud.yahoo.com>
References: <387131.49706.qm@web32808.mail.mud.yahoo.com>
Message-ID: <4ec853597bfc0f29f753340d93de4528.squirrel@mail.jcomserv.net>


> --- On Tue, 12/9/08, Behdad Esfahbod wrote:
>>
>> First, it's not like you wake up in the morning and
>> boot your Fedora and it
>> pops up a message saying "Merge reviews are not
>> fixied, shutting system
>> down."??  What's the problem really, other than
>> some cruft left in Bugzilla?
>>
>> If you were implying that the unreviewed packages should
>> have been removed
>> from Fedora, go ahead, remove cairo, fontconfig, freetype,
>> pango, and vte.
>>
>
> I have been thinking about this issue lately. Right now, if someone makes
> a new package (s)he has to throw it into a pool of ~800 other packages
> waiting for an assignee and hope that someone will notice the package.
> Approximately half of these packages are "Merge Reviews".
>
> - I joined the community this September. Nowhere in the guidelines I saw
> the definition of a "Merge Review". I had to ask people at #fedora-devel
> to figure that out.
>
> - Out of the 8 "Merge Review"s I have done so far, only 1 maintainer cared
> to reply and fix the issues. Some "Merge Reviews", that I have done, only
> ask for changing 1-2 lines in the SPEC file.
>
>>From my experience, I can tell that there is an apparent dismissal on the
>> "Merge Review" packages by the maintainers. How can we accelerate this
>> process? A review consists of two main contributors. A reviewer and a
>> maintainer. Here are some suggestions:
>
> 1- Finding the Reviewer: Whenever someone decides to contribute to Fedora,
> (s)he should be encouraged to do at least one "Merge Review". It would be
> fruitful if this is put in the guidelines and the sponsors check this
> before approving someone's sponsorship.
>
> If some contributor does a "Merge Review", his/her packages should be
> pushed upward on the Review Requests list[1]. That way they'll have a
> better chance to get reviewed. I think this will encourage some people to
> do "Merge Reviews".
>
> 2- What can be done to force these maintainers to fix their packages? If a
> maintainer has an ongoing "Merge Review" with a "package review" flag set
> to "?", (s)he shall not file a new "Review Request" until that "Merge
> Review" is resolved. If a reviewer takes time to make a full review, the
> maintainer should at least respect that, or more harshly, should be made
> to respect that.
>
> As I said there are ~800 packages awaiting a reviewer, and this number is
> not decreasing. An action should be taken soon.
> -Orcan
>
> [1] http://tinyurl.com/fedora-rev-req
>
We've been discussing this here:
http://fedoraproject.org/wiki/SIGs/Package_Review

>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From Lam at Lam.pl  Tue Dec  9 20:14:36 2008
From: Lam at Lam.pl (Leszek Matok)
Date: Tue, 9 Dec 2008 21:14:36 +0100
Subject: Stalled "Merge Reviews" (Re: What Fedora makes sucking for me -
 or why I am NOT Fedora
In-Reply-To: <387131.49706.qm@web32808.mail.mud.yahoo.com>
References: <493EBAB5.3010209@behdad.org>
	<387131.49706.qm@web32808.mail.mud.yahoo.com>
Message-ID: <20081209211436.09bd4c75@pensja.lam.pl>

Dnia 2008-12-09, o godz. 11:46:58 Orcan Ogetbil <orcanbahri at yahoo.com>
napisa?(a):

> Whenever someone decides to contribute to Fedora, (s)he should be encouraged
> to do at least one "Merge Review".
I would say that people new to the process and guidelines are not the best to
tell what is right or wrong with other packages.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/72849f71/attachment.sig>

From kwade at redhat.com  Tue Dec  9 20:29:19 2008
From: kwade at redhat.com (Karsten Wade)
Date: Tue, 9 Dec 2008 12:29:19 -0800
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1228821618.4861.83.camel@beta>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com> <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
	<1228128134.3451.36.camel@beta> <1228128814.3451.40.camel@beta>
	<20081209104229.GH9280@calliope.phig.org>
	<1228821618.4861.83.camel@beta>
Message-ID: <20081209202919.GM9280@calliope.phig.org>

On Tue, Dec 09, 2008 at 01:20:18PM +0200, Basil Mohamed Gohar wrote:
> 
> Okay, so back to my main point: is there an official step I have to take
> to start an initiative like this?

You know Fedora, we pride ourselves on our "be bold and do it"
spirit.  Well, unless we are complaining about the bureaucracy. :)

All I ask is you to send a self-intro[1] embedded in a discussion opener
to fedora-docs-list; obviously join the list.  We want to scope out
solution(s) and culture change ideas there, then bring a well formed
proposal/plan back to groups such as f-devel-l.

Within that planning process, we'll likely discover early that we need
some resourcs such as a publictest server instance to start
prototyping.  We can sort those requests out as needed.

Alternately, and we can consider this ... do we gain by keeping the
discussion on fedora-devel-list?  It feels to me that we've squeezed
the juice out of the ideas here so far, and it's time for a smaller
group (sub-project such as Docs) to take it aside and bring back
something more to squeeze.  But that is just a feeling, I'm open to
other ideas.

- Karsten
[1] That's the "how to join Docs" step that really matters:

https://fedoraproject.org/wiki/DocsProject/Join#Signing_Up
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/dd97c5f2/attachment.sig>

From loganjerry at gmail.com  Tue Dec  9 21:21:19 2008
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 9 Dec 2008 14:21:19 -0700
Subject: cpufreq module on x86_64
In-Reply-To: <20081205182915.GA28483@srcf.ucam.org>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
	<20081205182915.GA28483@srcf.ucam.org>
Message-ID: <870180fe0812091321h24f95edcwb55576a4bfb33462@mail.gmail.com>

On Fri, Dec 5, 2008 at 11:29 AM, Matthew Garrett <mjg at redhat.com> wrote:
> I suspect what's happening is that acpi-cpufreq is loading and failing
> to bind, and then p4-clockmod gets loaded, fails to bind and the module
> load is aborted.

Thanks to everyone who responded with reasons why I want a cpufreq
module loaded.  Matthew, you are absolutely correct.  I rebooted with
cpufreq.debug=7 on the boot line and got this in the logs:

acpi-cpufreq: acpi_cpufreq_init
acpi-cpufreq: acpi_cpufreq_early_init
cpufreq-core: trying to register driver acpi-cpufreq
cpufreq-core: adding CPU 0
acpi-cpufreq: acpi_cpufreq_cpu_init
cpufreq-core: initialization failed
cpufreq-core: adding CPU 1
acpi-cpufreq: acpi_cpufreq_cpu_init
cpufreq-core: initialization failed
cpufreq-core: adding CPU 2
acpi-cpufreq: acpi_cpufreq_cpu_init
cpufreq-core: initialization failed
cpufreq-core: adding CPU 3
acpi-cpufreq: acpi_cpufreq_cpu_init
cpufreq-core: initialization failed
cpufreq-core: no CPU initialized for driver acpi-cpufreq
cpufreq-core: unregistering CPU 0
cpufreq-core: unregistering CPU 1
cpufreq-core: unregistering CPU 2
cpufreq-core: unregistering CPU 3
cpufreq-core: trying to register driver p4-clockmod
cpufreq-core: adding CPU 0
[snip the rest; I posted it before]

So the "initialization failed" line tells me that this line:

  ret = cpufreq_driver->init(policy)

in cpufreq_add_dev() in drivers/cpufreq/cpufreq.c is where things are
going wrong.  Is there any way to tell what is going wrong here?  Is
this likely to be a BIOS bug?  (I just flashed my BIOS to fix 3D
graphics; it wouldn't surprise me if my vendor managed to mess this up
at the same time.)
-- 
Jerry James
http://loganjerry.googlepages.com/



From lesmikesell at gmail.com  Tue Dec  9 21:50:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 09 Dec 2008 15:50:19 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228849604.30987.31.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
Message-ID: <493EE81B.6000909@gmail.com>

James Antill wrote:
> On Tue, 2008-12-09 at 09:43 -0900, Jeff Spaleta wrote:
>> On Tue, Dec 9, 2008 at 9:33 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>>> But, as I've mentioned before, I think you'd get much better public
>>> participation in testing if yum could do repeatable updates.  That is, I'm
>>> only interested in testing exactly the update that I will later do on my own
>>> more critical machine(s) and I'm not interested enough to maintain my own
>>> mirrored repository which is currently the only way to get exactly the same
>>> set of programs installed on 2 different machines at different times.
>> Do you mean.... we require all the mirrors to hold all version of all
>> updates for a release cycle?
> 
>  Yes, that's the only sane way to do it. yum-debug-dump /
> yum-debug-restore will somewhat do the above, if the repo. has the old
> versions available.

I don't think that's the only sane way to do it, but it is the most 
obvious and adding a simple mechanism to yum to report the latest update 
timestamp or some repo transaction id(s) that could be fed to another 
instance to ensure it ignored subsequent changes to the repo(s) to 
perform an update to the same packages would be useful in its own right 
and appreciated when inherited by the enterprise versions.

> However Fedora only has the latest, so the only real
> alternative is creating a new repo. of somekind ... at which point you
> might as well just do a local mirror.

Fedora has this split personality about wanting to be both 
production-usable and also the leading edge where new code first meets a 
lot of new situations.  You can't quite be both at once. However, it 
could actually pull it off if there were a way designed in to avoid some 
of the bugs pushed out in updates on critical machines.  Asking every 
user to maintain a full repo mirror just doesn't sound like a reasonable 
approach to this though, especially if you think the mirrors themselves 
would have a problem storing all the updates.

It could be as simple as batching updates: suppose everything but 
critical security fixes and corrections for known-bad updates only 
updated every few weeks, and the user could could choose (with a 
permanent option) whether any particular machine should update on the 
leading or trailing edge of this window.

Or, pick a time frame reasonable both for mirrors to hold updates and 
for users to complete testing (2 months?) and only remove packages after 
their replacements have reached that age.

Or, what if one machine's yum automatically acted as a proxy for 
another's update, perhaps with an error generated if the package hadn't 
been downloaded already and if you want to be even more helpful, a 
warning if none of the code from a package had been run on the 
intermediate machine?   That way you'd get local mirroring of just the 
desired packages without extra work anywhere - in fact you'd get both 
repeatable updates and a load reduction on the mirrors out of it.  It's 
probably possible to do this now with a lot of extra steps.  Nobody is 
going to do it unless it is one step and looks like a cleverly planned 
design.

Or, design a working solution to back out broken changes.  The only one 
I'd trust would be to install with a spare system partition that is 
synchronized with the active one just before an update and used as an 
alternate boot for a fairly drastic fail-back mechanism.  And even that 
won't work where file formats of things in other partitions are modified 
in an update.

-- 
    Les Mikesell
    lesmikesell at gmail.com






From sgrubb at redhat.com  Tue Dec  9 21:54:54 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Tue, 9 Dec 2008 16:54:54 -0500
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
References: <20081205195914.GB3227@free.fr> <20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
Message-ID: <200812091654.54676.sgrubb@redhat.com>

>> I won't push this more, somebody else has to volunteer to make this
>> happen. I think it could be done in F11 and it should be a feature.
>
>Does fcron have the selinux context support that was added to cronie?
>
>joe

I just checked...

1) it does not support polyinstantiation. 
2) It also does not send audit events based on denying a cron job. 
3) Its pam settings do not support the audit system out of the box. 
4) Its default pam settings need alignment with vixie-cron in general.

My guess is that fcron needs work to be able to use it in high security 
environments.

-Steve



From james at fedoraproject.org  Tue Dec  9 22:23:46 2008
From: james at fedoraproject.org (James Antill)
Date: Tue, 09 Dec 2008 17:23:46 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493EE81B.6000909@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
Message-ID: <1228861426.30987.57.camel@code.and.org>

On Tue, 2008-12-09 at 15:50 -0600, Les Mikesell wrote:
> James Antill wrote:
> > On Tue, 2008-12-09 at 09:43 -0900, Jeff Spaleta wrote:
> >> On Tue, Dec 9, 2008 at 9:33 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> >>> But, as I've mentioned before, I think you'd get much better public
> >>> participation in testing if yum could do repeatable updates.  That is, I'm
> >>> only interested in testing exactly the update that I will later do on my own
> >>> more critical machine(s) and I'm not interested enough to maintain my own
> >>> mirrored repository which is currently the only way to get exactly the same
> >>> set of programs installed on 2 different machines at different times.
> >> Do you mean.... we require all the mirrors to hold all version of all
> >> updates for a release cycle?
> > 
> >  Yes, that's the only sane way to do it. yum-debug-dump /
> > yum-debug-restore will somewhat do the above, if the repo. has the old
> > versions available.
> 
> I don't think that's the only sane way to do it,

 And yet you haven't illuminated what those other sane ways are.

>  but it is the most 
> obvious and adding a simple mechanism to yum to report the latest update 
> timestamp or some repo transaction id(s) that could be fed to another 
> instance to ensure it ignored subsequent changes to the repo(s) to 
> perform an update to the same packages would be useful in its own right 
> and appreciated when inherited by the enterprise versions.

 What is this "repo. transaction ids" ... how is that different from a
local mirror. Even better question how is it _better_.
 Everyone who spends five minutes thinking about it comes up with "I
know we'll merge the functionality of git and yum, so that you can
follow branches in a repo. etc." ... which _might_ be fine, if _they'd_
actually have to implement it. But I fail to see the significant
advantages over doing all of this work on the repo. side (and possibly
creating tools there, to help -- again, feel free to if you want this).

> > However Fedora only has the latest, so the only real
> > alternative is creating a new repo. of somekind ... at which point you
> > might as well just do a local mirror.
> 
> Fedora has this split personality about wanting to be both 
> production-usable and also the leading edge where new code first meets a 
> lot of new situations.  You can't quite be both at once.

 Those features are not binary flags, they are a line with
RHEL-2.1/CentOS-2.1 on one end and rawhide on the other. There are a lot
of points on that line and Fedora serves some of them well.

>  However, it 
> could actually pull it off if there were a way designed in to avoid some 
> of the bugs pushed out in updates on critical machines.

 By "avoid some of the bugs" I'm going to assume you mean "I want other
people to do work" ... which is nice, but not how it works.

>   Asking every 
> user to maintain a full repo mirror just doesn't sound like a reasonable 
> approach to this though, especially if you think the mirrors themselves 
> would have a problem storing all the updates.

 I'm not asking "every user" to do that. Let me show you this full
conversation, and hopefully it will be obvious:

. LES: I need to do X.

. JAMES: To do X you need a local repo.

. LES: Asking every user to maintain a local repo. isn't reasonable.

> It could be as simple as batching updates: suppose everything but 
> critical security fixes and corrections for known-bad updates only 
> updated every few weeks, and the user could could choose (with a 
> permanent option) whether any particular machine should update on the 
> leading or trailing edge of this window.

 We already have updates-testing and --security, --bz. Which basically
do this ... if you think things should stay in updates-testing longer,
propose some reasoning to FESCo/whatever.
 Making updates become updates-testing2 based on an opaque time window
is not the solution though, IMO.

> Or, pick a time frame reasonable both for mirrors to hold updates and 
> for users to complete testing (2 months?) and only remove packages after 
> their replacements have reached that age.

 Have you spoken to anyone about how much data that would be, and how
much the mirror admins would like/want it? This is the fundamental
problem with keeping all the data for old updates ... the mirror admins
don't want to commit.
 If you have a local need for it though, you can presumably afford the
resources.

> Or, what if one machine's yum automatically acted as a proxy for 
> another's update, perhaps with an error generated if the package hadn't 
> been downloaded already and if you want to be even more helpful, a 
> warning if none of the code from a package had been run on the 
> intermediate machine?

 You want a specific collection of packages to be exported for other yum
clients to use ... we have this, it's called a repo.

>    That way you'd get local mirroring of just the 
> desired packages without extra work anywhere - in fact you'd get both 
> repeatable updates and a load reduction on the mirrors out of it.

 A mirror that is different from it's upstream repo. _isn't a mirror_.
 Yes, you can create a local repo. using data from a remote repo. as
it's basis ... but unless it's identical (within a limited timeframe)
then it isn't a mirror.

>   It's 
> probably possible to do this now with a lot of extra steps.  Nobody is 
> going to do it unless it is one step and looks like a cleverly planned 
> design.

 It kinda works right now, with Fedora, because Fedora doesn't sign the
repomd.xml or use metalinks to validate the repomd.xml ... both of those
things will change in Fedora 11 (and metalinks can be used now). At
which point yum will reject a mirror which isn't.

> Or, design a working solution to back out broken changes.  The only one 
> I'd trust would be to install with a spare system partition that is 
> synchronized with the active one just before an update and used as an 
> alternate boot for a fairly drastic fail-back mechanism.  And even that 
> won't work where file formats of things in other partitions are modified 
> in an update.

 Yeh, good luck with that, but it's far from a yum problem if you want
to follow that route.

-- 
James Antill <james at fedoraproject.org>
Fedora



From opensource at till.name  Tue Dec  9 22:23:53 2008
From: opensource at till.name (Till Maas)
Date: Tue, 09 Dec 2008 23:23:53 +0100
Subject: Displaying %doc and language specific files of an rpm
Message-ID: <200812092323.59642.opensource@till.name>

On Mon December 1 2008, Panu Matilainen wrote:

> Docs, config files, ghosts and the like can be viewed with this ('d' is
> for doc):
> rpm -qp --qf "[%{fileflags:fflags} %{filenames}\n]" <pkg>

I want to extend this to display a "-> linktarget" if a file is a symlink. 
This is what I tried, but it always adds the "->":

rpm -qp --qf "[%{filenames} %|filelinktos?{-> %{filelinktos}}:{}| \n]"

Do you know, how to make this work? I found the %|foo?{bar}:{baz}| syntax in 
the queryformat doc file from rpm.

Regards,
Till

-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/187439a7/attachment.sig>

From rjones at redhat.com  Tue Dec  9 22:33:00 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 9 Dec 2008 22:33:00 +0000
Subject: Who is "mriddle (a t) valueclick.com" ?
Message-ID: <20081209223300.GA32716@thinkpad>


I've wondered this for a while.  mriddle (apparently "Marc Riddle",
according to a quick Google search) gets emailed every time I update
many types of Bugzillas, particularly Review Requests.

Rich.



From mspevack at redhat.com  Tue Dec  9 22:42:16 2008
From: mspevack at redhat.com (Max Spevack)
Date: Tue, 9 Dec 2008 23:42:16 +0100 (CET)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1215.91.32.106.49.1228861312.squirrel@www.gbc.net>
References: <1215.91.32.106.49.1228861312.squirrel@www.gbc.net>
Message-ID: <alpine.LFD.2.00.0812092339590.9594@localhost.localdomain>

Let's leave fedora-devel-list off this sub-thread for all future 
replies, since we're talking about the one item on Robert's list that 
isn't technical in nature, and leave it on fedora-ambassadors-list where 
it belongs.

This should be the LAST email in this thread to include 
fedora-devel-list.

Check your headers before you hit send!

Thanks,
Max



From jspaleta at gmail.com  Tue Dec  9 22:43:08 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 13:43:08 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493EE81B.6000909@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
Message-ID: <604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>

On Tue, Dec 9, 2008 at 12:50 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> It could be as simple as batching updates: suppose everything but critical
> security fixes and corrections for known-bad updates only updated every few
> weeks, and the user could could choose (with a permanent option) whether any
> particular machine should update on the leading or trailing edge of this
> window.

1) Couldn't you get most of what you want by having a yum plugin that
deliberately held back updates which were too new for your local
administration needs? if package build/release datestamps were
available in the repository metadata? We already have the security and
bugfix flags in the metadata.

2) 'known bad' assumes we actually know that updates are bad before we
release them. If we knew they were bad we wouldn't release them at
all.


>
> Or, pick a time frame reasonable both for mirrors to hold updates and for
> users to complete testing (2 months?) and only remove packages after their
> replacements have reached that age.
>
> Or, what if one machine's yum automatically acted as a proxy for another's
> update, perhaps with an error generated if the package hadn't been
> downloaded already and if you want to be even more helpful, a warning if
> none of the code from a package had been run on the intermediate machine?

Feel free to take over InstantMirror and extend it
https://fedorahosted.org/InstantMirror/

-jef



From opensource at till.name  Tue Dec  9 22:46:26 2008
From: opensource at till.name (Till Maas)
Date: Tue, 09 Dec 2008 23:46:26 +0100
Subject: Stalled "Merge Reviews" (Re: What Fedora makes sucking for me -
 or why I am NOT Fedora
In-Reply-To: <387131.49706.qm@web32808.mail.mud.yahoo.com>
References: <387131.49706.qm@web32808.mail.mud.yahoo.com>
Message-ID: <200812092346.32964.opensource@till.name>

On Tue December 9 2008, Orcan Ogetbil wrote:

> As I said there are ~800 packages awaiting a reviewer, and this number is
> not decreasing. An action should be taken soon. -Orcan

The number also seems not not increase and there were 20-40 reviews completed 
per week the last three weeks. Therefore it seems that we have at least enough 
reviewers to handle the incoming packages. My proposal to reduce the backlog 
would be to have review days, where reviewers meet e.g. in an irc channel, 
where submitters can ask for reviewers. Then possible issues can be fixed 
reasonable fast and the reviews be finished. Or even better would be to have 
always an easy way to identify review request submitters, that are currently 
online/will respond to issues fast. Maybe this could be done by joining an irc 
channel, too. Maybe with a bot that can be queried for reviews of people in 
that room.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/cf9121eb/attachment.sig>

From kevin.kofler at chello.at  Tue Dec  9 23:35:15 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Dec 2008 00:35:15 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<ghkq7m$46p$1@ger.gmane.org>	<20081209104955.55a363b2.mschwendt@gmail.com>	<20081209100229.GD3833@free.fr>	<20081209120300.GJ14496@killefiz>	<493E6D72.9020605@hi.is>
	<493E7EED.6010607@fedoraproject.org> <493E8CC3.7030307@hi.is>
Message-ID: <ghmvbk$qio$1@ger.gmane.org>

J?hann B. Gu?mundsson wrote:
> For a developer to be able to test his code he needs to test on all
> possible scenarios
> hw and sw related repeated times the n option ( if any ) his application
> can do.

Right, and there's absolutely no way we can do that. That's what
updates-testing is for. We developers/packagers test as much as possible
where possible (or should, at least ;-) ), but we can't test everything all
on our own. Sometimes we don't even have the required hardware. And
sometimes in the real world it is also more important to work on the next
fix than to test the one we just wrote.

        Kevin Kofler



From mschwendt at gmail.com  Tue Dec  9 23:35:41 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 10 Dec 2008 00:35:41 +0100
Subject: pkgconfig dep problems in rawhide 20081209
In-Reply-To: <20081209152742.63B281F81E0@releng2.fedora.phx.redhat.com>
References: <20081209152742.63B281F81E0@releng2.fedora.phx.redhat.com>
Message-ID: <20081210003541.fee743ad.mschwendt@gmail.com>

Non-devel packages with problematic pkgconfig auto-dependencies
on -devel packages:

=> avahi-sharp-0.6.22-13.fc11.i386 (avahi-0.6.22-13.fc11.src.rpm)
    /usr/lib/pkgconfig/avahi-sharp.pc
    REQUIRES: libgdiplus-devel

=> avahi-ui-sharp-0.6.22-13.fc11.i386 (avahi-0.6.22-13.fc11.src.rpm)
    /usr/lib/pkgconfig/avahi-ui-sharp.pc
    REQUIRES: avahi-sharp
    REQUIRES: libgdiplus-devel
    REQUIRES: gtk-sharp2-devel

=> deskbar-applet-2.25.1-5.fc11.i386 (deskbar-applet-2.25.1-5.fc11.src.rpm)
    /usr/lib/pkgconfig/deskbar-applet.pc
    REQUIRES: pygtk2-devel
    REQUIRES: pygobject2-devel
    REQUIRES: glib2-devel
    REQUIRES: pycairo-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: fontconfig-devel
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info
    REQUIRES: gnome-icon-theme
    REQUIRES: gnome-python2-desktop

=> flumotion-0.4.2-7.fc11.i386 (flumotion-0.4.2-7.fc11.src.rpm)
    /usr/lib/pkgconfig/flumotion.pc
    REQUIRES: gstreamer-python
    REQUIRES: pygtk2-devel
    REQUIRES: pygobject2-devel
    REQUIRES: glib2-devel
    REQUIRES: pycairo-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: fontconfig-devel
    REQUIRES: gstreamer-devel
    REQUIRES: libxml2-devel
    REQUIRES: check-devel

=> gmime-sharp-2.4.3-2.fc11.i386 (gmime-2.4.3-2.fc11.src.rpm)
    /usr/lib/pkgconfig/gmime-sharp-2.4.pc
    REQUIRES: libgdiplus-devel

=> gstreamer-python-0.10.12-2.fc11.i386 (gstreamer-python-0.10.12-2.fc11.src.rpm)
    PROVIDES: gstreamer-python-devel
    /usr/lib/pkgconfig/gst-python-0.10.pc
    REQUIRES: pygtk2-devel
    REQUIRES: pygobject2-devel
    REQUIRES: glib2-devel
    REQUIRES: pycairo-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: fontconfig-devel
    REQUIRES: gstreamer-devel
    REQUIRES: libxml2-devel
    REQUIRES: check-devel

=> pygoocanvas-0.10.0-3.fc11.i386 (pygoocanvas-0.10.0-3.fc11.src.rpm)
    /usr/lib/pkgconfig/pygoocanvas.pc
    REQUIRES: pygtk2-devel
    REQUIRES: pygobject2-devel
    REQUIRES: glib2-devel
    REQUIRES: pycairo-devel
    REQUIRES: cairo-devel
    REQUIRES: freetype-devel
    REQUIRES: pixman-devel
    REQUIRES: libpng-devel
    REQUIRES: libXrender-devel
    REQUIRES: libX11-devel
    REQUIRES: libXdmcp-devel
    REQUIRES: xorg-x11-proto-devel
    REQUIRES: mesa-libGL-devel
    REQUIRES: libXau-devel
    REQUIRES: libxcb-devel
    REQUIRES: fontconfig-devel

=> tomboy-0.13.1-6.fc11.i386 (tomboy-0.13.1-6.fc11.src.rpm)
    /usr/lib/pkgconfig/tomboy-addins.pc
    REQUIRES: libgdiplus-devel
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info
    REQUIRES: gnome-icon-theme
    REQUIRES: gtk-sharp2-devel
    REQUIRES: xorg-x11-font-utils

=> ustr-debug-1.0.4-7.fc10.i386 (ustr-1.0.4-7.fc10.src.rpm)
    /usr/lib/pkgconfig/ustr-debug.pc
    REQUIRES: ustr-devel


========================================================================

Non-devel packages with harmless pkgconfig files:

=> 1:control-center-2.25.2-6.fc11.i386 (control-center-2.25.2-6.fc11.src.rpm)
    /usr/share/pkgconfig/gnome-default-applications.pc
    /usr/share/pkgconfig/gnome-keybindings.pc
    REQUIRES: gnome-icon-theme
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info

=> 1:emacs-el-22.3-2.fc11.i386 (emacs-22.3-2.fc11.src.rpm)
    /usr/share/pkgconfig/emacs.pc

=> 1:xorg-x11-font-utils-7.2-6.fc10.i386 (xorg-x11-font-utils-7.2-6.fc10.src.rpm)
    /usr/lib/pkgconfig/fontutil.pc

=> bodr-8-1.fc9.noarch (bodr-8-1.fc9.src.rpm)
    /usr/share/pkgconfig/bodr.pc

=> chemical-mime-data-0.1.94-3.fc8.noarch (chemical-mime-data-0.1.94-3.fc8.src.rpm)
    /usr/share/pkgconfig/chemical-mime-data.pc
    REQUIRES: shared-mime-info

=> compiz-bcop-0.7.8-1.fc11.noarch (compiz-bcop-0.7.8-1.fc11.src.rpm)
    /usr/share/pkgconfig/bcop.pc

=> freehdl-0.0.6-2.fc10.i386 (freehdl-0.0.6-2.fc10.src.rpm)
    /usr/lib/pkgconfig/freehdl.pc

=> gnome-doc-utils-stylesheets-0.14.0-7.fc11.noarch (gnome-doc-utils-0.14.0-7.fc11.src.rpm)
    /usr/share/pkgconfig/gnome-doc-utils.pc
    /usr/share/pkgconfig/xml2po.pc

=> gnome-icon-theme-2.24.0-1.fc10.noarch (gnome-icon-theme-2.24.0-1.fc10.src.rpm)
    /usr/share/pkgconfig/gnome-icon-theme.pc

=> gnome-mime-data-2.18.0-3.fc10.noarch (gnome-mime-data-2.18.0-3.fc10.src.rpm)
    /usr/share/pkgconfig/gnome-mime-data-2.0.pc

=> gnome-python2-desktop-2.24.0-5.fc11.i386 (gnome-python2-desktop-2.24.0-5.fc11.src.rpm)
    /usr/lib/pkgconfig/gnome-python-desktop-2.0.pc
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info

=> gnome-python2-extras-2.19.1-26.fc11.i386 (gnome-python2-extras-2.19.1-26.fc11.src.rpm)
    /usr/lib/pkgconfig/gnome-python-extras-2.0.pc
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info

=> gnome-screensaver-2.25.1-2.fc11.i386 (gnome-screensaver-2.25.1-2.fc11.src.rpm)
    /usr/lib/pkgconfig/gnome-screensaver.pc
    REQUIRES: gnome-mime-data
    REQUIRES: shared-mime-info
    REQUIRES: gnome-icon-theme

=> gtk-doc-1.11-2.fc11.noarch (gtk-doc-1.11-2.fc11.src.rpm)
    /usr/share/pkgconfig/gtk-doc.pc

=> gtk-sharp2-gapi-2.12.5-2.fc11.i386 (gtk-sharp2-2.12.5-2.fc11.src.rpm)
    /usr/lib/pkgconfig/gapi-2.0.pc

=> icon-naming-utils-0.8.7-1.fc10.noarch (icon-naming-utils-0.8.7-1.fc10.src.rpm)
    /usr/share/pkgconfig/icon-naming-utils.pc

=> libXaw-compat-1.0.4-3.fc10.i386 (libXaw-1.0.4-3.fc10.src.rpm)
    /usr/lib/pkgconfig/xaw6.pc

=> nfs-utils-lib-1.1.4-1.fc10.i386 (nfs-utils-lib-1.1.4-1.fc10.src.rpm)
    /usr/lib/pkgconfig/libnfsidmap.pc
    /usr/lib/pkgconfig/librpcsecgss.pc

=> notify-python-0.1.1-5.fc11.i386 (notify-python-0.1.1-5.fc11.src.rpm)
    /usr/lib/pkgconfig/notify-python.pc

=> python-gtkextra-1.1.0-3.fc10.i386 (python-gtkextra-1.1.0-3.fc10.src.rpm)
    /usr/lib/pkgconfig/python-gtkextra.pc

=> samba-common-3.2.5-0.23.fc11.i386 (samba-3.2.5-0.23.fc11.src.rpm)
    /usr/lib/pkgconfig/netapi.pc

=> shared-mime-info-0.51-5.fc11.i386 (shared-mime-info-0.51-5.fc11.src.rpm)
    /usr/share/pkgconfig/shared-mime-info.pc

=> xcb-proto-1.2-3.fc11.noarch (xcb-proto-1.2-3.fc11.src.rpm)
    /usr/share/pkgconfig/xcb-proto.pc

=> xorg-x11-xbitmaps-1.0.1-6.fc10.i386 (xorg-x11-xbitmaps-1.0.1-6.fc10.src.rpm)
    PROVIDES: xbitmaps-devel
    /usr/lib/pkgconfig/xbitmaps.pc



From kevin.kofler at chello.at  Tue Dec  9 23:36:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Dec 2008 00:36:02 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
Message-ID: <ghmvd2$qio$2@ger.gmane.org>

Sven Lankes wrote:
> Which then leads to the question, why a broken package was pushed to
> stable in the first place.

Because it was deemed a security update, complete with a CVE ID, and pushed
directly to stable.

        Kevin Kofler



From mclasen at redhat.com  Tue Dec  9 23:40:35 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 09 Dec 2008 18:40:35 -0500
Subject: Seahorse is orphaned?
In-Reply-To: <604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>
References: <3170f42f0812010315v1995ea4aid830b86a551f7a59@mail.gmail.com>
	<1228141066.3391.6.camel@localhost.localdomain>
	<493D24D1.6050202@redhat.com>
	<1228751408.3539.7.camel@localhost.localdomain>
	<604aa7910812081423w108cfdc8y5febe935a64050ae@mail.gmail.com>
Message-ID: <1228866035.7475.1.camel@matthiasc>

On Mon, 2008-12-08 at 13:23 -0900, Jeff Spaleta wrote:

> Assuming seahorse is not installed on the system can you describe how
> you expect typical desktop users who need the functionality that
> seahorse provides to find it and install it without knowing the
> package name before hand? A screencast of you pretending to be a user
> installing searching for and installing seahorse would be interesting
> to watch.

Here is a screencast of me playing 'Jeff, the user':
http://people.redhat.com/mclasen/install-seahorse.ogg


> Once installed how do users know where to look in the menus to find it?

The screencast was taken with PackageKit 0.3.x. PackageKit 0.4.0 (in
rawhide tomorrow) will show the menu path in the 'new application'
dialog that you see at the end.


Matthias



From kevin.kofler at chello.at  Tue Dec  9 23:45:24 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Dec 2008 00:45:24 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
Message-ID: <ghmvuk$v45$1@ger.gmane.org>

Michael Schwendt wrote:
> Fedora has a serious problem with updates that are pushed out to "stable"
> directly. Originally we've had a guideline to use updates-testing for
> a few days.

I think we need to differentiate, not all updates pushed straight to stable
are bad. Some updates really bear essentially no risk, for example an
update which just restores a bugfix patch which accidentally got forgotten
while rebasing to a new version, e.g.:
https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11045
https://admin.fedoraproject.org/updates/F9/FEDORA-2008-11054
(and yes, the rebase to the new version *did* go through testing, the
regression was not noticed there unfortunately). It also makes sense to
push critical security updates directly to stable, like a trivial fix for a
remote root. The problem is when the security update is not critical (at
least not to the point where it would have been fixed in less than a
month!) and the fix is very much non-obvious and risky, but it still gets
the expedited treatment.

> I'm also surprised to find discrepancies between Rawhide (just 1-2 weeks
> before F10 release) and F10 final.

The first weeks of Rawhide after a release are always a horribly broken
mess, why are you surprised? It's called "pre-alpha software".

        Kevin Kofler



From jspaleta at gmail.com  Wed Dec 10 00:05:49 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 15:05:49 -0900
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <ghmvuk$v45$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<ghmvuk$v45$1@ger.gmane.org>
Message-ID: <604aa7910812091605n6a95a0ecxb0df579748feef46@mail.gmail.com>

On Tue, Dec 9, 2008 at 2:45 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> I'm also surprised to find discrepancies between Rawhide (just 1-2 weeks
>> before F10 release) and F10 final.
>
> The first weeks of Rawhide after a release are always a horribly broken
> mess, why are you surprised? It's called "pre-alpha software".

I think you read that backwards. I think he's saying that F10 final
had regressions compared to rawhide 1-2 weeks before release.

-jef



From kevin.kofler at chello.at  Wed Dec 10 00:10:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Dec 2008 01:10:55 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<ghmvuk$v45$1@ger.gmane.org>
	<604aa7910812091605n6a95a0ecxb0df579748feef46@mail.gmail.com>
Message-ID: <ghn1ef$312$1@ger.gmane.org>

Jeff Spaleta wrote:
> I think you read that backwards. I think he's saying that F10 final
> had regressions compared to rawhide 1-2 weeks before release.

Oh, indeed I did.

Well, the changes which went in at the last moment were all fixes for
critical showstoppers.

        Kevin Kofler



From mschwendt at gmail.com  Wed Dec 10 00:19:12 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 10 Dec 2008 00:19:12 -0000
Subject: Broken dependencies in Fedora 10 - 2008-12-10
Message-ID: <20081210001912.2084.59721@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by owner):

    aconway AT redhat.com
        qpidc

    cooly AT gnome.eu.org
        fuse-emulator
        fuse-emulator-utils

    dhuff AT redhat.com
        appliance-tools

    jspaleta AT gmail.com
        python-basemap

    mr.ecik AT gmail.com
        kadu

    nphilipp AT redhat.com
        ufraw

    silfreed AT silfreed.net
        qgis

    smparrish AT shallowcreek.net
        kpackagekit

    sundaram AT redhat.com
        gyachi
        olpc-utils


======================================================================
Broken packages in fedora-10-i386:

    fuse-emulator-0.9.0-4.fc10.i386  requires  libspectrum.so.5
    fuse-emulator-utils-0.9.0-3.fc10.i386  requires  libspectrum.so.5
    gyachi-plugin-photo_album-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kpackagekit-0.3.1-4.fc10.i386  requires  libpackagekit-qt.so.10
    python-basemap-0.99-5.fc10.i386  requires  libgeos-3.0.1.so
    qgis-0.11.0-3.fc10.i386  requires  libgeos-3.0.1.so
    qgis-grass-0.11.0-3.fc10.i386  requires  libgeos-3.0.1.so
    qgis-python-0.11.0-3.fc10.i386  requires  libgeos-3.0.1.so
    qpidd-cluster-0.3.705289-1.fc10.i386  requires  qpidd = 0:0.3.705289-1.fc10


======================================================================
Broken packages in fedora-10-ppc:

    fuse-emulator-0.9.0-4.fc10.ppc  requires  libspectrum.so.5
    fuse-emulator-utils-0.9.0-3.fc10.ppc  requires  libspectrum.so.5
    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kpackagekit-0.3.1-4.fc10.ppc  requires  libpackagekit-qt.so.10
    python-basemap-0.99-5.fc10.ppc  requires  libgeos-3.0.1.so
    qgis-0.11.0-3.fc10.ppc  requires  libgeos-3.0.1.so
    qgis-0.11.0-3.fc10.ppc64  requires  libgeos-3.0.1.so()(64bit)
    qgis-grass-0.11.0-3.fc10.ppc  requires  libgeos-3.0.1.so
    qgis-grass-0.11.0-3.fc10.ppc64  requires  libgeos-3.0.1.so()(64bit)
    qgis-python-0.11.0-3.fc10.ppc  requires  libgeos-3.0.1.so
    qgis-python-0.11.0-3.fc10.ppc64  requires  libgeos-3.0.1.so()(64bit)


======================================================================
Broken packages in fedora-10-ppc64:

    fuse-emulator-0.9.0-4.fc10.ppc64  requires  libspectrum.so.5()(64bit)
    fuse-emulator-utils-0.9.0-3.fc10.ppc64  requires  libspectrum.so.5()(64bit)
    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kpackagekit-0.3.1-4.fc10.ppc64  requires  libpackagekit-qt.so.10()(64bit)
    python-basemap-0.99-5.fc10.ppc64  requires  libgeos-3.0.1.so()(64bit)
    qgis-0.11.0-3.fc10.ppc64  requires  libgeos-3.0.1.so()(64bit)
    qgis-grass-0.11.0-3.fc10.ppc64  requires  libgeos-3.0.1.so()(64bit)
    qgis-python-0.11.0-3.fc10.ppc64  requires  libgeos-3.0.1.so()(64bit)


======================================================================
Broken packages in fedora-10-x86_64:

    fuse-emulator-0.9.0-4.fc10.x86_64  requires  libspectrum.so.5()(64bit)
    fuse-emulator-utils-0.9.0-3.fc10.x86_64  requires  libspectrum.so.5()(64bit)
    gyachi-plugin-photo_album-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kpackagekit-0.3.1-4.fc10.x86_64  requires  libpackagekit-qt.so.10()(64bit)
    python-basemap-0.99-5.fc10.x86_64  requires  libgeos-3.0.1.so()(64bit)
    qgis-0.11.0-3.fc10.i386  requires  libgeos-3.0.1.so
    qgis-0.11.0-3.fc10.x86_64  requires  libgeos-3.0.1.so()(64bit)
    qgis-grass-0.11.0-3.fc10.i386  requires  libgeos-3.0.1.so
    qgis-grass-0.11.0-3.fc10.x86_64  requires  libgeos-3.0.1.so()(64bit)
    qgis-python-0.11.0-3.fc10.i386  requires  libgeos-3.0.1.so
    qgis-python-0.11.0-3.fc10.x86_64  requires  libgeos-3.0.1.so()(64bit)
    qpidd-cluster-0.3.705289-1.fc10.x86_64  requires  qpidd = 0:0.3.705289-1.fc10


======================================================================
Broken packages in fedora-updates-10-i386:

    olpc-utils-0.89-6.fc10.i386  requires  olpcupdate >= 0:2.10


======================================================================
Broken packages in fedora-updates-10-ppc:

    olpc-utils-0.89-6.fc10.ppc  requires  olpcupdate >= 0:2.10


======================================================================
Broken packages in fedora-updates-10-ppc64:

    appliance-tools-003.9-1.fc10.noarch  requires  qemu-img
    olpc-utils-0.89-6.fc10.ppc64  requires  olpcupdate >= 0:2.10


======================================================================
Broken packages in fedora-updates-10-x86_64:

    olpc-utils-0.89-6.fc10.x86_64  requires  olpcupdate >= 0:2.10


======================================================================
Broken packages in fedora-updates-testing-10-i386:

    ufraw-cinepaint-0.14.1-3.fc10.i386  requires  cinepaint(x86-32)


======================================================================
Broken packages in fedora-updates-testing-10-ppc:

    ufraw-cinepaint-0.14.1-3.fc10.ppc  requires  cinepaint(ppc-32)


======================================================================
Broken packages in fedora-updates-testing-10-ppc64:

    ufraw-cinepaint-0.14.1-3.fc10.ppc64  requires  cinepaint(ppc-64)


======================================================================
Broken packages in fedora-updates-testing-10-x86_64:

    ufraw-cinepaint-0.14.1-3.fc10.x86_64  requires  cinepaint(x86-64)



From kevin.kofler at chello.at  Wed Dec 10 00:22:12 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Dec 2008 01:22:12 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
Message-ID: <ghn23k$50a$1@ger.gmane.org>

Colin Walters wrote:
> Just to be clear, the direct push into stable is my fault; not Red
> Hat's or other DBus developers or anyone else's.  I had originally
> listed it for updates-testing, but then changed the update to security
> and in a moment of total stupidity also changed the listing for
> stable.

Are you sure you were the one who requested the push to stable and not the
security team (when they gave their approval for the security update)?

I'm asking because the way Bodhi is set up, I think the security team does
not see where you actually intend security updates to be pushed to, they
all show up as requests for testing until they get approval, and somehow
they automatically get queued for stable on approval unless explicitly
canceled.

All this was so much simpler and more obvious before that useless security
team approval step was introduced (without really consulting packagers
outside of the security team). :-( What benefit does that approval step
bring us? It's obviously not QA or this update wouldn't have ended up in
stable!

        Kevin Kofler



From lesmikesell at gmail.com  Wed Dec 10 00:22:00 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 09 Dec 2008 18:22:00 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228861426.30987.57.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
Message-ID: <493F0BA8.1050300@gmail.com>

James Antill wrote:
> 
>> I don't think that's the only sane way to do it,
> 
>  And yet you haven't illuminated what those other sane ways are.

I thought I did.

> 
>>  but it is the most 
>> obvious and adding a simple mechanism to yum to report the latest update 
>> timestamp or some repo transaction id(s) that could be fed to another 
>> instance to ensure it ignored subsequent changes to the repo(s) to 
>> perform an update to the same packages would be useful in its own right 
>> and appreciated when inherited by the enterprise versions.
> 
>  What is this "repo. transaction ids" 

If you tracked changes in a repo, yum could use that to ensure that it 
didn't pull newer packages when you were trying to reproduce a tested 
update.

... how is that different from a
> local mirror. Even better question how is it _better_.

Ummm, it saves every user a boatload of work and disk space... More to 
the point it is something that they might actually do.

>  Everyone who spends five minutes thinking about it comes up with "I
> know we'll merge the functionality of git and yum, so that you can
> follow branches in a repo. etc." ... which _might_ be fine, if _they'd_
> actually have to implement it. But I fail to see the significant
> advantages over doing all of this work on the repo. side (and possibly
> creating tools there, to help -- again, feel free to if you want this).

Yes, it is clear that you need version control capability in a package 
manager.  And it is equally clear that yum doesn't provide it.  So some 
simple workaround is necessary.  Ultimately, I'd love to see git or 
subversion managing the list of package names _and_ all locally modified 
config files, but a first cut could be just a planned, sane way to 
reproduce a tested set of packages since everyone knows that fedora's 
repos have their good days and bad days.  _Any_ way to keep untested 
packages on a test machine and exactly the tested set on production 
machines is better than none.  We aren't talking about people who will 
test and people who want someone else to do it - I mean this for people 
with more than one machine, where some actually have to work every day.

>>> However Fedora only has the latest, so the only real
>>> alternative is creating a new repo. of somekind ... at which point you
>>> might as well just do a local mirror.
>> Fedora has this split personality about wanting to be both 
>> production-usable and also the leading edge where new code first meets a 
>> lot of new situations.  You can't quite be both at once.
> 
>  Those features are not binary flags, they are a line with
> RHEL-2.1/CentOS-2.1 on one end and rawhide on the other. There are a lot
> of points on that line and Fedora serves some of them well.

That's not what I mean. There are days when what you get mostly-working 
code in a fedora update and days you don't.   I'm not talking about 
rawhide or RHEL,. just about what happens when a large number of users 
run something new for the first time which is what happens in fedora.

>>  However, it 
>> could actually pull it off if there were a way designed in to avoid some 
>> of the bugs pushed out in updates on critical machines.
> 
>  By "avoid some of the bugs" I'm going to assume you mean "I want other
> people to do work" ... which is nice, but not how it works.

No, I have said I would do much more testing if given a design where I 
knew I could subsequently update a working machine to exactly the same 
set of packages I had tested.  I'm just not willing to mirror a whole 
repository to deal with this on my own.

>>   Asking every 
>> user to maintain a full repo mirror just doesn't sound like a reasonable 
>> approach to this though, especially if you think the mirrors themselves 
>> would have a problem storing all the updates.
> 
>  I'm not asking "every user" to do that. Let me show you this full
> conversation, and hopefully it will be obvious:
> 
> . LES: I need to do X.

You misunderstood.  I'm not prepared to be the only tester. I mean "if 
you do X, many more people will test".  Basically everyone who runs 
fedora needs to do X unless they can afford to be down a while.

> . JAMES: To do X you need a local repo.
> 
> . LES: Asking every user to maintain a local repo. isn't reasonable.

OK, asking any user to maintain a local repo isn't reasonable. I'm not 
going to do it anyway.  And expecting a lot of people to do it is less 
so, along with expecting any users to be able to test package sets they 
can't reproduce.

>> It could be as simple as batching updates: suppose everything but 
>> critical security fixes and corrections for known-bad updates only 
>> updated every few weeks, and the user could could choose (with a 
>> permanent option) whether any particular machine should update on the 
>> leading or trailing edge of this window.
> 
>  We already have updates-testing and --security, --bz. Which basically
> do this ... if you think things should stay in updates-testing longer,
> propose some reasoning to FESCo/whatever.
>  Making updates become updates-testing2 based on an opaque time window
> is not the solution though, IMO.

Why is the time window opaque?  Again, why do you expect anyone to test, 
whether from updates-testing or elsewhere without a mechanism to use 
exactly the package set that they tested on their working machines?

>> Or, pick a time frame reasonable both for mirrors to hold updates and 
>> for users to complete testing (2 months?) and only remove packages after 
>> their replacements have reached that age.
> 
>  Have you spoken to anyone about how much data that would be, and how
> much the mirror admins would like/want it? This is the fundamental
> problem with keeping all the data for old updates ... the mirror admins
> don't want to commit.
>  If you have a local need for it though, you can presumably afford the
> resources.

I don't have a local need for it other than testing fedora, which, if it 
can't be done without maintaining more disk space than the people in the 
business of maintaining mirrors can handle, I'll just ignore.

>> Or, what if one machine's yum automatically acted as a proxy for 
>> another's update, perhaps with an error generated if the package hadn't 
>> been downloaded already and if you want to be even more helpful, a 
>> warning if none of the code from a package had been run on the 
>> intermediate machine?
> 
>  You want a specific collection of packages to be exported for other yum
> clients to use ... we have this, it's called a repo.

No, a repo is where you put new packages in.  A cache is where you get 
ones you've gotten before.  One instance of yum acting as a proxy cache 
for others would be a minimalist solution, since yum already knows how 
to cache and how to use a proxy.

>>    That way you'd get local mirroring of just the 
>> desired packages without extra work anywhere - in fact you'd get both 
>> repeatable updates and a load reduction on the mirrors out of it.
> 
>  A mirror that is different from it's upstream repo. _isn't a mirror_.
>  Yes, you can create a local repo. using data from a remote repo. as
> it's basis ... but unless it's identical (within a limited timeframe)
> then it isn't a mirror.

I don't want a mirror of a revolving door repo.  I want a reproducible 
update.  The mechanism is sort-of irrelevant.

>>   It's 
>> probably possible to do this now with a lot of extra steps.  Nobody is 
>> going to do it unless it is one step and looks like a cleverly planned 
>> design.
> 
>  It kinda works right now, with Fedora, because Fedora doesn't sign the
> repomd.xml or use metalinks to validate the repomd.xml ... both of those
> things will change in Fedora 11 (and metalinks can be used now). At
> which point yum will reject a mirror which isn't.

I don't want a mirror, I want a cache.  And yum had better keep working 
with proxy caches.

>> Or, design a working solution to back out broken changes.  The only one 
>> I'd trust would be to install with a spare system partition that is 
>> synchronized with the active one just before an update and used as an 
>> alternate boot for a fairly drastic fail-back mechanism.  And even that 
>> won't work where file formats of things in other partitions are modified 
>> in an update.
> 
>  Yeh, good luck with that, but it's far from a yum problem if you want
> to follow that route.

One way or another, if I were building a distribution that wanted to 
simultaneously claim that it is both new code and 'tested and working', 
I'd try to plan in a way that it wasn't a flip of the coin on every 
machine which you'll get today.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From ivazqueznet at gmail.com  Wed Dec 10 00:24:17 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 09 Dec 2008 19:24:17 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<corn06xveo.ln2@ppp1053.in.ipex.cz> <493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com> <493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
Message-ID: <1228868657.15367.138.camel@ignacio.lan>

On Tue, 2008-12-09 at 13:05 -0600, Arthur Pemberton wrote:
> 2008/12/9 Toshio Kuratomi <a.badger at gmail.com>:
> > So let me reiterate:
> >
> > * python-3.x will not be in Fedora-11 unless it becomes obvious in the
> > next few weeks that we absolutely must be running it for the next release.
> > * we need more experience with python-2.6+ & python-3 compatibility
> > before we decide whether parallel versions of python are necessary.
> >
> > .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
> >
> > -Toshio
> 
> 
> Well again. Some people (like Toshio) seem to have a grasp on the
> matter. All this banter hasn't produced anything more of use. How
> about forming a temp SIG to take care of this trusting they do the
> right thing?

As opposed to the Python SIG that already exists?

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081209/55583918/attachment.sig>

From jspaleta at gmail.com  Wed Dec 10 00:33:02 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 15:33:02 -0900
Subject: Broken dependencies in Fedora 10 - 2008-12-10
In-Reply-To: <20081210001912.2084.59721@faldor.intranet>
References: <20081210001912.2084.59721@faldor.intranet>
Message-ID: <604aa7910812091633t531db611kbc2398f813a29993@mail.gmail.com>

On Tue, Dec 9, 2008 at 3:19 PM, Michael Schwendt <mschwendt at gmail.com> wrote:
>    jspaleta AT gmail.com
>        python-basemap
>    python-basemap-0.99-5.fc10.i386  requires  libgeos-3.0.1.so

Hmm geos-3.0.3 went out as an update and bumped the library and it
appears that it skipped testing and went straight to stable and was
not marked as security. Joy!
Let's see if I can get python-basemap rebuilt.

Now before I go ballistic over the fact that this skipped testing and
isnt marked as security... was that just a mistake or was that
intended?

-jef



From kevin.kofler at chello.at  Wed Dec 10 00:54:34 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Dec 2008 01:54:34 +0100
Subject: arial narrow is broken since Fedora 8
References: <493E56B2.7060101@gmail.com>
	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>
	<493E6F6A.3060806@gmail.com>
	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>
Message-ID: <ghn40c$9bs$1@ger.gmane.org>

Nicolas Mailhot wrote:
> It's not the right one, and again please spend your energy lobbying
> for a long term-fix in *every* upstream bugzilla instead of muddying
> waters by asking to a return to the good old days which won't happen
> as the technical context changed.

Please do not ignore real-world usability in your quest for perfection.

Half-baked support for useless font "features" is counterproductive. It's
similar with Latin ligatures (thankfully in that case the fix turned out
trivial, though it doesn't fix the issue completely because fonts may also
define ligatures other than the standard Unicode ligatures). IMHO it would
be much better to keep all those features disabled (at least by default)
until they actually *work* in all the major applications. If that's
forever, so be it, those features can all be done without.

Is having separate entries for "Arial" and "Arial Narrow" in the font list
really such a serious issue that avoiding it is so important that it is
worth breaking almost all applications in some way?

        Kevin Kofler



From behdad at behdad.org  Wed Dec 10 01:04:18 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 09 Dec 2008 20:04:18 -0500
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <ghn40c$9bs$1@ger.gmane.org>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>
	<ghn40c$9bs$1@ger.gmane.org>
Message-ID: <493F1592.5040707@behdad.org>

Kevin Kofler wrote:

> Half-baked support for useless font "features" is counterproductive. It's
> similar with Latin ligatures (thankfully in that case the fix turned out
> trivial, though it doesn't fix the issue completely because fonts may also
> define ligatures other than the standard Unicode ligatures).

Talk is cheap.  Show me the screenshot of a broken case.

> IMHO it would
> be much better to keep all those features disabled (at least by default)
> until they actually *work* in all the major applications. If that's
> forever, so be it, those features can all be done without.

Apparently thousands of people think it works.  If it doesn't for you, use
some pre-GNOME, pre-KDE desktop on Debian stale, err, stable.

> Is having separate entries for "Arial" and "Arial Narrow" in the font list
> really such a serious issue that avoiding it is so important that it is
> worth breaking almost all applications in some way?

That has nothing to do with why the bug is there.  The bug is there because no
one every got to fix it.  Part of the problem has been that I have no Free
fonts installed that show that behavior.

behdad

>         Kevin Kofler



From bnocera at redhat.com  Wed Dec 10 01:18:25 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 10 Dec 2008 01:18:25 +0000
Subject: nautilus depends on a lot of stuff via gvfs
In-Reply-To: <1228818420.3626.52.camel@eagle.danny.cz>
References: <1228818420.3626.52.camel@eagle.danny.cz>
Message-ID: <1228871905.24963.646.camel@cookie.hadess.net>

On Tue, 2008-12-09 at 11:27 +0100, Dan Hor?k wrote:
> Hi,
> 
> I was trying to remove samba-winbind (plus the rest of samba, because I
> don't need it and samba represents MBs of updates and tens of MB of used
> space) from my F-10 machine and found out that it will remove nautilus
> too.
> 
> Removing:
>  samba-winbind                      i386         3.2.5-0.23.fc10            installed         7.9 M
> Removing for dependencies:
>  gnome-vfs2-smb                     i386         2.24.0-3.fc10              installed          28 k
>  gvfs-smb                           i386         1.0.2-3.fc10               installed         255 k
>  hal-cups-utils                     i386         0.6.17-4.fc10              installed         100 k
>  libsmbclient                       i386         3.2.5-0.23.fc10            installed         3.8 M
>  nautilus                           i386         2.24.1-3.fc10              installed          13 M
>  samba-client                       i386         3.2.5-0.23.fc10            installed          27 M
>  samba-common                       i386         3.2.5-0.23.fc10            installed          29 M
>  system-config-printer              i386         1.0.9-1.fc10               installed         1.6 M
>  system-config-printer-libs         i386         1.0.9-1.fc10               installed         2.8 M
> 
> The problem is that nautilus has hard dependencies on many (all?) gvfs
> modules.

All of them, so things work out of the box.

>  Trying to remove libgphoto2 has similar effects.
> 
> So my proposal is to split nautilus into nautilus-core, that will
> contains the content of the current nautilus package, and nautilus
> "meta" package that will contains all the dependencies plus dependency
> on nautilus-core. This solution will install all the deps as today, but
> leave the option to remove the unnecessary packages afterwards.
> 
> Only 3 packages will be affected with this split
> nautilus-devel
> nautilus-python
> seahorse-plugins
> and they should be made to depend on nautilus-core instead of nautilus.
> 
> I will file a bug with the proposed change to nautilus spec file.

That's not workable. You'd probably rather rejigger the samba packages
so it's possible to use Samba in any appropriate environment without
dragging in the server, or the excessively big packages. You should do
the same for other dependencies.

Removing functionality from nautilus as it is installed by default won't
fix that problem.

Cheers



From bnocera at redhat.com  Wed Dec 10 01:29:07 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 10 Dec 2008 01:29:07 +0000
Subject: Scanner's firmware HOWTO and suggestions for improving user's
 experience with scanners
In-Reply-To: <1228604033.3495.90.camel@agnes.fremen.dune>
References: <1228604033.3495.90.camel@agnes.fremen.dune>
Message-ID: <1228872547.24963.662.camel@cookie.hadess.net>

On Sat, 2008-12-06 at 23:53 +0100, Jean Francois Martinez wrote:
> Some scanners need a firmawre file who, while it cannot be provided by 
> Fedora can be legally downloaded from the manufacturer's site.  The
> problem is that Fedora provides zero hints about it.  
> 
> I have an EPSON USB scanner (snapscan driver) and if you look at the
> sane-backends doc it says _nothing_ about firmware and it points to a
> web page who hasn't been updated in _eight_ years.  In other words
> official documentation is zero help.
> 
> In the following I detail what to do and make a few suggestions for
> improving user experience with scanners requiring firmware.

The SANE UI(s) should probably rely on PackageKit's session daemon to
download the file automatically, as necessary. This is a process similar
to what we have for codecs and kernel firmwares, and what we want to
have for mime-types and fonts.

Flegita (gnome-scan's scanner UI) is probably the best place to request
such a change. See
http://bugzilla.gnome.org/browse.cgi?product=gnome-scan and
http://projects.gnome.org/gnome-scan/index

Cheers



From bnocera at redhat.com  Wed Dec 10 01:39:39 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 10 Dec 2008 01:39:39 +0000
Subject: Orphaning thinkfinger
In-Reply-To: <4935FFE2.8050402@silfreed.net>
References: <4935FFE2.8050402@silfreed.net>
Message-ID: <1228873179.24963.674.camel@cookie.hadess.net>

On Tue, 2008-12-02 at 22:41 -0500, Douglas E. Warner wrote:
> I picked up this package thinking I could give it some love, but the bugs that 
> exist are out of my expertise.  I believe thinkfinger is largely being 
> superseded by libfprint, as well.

See also:
https://fedoraproject.org/wiki/Features/Fingerprint



From mclasen at redhat.com  Wed Dec 10 01:42:47 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 09 Dec 2008 20:42:47 -0500
Subject: nautilus depends on a lot of stuff via gvfs
In-Reply-To: <1228871905.24963.646.camel@cookie.hadess.net>
References: <1228818420.3626.52.camel@eagle.danny.cz>
	<1228871905.24963.646.camel@cookie.hadess.net>
Message-ID: <1228873368.7475.5.camel@matthiasc>

On Wed, 2008-12-10 at 01:18 +0000, Bastien Nocera wrote:

> > 
> > So my proposal is to split nautilus into nautilus-core, that will
> > contains the content of the current nautilus package, and nautilus
> > "meta" package that will contains all the dependencies plus dependency
> > on nautilus-core. This solution will install all the deps as today, but
> > leave the option to remove the unnecessary packages afterwards.
> > 
> > Only 3 packages will be affected with this split
> > nautilus-devel
> > nautilus-python
> > seahorse-plugins
> > and they should be made to depend on nautilus-core instead of nautilus.
> > 
> > I will file a bug with the proposed change to nautilus spec file.
> 
> That's not workable. You'd probably rather rejigger the samba packages
> so it's possible to use Samba in any appropriate environment without
> dragging in the server, or the excessively big packages. You should do
> the same for other dependencies.
> 
> Removing functionality from nautilus as it is installed by default won't
> fix that problem.

Fwiw, I don't think it is a big problem to change things so that gvfs
subpackages are pulled in by comps instead of by hard deps from
nautilus, as long as they are all in the default install. I don't
introducing a nautilus metapackage for this purpose is necessary or a
good idea. 



From jspaleta at gmail.com  Wed Dec 10 01:46:10 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 16:46:10 -0900
Subject: nautilus depends on a lot of stuff via gvfs
In-Reply-To: <1228873368.7475.5.camel@matthiasc>
References: <1228818420.3626.52.camel@eagle.danny.cz>
	<1228871905.24963.646.camel@cookie.hadess.net>
	<1228873368.7475.5.camel@matthiasc>
Message-ID: <604aa7910812091746s368a410cj4f5e89156aa9c3d9@mail.gmail.com>

On Tue, Dec 9, 2008 at 4:42 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> Fwiw, I don't think it is a big problem to change things so that gvfs
> subpackages are pulled in by comps instead of by hard deps from
> nautilus, as long as they are all in the default install. I don't
> introducing a nautilus metapackage for this purpose is necessary or a
> good idea.

In THE default install? Are you thinking about the traditional
installer and the Desktop spin here?

-jef



From bnocera at redhat.com  Wed Dec 10 01:46:47 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 10 Dec 2008 01:46:47 +0000
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <493224B2.60706@redhat.com>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1227522629.3675.2625.camel@cookie.hadess.net>
	<493224B2.60706@redhat.com>
Message-ID: <1228873607.24963.684.camel@cookie.hadess.net>

On Sun, 2008-11-30 at 00:29 -0500, Warren Togami wrote:
> Bastien Nocera wrote:
> >>
> >> There's no sound mixing (through ALSA or PulseAudio) when OSS emulation
> >> is used in ALSA. Kill it (and file a bug against the app).
> > 
> > Filed:
> > https://bugzilla.redhat.com/show_bug.cgi?id=472741
> > 
> 
> http://lwn.net/Articles/308445/
> CUSE: Character devices in user space
> 
> The first cuse driver is an OSS proxy to pulseaudio, that provides 
> /dev/dsp, /dev/adsp and /dev/mixer.  The article describes it as likely 
> to be merged in the upstream 2.6.29 kernel.  Let us help this become 
> stable so we can count on it for F11.
> 
> Assuming cuse OSS proxy is ready for F11, and it works reasonably well 
> as a complete replacement for ALSA's OSS compat layer, we would do the 
> following:
<snip>

I don't see this happening for F11, so I'll comment on the fallback
strategy.

> The fallback plan if cuse OSS proxy is not ready for F11...
> 
> 1) Keep the OSS kernel modules.
> 2) alsa-plugins-pulseaudio ships /etc/modprobe.d/blacklist-oss-sound, 
> thereby preventing loading of these kernel modules and interfering with 
> pulseaudio daemon.
> 3) If the user wants to use an OSS sound application they can use padsp 
> manually.
> 4) Native OSS comes back if the user uninstalls alsa-plugins-pulseaudio, 
> which also makes it so nothing uses pulseaudio for sound output by default.

You assume that using OSS on top of ALSA is only broken when PulseAudio
is involved. This isn't the case, dmix won't work when a program uses
OSS, so no sound mixing for you as soon as a single OSS app is used.

I'd rather a list of apps that use OSS in Fedora were compiled, so they
can be fixed.

Cheers



From pemboa at gmail.com  Wed Dec 10 02:40:43 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 9 Dec 2008 20:40:43 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <1228868657.15367.138.camel@ignacio.lan>
References: <49393DE3.1080707@redhat.com> <493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com> <493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
	<1228868657.15367.138.camel@ignacio.lan>
Message-ID: <16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>

2008/12/9 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Tue, 2008-12-09 at 13:05 -0600, Arthur Pemberton wrote:
>> 2008/12/9 Toshio Kuratomi <a.badger at gmail.com>:
>> > So let me reiterate:
>> >
>> > * python-3.x will not be in Fedora-11 unless it becomes obvious in the
>> > next few weeks that we absolutely must be running it for the next release.
>> > * we need more experience with python-2.6+ & python-3 compatibility
>> > before we decide whether parallel versions of python are necessary.
>> >
>> > .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
>> >
>> > -Toshio
>>
>>
>> Well again. Some people (like Toshio) seem to have a grasp on the
>> matter. All this banter hasn't produced anything more of use. How
>> about forming a temp SIG to take care of this trusting they do the
>> right thing?
>
> As opposed to the Python SIG that already exists?

No. Seems like the ideal body to come to a decision and let the rest
of us know.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From notting at redhat.com  Wed Dec 10 03:13:44 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 9 Dec 2008 22:13:44 -0500
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <1228873607.24963.684.camel@cookie.hadess.net>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1227522629.3675.2625.camel@cookie.hadess.net>
	<493224B2.60706@redhat.com>
	<1228873607.24963.684.camel@cookie.hadess.net>
Message-ID: <20081210031344.GA21432@nostromo.devel.redhat.com>

Bastien Nocera (bnocera at redhat.com) said: 
> > http://lwn.net/Articles/308445/
> > CUSE: Character devices in user space
> > 
> > The first cuse driver is an OSS proxy to pulseaudio, that provides 
> > /dev/dsp, /dev/adsp and /dev/mixer.  The article describes it as likely 
> > to be merged in the upstream 2.6.29 kernel.  Let us help this become 
> > stable so we can count on it for F11.
> > 
> > Assuming cuse OSS proxy is ready for F11, and it works reasonably well 
> > as a complete replacement for ALSA's OSS compat layer, we would do the 
> > following:
> <snip>
> 
> I don't see this happening for F11, so I'll comment on the fallback
> strategy.

FYI, one thing pointed out elsewhere about this strategy is that any
remaining OSS apps that use mmap() likely won't work with CUSE. Of
course, they wouldn't work with padsp either.

Bill



From notting at redhat.com  Wed Dec 10 03:17:51 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 9 Dec 2008 22:17:51 -0500
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <20081209223300.GA32716@thinkpad>
References: <20081209223300.GA32716@thinkpad>
Message-ID: <20081210031750.GB21432@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
> I've wondered this for a while.  mriddle (apparently "Marc Riddle",
> according to a quick Google search) gets emailed every time I update
> many types of Bugzillas, particularly Review Requests.

https://bugzilla.redhat.com/userprefs.cgi?tab=email

See 'user watching'.

People can set up bugstalking filters to get e-mailed any time someone
else would be e-mailed.

Bill



From mclasen at redhat.com  Wed Dec 10 03:47:03 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 09 Dec 2008 22:47:03 -0500
Subject: nautilus depends on a lot of stuff via gvfs
In-Reply-To: <604aa7910812091746s368a410cj4f5e89156aa9c3d9@mail.gmail.com>
References: <1228818420.3626.52.camel@eagle.danny.cz>
	<1228871905.24963.646.camel@cookie.hadess.net>
	<1228873368.7475.5.camel@matthiasc>
	<604aa7910812091746s368a410cj4f5e89156aa9c3d9@mail.gmail.com>
Message-ID: <1228880823.19941.3.camel@matthiasc>

On Tue, 2008-12-09 at 16:46 -0900, Jeff Spaleta wrote:
> On Tue, Dec 9, 2008 at 4:42 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> > Fwiw, I don't think it is a big problem to change things so that gvfs
> > subpackages are pulled in by comps instead of by hard deps from
> > nautilus, as long as they are all in the default install. I don't
> > introducing a nautilus metapackage for this purpose is necessary or a
> > good idea.
> 
> In THE default install? Are you thinking about the traditional
> installer and the Desktop spin here?

I was thinking about comps. Spins override the comps defaults according
to their needs in the .ks anyway.



From dgboles at gmail.com  Wed Dec 10 03:48:34 2008
From: dgboles at gmail.com (David)
Date: Tue, 09 Dec 2008 22:48:34 -0500
Subject: The developers/maintainers
Message-ID: <493F3C12.2050605@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First let me say that I do not belong here. I am not a developer nor am
I a maintainer.

I am a lurker with vested interests. I use, and enjoy, your product. Fedora.

Does *everything* always work from the box for me? The only thing that I
can think of is my monitor. It does not ID correctly so my start off
resolution is set incorrectly. But it does display. Is this your fault?
Of course not. My fault, in a way, because I selected the monitor.

Others things? Not any that I can recall. But if there were I would read
about them and fix them. If it was a major problem I would report it but
there are already too many that jump in the air and scream for me.  ;-)

Many of the reported problems do not affect me in any way.

DVD movies. I watch, from time to time, rented DVD movies with a DVD
player on my television. I only own two DVD movies. both of them gifts.
I can not see any reason to watch a movie on a small screen monitor.

Music CDs. I don't own any. I do listen to the radio on the way to and
from work. I can not see any reason to listen to music played from CDs
over my computer sound system.

I do not own or use a laptop. Nor do I own a 'webcam'. And my network
does not contain any 'special' cards that need drivers that are not
freely available.

I don't use anything that does not really come from Fedora. Hmm...
Flash. I forgot about Flash.

So? Does Fedora 'work from the box'? For me? Yes. A resounding yes! I am
lucky perhaps. Or maybe not as demanding as some.

Are there some things that don't work for some users? Yes. Of course.
But most of those are not 'your' doing. What you provide works with what
you provide.

IMO you have a fine product and you have nothing, absolutely
nothing, to apologize for with your product.

Thank you for Fedora.
- --


  David

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkk/PBIACgkQAO0wNI1X4QEGTgCg47Xqp//sL2326rsHfW6DDIfz
bGAAniUxb9tuLRc2z64CoN+WC66Q8BCz
=7uP+
-----END PGP SIGNATURE-----



From lesmikesell at gmail.com  Wed Dec 10 07:11:11 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 01:11:11 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>
Message-ID: <493F6B8F.8010209@gmail.com>

Jeff Spaleta wrote:
> On Tue, Dec 9, 2008 at 12:50 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> It could be as simple as batching updates: suppose everything but critical
>> security fixes and corrections for known-bad updates only updated every few
>> weeks, and the user could could choose (with a permanent option) whether any
>> particular machine should update on the leading or trailing edge of this
>> window.
> 
> 1) Couldn't you get most of what you want by having a yum plugin that
> deliberately held back updates which were too new for your local
> administration needs? if package build/release datestamps were
> available in the repository metadata? We already have the security and
> bugfix flags in the metadata.

Maybe, but the repos would still have to have overlapping package sets 
and the yum plugin would have to be able to distinguish between a new 
'feature-update' package that it should defer and a fix to the last 
version that it should accept.   And it doesn't do much for the case 
where I find an issue on the test machine that doesn't get fixed before 
the normal time to accept updates on the critical ones.

> 2) 'known bad' assumes we actually know that updates are bad before we
> release them. If we knew they were bad we wouldn't release them at
> all.

Known-bad in this scenario means detected after the initial rollout but 
before the end of the window to the next 'new code' push.  Being able to 
   avoid those and get the fixed version instead on your critical 
machines would make using fedora a lot more practical.

>> Or, pick a time frame reasonable both for mirrors to hold updates and for
>> users to complete testing (2 months?) and only remove packages after their
>> replacements have reached that age.
>>
>> Or, what if one machine's yum automatically acted as a proxy for another's
>> update, perhaps with an error generated if the package hadn't been
>> downloaded already and if you want to be even more helpful, a warning if
>> none of the code from a package had been run on the intermediate machine?
> 
> Feel free to take over InstantMirror and extend it
> https://fedorahosted.org/InstantMirror/

I think that's pretty far from what I'd want to happen.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From jspaleta at gmail.com  Wed Dec 10 07:17:49 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 22:17:49 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493F6B8F.8010209@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>
	<493F6B8F.8010209@gmail.com>
Message-ID: <604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>

On Tue, Dec 9, 2008 at 10:11 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Known-bad in this scenario means detected after the initial rollout but
> before the end of the window to the next 'new code' push.  Being able to
>  avoid those and get the fixed version instead on your critical machines
> would make using fedora a lot more practical.

Where do you collect and store the information that marks an update as
known bad?

-jef



From wtogami at redhat.com  Wed Dec 10 07:21:38 2008
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 10 Dec 2008 02:21:38 -0500
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <1228873607.24963.684.camel@cookie.hadess.net>
References: <491DA325.3010305@redhat.com>	<1226702549.29933.2.camel@snoogens.fab.redhat.com>	<1227522629.3675.2625.camel@cookie.hadess.net>	<493224B2.60706@redhat.com>
	<1228873607.24963.684.camel@cookie.hadess.net>
Message-ID: <493F6E02.8050805@redhat.com>

Bastien Nocera wrote:
> On Sun, 2008-11-30 at 00:29 -0500, Warren Togami wrote:
>> Bastien Nocera wrote:
>>>> There's no sound mixing (through ALSA or PulseAudio) when OSS emulation
>>>> is used in ALSA. Kill it (and file a bug against the app).
>>> Filed:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=472741
>>>
>> http://lwn.net/Articles/308445/
>> CUSE: Character devices in user space
>>
>> The first cuse driver is an OSS proxy to pulseaudio, that provides 
>> /dev/dsp, /dev/adsp and /dev/mixer.  The article describes it as likely 
>> to be merged in the upstream 2.6.29 kernel.  Let us help this become 
>> stable so we can count on it for F11.
>>
>> Assuming cuse OSS proxy is ready for F11, and it works reasonably well 
>> as a complete replacement for ALSA's OSS compat layer, we would do the 
>> following:
> <snip>
> 
> I don't see this happening for F11, so I'll comment on the fallback
> strategy.

Seriously?  That article says it is likely to happen for 2.6.29.  Is 
this unlikely?

In any case CUSE would undoubtedly be useful to have in the next RHEL. 
Just imagine how much more flexible RHEL5 would have been to customers 
if we had fuse back then.

Warren



From jspaleta at gmail.com  Wed Dec 10 07:23:38 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 22:23:38 -0900
Subject: Broken dependencies in Fedora 10 - 2008-12-10
In-Reply-To: <604aa7910812091633t531db611kbc2398f813a29993@mail.gmail.com>
References: <20081210001912.2084.59721@faldor.intranet>
	<604aa7910812091633t531db611kbc2398f813a29993@mail.gmail.com>
Message-ID: <604aa7910812092323s6a77451aya06f53fc55add94f@mail.gmail.com>

On Tue, Dec 9, 2008 at 3:33 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> Hmm geos-3.0.3 went out as an update and bumped the library and it
> appears that it skipped testing and went straight to stable and was
> not marked as security. Joy!
> Let's see if I can get python-basemap rebuilt.


Okay python-basemap has been rebuilt. I'm pushing this directly to
stable to fix the dep.. though I would prefer to have been able to put
this into testing and beat on it for a week.

-jef



From wtogami at redhat.com  Wed Dec 10 07:24:54 2008
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 10 Dec 2008 02:24:54 -0500
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <20081210031344.GA21432@nostromo.devel.redhat.com>
References: <491DA325.3010305@redhat.com>	<1226702549.29933.2.camel@snoogens.fab.redhat.com>	<1227522629.3675.2625.camel@cookie.hadess.net>	<493224B2.60706@redhat.com>	<1228873607.24963.684.camel@cookie.hadess.net>
	<20081210031344.GA21432@nostromo.devel.redhat.com>
Message-ID: <493F6EC6.7090100@redhat.com>

Bill Nottingham wrote:
>>> Assuming cuse OSS proxy is ready for F11, and it works reasonably well 
>>> as a complete replacement for ALSA's OSS compat layer, we would do the 
>>> following:
>> <snip>
>>
>> I don't see this happening for F11, so I'll comment on the fallback
>> strategy.
> 
> FYI, one thing pointed out elsewhere about this strategy is that any
> remaining OSS apps that use mmap() likely won't work with CUSE. Of
> course, they wouldn't work with padsp either.
> 
> Bill
> 

If this is the case, then the fallback strategy is really the only 
doable strategy for OSS support.  None of the other options can offer 
legacy support that some proprietary software customers will whine for.

The fallback strategy has the benefit of not effecting any Fedora/RHEL 
user by default, so is there any drawback in doing it?  OSS would simply 
NOT WORK by default which is absolutely fine.

OTOH, what are concrete examples of OSS apps that use mmap()?

Warren



From lesmikesell at gmail.com  Wed Dec 10 07:44:40 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 01:44:40 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
Message-ID: <493F7368.9010005@gmail.com>

Jeff Spaleta wrote:
> On Tue, Dec 9, 2008 at 10:11 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> Known-bad in this scenario means detected after the initial rollout but
>> before the end of the window to the next 'new code' push.  Being able to
>>  avoid those and get the fixed version instead on your critical machines
>> would make using fedora a lot more practical.
> 
> Where do you collect and store the information that marks an update as
> known bad?

Bugzilla? Where do you want people to report bugs? If you had a fixed 
window before updates would be picked up on the machines with the more 
conservative setting people might be more anxious to report them.

But I wouldn't envision marking an update as 'bad' although that's an 
interesting concept itself.  I was thinking that there would be a 
specified time when all normal updates enter the repository, followed by 
a time when only critical bug and security fix updates could be added, 
so towards the end of that interval, packages that hadn't been replaced 
with 'better' updates would automatically be assumed 'good' and it would 
be fairly safe to update machines where you want less risk.  Then a new 
cycle of 'new feature' updates could start.

--
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Wed Dec 10 07:47:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Dec 2008 08:47:44 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com>
Message-ID: <ghns71$ss5$1@ger.gmane.org>

Les Mikesell wrote:
> Bugzilla? Where do you want people to report bugs? If you had a fixed
> window before updates would be picked up on the machines with the more
> conservative setting people might be more anxious to report them.

I think Bodhi would be a better place. For example we could do something
with negative karma for stable updates, right now it just gets ignored.

> But I wouldn't envision marking an update as 'bad' although that's an
> interesting concept itself.  I was thinking that there would be a
> specified time when all normal updates enter the repository, followed by
> a time when only critical bug and security fix updates could be added,
> so towards the end of that interval, packages that hadn't been replaced
> with 'better' updates would automatically be assumed 'good' and it would
> be fairly safe to update machines where you want less risk.  Then a new
> cycle of 'new feature' updates could start.

How's that different from updates-testing?

        Kevin Kofler



From jspaleta at gmail.com  Wed Dec 10 08:02:04 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Dec 2008 23:02:04 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghns71$ss5$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>
	<493F6B8F.8010209@gmail.com>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com> <ghns71$ss5$1@ger.gmane.org>
Message-ID: <604aa7910812100002h7d68fcc2u337a85fddf9b6751@mail.gmail.com>

On Tue, Dec 9, 2008 at 10:47 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> How's that different from updates-testing?

It's update-testing with time based flushes to stable with an
infrequent flush rate instead of the stochastic flushing to stable
that we do now.

But the bulk of what he wants is for older stable update to continue
to available to be able to downgrade to if a stable update becomes
'known bad' at some point. Instead of pushing yet another update for
'known bad' updates, he wants to back out to a previous 'known good'
update..assuming it isn't marked as 'known bad' as well.  I feel there
is a logical fallacy lurking here concerning how things are classified
as 'known bad' but I'm too tired right now to try to articulate it.

-jef



From lesmikesell at gmail.com  Wed Dec 10 08:20:26 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 02:20:26 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghns71$ss5$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>
	<ghns71$ss5$1@ger.gmane.org>
Message-ID: <493F7BCA.3030405@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> Bugzilla? Where do you want people to report bugs? If you had a fixed
>> window before updates would be picked up on the machines with the more
>> conservative setting people might be more anxious to report them.
> 
> I think Bodhi would be a better place. For example we could do something
> with negative karma for stable updates, right now it just gets ignored.
> 
>> But I wouldn't envision marking an update as 'bad' although that's an
>> interesting concept itself.  I was thinking that there would be a
>> specified time when all normal updates enter the repository, followed by
>> a time when only critical bug and security fix updates could be added,
>> so towards the end of that interval, packages that hadn't been replaced
>> with 'better' updates would automatically be assumed 'good' and it would
>> be fairly safe to update machines where you want less risk.  Then a new
>> cycle of 'new feature' updates could start.
> 
> How's that different from updates-testing?

This would be to catch the things that get past updates-testing but can 
be fixed quickly.  You'd probably have the default set to pull all 
updates (which will keep a big base of users) but once you have a 
machine running nicely and doing important work you'd have a setting to 
make it be more conservative there.  I don't think it's as nice as 
repeatable updates, but it would not take much infrastructure change.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pmatilai at laiskiainen.org  Wed Dec 10 08:28:25 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 10 Dec 2008 10:28:25 +0200 (EET)
Subject: Displaying %doc and language specific files of an rpm
In-Reply-To: <200812092323.59642.opensource@till.name>
References: <200812092323.59642.opensource@till.name>
Message-ID: <alpine.DEB.1.10.0812100932150.8888@gotcha.dreamhost.com>

On Tue, 9 Dec 2008, Till Maas wrote:

> On Mon December 1 2008, Panu Matilainen wrote:
>
>> Docs, config files, ghosts and the like can be viewed with this ('d' is
>> for doc):
>> rpm -qp --qf "[%{fileflags:fflags} %{filenames}\n]" <pkg>
>
> I want to extend this to display a "-> linktarget" if a file is a symlink.
> This is what I tried, but it always adds the "->":
>
> rpm -qp --qf "[%{filenames} %|filelinktos?{-> %{filelinktos}}:{}| \n]"
>
> Do you know, how to make this work? I found the %|foo?{bar}:{baz}| syntax in
> the queryformat doc file from rpm.

The queryformat conditional result is about tag existence (and all 
packages have filelinktos tag, regardless if they contain symlinks or 
not), not would it print something for a particular item.

In other words, there's no way to do that within queryformat, but you can 
of course pipe the output for extra processing, eg
rpm -q --qf "[%{FILENAMES} %{FILELINKTOS}\n]\n" libcap.x86_64 | awk 
'{print $2 ? $1 " -> " $2 : $1}'

Or use --pipe option to rpm but that's hardly useful outside popt 
aliases. But that's not likely to work too well if you have lots of 
optional data. Sooner or later it's going to be easier to just use python 
for fancy formatting.

 	- Panu -



From lesmikesell at gmail.com  Wed Dec 10 08:30:55 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 02:30:55 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812100002h7d68fcc2u337a85fddf9b6751@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>
	<ghns71$ss5$1@ger.gmane.org>
	<604aa7910812100002h7d68fcc2u337a85fddf9b6751@mail.gmail.com>
Message-ID: <493F7E3F.1020800@gmail.com>

Jeff Spaleta wrote:
> On Tue, Dec 9, 2008 at 10:47 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> How's that different from updates-testing?
> 
> It's update-testing with time based flushes to stable with an
> infrequent flush rate instead of the stochastic flushing to stable
> that we do now.
> 
> But the bulk of what he wants is for older stable update to continue
> to available to be able to downgrade to if a stable update becomes
> 'known bad' at some point. Instead of pushing yet another update for
> 'known bad' updates, he wants to back out to a previous 'known good'
> update..assuming it isn't marked as 'known bad' as well.  I feel there
> is a logical fallacy lurking here concerning how things are classified
> as 'known bad' but I'm too tired right now to try to articulate it.

Actually I'd leave it up to the packager as to how to best fix the bug - 
and would usually expect it to be yet another update with numbering 
going forward with either a fix or a backout of some problematic change.
There would just have to be a way to mark the 'fixed' version to be 
installed without the delay, bypassing the one it replaces.

That's sort of optimistic, but at least it gives a second chance to fix 
things before they hit machines that you can't afford to break.  And a 
user would have a choice of which machine he would use to test on.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From dan at danny.cz  Wed Dec 10 09:05:34 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 10 Dec 2008 10:05:34 +0100
Subject: nautilus depends on a lot of stuff via gvfs
In-Reply-To: <1228871905.24963.646.camel@cookie.hadess.net>
References: <1228818420.3626.52.camel@eagle.danny.cz>
	<1228871905.24963.646.camel@cookie.hadess.net>
Message-ID: <1228899934.3616.17.camel@eagle.danny.cz>


Bastien Nocera p??e v St 10. 12. 2008 v 01:18 +0000:
> On Tue, 2008-12-09 at 11:27 +0100, Dan Hor?k wrote:
> > Hi,
> > 
> > I was trying to remove samba-winbind (plus the rest of samba, because I
> > don't need it and samba represents MBs of updates and tens of MB of used
> > space) from my F-10 machine and found out that it will remove nautilus
> > too.
> > 
> > Removing:
> >  samba-winbind                      i386         3.2.5-0.23.fc10            installed         7.9 M
> > Removing for dependencies:
> >  gnome-vfs2-smb                     i386         2.24.0-3.fc10              installed          28 k
> >  gvfs-smb                           i386         1.0.2-3.fc10               installed         255 k
> >  hal-cups-utils                     i386         0.6.17-4.fc10              installed         100 k
> >  libsmbclient                       i386         3.2.5-0.23.fc10            installed         3.8 M
> >  nautilus                           i386         2.24.1-3.fc10              installed          13 M
> >  samba-client                       i386         3.2.5-0.23.fc10            installed          27 M
> >  samba-common                       i386         3.2.5-0.23.fc10            installed          29 M
> >  system-config-printer              i386         1.0.9-1.fc10               installed         1.6 M
> >  system-config-printer-libs         i386         1.0.9-1.fc10               installed         2.8 M
> > 
> > The problem is that nautilus has hard dependencies on many (all?) gvfs
> > modules.
> 
> All of them, so things work out of the box.
> 
> >  Trying to remove libgphoto2 has similar effects.
> > 
> > So my proposal is to split nautilus into nautilus-core, that will
> > contains the content of the current nautilus package, and nautilus
> > "meta" package that will contains all the dependencies plus dependency
> > on nautilus-core. This solution will install all the deps as today, but
> > leave the option to remove the unnecessary packages afterwards.
> > 
> > Only 3 packages will be affected with this split
> > nautilus-devel
> > nautilus-python
> > seahorse-plugins
> > and they should be made to depend on nautilus-core instead of nautilus.
> > 
> > I will file a bug with the proposed change to nautilus spec file.
> 
> That's not workable. You'd probably rather rejigger the samba packages
> so it's possible to use Samba in any appropriate environment without
> dragging in the server, or the excessively big packages. You should do
> the same for other dependencies.
> 

It is workable. Because with such hard dependencies you are loosing the
reason to have the gvfs handlers in separate packages.

> Removing functionality from nautilus as it is installed by default won't
> fix that problem.

There is no functionality removed in the default situation, only better
structured.

bug is filled as https://bugzilla.redhat.com/show_bug.cgi?id=475486

test build at https://koji.fedoraproject.org/koji/taskinfo?taskID=988959


		Dan




From belegdol at gmail.com  Wed Dec 10 09:07:28 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Wed, 10 Dec 2008 10:07:28 +0100
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493F1592.5040707@behdad.org>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>	<ghn40c$9bs$1@ger.gmane.org>
	<493F1592.5040707@behdad.org>
Message-ID: <493F86D0.3060208@gmail.com>

I think that the issue here is that legacy font families are not ready
to be merged yet. Nicolas wrote:
Unfortunately there are still many historic fonts in the wild
distributed in several sets of four faces (gs fonts, arial narrow, arial
bold, etc). Those fonts *currently appear under different family names*
in fontconfig-using apps. This is perturbing to users, since the same
faces of historic and modern fonts are not handled the same way.
Microsoft did some sort of magic in uniscribe to hide this distinction
(irrelevant to users).
This bug was opened in November 2008, yet the erroneous merging of Arial
and Arial Narrow is in place since Fedora 8 was released. I have to
agree with Kevin here, that while the legacy fonts should be merged with
some help of additional quirks, it would be nicer if they just were
exposed as separate families until the merged variant works properly
(correct me if I'm wrong, but judging from the bug report they are not
expected to be merged yet).

Julian

P.S.
For reference, here is the bugzilla entry:
http://bugzilla.freedesktop.org/show_bug.cgi?id=18725



From dan at danny.cz  Wed Dec 10 09:10:50 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 10 Dec 2008 10:10:50 +0100
Subject: nautilus depends on a lot of stuff via gvfs
In-Reply-To: <1228873368.7475.5.camel@matthiasc>
References: <1228818420.3626.52.camel@eagle.danny.cz>
	<1228871905.24963.646.camel@cookie.hadess.net>
	<1228873368.7475.5.camel@matthiasc>
Message-ID: <1228900250.3616.21.camel@eagle.danny.cz>


Matthias Clasen p??e v ?t 09. 12. 2008 v 20:42 -0500:
> On Wed, 2008-12-10 at 01:18 +0000, Bastien Nocera wrote:
> 
> > > 
> > > So my proposal is to split nautilus into nautilus-core, that will
> > > contains the content of the current nautilus package, and nautilus
> > > "meta" package that will contains all the dependencies plus dependency
> > > on nautilus-core. This solution will install all the deps as today, but
> > > leave the option to remove the unnecessary packages afterwards.
> > > 
> > > Only 3 packages will be affected with this split
> > > nautilus-devel
> > > nautilus-python
> > > seahorse-plugins
> > > and they should be made to depend on nautilus-core instead of nautilus.
> > > 
> > > I will file a bug with the proposed change to nautilus spec file.
> > 
> > That's not workable. You'd probably rather rejigger the samba packages
> > so it's possible to use Samba in any appropriate environment without
> > dragging in the server, or the excessively big packages. You should do
> > the same for other dependencies.
> > 
> > Removing functionality from nautilus as it is installed by default won't
> > fix that problem.
> 
> Fwiw, I don't think it is a big problem to change things so that gvfs
> subpackages are pulled in by comps instead of by hard deps from
> nautilus, as long as they are all in the default install. I don't
> introducing a nautilus metapackage for this purpose is necessary or a
> good idea. 
> 

Yes, pulling the deps via comps could be a nice solution.


		Dan




From nicolas.mailhot at laposte.net  Wed Dec 10 09:31:48 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 10 Dec 2008 10:31:48 +0100 (CET)
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <ghn40c$9bs$1@ger.gmane.org>
References: <493E56B2.7060101@gmail.com>
	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>
	<493E6F6A.3060806@gmail.com>
	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>
	<ghn40c$9bs$1@ger.gmane.org>
Message-ID: <42e4d620f4f0538308e6e254b95f4122.squirrel@arekh.dyndns.org>



Le Mer 10 d?cembre 2008 01:54, Kevin Kofler a ?crit :

> Please do not ignore real-world usability in your quest for
> perfection.

This is not a quest of perfection this is getting font and text bugs
fixed.

The freetype autohinter has progressed because we've enabled it in
Fedora despite its problems and told people to report bugs upstream
instead of helping them enable the bytecode interpreter and ignore the
problem.

OO.o has started working on OpenType CFF support because we told them
plainly we would not stop merging fonts in this format or prioritize
OpenType TTF just so people didn't notice that unlike other apps, OO.o
didn't work.

Ligature support was fixed in Firefox because we didn't try to hide
them and so people complained upstream of upstream bugs.

Likewise ligature support was lately fixed in freetype, again because
we didn't hide the problem and people complained in the right place
(upstream issue trackers, not general-purpose downstream lists).

When we tried to hide a problem by removing triggering glyphs
font-side there was 0% progress on fixing application-side and some
upstreams still argue we should restore the hiding so they don't have
to bother.

Red Hat tried to avoid font problems by not merging anything that
looked like it would trigger application bugs, and had to shell some
millions later for Liberation; complaining at the same time the FLOSS
font scene really was not active enough for them to rely on it. Well,
if you want activity you have to support this activity not ignore it
and hope things will magically perfect themselves without distro-side
exposition.

Your proposition is made of 100% pure un-adultered FAIL. And facts
back me up on this.

You'll find scores of people to rewrite spontaneously media players,
MUAs, or the distro boot chrome, but people won't work on font
problems unless users complain to them, and users won't complain if
you hide or diffuse the problems. They'll just note Fedora font
support is crap, without pointing to any specific fact.

Just Google for 'linux fonts', and you'll find many such reports,
culminating around 2006, which incidently is when Fedora decided to
get its feet wet, and released Fedora 6 with DejaVu LGC as default,
breaking the status quo and starting the virtuous circle of upstream
fixes.

True, even with users complaining, some bugs take ages to get fixed,
but the way to accelerate this is to get more users to complain, not
remove the complains. If some of your favorite DEs or apps are not
fixed yet organise fellow users and put some pression upstream (or,
better, find someone to submit upstream a patch).

I personally think our current course is the best to ? [lead] the
advancement of free, open software and content. ?

Anyway, I'm sick of repeating the same arguments in different forums.
Here's the deal: you disagree with our current font strategy, so go
convince FESCO. If FESCO agrees with you, I'll happily give you the
Fonts SIG keys, and let you manage as you wish from now on. I
personnaly do not intend to waste my personal time trying to improve
the Fedora font situation if one of the precious few levers I have at
my disposition, users complaining upstream of problems, is removed.

And that's the last thing I'll write on the subject.

-- 
Nicolas Mailhot



From paul at city-fan.org  Wed Dec 10 09:38:49 2008
From: paul at city-fan.org (Paul Howarth)
Date: Wed, 10 Dec 2008 09:38:49 +0000
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <20081210031750.GB21432@nostromo.devel.redhat.com>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
Message-ID: <493F8E29.7030205@city-fan.org>

Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
>> I've wondered this for a while.  mriddle (apparently "Marc Riddle",
>> according to a quick Google search) gets emailed every time I update
>> many types of Bugzillas, particularly Review Requests.
> 
> https://bugzilla.redhat.com/userprefs.cgi?tab=email
> 
> See 'user watching'.
> 
> People can set up bugstalking filters to get e-mailed any time someone
> else would be e-mailed.

Which can be useful when you've just sponsored someone for instance.

Paul.



From opensource at till.name  Wed Dec 10 09:51:15 2008
From: opensource at till.name (Till Maas)
Date: Wed, 10 Dec 2008 10:51:15 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghn23k$50a$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<ghn23k$50a$1@ger.gmane.org>
Message-ID: <200812101051.26932.opensource@till.name>

On Wed December 10 2008, Kevin Kofler wrote:

> All this was so much simpler and more obvious before that useless security
> team approval step was introduced (without really consulting packagers
> outside of the security team). :-( What benefit does that approval step
> bring us? It's obviously not QA or this update wouldn't have ended up in
> stable!

It is QA, but with a different focus. The security team checks whether the 
information within the update is correct, e.g. using the correct bug number 
for the CVE and whether the update contains a useful explaination. At least 
this is what I believe to have read and experienced with a security update.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/a3bccd0f/attachment.sig>

From mschwendt at gmail.com  Wed Dec 10 10:21:53 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 10 Dec 2008 11:21:53 +0100
Subject: Broken dependencies in Fedora 10 - 2008-12-10
In-Reply-To: <604aa7910812091633t531db611kbc2398f813a29993@mail.gmail.com>
References: <20081210001912.2084.59721@faldor.intranet>
	<604aa7910812091633t531db611kbc2398f813a29993@mail.gmail.com>
Message-ID: <20081210112153.e7ca0a21.mschwendt@gmail.com>

On Tue, 9 Dec 2008 15:33:02 -0900, Jeff wrote:

> >    jspaleta AT gmail.com
> >        python-basemap
> >    python-basemap-0.99-5.fc10.i386  requires  libgeos-3.0.1.so
> 
> Hmm geos-3.0.3 went out as an update and bumped the library and it
> appears that it skipped testing and went straight to stable and was
> not marked as security. Joy!
> Let's see if I can get python-basemap rebuilt.
> 
> Now before I go ballistic over the fact that this skipped testing and
> isnt marked as security... was that just a mistake or was that
> intended?

It hopefully tells some people that often I'm equal to an early-warning
system. And if I complain that updates ought to spend some time in
updates-testing first [1], this is based on experience. More breakage in
this report, earlier reports, and private reports based on other check
scripts, was also caused by skipping updates-testing. One packager this
time did not know about releng's buildroot overrides and didn't ask
either. So, once again it is both a documentation and communication
problem.

-- 
[1] And I never suggested that it should not be possible to skip
"testing" for special updates.



From thomas.moschny at gmail.com  Wed Dec 10 10:25:31 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Wed, 10 Dec 2008 11:25:31 +0100
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <20081210031750.GB21432@nostromo.devel.redhat.com>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
Message-ID: <a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>

2008/12/10 Bill Nottingham <notting at redhat.com>:
> Richard W.M. Jones (rjones at redhat.com) said:
>> I've wondered this for a while.  mriddle (apparently "Marc Riddle",
>> according to a quick Google search) gets emailed every time I update
>> many types of Bugzillas, particularly Review Requests.
>
> https://bugzilla.redhat.com/userprefs.cgi?tab=email
>
> See 'user watching'.
>
> People can set up bugstalking filters to get e-mailed any time someone
> else would be e-mailed.

So, whom is he watching? I've seen him cc'ed on any review ticket,
too, so maybe he's watching some generic address?

- Thomas



From hughsient at gmail.com  Wed Dec 10 10:34:40 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 10 Dec 2008 10:34:40 +0000
Subject: testing request
In-Reply-To: <faa16b610812091117i161377ddpcfb744cda16b613e@mail.gmail.com>
References: <faa16b610812091117i161377ddpcfb744cda16b613e@mail.gmail.com>
Message-ID: <1228905280.3242.25.camel@hughsie-work.lan>

On Tue, 2008-12-09 at 14:17 -0500, Colin Walters wrote:
> https://admin.fedoraproject.org/updates/F9/FEDORA-2008-11037

I've rolled gnome-packagekit and PackageKit 0.3.12 (and the latest
version in F10 of KPackageKit) into the following Fedora 9 update:

https://admin.fedoraproject.org/updates/PackageKit-0.3.12-1.fc9,gnome-packagekit-0.3.12-3.fc9,kpackagekit-0.3.1-6.fc9

This should fix any outstanding dep problems. Karma appreciated.

Richard.




From sundaram at fedoraproject.org  Wed Dec 10 10:52:16 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 10 Dec 2008 16:22:16 +0530
Subject: [Ambassadors] What Fedora makes sucking for me - or why I am
 NOT	Fedora
In-Reply-To: <775aa32d0812091818g2270146dr5bc0922f29b407c2@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<775aa32d0812091818g2270146dr5bc0922f29b407c2@mail.gmail.com>
Message-ID: <493F9F60.9010502@fedoraproject.org>

Ujjwol Lamichhane wrote:

> Though, i love fedora and will be using it. There are many things Fedora 
> Needs to improve in the upcomming versions...

It would be useful to get bug reports on these at http://bugzilla.redhat.com

Rahul



From kanarip at kanarip.com  Tue Dec  9 11:29:18 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Tue, 09 Dec 2008 12:29:18 +0100
Subject: [Ambassadors] Live CD & Localization (was: What Fedora makes
 sucking for me - or why I am NOT Fedora)
In-Reply-To: <20081209002540.GA25637@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
Message-ID: <493E568E.3090404@kanarip.com>

Robert Scheck wrote:
> Oh, we've the Live CD for a long time now. Did anybody use that medium on a
> slower, older computer? Surely not. Otherwise you would have noticed, that
> the Live CD is very slow there. The USB stick/variant may be fast, but the
> CD which we're now promoting at our download page better and more that the
> installation DVD, is IMHO not a good store sign as it is just slow. It even
> has not a localisation - folks, not the whole world is speaking english,
> just there is America on the worldmap! I know people from fairs, which are
> really frusted by their first try with a Live CD as it was just English.
> Yes, we maybe can create a spin, but these ones, we cannot offer on the FTP
> and HTTP mirrors, because Fedora is already too big. On the other hand, the
> issue of a non-US keyboard layout when trying to generate a localized
> version of the Live medium is still not fixed. There were some tries to
> solve that on LinuxTag 2008, but as far as I know, afterwards nobody again
> cared about and it went down.
> 

As the Spin SIG leader, I feel this is my piece of the pie.

As far as the localization of Live CDs and DVDs is concerned, I cannot 
but wholeheartedly agree;

The Live media is supposed to be the perfect show-case of whatever 
Fedora can do or KDE 4.X foo brings. If that's in English by default, 
that's fine, I'm not saying we should include kde-l10n-* on a LiveCD 
because that simply won't fit.

However, if that supposedly perfect show-case can be in German, Dutch, 
Swahili or you-name-the-language, the better. Localization is one of the 
selling points of Linux in general (because you get a lot of it for no 
mentionable effort -other then selecting your locale and browsing 
through the giant list of available locales), and it's one of the 
selling points of Fedora specifically (transifex, upstream, you know the 
story). And that's besides the difficulty or annoyance people sometimes 
experience when that supposedly perfect show-case is not in their 
favorite language.

In an effort to make these localized LiveCDs maintainable, I've accepted 
every contributor that wanted to create localized extensions of each 
spin concept. I know that Fabian Affolter and Igor Pieres Soares have 
done a good job at creating and maintaining their locales, and I ship 
them in the spin-kickstarts package for everyone to use.

Of course, that's only one small piece of the pie. We would love to 
create the spins on Fedora Infrastructure, or outside of Fedora 
Infrastructure (but that introduces verifiability constraints we're 
unable to get past yet) and have them promoted and distributed by the 
Fedora Project. However, that only stretches so far. There's a limited 
amount of Release Engineering the Fedora Project can do -being Jesse 
Keating, especially around Fedora N GA. In addition, there's a limited 
amount of QA the Fedora Project can do, and since it would be the Fedora 
Project composing, promoting and distributing such localized spin, it 
better be a good one.

Instead of thinking in terms of problems though, I like to think in 
terms of (potential) solutions. One of the solutions I suggested is that 
outside of Release Engineering, the localized spins can be created by 
peers (possibly Spin SIG members, possibly localized Spin maintainers) 
-to offload Release Engineering. It's a standard, pretty 
straight-forward process.

As for the promotion part... Well that's not really a problem, is it? It 
just depends on the composing and distribution parts.

Then in terms of distribution, which is another challenge for the Fedora 
Project, I've suggested we let the seeds for a torrent be the 
responsibility of the Spin maintainers. In practice, that responsibility 
boils down to: No Seeds, No Spin. The Fedora Project however would still 
host the torrent tracker so they have control over revocation and/or 
modification of the spin/torrent.

Since then, the discussion has come to a halt. I guess we were involved 
with other stuff, we didn't see much localization happening yet (as far 
as the kickstart repo is concerned, that is), and we lost interest in 
pursuing it for Fedora 10.

I hope this brings some perspective to the issue of localized live 
media, and I certainly hope this starts up a new discussion around 
including localized versions of spins, one way or the other, in F11.

Kind regards,

Jeroen van Meeuwen
-kanarip



From hughsient at gmail.com  Wed Dec 10 10:52:28 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 10 Dec 2008 10:52:28 +0000
Subject: Broken dependencies in Fedora 10 - 2008-12-10
In-Reply-To: <20081210001912.2084.59721@faldor.intranet>
References: <20081210001912.2084.59721@faldor.intranet>
Message-ID: <1228906348.3242.30.camel@hughsie-work.lan>

On Wed, 2008-12-10 at 00:19 +0000, Michael Schwendt wrote:
>     smparrish AT shallowcreek.net
>         kpackagekit

I've fixed this in
http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11078

Richard.




From mschwendt at gmail.com  Wed Dec 10 11:03:07 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 10 Dec 2008 11:03:07 -0000
Subject: Broken dependencies in Fedora 9 - 2008-12-10
Message-ID: <20081210110307.6153.3506@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by owner):

    berrange AT redhat.com
        perl-Test-AutoBuild

    cooly AT gnome.eu.org
        fuse-emulator
        fuse-emulator-utils

    dhuff AT redhat.com
        appliance-tools

    ebmunson AT us.ibm.com
        libhugetlbfs

    huzaifas AT redhat.com
        openvas-libraries

    katzj AT redhat.com
        livecd-tools

    matthias AT rpmforge.net
        pigment-python

    mr.ecik AT gmail.com
        kadu

    nigjones AT redhat.com
        mediawiki-SpecialInterwiki

    oliver AT linux-kernel.at
        syck

    orion AT cora.nwra.com
        paraview

    phuang AT redhat.com
        scim-bridge

    sundaram AT redhat.com
        gyachi

    wart AT kobold.org
        cyphesis
        sear


======================================================================
Broken packages in fedora-9-i386:

    cyphesis-selinux-0.5.15-6.fc9.i386  requires  cyphesis = 0:0.5.15-6.fc9
    fuse-emulator-utils-0.9.0-2.fc9.i386  requires  libspectrum.so.5
    gyachi-plugin-photosharing-1.1.0-7.fc9.i386  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.i386  requires  gyachi = 0:1.1.0-7.fc9
    kadu-agent-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-alsa_sound-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.i386  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-antistring-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.i386  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-cenzor-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-esd_sound-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-falf_mediaplayer-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-mx610_notify-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-osdhints_notify-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-screenshot-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-spellchecker-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-water_notify-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-weather-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.i386  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-gtk-0.3.so.4
    sear-0.6.3-10.fc9.i386  requires  libmercator-0.2.so.4
    syck-php-0.61-4.3.fc9.i386  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc:

    cyphesis-selinux-0.5.15-6.fc9.ppc  requires  cyphesis = 0:0.5.15-6.fc9
    fuse-emulator-utils-0.9.0-2.fc9.ppc  requires  libspectrum.so.5
    gyachi-plugin-photosharing-1.1.0-7.fc9.ppc  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.ppc  requires  gyachi = 0:1.1.0-7.fc9
    kadu-agent-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-alsa_sound-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-antistring-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-cenzor-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-esd_sound-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-falf_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-mx610_notify-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-osdhints_notify-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-screenshot-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-spellchecker-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-water_notify-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-weather-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    libhugetlbfs-test-1.1-6.fc9.ppc  requires  libhugetlbfs = 0:1.1-6.fc9
    paraview-3.2.1-6.fc9.ppc64  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.ppc64  requires  paraview-data = 0:3.2.1-6.fc9
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-gtk-0.3.so.4
    scim-bridge-qt-0.4.15-5.fc9.ppc64  requires  scim-bridge = 0:0.4.15-5.fc9
    sear-0.6.3-10.fc9.ppc  requires  libmercator-0.2.so.4
    syck-php-0.61-4.3.fc9.ppc  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc64:

    cyphesis-selinux-0.5.15-6.fc9.ppc64  requires  cyphesis = 0:0.5.15-6.fc9
    fuse-emulator-utils-0.9.0-2.fc9.ppc64  requires  libspectrum.so.5()(64bit)
    gyachi-plugin-photosharing-1.1.0-7.fc9.ppc64  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.ppc64  requires  gyachi = 0:1.1.0-7.fc9
    kadu-agent-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-alsa_sound-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-antistring-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-cenzor-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-esd_sound-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-falf_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-mx610_notify-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-osdhints_notify-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-screenshot-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-spellchecker-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-water_notify-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-weather-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    libhugetlbfs-test-1.1-6.fc9.ppc64  requires  libhugetlbfs = 0:1.1-6.fc9
    perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch  requires  darcs >= 0:1.0.0
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-0.3.so.4()(64bit)
    sear-0.6.3-10.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    syck-php-0.61-4.3.fc9.ppc64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-x86_64:

    cyphesis-selinux-0.5.15-6.fc9.x86_64  requires  cyphesis = 0:0.5.15-6.fc9
    fuse-emulator-utils-0.9.0-2.fc9.x86_64  requires  libspectrum.so.5()(64bit)
    gyachi-plugin-photosharing-1.1.0-7.fc9.x86_64  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.x86_64  requires  gyachi = 0:1.1.0-7.fc9
    kadu-agent-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-alsa_sound-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-antistring-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-cenzor-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-esd_sound-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-falf_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-mx610_notify-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-osdhints_notify-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-screenshot-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-spellchecker-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-water_notify-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-weather-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    libhugetlbfs-test-1.1-6.fc9.x86_64  requires  libhugetlbfs = 0:1.1-6.fc9
    paraview-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-0.3.so.4()(64bit)
    scim-bridge-qt-0.4.15-5.fc9.i386  requires  scim-bridge = 0:0.4.15-5.fc9
    sear-0.6.3-10.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    syck-php-0.61-4.3.fc9.x86_64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-updates-9-i386:

    cyphesis-0.5.15-8.fc9.i386  requires  libmercator-0.2.so.4
    fuse-emulator-0.9.0-3.fc9.i386  requires  libspectrum.so.5
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.i386  requires  libresolv.so.2(GLIBC_PRIVATE)


======================================================================
Broken packages in fedora-updates-9-ppc:

    cyphesis-0.5.15-8.fc9.ppc  requires  libmercator-0.2.so.4
    fuse-emulator-0.9.0-3.fc9.ppc  requires  libspectrum.so.5
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.ppc  requires  libresolv.so.2(GLIBC_PRIVATE)
    openvas-libraries-1.0.2-2.fc9.ppc64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)


======================================================================
Broken packages in fedora-updates-9-ppc64:

    appliance-tools-002-4.fc9.noarch  requires  qemu-img
    cyphesis-0.5.15-8.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    fuse-emulator-0.9.0-3.fc9.ppc64  requires  libspectrum.so.5()(64bit)
    livecd-tools-017.1-1.fc9.ppc64  requires  yaboot
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.ppc64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)


======================================================================
Broken packages in fedora-updates-9-x86_64:

    cyphesis-0.5.15-8.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    fuse-emulator-0.9.0-3.fc9.x86_64  requires  libspectrum.so.5()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.i386  requires  libresolv.so.2(GLIBC_PRIVATE)
    openvas-libraries-1.0.2-2.fc9.x86_64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)



From ivazqueznet at gmail.com  Wed Dec 10 11:35:03 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 10 Dec 2008 06:35:03 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>
References: <49393DE3.1080707@redhat.com> <493C462B.4070607@gmail.com>
	<493D5DA3.7010408@gmail.com> <493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
	<1228868657.15367.138.camel@ignacio.lan>
	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>
Message-ID: <1228908903.15367.180.camel@ignacio.lan>

On Tue, 2008-12-09 at 20:40 -0600, Arthur Pemberton wrote:
> 2008/12/9 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > On Tue, 2008-12-09 at 13:05 -0600, Arthur Pemberton wrote:
> >> 2008/12/9 Toshio Kuratomi <a.badger at gmail.com>:
> >> > So let me reiterate:
> >> >
> >> > * python-3.x will not be in Fedora-11 unless it becomes obvious in the
> >> > next few weeks that we absolutely must be running it for the next release.
> >> > * we need more experience with python-2.6+ & python-3 compatibility
> >> > before we decide whether parallel versions of python are necessary.
> >> >
> >> > .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
> >> >
> >> > -Toshio
> >>
> >>
> >> Well again. Some people (like Toshio) seem to have a grasp on the
> >> matter. All this banter hasn't produced anything more of use. How
> >> about forming a temp SIG to take care of this trusting they do the
> >> right thing?
> >
> > As opposed to the Python SIG that already exists?
> 
> No. Seems like the ideal body to come to a decision and let the rest
> of us know.

Well, most of the active members of the Python SIG have chimed in on
this, and we're all channeling Frankie.

Now, I do believe this is an important subject and we do need to gauge
the impact Python 3000 has on Fedora, but I believe that we are grossly
unequipped to do so at this time. I'd like to revisit this topic in
about a year (perhaps sooner, depending on circumstances), but for now
everyone just relax.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/b34efdd5/attachment.sig>

From pbrobinson at gmail.com  Wed Dec 10 12:14:36 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 10 Dec 2008 13:14:36 +0100
Subject: The looming Python 3(000) monster
In-Reply-To: <1228908903.15367.180.camel@ignacio.lan>
References: <49393DE3.1080707@redhat.com> <493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
	<1228868657.15367.138.camel@ignacio.lan>
	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>
	<1228908903.15367.180.camel@ignacio.lan>
Message-ID: <5256d0b0812100414q6abb3bd8gf12e4718b61ccacb@mail.gmail.com>

>> >> > * python-3.x will not be in Fedora-11 unless it becomes obvious in the
>> >> > next few weeks that we absolutely must be running it for the next release.
>> >> > * we need more experience with python-2.6+ & python-3 compatibility
>> >> > before we decide whether parallel versions of python are necessary.
>> >> >
>> >> > .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
>> >> >
>> >> > -Toshio
>> >>
>> >>
>> >> Well again. Some people (like Toshio) seem to have a grasp on the
>> >> matter. All this banter hasn't produced anything more of use. How
>> >> about forming a temp SIG to take care of this trusting they do the
>> >> right thing?
>> >
>> > As opposed to the Python SIG that already exists?
>>
>> No. Seems like the ideal body to come to a decision and let the rest
>> of us know.
>
> Well, most of the active members of the Python SIG have chimed in on
> this, and we're all channeling Frankie.
>
> Now, I do believe this is an important subject and we do need to gauge
> the impact Python 3000 has on Fedora, but I believe that we are grossly
> unequipped to do so at this time. I'd like to revisit this topic in
> about a year (perhaps sooner, depending on circumstances), but for now
> everyone just relax.

I would have thought we'd want to wait for a number of point releases
before putting it in anyway. Invariably there will be issues with a 0
release and you'd want to wait a couple of months for things to bed
down. With 2.6 being a release to allow easier migration to 3 I would
have thought its the perfect candidate for F-11 and by the time its
out there will be a much better picture of how we'd stand for v3.

Peter



From rawhide at fedoraproject.org  Wed Dec 10 12:38:21 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 10 Dec 2008 12:38:21 +0000 (UTC)
Subject: rawhide report: 20081210 changes
Message-ID: <20081210123821.693F31F8230@releng2.fedora.phx.redhat.com>

Compose started at Wed Dec 10 06:01:07 UTC 2008

New package mingw32-gcc
        MinGW Windows cross-compiler (GCC) for C
New package mingw32-runtime
        MinGW Windows cross-compiler runtime
New package mingw32-w32api
        Win32 header files and stubs
New package perl-Data-Dump-Streamer
        Accurately serialize a data structure as Perl code
New package xjparse
        Wrapper for the Xerces XML Schema validator
Removed package pam_fprint
Updated Packages:

DeviceKit-power-003-1.fc11
--------------------------
* Tue Dec  9 17:00:00 2008 Richard Hughes <richard at hughsie.com> 003-1
- Update to 003


PackageKit-0.4.0-1.fc11
-----------------------
* Tue Dec  9 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.4.0-1
- New upstream version
- Now integrates with BASH suggesting replacements and offering to install
  missing packages.
- Now integrates with Pango using a gtk-module to install missing fonts.
- Much tighter security model and new audit logging framework.
- Lots of new, untested, code so probably not a good idea for F10.


amarok-2.0-2.fc11
-----------------
* Tue Dec  9 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 2.0-2
- respin tarball


anyremote-4.13-1.fc11
---------------------
* Sun Dec  7 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 4.13-1
- Small corrections in configuration files. Configuration file for WmCtrl and 
  Juk/KDE4 were added.


asymptote-1.56-1.fc11
---------------------
* Tue Dec  9 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.56-1
- 1.56


bash-3.2-31.fc11
----------------
* Tue Dec  9 17:00:00 2008 Roman Rakus <rrakus at redhat.com> - 3.2-31
- Patchlevel 48


bluez-4.22-2.fc11
-----------------
* Tue Dec  9 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.22-2
- Fix D-Bus configuration for latest D-Bus (#475069)


cairo-dock-2.0.0-0.1.svn1430_trunk.fc11
---------------------------------------
* Wed Dec 10 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1430


cinepaint-0.22.1-10.fc11
------------------------
* Mon Dec  8 17:00:00 2008 kwizart < kwizart at gmail.com > - 0.22.1-10
- Fix underquoted cinepaint.m4 - #450325


darcs-2.1.2-1.fc11
------------------
* Wed Dec 10 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 2.1.2-1
- update to 2.1.2


eric-4.2.4a-1.fc11
------------------
* Tue Dec  9 17:00:00 2008 Johan Cwiklinski <johan AT x-tnd DOT be> 4.2.4a-1
- 4.2.4a


evolution-2.25.2-2.fc11
-----------------------
* Tue Dec  9 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.2-2.fc11
- Add patch for GNOME bug #552583 (fix account URI comparisons).


fprintd-0.1-4.git43fe72a2aa.fc11
--------------------------------
* Tue Dec  9 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.1-4.git43fe72a2aa
- Update D-Bus config file for recent D-Bus changes


freetype-2.3.7-3.fc11
---------------------
* Tue Dec  9 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> 2.3.7-3
- Add full source URL to Source lines.
- Add docs to main and devel package.
- rpmlint is happy now.
- Resolves: #225770


fuse-sshfs-2.2-1.fc11
---------------------
* Tue Dec  9 17:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 2.2-1
- Ver. 2.2


gnome-commander-1.2.8-0.2.svn2345_trunk.fc11
--------------------------------------------
* Wed Dec 10 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2345


gnome-packagekit-0.4.0-1.fc11
-----------------------------
* Tue Dec  9 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.4.0-1
- New upstream version


gnome-settings-daemon-2.25.2-5.fc11
-----------------------------------
* Tue Dec  9 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-5
- Shutdown cleanly on TERM signal (bug 445898)


guile-1.8.6-1.fc11
------------------
* Tue Dec  9 17:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> - 5:1.8.6-1
- update to 1.8.6


gvfs-1.1.1-4.fc11
-----------------
* Tue Dec  9 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.1.1-4
- Add support for .tar.lzma archives in archive mounter


iso-codes-3.5-1.fc11
--------------------
* Tue Dec  9 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 3.5-1
- Update to 3.5


kadu-0.6.5-3.fc11
-----------------
* Tue Dec  9 17:00:00 2008 Micha?? Bentkowski <mr.ecik at gmail.com> - 0.6.5-3
- Fix bz #475629

* Tue Dec  9 17:00:00 2008 Micha?? Bentkowski <mr.ecik at gmail.com> - 0.6.5-2
- Fix kadu-0.6.5 bug and install sounds to proper directory


kdelibs-4.1.82-2.fc11
---------------------
* Tue Dec  9 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.82-2
- rebase parallel devel patch and kde149705 patch

* Mon Dec  8 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.82-1
- 4.1.82


libarchive-2.5.903a-2.fc11
--------------------------
* Tue Dec  9 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> 2.5.903a-2
- Add LZMA support


liberation-fonts-1.04.93-2.fc11
-------------------------------
* Tue Dec  9 17:00:00 2008 Caius Chance <cchance at redhat.com> - 1.04.93-2.fc11
- Resolves: rhbz#474522 (Cent sign is not coressed in Sans & Mono.)


libgnome-2.24.1-8.fc11
----------------------
* Tue Dec  9 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-8
- Drop esound-devel requires (bug 475442)


libraw1394-2.0.0-5.fc11
-----------------------
* Mon Dec  8 17:00:00 2008 Jarod Wilson <jarod at redhat.com> - 2.0.0-5
- Fix up iso stop command so starting/stopping/starting iso reception works
- Plug firewire handle leak


ocaml-cairo-1.2.0.cvs20080301-6.fc11
------------------------------------
* Tue Dec  9 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0.cvs20080301-6
- Include cairo.a and cairo_lablgtk.a (fixes BZ 475349).


ochusha-0.5.99.69-0.4.cvs20081210T1425.fc11
-------------------------------------------
* Wed Dec 10 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


openbox-3.4.7.2-7.fc11
----------------------
* Tue Dec  9 17:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> - 3.4.7.2-7
- Restore gnome session script (#474143)
- Use DESKTOP_AUTOSTART_ID to avoid gnome-session registration timeout


openoffice.org-3.0.1-13.1.fc11
------------------------------
* Tue Dec  9 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-13.1
- rhbz#474719 add libXinerama-devel BuildRequires
- merge openoffice.org-3.0.0.ooo91904.sd.wrongindex.patch and
  openoffice.org-2.3.0.ooo80257.sd.textonlystyle to upstream
  workspace.impressfontsize.patch
- rename openoffice.org-3.0.1.ooo96906.ucb.symlinks.and.size.patch to
  upstream workspace.tkr16.patch
- drop integrated workspace.swffixes.patch


pciutils-3.0.3-1.fc11
---------------------
* Tue Dec  9 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> 3.0.3-1
- version 3.0.3


perl-DateTime-0.4501-1.fc11
---------------------------
* Tue Dec  9 17:00:00 2008 Steven Pritchard <steve at kspei.com> 1:0.4501-1
- Update to DateTime 0.4501.

* Mon Nov 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 1:0.4401-1
- Update to DateTime 0.4401.
- Update to DateTime::Locale 0.42.
- Update to DateTime::TimeZone 0.8301.


php-5.2.8-1.fc11
----------------
* Tue Dec  9 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 5.2.8-1
- update to 5.2.8


picard-0.11-2.fc11
------------------
* Tue Dec  9 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.11-2
- Fixed sources.

* Tue Dec  9 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.11-1
- Update to latest upstream (0.11)
- Drop upstreamed patch
- Remove sed-ing of .desktop file


python-paste-script-1.6.3-5.fc11
--------------------------------
* Tue Dec  9 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.6.3-5
- Add patch for copydir re error
-   (http://trac.pythonpaste.org/pythonpaste/ticket/313)


rhythmbox-0.11.6-19.r6096.fc11
------------------------------
* Tue Dec  9 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-19.r6096
- Update to rev 6096
- Fixes some crashers during playback


rpm-4.6.0-0.rc3.1
-----------------
* Tue Dec  9 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 4.6.0-0.rc3.1
- update to rpm 4.6.0-rc3
- fixes #475214, #474550, #473239


sofia-sip-1.12.10-1.fc11
------------------------
* Tue Dec  9 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.12.10-1
- Update to 1.12.10


totem-pl-parser-2.25.1-2.fc11
-----------------------------
* Tue Dec  9 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.1-2
- Add evolution-data-server-devel Requires for the devel package


twinkle-1.3.2-2.fc11
--------------------
* Tue Dec  9 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 1.3.2-2
- Add patch to fix command line segfault (fixes #473677)


wine-1.1.10-1.fc11
------------------
* Sat Dec  6 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 1.1.10-1
- version upgrade
- add native pulseaudio driver from winehq bugzilla (#10495)
  fixes #474435, #344281


xorg-x11-xtrans-devel-1.2.2-1.fc11
----------------------------------
* Tue Dec  9 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.2.2-1
- xtrans 1.2.2
- Move to BuildArch: noarch.


yumex-2.0.5-5.fc11
------------------
* Tue Dec  9 17:00:00 2008 Tim Lauridsen <tla at rasmil.dk> - 2.0.5-5
- Update Requires: yum to 3.2
- Added patch to fix python 2.6 syntax errors


Summary:
Added Packages: 5
Removed Packages: 1
Modified Packages: 44
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.i386 requires libspectrum.so.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-gui-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.i386 requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rdflib-2.4.0-7.fc10.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.x86_64 requires libspectrum.so.5()(64bit)
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.i386 requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.x86_64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.i386 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.i386 requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	picviz-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	picviz-gui-0.4-1.fc11.x86_64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.x86_64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc requires libspectrum.so.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.ppc requires pkgconfig(sigc++-2.0)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc requires libpython2.5.so.1.0
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-gui-0.4-1.fc11.ppc requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	fuse-emulator-utils-0.9.0-3.fc10.ppc64 requires libspectrum.so.5()(64bit)
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	libwfut-devel-0.2.1-3.fc11.ppc64 requires pkgconfig(sigc++-2.0)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	picviz-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	picviz-0.4-1.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	picviz-gui-0.4-1.fc11.ppc64 requires python(abi) = 0:2.5
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-libgmail-0.1.10-2.fc10.noarch requires python(abi) = 0:2.5
	python-nevow-0.9.31-1.fc10.noarch requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rdflib-2.4.0-7.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-tgcaptcha-0.11-3.fc10.noarch requires python(abi) = 0:2.5
	python-turboflot-0.1.1-1.fc10.noarch requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(MagickWand)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From belegdol at gmail.com  Wed Dec 10 13:21:27 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Wed, 10 Dec 2008 14:21:27 +0100
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <42e4d620f4f0538308e6e254b95f4122.squirrel@arekh.dyndns.org>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>	<ghn40c$9bs$1@ger.gmane.org>
	<42e4d620f4f0538308e6e254b95f4122.squirrel@arekh.dyndns.org>
Message-ID: <493FC257.4000202@gmail.com>

Nicolas Mailhot pisze:
> 
> Le Mer 10 d?cembre 2008 01:54, Kevin Kofler a ?crit :
> 
>> Please do not ignore real-world usability in your quest for
>> perfection.
> 
> This is not a quest of perfection this is getting font and text bugs
> fixed.
> 
> The freetype autohinter has progressed because we've enabled it in
> Fedora despite its problems and told people to report bugs upstream
> instead of helping them enable the bytecode interpreter and ignore the
> problem.
> 
> OO.o has started working on OpenType CFF support because we told them
> plainly we would not stop merging fonts in this format or prioritize
> OpenType TTF just so people didn't notice that unlike other apps, OO.o
> didn't work.
> 
> Ligature support was fixed in Firefox because we didn't try to hide
> them and so people complained upstream of upstream bugs.
> 
> Likewise ligature support was lately fixed in freetype, again because
> we didn't hide the problem and people complained in the right place
> (upstream issue trackers, not general-purpose downstream lists).
> 
> When we tried to hide a problem by removing triggering glyphs
> font-side there was 0% progress on fixing application-side and some
> upstreams still argue we should restore the hiding so they don't have
> to bother.
> 
> Red Hat tried to avoid font problems by not merging anything that
> looked like it would trigger application bugs, and had to shell some
> millions later for Liberation; complaining at the same time the FLOSS
> font scene really was not active enough for them to rely on it. Well,
> if you want activity you have to support this activity not ignore it
> and hope things will magically perfect themselves without distro-side
> exposition.
> 
> Your proposition is made of 100% pure un-adultered FAIL. And facts
> back me up on this.
> 
> You'll find scores of people to rewrite spontaneously media players,
> MUAs, or the distro boot chrome, but people won't work on font
> problems unless users complain to them, and users won't complain if
> you hide or diffuse the problems. They'll just note Fedora font
> support is crap, without pointing to any specific fact.
> 
> Just Google for 'linux fonts', and you'll find many such reports,
> culminating around 2006, which incidently is when Fedora decided to
> get its feet wet, and released Fedora 6 with DejaVu LGC as default,
> breaking the status quo and starting the virtuous circle of upstream
> fixes.
> 
> True, even with users complaining, some bugs take ages to get fixed,
> but the way to accelerate this is to get more users to complain, not
> remove the complains. If some of your favorite DEs or apps are not
> fixed yet organise fellow users and put some pression upstream (or,
> better, find someone to submit upstream a patch).
> 
> I personally think our current course is the best to ? [lead] the
> advancement of free, open software and content. ?
> 
> Anyway, I'm sick of repeating the same arguments in different forums.
> Here's the deal: you disagree with our current font strategy, so go
> convince FESCO. If FESCO agrees with you, I'll happily give you the
> Fonts SIG keys, and let you manage as you wish from now on. I
> personnaly do not intend to waste my personal time trying to improve
> the Fedora font situation if one of the precious few levers I have at
> my disposition, users complaining upstream of problems, is removed.
> 
> And that's the last thing I'll write on the subject.
> 

Looks like the current strategy works then, but quite slowly in some
cases. The main issue I see here is that freedesktop bugzilla seems to
be a black hole - I added a comment to bug #13416 half a year ago and
got zero response from upstream developers, so please forgive me my
slight frustration at this point - it's not that I didn't try, but if no
one upstream gives a damn about the problem, I tried to find allies
here, who could possibly have more convincing power. Attracting
attention - that was the purpose of my post.

Julian



From behdad at behdad.org  Wed Dec 10 13:32:55 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 10 Dec 2008 08:32:55 -0500
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493FC257.4000202@gmail.com>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>	<ghn40c$9bs$1@ger.gmane.org>	<42e4d620f4f0538308e6e254b95f4122.squirrel@arekh.dyndns.org>
	<493FC257.4000202@gmail.com>
Message-ID: <493FC507.4060203@behdad.org>

Julian Sikorski wrote:

> Looks like the current strategy works then, but quite slowly in some
> cases. The main issue I see here is that freedesktop bugzilla seems to
> be a black hole - I added a comment to bug #13416 half a year ago and
> got zero response from upstream developers, so please forgive me my
> slight frustration at this point - it's not that I didn't try, but if no
> one upstream gives a damn about the problem, I tried to find allies
> here, who could possibly have more convincing power. Attracting
> attention - that was the purpose of my post.

That "they" thinking is so broken.  "Upstream developers" is not a group of
aliens.  Ask on any IRC channel who maintains fontconfig and people will tell
you.  Currently Keith Packard makes a release every year.  That is, he spends
two or three days every year to make a release with patches that are ready to
go in.  The only other person spending time on it has been me, preparing
patches for Keith when release time gets close.  So in one sense there is no
upstream developers.  Want to change that?  Become one.

That said, I'm going to spend some time before the end of the year on getting
a fontconfig tree ready for release.  I'll take a look at your issue.

behdad

> Julian



From yersinia.spiros at gmail.com  Wed Dec 10 13:51:04 2008
From: yersinia.spiros at gmail.com (yersinia)
Date: Wed, 10 Dec 2008 14:51:04 +0100
Subject: Unowned directories
In-Reply-To: <20081129121957.GA17701@amd.home.annexia.org>
References: <200811290123.53933.MathStuf@gmail.com>
	<20081129102145.b4d83f21.mschwendt@gmail.com>
	<20081129121957.GA17701@amd.home.annexia.org>
Message-ID: <b086760e0812100551j11ef94c1x10cd0e16e4285f2d@mail.gmail.com>

On Sat, Nov 29, 2008 at 1:19 PM, Richard W.M. Jones <rjones at redhat.com>wrote:

> On Sat, Nov 29, 2008 at 10:21:45AM +0100, Michael Schwendt wrote:
> > Doesn't surprise me. The list has gotten longer. A lot. Reviewers don't
> > look for such issues, because reviewers themselves are packagers, and
> many
> > packagers either don't know or don't care about unowned dirs.
>
> Quite right too - it's the sort of thing that RPM could track.
>

Yes, this feature was already tracked
https://fedoraproject.org/wiki/Rpm-devel
some year ago.






>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat
> http://et.redhat.com/~rjones
> virt-df <http://et.redhat.com/%7Erjonesvirt-df> lists disk usage of guests
> without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://et.redhat.com/~rjones/virt-df/<http://et.redhat.com/%7Erjones/virt-df/>
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/5b832075/attachment.htm>

From belegdol at gmail.com  Wed Dec 10 14:06:03 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Wed, 10 Dec 2008 15:06:03 +0100
Subject: arial narrow is broken since Fedora 8
In-Reply-To: <493FC507.4060203@behdad.org>
References: <493E56B2.7060101@gmail.com>	<b586ee3b290bac3dc0af06fe9a992f91.squirrel@arekh.dyndns.org>	<493E6F6A.3060806@gmail.com>	<db5a64a25d0427e4b7f46e86dbc89d13.squirrel@arekh.dyndns.org>	<ghn40c$9bs$1@ger.gmane.org>	<42e4d620f4f0538308e6e254b95f4122.squirrel@arekh.dyndns.org>	<493FC257.4000202@gmail.com>
	<493FC507.4060203@behdad.org>
Message-ID: <493FCCCB.7080000@gmail.com>

Behdad Esfahbod pisze:
> Julian Sikorski wrote:
> 
>> Looks like the current strategy works then, but quite slowly in some
>> cases. The main issue I see here is that freedesktop bugzilla seems to
>> be a black hole - I added a comment to bug #13416 half a year ago and
>> got zero response from upstream developers, so please forgive me my
>> slight frustration at this point - it's not that I didn't try, but if no
>> one upstream gives a damn about the problem, I tried to find allies
>> here, who could possibly have more convincing power. Attracting
>> attention - that was the purpose of my post.
> 
> That "they" thinking is so broken.  "Upstream developers" is not a group of
> aliens.  Ask on any IRC channel who maintains fontconfig and people will tell
> you.  Currently Keith Packard makes a release every year.  That is, he spends
> two or three days every year to make a release with patches that are ready to
> go in.  The only other person spending time on it has been me, preparing
> patches for Keith when release time gets close.  So in one sense there is no
> upstream developers.  Want to change that?  Become one.
> 
> That said, I'm going to spend some time before the end of the year on getting
> a fontconfig tree ready for release.  I'll take a look at your issue.
> 
> behdad
> 
>> Julian
> 
I would happily become an upstream dev, but unfortunately I can't code.
What I can do is testing patches, which could be helpful in case, as you
said, the fonts you are using are not exhibiting the issue. I could also
provide more information if necessary, but I'd need some guidance how to
obtain it. Thanks for looking into it in advance!

Julian



From notting at redhat.com  Wed Dec 10 14:27:43 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 10 Dec 2008 09:27:43 -0500
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <493F6EC6.7090100@redhat.com>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1227522629.3675.2625.camel@cookie.hadess.net>
	<493224B2.60706@redhat.com>
	<1228873607.24963.684.camel@cookie.hadess.net>
	<20081210031344.GA21432@nostromo.devel.redhat.com>
	<493F6EC6.7090100@redhat.com>
Message-ID: <20081210142743.GA18314@nostromo.devel.redhat.com>

Warren Togami (wtogami at redhat.com) said: 
> OTOH, what are concrete examples of OSS apps that use mmap()?

Old binary-only games were the usual culprit. In Fedora, Wine and
various games would need to be checked.

Bill



From notting at redhat.com  Wed Dec 10 14:33:09 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 10 Dec 2008 09:33:09 -0500
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
Message-ID: <20081210143309.GB18314@nostromo.devel.redhat.com>

Thomas Moschny (thomas.moschny at gmail.com) said: 
> > https://bugzilla.redhat.com/userprefs.cgi?tab=email
> >
> > See 'user watching'.
> >
> > People can set up bugstalking filters to get e-mailed any time someone
> > else would be e-mailed.
> 
> So, whom is he watching?

Myself, at least (which will cover most all the review tickets). You can see
who's watching you on the same bugzilla pref page.

Bill



From silfreed at silfreed.net  Wed Dec 10 14:07:55 2008
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Wed, 10 Dec 2008 09:07:55 -0500
Subject: Broken dependencies in Fedora 10 - 2008-12-10
In-Reply-To: <20081210001912.2084.59721@faldor.intranet>
References: <20081210001912.2084.59721@faldor.intranet>
Message-ID: <493FCD3B.6030501@silfreed.net>

Michael Schwendt wrote:
>     silfreed AT silfreed.net
>         qgis

Submitted rebuilds yesterday.

-Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/89278cb0/attachment.sig>

From alan at redhat.com  Wed Dec 10 14:39:47 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 10 Dec 2008 09:39:47 -0500
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <493F6EC6.7090100@redhat.com>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1227522629.3675.2625.camel@cookie.hadess.net>
	<493224B2.60706@redhat.com>
	<1228873607.24963.684.camel@cookie.hadess.net>
	<20081210031344.GA21432@nostromo.devel.redhat.com>
	<493F6EC6.7090100@redhat.com>
Message-ID: <20081210143947.GA20931@shell.devel.redhat.com>

On Wed, Dec 10, 2008 at 02:24:54AM -0500, Warren Togami wrote:
> NOT WORK by default which is absolutely fine.
> 
> OTOH, what are concrete examples of OSS apps that use mmap()?

Most apps that want any kind of fine level mixing - so games, media and the
like that hasn't gone ALSA uses mmap. I don't really see a problem there
is very little OSS stuff left out there and the ALSA emulation is a fall back
that works ok.

Alan



From jkeating at redhat.com  Wed Dec 10 16:36:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 08:36:54 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493F0BA8.1050300@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
Message-ID: <1228927014.3863.38.camel@localhost.localdomain>

On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
> One way or another, if I were building a distribution that wanted to 
> simultaneously claim that it is both new code and 'tested and working', 
> I'd try to plan in a way that it wasn't a flip of the coin on every 
> machine which you'll get today.

Now here's a crazy idea, that nobody seems to want to follow:

Treat rawhide as your 'new code' land, leave the release trees as your
'testing and working' code.  That is don't be so goddamn eager to push
new packages and new upstream releases to every freaking branch in
existence.

Of course, when I make suggestions like these, I become extremely
unpopular.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/d3e016c3/attachment.sig>

From jkeating at redhat.com  Wed Dec 10 16:41:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 08:41:17 -0800
Subject: [Ambassadors] Live CD & Localization (was: What Fedora makes
 sucking for me - or why I am NOT Fedora)
In-Reply-To: <493E568E.3090404@kanarip.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493E568E.3090404@kanarip.com>
Message-ID: <1228927277.3863.41.camel@localhost.localdomain>

On Tue, 2008-12-09 at 12:29 +0100, Jeroen van Meeuwen wrote:
> The Fedora Project however would still 
> host the torrent tracker so they have control over revocation and/or 
> modification of the spin/torrent.

The problem that this still leaves is currently to host the tracker, we
have to host the bits, and when you start multiplying each spin by 3 or
5 for languages, that space adds up /really/ quickly.  And it's a /ton/
of duplicate data.  The project just doesn't have the resources to host
that many spins per release.

We have to pick things which are interesting and worth the usage of
space.  In the past that has been include as many vastly different
things as possible, and have some form of !English support in them.  We
could go the other direction, pick /one/ spin to feature and then offer
it in as many different language specific variations of it as possible.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/545d2e51/attachment.sig>

From nicolas.mailhot at laposte.net  Wed Dec 10 16:48:20 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 10 Dec 2008 17:48:20 +0100 (CET)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927014.3863.38.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <137688a8d006acaa81580562c02e48e4.squirrel@arekh.dyndns.org>



Le Mer 10 d?cembre 2008 17:36, Jesse Keating a ?crit :

> Of course, when I make suggestions like these, I become extremely
> unpopular.

Not at all

/me agrees with F13

-- 
Nicolas Mailhot



From dmalcolm at redhat.com  Wed Dec 10 16:49:59 2008
From: dmalcolm at redhat.com (David Malcolm)
Date: Wed, 10 Dec 2008 11:49:59 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927014.3863.38.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <1228927799.15393.57.camel@radiator.bos.redhat.com>

On Wed, 2008-12-10 at 08:36 -0800, Jesse Keating wrote:
> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
> > One way or another, if I were building a distribution that wanted to 
> > simultaneously claim that it is both new code and 'tested and working', 
> > I'd try to plan in a way that it wasn't a flip of the coin on every 
> > machine which you'll get today.
> 
> Now here's a crazy idea, that nobody seems to want to follow:
> 
> Treat rawhide as your 'new code' land, leave the release trees as your
> 'testing and working' code.  That is don't be so goddamn eager to push
> new packages and new upstream releases to every freaking branch in
> existence.
> 
> Of course, when I make suggestions like these, I become extremely
> unpopular.

I've only partly followed this discussion, but one simple implementation
idea, if this hasn't been thought of/implemented:
- have bodhi detect if the version part of the NVR is being changed; if
so, raise the karma level needed to push the package. 

Rationale: it's my belief that a rebase to a different upstream version
typically carries greater risk of destabilization than targeted
patching.  Thus, a bump to a more recent upstream should receive more
testing than a packaging/patch change.


Hope this helps
Dave



From kevin at scrye.com  Wed Dec 10 16:55:50 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 10 Dec 2008 09:55:50 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghn23k$50a$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<ghn23k$50a$1@ger.gmane.org>
Message-ID: <20081210095550.4576b8c9@ohm.scrye.com>

On Wed, 10 Dec 2008 01:22:12 +0100
kevin.kofler at chello.at (Kevin Kofler) wrote:

> Colin Walters wrote:
> > Just to be clear, the direct push into stable is my fault; not Red
> > Hat's or other DBus developers or anyone else's.  I had originally
> > listed it for updates-testing, but then changed the update to
> > security and in a moment of total stupidity also changed the
> > listing for stable.
> 
> Are you sure you were the one who requested the push to stable and
> not the security team (when they gave their approval for the security
> update)?

The security team doesn't change where the update is set to go to. 

> I'm asking because the way Bodhi is set up, I think the security team
> does not see where you actually intend security updates to be pushed
> to, they all show up as requests for testing until they get approval,
> and somehow they automatically get queued for stable on approval
> unless explicitly canceled.

That may be the case, but it's bodhi doing that, not the security team. 
We should confirm this behavior/fix it. 

> All this was so much simpler and more obvious before that useless
> security team approval step was introduced (without really consulting
> packagers outside of the security team). :-( What benefit does that
> approval step bring us? It's obviously not QA or this update wouldn't
> have ended up in stable!

Security team checks the update for correctness with respect to CVE(s)
fixed, that there is a tracking bug filed against the update, that it
has some information about what the vulnerability is either in the
update text or in the bug, that it points to upstream info about the
bug, etc. 

There has been some talk of removing this step, but I think it's
usefull for the above reasons. I have seen security updates come in
with no bug attached, no CVE, and text of 'security update'. This is
not usefull to our users, IMHO. I might be in a minority here tho, so
perhaps the step should be removed. 

> 
>         Kevin Kofler
> 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/238fab62/attachment.sig>

From jspaleta at gmail.com  Wed Dec 10 17:05:27 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 10 Dec 2008 08:05:27 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927799.15393.57.camel@radiator.bos.redhat.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228927799.15393.57.camel@radiator.bos.redhat.com>
Message-ID: <604aa7910812100905s4671c0ffo751099dc9005e3ab@mail.gmail.com>

On Wed, Dec 10, 2008 at 7:49 AM, David Malcolm <dmalcolm at redhat.com> wrote:
> Rationale: it's my belief that a rebase to a different upstream version
> typically carries greater risk of destabilization than targeted
> patching.  Thus, a bump to a more recent upstream should receive more
> testing than a packaging/patch change.

hmmm......I like that.  However that would still require having people
consume updates-testing and reporting in bodhi.   Do we have enough
people doing that? Do we have a good picture of how many are consuming
testing right now?  If we got a ratio of the number of ips in the
mirrormanager logs for updates-testing to updates-stable in say the
last week of F9 mirrormanager activity we'd have a baseline
understanding of the percentage of the base which is consuming
testing.

I'm going to talk about my experience for a second, mainly because I
like talking about me.  For most of the packages I maintain I don't
think I've ever seen karma raised to 3 or down to -3 for any package
I've had in testing...even when the update was pushed specifically as
a bugfix. I'll maybe get the reporter to chime in, but maybe not in
bodhi it maybe in the bugticket as a new comment (and it maybe by
consuming the koji builds directly before the bodhi push).  I'm not
sure I'd ever see an update for one of my packages pushed t stable if
I waited for bodhi karma to pile up, my packages just aren't that
important and don't appear in any default packageset for a spin. Maybe
that's different for more critical or more important packages.

-jef



From abu_hurayrah at hidayahonline.org  Wed Dec 10 17:23:09 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Wed, 10 Dec 2008 19:23:09 +0200
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081209202919.GM9280@calliope.phig.org>
References: <492E05E7.2080708@cchtml.com>
	<90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>
	<493341BB.10706@cchtml.com> <5rjc06xma9.ln2@ppp1053.in.ipex.cz>
	<1228128134.3451.36.camel@beta> <1228128814.3451.40.camel@beta>
	<20081209104229.GH9280@calliope.phig.org>
	<1228821618.4861.83.camel@beta>
	<20081209202919.GM9280@calliope.phig.org>
Message-ID: <1228929790.3572.45.camel@beta>

On Tue, 2008-12-09 at 12:29 -0800, Karsten Wade wrote:
> You know Fedora, we pride ourselves on our "be bold and do it"
> spirit.  Well, unless we are complaining about the bureaucracy. :)
> 
> All I ask is you to send a self-intro[1] embedded in a discussion opener
> to fedora-docs-list; obviously join the list.  We want to scope out
> solution(s) and culture change ideas there, then bring a well formed
> proposal/plan back to groups such as f-devel-l.
> 
> Within that planning process, we'll likely discover early that we need
> some resourcs such as a publictest server instance to start
> prototyping.  We can sort those requests out as needed.
> 
> Alternately, and we can consider this ... do we gain by keeping the
> discussion on fedora-devel-list?  It feels to me that we've squeezed
> the juice out of the ideas here so far, and it's time for a smaller
> group (sub-project such as Docs) to take it aside and bring back
> something more to squeeze.  But that is just a feeling, I'm open to
> other ideas.
> 
> - Karsten
> [1] That's the "how to join Docs" step that really matters:
> 
> https://fedoraproject.org/wiki/DocsProject/Join#Signing_Up
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Thanks Karsten, that's what I needed.  I think I'm already on the Docs
list, but I'll do the introduction and post some of the most succulent
ideas from this thread (at least, as I see them) there.  And I agree
with moving this to the docs list, and if we need devel input, then we
can always cross-post when needed, rather than saturate devel with
tangential issues.



From jamundso at gmail.com  Wed Dec 10 17:25:29 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Wed, 10 Dec 2008 11:25:29 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927014.3863.38.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <6d06ce20812100925u12ca4019ucafb252d87eb91b7@mail.gmail.com>

2008/12/10 Jesse Keating <jkeating at redhat.com>:
> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
>> One way or another, if I were building a distribution that wanted to
>> simultaneously claim that it is both new code and 'tested and working',
>> I'd try to plan in a way that it wasn't a flip of the coin on every
>> machine which you'll get today.
>
> Now here's a crazy idea, that nobody seems to want to follow:
>
> Treat rawhide as your 'new code' land, leave the release trees as your
> 'testing and working' code.  That is don't be so goddamn eager to push
> new packages and new upstream releases to every freaking branch in
> existence.
>
> Of course, when I make suggestions like these, I become extremely
> unpopular.

Not to me. +1

Regarding +/-,
Can new packages default accordingly?
+1 rawhide
 0 testing
-1 stable

(or, +2, 0, -2... you get the idea)

Then, the voting system does what it's supposed to do!!!
Maybe analogous to pkg submitter, sponsor, review, etc - other sets of
eyes, taking ownership of action....

In other words, push back some of the "goddamn" ownership where it
belows, instead of the front-end where testers and **end-users** have
to do cart-wheels to fix things.
And, don't start crying, "aww, we just don't have time..."
boo-f*(&ing-hoo. Neither do the rest of us.
But, working together, the system should balance itself - when the
votes happen it's a good package, when they don't it means, go figure,
more testing needs to be done, and help should be requested
accordingly.

See the efficiency there? The few request help *forward*, rather than
the masses, in a panic, requesting help *backwards*...

jerry

p.s. I only started those sentences with conjunctions for the sake of
time. Please don't try this at home! :-)
-- 
Store in cool, dry place. Rotate stock.



From bruno at wolff.to  Wed Dec 10 17:28:36 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 10 Dec 2008 11:28:36 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812100905s4671c0ffo751099dc9005e3ab@mail.gmail.com>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228927799.15393.57.camel@radiator.bos.redhat.com>
	<604aa7910812100905s4671c0ffo751099dc9005e3ab@mail.gmail.com>
Message-ID: <20081210172836.GA7660@wolff.to>

On Wed, Dec 10, 2008 at 08:05:27 -0900,
  Jeff Spaleta <jspaleta at gmail.com> wrote:
> 
> hmmm......I like that.  However that would still require having people
> consume updates-testing and reporting in bodhi.   Do we have enough
> people doing that? Do we have a good picture of how many are consuming
> testing right now?  If we got a ratio of the number of ips in the
> mirrormanager logs for updates-testing to updates-stable in say the
> last week of F9 mirrormanager activity we'd have a baseline
> understanding of the percentage of the base which is consuming
> testing.

I have updates-testing enabled but I am not typically going to notice
changes there unless something breaks. So you'll only get negative
feedback, not positive feedback via that route.

For packages that I am really interested in looking for changes in (for
say fixes to bugs I have reported), updates-testing is way too slow.
I just keep an eye on koji and pull updates from there when they show up for
what I am interested in and feedback typically goes into bugzilla.



From james at fedoraproject.org  Wed Dec 10 17:30:26 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 10 Dec 2008 12:30:26 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493F0BA8.1050300@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
Message-ID: <1228930226.30987.107.camel@code.and.org>

On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
> James Antill wrote:
> >>  but it is the most 
> >> obvious and adding a simple mechanism to yum to report the latest update 
> >> timestamp or some repo transaction id(s) that could be fed to another 
> >> instance to ensure it ignored subsequent changes to the repo(s) to 
> >> perform an update to the same packages would be useful in its own right 
> >> and appreciated when inherited by the enterprise versions.
> > 
> >  What is this "repo. transaction ids" 
> 
> If you tracked changes in a repo, yum could use that to ensure that it 
> didn't pull newer packages when you were trying to reproduce a tested 
> update.

 Or, without re-writting the entire world ... it could just use the
NEVRA information that is already there.

> ... how is that different from a
> > local mirror. Even better question how is it _better_.
> 
> Ummm, it saves every user a boatload of work and disk space... More to 
> the point it is something that they might actually do.

 Again, transaction ids are just a way of saying "turn a yum repo. into
a git repo. ... with branches etc." ... but doing that it _still_
requires the "old" packages, which we don't have. And if we did have
them, then we don't need to integrate git functionality into yum to get
the behaviour of being able to install older tested packages.
 The advantage of a local repo. (with an upstream source) is that you
have to do minimal work, and you can control when the data changes.

> >  Everyone who spends five minutes thinking about it comes up with "I
> > know we'll merge the functionality of git and yum, so that you can
> > follow branches in a repo. etc." ... which _might_ be fine, if _they'd_
> > actually have to implement it. But I fail to see the significant
> > advantages over doing all of this work on the repo. side (and possibly
> > creating tools there, to help -- again, feel free to if you want this).
> 
> Yes, it is clear that you need version control capability in a package 
> manager.

 No, it isn't.

> >  By "avoid some of the bugs" I'm going to assume you mean "I want other
> > people to do work" ... which is nice, but not how it works.
> 
> No, I have said I would do much more testing if given a design where I 
> knew I could subsequently update a working machine to exactly the same 
> set of packages I had tested.  I'm just not willing to mirror a whole 
> repository to deal with this on my own.

 Again, other people don't need this extra behaviour ... I run packages
from updates-testing all the time. And surprise, surprise, 99% of the
time they are the exact same things that end up in updates ... and the
majority of the rest of the time, they just have bugfixes for
regressions found when in updates-testing.
 If _you_ "need" to stop all updates while you test, then as I've said
multiple times ... feel free to create a local repo. based off the
upstream Fedora. This is very easy for you to do. 

> >>   Asking every 
> >> user to maintain a full repo mirror just doesn't sound like a reasonable 
> >> approach to this though, especially if you think the mirrors themselves 
> >> would have a problem storing all the updates.
> > 
> >  I'm not asking "every user" to do that. Let me show you this full
> > conversation, and hopefully it will be obvious:
> > 
> > . LES: I need to do X.
> 
> You misunderstood.  I'm not prepared to be the only tester. I mean "if 
> you do X, many more people will test".  Basically everyone who runs 
> fedora needs to do X unless they can afford to be down a while.

 Again, there are people testing already ... I run many updates from
updates-testing. What you desire is not required to test things from
updates-testing.

> >  We already have updates-testing and --security, --bz. Which basically
> > do this ... if you think things should stay in updates-testing longer,
> > propose some reasoning to FESCo/whatever.
> >  Making updates become updates-testing2 based on an opaque time window
> > is not the solution though, IMO.
> 
> Why is the time window opaque?

 Because you have the same object "updates" which has different
properties depending on the time, and there is no code which would
automatically let the user know that this object changes.
 For instance if you have "yum update -y" in cron. ... for this to work
with your "time window" we now need code so the user can say "apply
updates when the time window is 50% complete". Without that code the
window is opaque, maybe apart from people hanging out in f-d-l (and who
have a good memory).

>   Again, why do you expect anyone to test, 
> whether from updates-testing or elsewhere without a mechanism to use 
> exactly the package set that they tested on their working machines?

 Because most people don't need that feature to test, they trust that
the package owners aren't going to put X-1 into updates-testing and then
quickly put X-666 into updates, which is completely different, when
noone is looking.
 In the _vast_ majority of cases this trust is not misplaced.

 As many other people have already told you, many times. If you don't
trust Fedora, aren't prepared to help test it and think that it isn't
tested enough for your use ... why don't you just use CentOS/whatever?

-- 
James Antill <james at fedoraproject.org>
Fedora



From fedora at matbooth.co.uk  Wed Dec 10 17:06:40 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Wed, 10 Dec 2008 17:06:40 +0000
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927799.15393.57.camel@radiator.bos.redhat.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228927799.15393.57.camel@radiator.bos.redhat.com>
Message-ID: <9497e9990812100906l155e71bchf8cc146cd11d5f@mail.gmail.com>

On Wed, Dec 10, 2008 at 4:49 PM, David Malcolm <dmalcolm at redhat.com> wrote:
> On Wed, 2008-12-10 at 08:36 -0800, Jesse Keating wrote:
>> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
>> > One way or another, if I were building a distribution that wanted to
>> > simultaneously claim that it is both new code and 'tested and working',
>> > I'd try to plan in a way that it wasn't a flip of the coin on every
>> > machine which you'll get today.
>>
>> Now here's a crazy idea, that nobody seems to want to follow:
>>
>> Treat rawhide as your 'new code' land, leave the release trees as your
>> 'testing and working' code.  That is don't be so goddamn eager to push
>> new packages and new upstream releases to every freaking branch in
>> existence.
>>
>> Of course, when I make suggestions like these, I become extremely
>> unpopular.
>
> I've only partly followed this discussion, but one simple implementation
> idea, if this hasn't been thought of/implemented:
> - have bodhi detect if the version part of the NVR is being changed; if
> so, raise the karma level needed to push the package.
>

There is nothing to stop breaking changes sneaking into revision bumps
only. Especially when the package is a source control snapshot of some
future version. Version numbers mean different things to different
upstream projects anyway, so I don't think anybody (anybodhi?) here
should be defining what a version bump signifies.


> Rationale: it's my belief that a rebase to a different upstream version
> typically carries greater risk of destabilization than targeted
> patching.  Thus, a bump to a more recent upstream should receive more
> testing than a packaging/patch change.
>
>
> Hope this helps
> Dave
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Mat Booth
www.matbooth.co.uk



From jspaleta at gmail.com  Wed Dec 10 17:32:45 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 10 Dec 2008 08:32:45 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927014.3863.38.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <604aa7910812100932h344932f2v23ead968f2693dc4@mail.gmail.com>

2008/12/10 Jesse Keating <jkeating at redhat.com>:
> Of course, when I make suggestions like these, I become extremely
> unpopular.

If we had an alternative for people to use other than updates-testing
to get new new versions of applications to new releases.. like your
KoPeR's idea of old... maybe that would take the pressure off to put
significant version changes into the standard updates space.

-jef



From mclasen at redhat.com  Wed Dec 10 17:35:49 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 10 Dec 2008 12:35:49 -0500
Subject: Making updates-testing more useful
Message-ID: <1228930549.3648.14.camel@localhost.localdomain>

I have an F10 installation, and have updates-testing enabled, but I
almost never give any feedback in bodhi, because it is fairly hard to
keep track of what updates are installed, which of them are in testing,
etc. 

I think we could make updates-testing much more useful if we had a tiny
bit of PackageKit integration. Basically, PackageKit should know that
these are testing updates, and should ask me 'There are ... package
updates available that need testing. Do you want to test these now ?' 
For extra points, we could even show a 'report back' link somewhere that
allows to send comments to bodhi. 

Of course, this has to be implemented in a suitably distibution-neutral
way to be integrated in PackageKit, but I think test updates are a
sufficiently general concept that PackageKit should support.

What do you think ?


Matthias 



From jamundso at gmail.com  Wed Dec 10 17:35:33 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Wed, 10 Dec 2008 11:35:33 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228930226.30987.107.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org>
Message-ID: <6d06ce20812100935x29fa48dejcab2fcb0eb3a8c4c@mail.gmail.com>

On Wed, Dec 10, 2008 at 11:30 AM, James Antill <james at fedoraproject.org> wrote:
> tested enough for your use ... why don't you just use CentOS/whatever?

Because we shouldn't have to?
I never expect "bleeding edge" to mean "breaks important things
sometimes", unless it's rawhide.

jerry

-- 
Store in cool, dry place. Rotate stock.



From james at fedoraproject.org  Wed Dec 10 17:43:46 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 10 Dec 2008 12:43:46 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927014.3863.38.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <1228931026.30987.121.camel@code.and.org>

On Wed, 2008-12-10 at 08:36 -0800, Jesse Keating wrote:
> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
> > One way or another, if I were building a distribution that wanted to 
> > simultaneously claim that it is both new code and 'tested and working', 
> > I'd try to plan in a way that it wasn't a flip of the coin on every 
> > machine which you'll get today.
> 
> Now here's a crazy idea, that nobody seems to want to follow:
> 
> Treat rawhide as your 'new code' land, leave the release trees as your
> 'testing and working' code.  That is don't be so goddamn eager to push
> new packages and new upstream releases to every freaking branch in
> existence.
> 
> Of course, when I make suggestions like these, I become extremely
> unpopular.

 With some people, I guess, although as long as I've been reading f-d-l
there has been repeated calls for the updates to slow down.

 There are two problems here:

1. Sometimes updates have significant bug fixes, as well as a couple of
new features (and are fairly well testing, although sometimes even the
bugfixes have bugs).
 I would put most of the yum updates that have been released for
non-rawhide versions in this category.

2. Prisoners dilemma, if there are 100M of updates a week then it
becomes very easy to say "Well my 100k update isn't that big, and has
XYZ feature which is really nice ... so I'll update it too".


...if you are just asking nicely then #1 and #2 create a feedback loop
which perpetuates the current updates firehose, if we want to do this we
need to start forcing updates to not happen (ie. policy saying that
updates _won't_ happen unless they qualify under XYZ).
 Maybe we could introduce this with usable KOPERS, so people can put
their updates/non-critical-fixes into those repos.

 And as a Fedora user, an upstream developer and a Fedora packager ... I
would welcome a policy to that effect.

-- 
James Antill <james at fedoraproject.org>
Fedora



From mclasen at redhat.com  Wed Dec 10 17:45:11 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 10 Dec 2008 12:45:11 -0500
Subject: Making updates-testing more useful
In-Reply-To: <1228931001.10235.55.camel@hughsie-work.lan>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228931001.10235.55.camel@hughsie-work.lan>
Message-ID: <1228931111.3648.15.camel@localhost.localdomain>

On Wed, 2008-12-10 at 17:43 +0000, Richard Hughes wrote:
> On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> > There are ... package
> > updates available that need testing. Do you want to test these now ?
> 
> Also, this would imply automatically turning on updates-testing,
> downloading metadata, and disabling updates-testing all behind the users
> back. A few people might get upset by this.
> 

I would probably restrict this to people who have explicitly enabled
updates-testing.



From hughsient at gmail.com  Wed Dec 10 17:48:48 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 10 Dec 2008 17:48:48 +0000
Subject: Making updates-testing more useful
In-Reply-To: <1228930549.3648.14.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
Message-ID: <1228931328.10235.56.camel@hughsie-work.lan>

> I have an F10 installation, and have updates-testing enabled, but I
> almost never give any feedback in bodhi, because it is fairly hard to
> keep track of what updates are installed, which of them are in
testing,
> etc. 

I think it makes a lot of sense, and something we _need_ to do to
increase the number of people sending karma.

> I think we could make updates-testing much more useful if we had a
tiny
> bit of PackageKit integration. Basically, PackageKit should know that
> these are testing updates, and should ask me 'There are ... package
> updates available that need testing. Do you want to test these now ?' 
> For extra points, we could even show a 'report back' link somewhere
that
> allows to send comments to bodhi. 

And let people opt in or opt out. I think we can do this in a cross
distro way with a little bit of cleverness.

> Of course, this has to be implemented in a suitably
distibution-neutral
> way to be integrated in PackageKit, but I think test updates are a
> sufficiently general concept that PackageKit should support.

Yes. This has to be general. Last time I asked, a yum repo didn't
support a "class", i.e. a testing repo, and we have to use some
heuristics in the yum backend to detect debuginfo repos. We could do the
same thing here.

Richard.



From pemboa at gmail.com  Wed Dec 10 17:55:01 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 10 Dec 2008 11:55:01 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <1228908903.15367.180.camel@ignacio.lan>
References: <49393DE3.1080707@redhat.com> <493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
	<1228868657.15367.138.camel@ignacio.lan>
	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>
	<1228908903.15367.180.camel@ignacio.lan>
Message-ID: <16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>

2008/12/10 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Tue, 2008-12-09 at 20:40 -0600, Arthur Pemberton wrote:
>> 2008/12/9 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
>> > On Tue, 2008-12-09 at 13:05 -0600, Arthur Pemberton wrote:
>> >> 2008/12/9 Toshio Kuratomi <a.badger at gmail.com>:
>> >> > So let me reiterate:
>> >> >
>> >> > * python-3.x will not be in Fedora-11 unless it becomes obvious in the
>> >> > next few weeks that we absolutely must be running it for the next release.
>> >> > * we need more experience with python-2.6+ & python-3 compatibility
>> >> > before we decide whether parallel versions of python are necessary.
>> >> >
>> >> > .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
>> >> >
>> >> > -Toshio
>> >>
>> >>
>> >> Well again. Some people (like Toshio) seem to have a grasp on the
>> >> matter. All this banter hasn't produced anything more of use. How
>> >> about forming a temp SIG to take care of this trusting they do the
>> >> right thing?
>> >
>> > As opposed to the Python SIG that already exists?
>>
>> No. Seems like the ideal body to come to a decision and let the rest
>> of us know.
>
> Well, most of the active members of the Python SIG have chimed in on
> this, and we're all channeling Frankie.
>
> Now, I do believe this is an important subject and we do need to gauge
> the impact Python 3000 has on Fedora, but I believe that we are grossly
> unequipped to do so at this time. I'd like to revisit this topic in
> about a year (perhaps sooner, depending on circumstances), but for now
> everyone just relax.


Just to  be clear, does that mean no Python 3.0 in parallel either?


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mike at miketc.net  Wed Dec 10 18:23:24 2008
From: mike at miketc.net (Mike Chambers)
Date: Wed, 10 Dec 2008 12:23:24 -0600
Subject: Making updates-testing more useful
In-Reply-To: <1228930549.3648.14.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
Message-ID: <1228933404.2682.7.camel@scrappy.miketc.net>

On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> I have an F10 installation, and have updates-testing enabled, but I
> almost never give any feedback in bodhi, because it is fairly hard to
> keep track of what updates are installed, which of them are in testing,
> etc. 

+1, same reason, cept for the pain of sometimes a breakage that hate
dealing with.

> 
> I think we could make updates-testing much more useful if we had a tiny
> bit of PackageKit integration. Basically, PackageKit should know that
> these are testing updates, and should ask me 'There are ... package
> updates available that need testing. Do you want to test these now ?' 
> For extra points, we could even show a 'report back' link somewhere that
> allows to send comments to bodhi. 


What are general thoughts on how this would work?  You get the testing
updates, install/update, run them, then click on some GUI and enter
comments to be submitted to Bodhi?

And I guess (not to get too detailed into something not created yet)
those updates would stay polluted in the GUI until you make a comment or
remove it yourself (this would help show what you have left to comment
on so you can remember)?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From lesmikesell at gmail.com  Wed Dec 10 18:27:52 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 12:27:52 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927014.3863.38.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <49400A28.9080508@gmail.com>

Jesse Keating wrote:
> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
>> One way or another, if I were building a distribution that wanted to 
>> simultaneously claim that it is both new code and 'tested and working', 
>> I'd try to plan in a way that it wasn't a flip of the coin on every 
>> machine which you'll get today.
> 
> Now here's a crazy idea, that nobody seems to want to follow:
> 
> Treat rawhide as your 'new code' land, leave the release trees as your
> 'testing and working' code.  That is don't be so goddamn eager to push
> new packages and new upstream releases to every freaking branch in
> existence.
> 
> Of course, when I make suggestions like these, I become extremely
> unpopular.

That might work if very large numbers of users used updates-testing.  Is 
that the case?  Without a large well-equipped (and paid?) QA team, and 
maybe even with, there are always going to be at least two types of 
problems that sneak by.  One is human error in deciding what to release 
and another is the kind of bug that only affects certain hardware or 
configurations that weren't tested.

Do you keep statistics on how many things fail to move from 
updates-testing to updates?   Maybe batching the moves would be enough 
to get the safety net effect.  What if updates-testing moved to updates 
once a month with a requirement that packages had spent at least 2 weeks 
in updates-testing or had been through a more stringent review to 
enforce extra safety checks on anything that had to be pushed (time 
values could be seasoned to taste), and an even more stringent policy 
would control emergency fixes directly to updates.   That way the people 
who want bleeding-edge would have to pull from updates-testing to get 
them (and the longer the cycle the more you would encourage this) and 
for machines where you have to avoid risks you could just not do updates 
   near the scheduled times for the moves, allowing a chance for 
emergency fixes to be pushed if needed.

--
   Les Mikesell
     lesmikesell at gmail.com



From ivazqueznet at gmail.com  Wed Dec 10 18:14:26 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 10 Dec 2008 13:14:26 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>
References: <49393DE3.1080707@redhat.com> <493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
	<1228868657.15367.138.camel@ignacio.lan>
	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>
	<1228908903.15367.180.camel@ignacio.lan>
	<16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>
Message-ID: <1228932866.30148.15.camel@ignacio.lan>

On Wed, 2008-12-10 at 11:55 -0600, Arthur Pemberton wrote:
> Just to  be clear, does that mean no Python 3.0 in parallel either?

That has already been turned down multiple times. Watch my blog if you
want a parallel-installable package for 3.x. I plan to update my SRPM to
final once the 2.6 work in Fedora is done.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/1f8846a3/attachment.sig>

From lesmikesell at gmail.com  Wed Dec 10 18:29:55 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 12:29:55 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>
	<493D68D8.2000308@gmail.com>	<1228762046.3545.2.camel@localhost.localdomain>	<1228774767.25085.141.camel@localhost.localdomain>	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>	<493EA2D8.90200@gmail.com>	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>	<1228868657.15367.138.camel@ignacio.lan>	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>	<1228908903.15367.180.camel@ignacio.lan>
	<16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>
Message-ID: <49400AA3.1040701@gmail.com>

Arthur Pemberton wrote:
>
>> Well, most of the active members of the Python SIG have chimed in on
>> this, and we're all channeling Frankie.
>>
>> Now, I do believe this is an important subject and we do need to gauge
>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>> unequipped to do so at this time. I'd like to revisit this topic in
>> about a year (perhaps sooner, depending on circumstances), but for now
>> everyone just relax.
> 
> 
> Just to  be clear, does that mean no Python 3.0 in parallel either?

How do you expect people to modify and test their own code without a 
parallel install?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Wed Dec 10 18:30:14 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 10 Dec 2008 09:30:14 -0900
Subject: Making updates-testing more useful
In-Reply-To: <1228933404.2682.7.camel@scrappy.miketc.net>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
Message-ID: <604aa7910812101030h62efb942j5c82f290e84f62e5@mail.gmail.com>

On Wed, Dec 10, 2008 at 9:23 AM, Mike Chambers <mike at miketc.net> wrote:
> What are general thoughts on how this would work?  You get the testing
> updates, install/update, run them, then click on some GUI and enter
> comments to be submitted to Bodhi?

PK's notification applet periodically reminds you that you have
testing updates installed that you haven't sent any karma love in for.
  Something like "Hey you've had this testing package installed now
for a few days, maybe its time to send it some love?"


-jef



From maxx at krakoa.dk  Wed Dec 10 18:40:15 2008
From: maxx at krakoa.dk (Mads Villadsen)
Date: Wed, 10 Dec 2008 19:40:15 +0100
Subject: Making updates-testing more useful
In-Reply-To: <1228930549.3648.14.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
Message-ID: <1228934415.3395.2.camel@localhost.localdomain>

On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> I think we could make updates-testing much more useful if we had a tiny
> bit of PackageKit integration. Basically, PackageKit should know that
> these are testing updates, and should ask me 'There are ... package
> updates available that need testing. Do you want to test these now ?' 
> For extra points, we could even show a 'report back' link somewhere that
> allows to send comments to bodhi. 
> 
> Of course, this has to be implemented in a suitably distibution-neutral
> way to be integrated in PackageKit, but I think test updates are a
> sufficiently general concept that PackageKit should support.
> 
> What do you think ?

I think it is a great idea. As it is also possible to track the date of
the install then PackageKit could ask a question like this: "You have
had package Y from updates-testing installed for 5 days. Would you like
to rate it now?"
-- 
Mads Villadsen <maxx at krakoa.dk>



From skvidal at fedoraproject.org  Wed Dec 10 18:52:18 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 10 Dec 2008 13:52:18 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <1228931328.10235.56.camel@hughsie-work.lan>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228931328.10235.56.camel@hughsie-work.lan>
Message-ID: <alpine.LFD.2.00.0812101351370.20073@localhost.localdomain>



On Wed, 10 Dec 2008, Richard Hughes wrote:

>> I have an F10 installation, and have updates-testing enabled, but I
>> almost never give any feedback in bodhi, because it is fairly hard to
>> keep track of what updates are installed, which of them are in
> testing,
>> etc.
>

I think the idea is good. I don't think it helps us to store more 
information in PK, though.

If we're going to be storing where a package is installed from. It should 
probably be in rpm.

-sv



From lesmikesell at gmail.com  Wed Dec 10 18:54:30 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 12:54:30 -0600
Subject: Making updates-testing more useful
In-Reply-To: <1228933404.2682.7.camel@scrappy.miketc.net>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
Message-ID: <49401066.2030403@gmail.com>

Mike Chambers wrote:
> On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
>> I have an F10 installation, and have updates-testing enabled, but I
>> almost never give any feedback in bodhi, because it is fairly hard to
>> keep track of what updates are installed, which of them are in testing,
>> etc. 
> 
> +1, same reason, cept for the pain of sometimes a breakage that hate
> dealing with.
> 
>> I think we could make updates-testing much more useful if we had a tiny
>> bit of PackageKit integration. Basically, PackageKit should know that
>> these are testing updates, and should ask me 'There are ... package
>> updates available that need testing. Do you want to test these now ?' 
>> For extra points, we could even show a 'report back' link somewhere that
>> allows to send comments to bodhi. 
> 
> 
> What are general thoughts on how this would work?  You get the testing
> updates, install/update, run them, then click on some GUI and enter
> comments to be submitted to Bodhi?
> 
> And I guess (not to get too detailed into something not created yet)
> those updates would stay polluted in the GUI until you make a comment or
> remove it yourself (this would help show what you have left to comment
> on so you can remember)?

Could there be a way to throw everything in the same repo and give the 
user/installer a choice of how 'well-tested' something should be before 
installing it?  Preferably with a sliding scale instead of just 2 
choices.  Normally on new installs and machines used explicitly for 
testing I'd expect people to want the latest changes but become more 
conservative on machines that are working well and used for important 
work.  The 'well-tested' concept might have factors for age, feedback, 
emergency overrides, etc.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From fedora at leemhuis.info  Wed Dec 10 18:58:19 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 10 Dec 2008 19:58:19 +0100
Subject: The looming Python 3(000) monster
In-Reply-To: <1228932866.30148.15.camel@ignacio.lan>
References: <49393DE3.1080707@redhat.com>
	<493D68D8.2000308@gmail.com>	<1228762046.3545.2.camel@localhost.localdomain>	<1228774767.25085.141.camel@localhost.localdomain>	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>	<493EA2D8.90200@gmail.com>	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>	<1228868657.15367.138.camel@ignacio.lan>	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>	<1228908903.15367.180.camel@ignacio.lan>	<16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>
	<1228932866.30148.15.camel@ignacio.lan>
Message-ID: <4940114B.3000208@leemhuis.info>

On 10.12.2008 19:14, Ignacio Vazquez-Abrams wrote:
> On Wed, 2008-12-10 at 11:55 -0600, Arthur Pemberton wrote:
>> Just to  be clear, does that mean no Python 3.0 in parallel either?
> That has already been turned down multiple times. 

Those things (and the discussion around it, like this one) will drive me 
away from Fedora sooner or later.

For me the whole thing boils down to: There is a software that some 
people want (developers for example; and there are a lot of developers 
that use Fedora afaics...); it's open-source, it doesn't hurt upstream 
if we ship it (like kernel-modules), so let's just ship it.

Anyway:

> Watch my blog if you
> want a parallel-installable package for 3.x. I plan to update my SRPM to
> final once the 2.6 work in Fedora is done.

Do you plan to submit it to RPM Fusion?

Cu
knurd



From dominik at greysector.net  Wed Dec 10 19:00:36 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 10 Dec 2008 20:00:36 +0100
Subject: nautilus depends on a lot of stuff via gvfs
In-Reply-To: <1228873368.7475.5.camel@matthiasc>
References: <1228818420.3626.52.camel@eagle.danny.cz>
	<1228871905.24963.646.camel@cookie.hadess.net>
	<1228873368.7475.5.camel@matthiasc>
Message-ID: <20081210190035.GA5197@mokona.greysector.net>

On Wednesday, 10 December 2008 at 02:42, Matthias Clasen wrote:
> On Wed, 2008-12-10 at 01:18 +0000, Bastien Nocera wrote:
> 
> > > 
> > > So my proposal is to split nautilus into nautilus-core, that will
> > > contains the content of the current nautilus package, and nautilus
> > > "meta" package that will contains all the dependencies plus dependency
> > > on nautilus-core. This solution will install all the deps as today, but
> > > leave the option to remove the unnecessary packages afterwards.
> > > 
> > > Only 3 packages will be affected with this split
> > > nautilus-devel
> > > nautilus-python
> > > seahorse-plugins
> > > and they should be made to depend on nautilus-core instead of nautilus.
> > > 
> > > I will file a bug with the proposed change to nautilus spec file.
> > 
> > That's not workable. You'd probably rather rejigger the samba packages
> > so it's possible to use Samba in any appropriate environment without
> > dragging in the server, or the excessively big packages. You should do
> > the same for other dependencies.
> > 
> > Removing functionality from nautilus as it is installed by default won't
> > fix that problem.
> 
> Fwiw, I don't think it is a big problem to change things so that gvfs
> subpackages are pulled in by comps instead of by hard deps from
> nautilus, as long as they are all in the default install. I don't
> introducing a nautilus metapackage for this purpose is necessary or a
> good idea.

Why is it not a good idea? We're doing metapackages already and they seem
to be working out just fine (see git or R, just to give a couple of examples).

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From a.badger at gmail.com  Wed Dec 10 18:59:54 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 10 Dec 2008 10:59:54 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <49400AA3.1040701@gmail.com>
References: <49393DE3.1080707@redhat.com>	<493D68D8.2000308@gmail.com>	<1228762046.3545.2.camel@localhost.localdomain>	<1228774767.25085.141.camel@localhost.localdomain>	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>	<493EA2D8.90200@gmail.com>	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>	<1228868657.15367.138.camel@ignacio.lan>	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>	<1228908903.15367.180.camel@ignacio.lan>	<16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>
	<49400AA3.1040701@gmail.com>
Message-ID: <494011AA.5080107@gmail.com>

Les Mikesell wrote:
> Arthur Pemberton wrote:
>>
>>> Well, most of the active members of the Python SIG have chimed in on
>>> this, and we're all channeling Frankie.
>>>
>>> Now, I do believe this is an important subject and we do need to gauge
>>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>>> unequipped to do so at this time. I'd like to revisit this topic in
>>> about a year (perhaps sooner, depending on circumstances), but for now
>>> everyone just relax.
>>
>>
>> Just to  be clear, does that mean no Python 3.0 in parallel either?
> 
> How do you expect people to modify and test their own code without a
> parallel install?
> 
As stated multiple times, the initial port will be to python-2.6+ with
python-3 features turned on.  Then we'll see where we're at.

It's possible that the remaining porting work will be small at that
point and we can migrate easily.  It's also possible that it's still a
major undertaking to go from py-2.6 w/ python-3 features to py3.  But we
won't know until code starts being ported so there's no use trying to
guess what we need to do now.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/7d20cb5a/attachment.sig>

From dominik at greysector.net  Wed Dec 10 19:11:03 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 10 Dec 2008 20:11:03 +0100
Subject: Making updates-testing more useful
In-Reply-To: <604aa7910812101030h62efb942j5c82f290e84f62e5@mail.gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<604aa7910812101030h62efb942j5c82f290e84f62e5@mail.gmail.com>
Message-ID: <20081210191103.GB5197@mokona.greysector.net>

On Wednesday, 10 December 2008 at 19:30, Jeff Spaleta wrote:
> On Wed, Dec 10, 2008 at 9:23 AM, Mike Chambers <mike at miketc.net> wrote:
> > What are general thoughts on how this would work?  You get the testing
> > updates, install/update, run them, then click on some GUI and enter
> > comments to be submitted to Bodhi?
> 
> PK's notification applet periodically reminds you that you have
> testing updates installed that you haven't sent any karma love in for.
>   Something like "Hey you've had this testing package installed now
> for a few days, maybe its time to send it some love?"

"Here are the links to bug reports about problems it was supposed
 to fix:"

So that I can verify that the bug is indeed gone instead of writing
"worksforme" in the comment when in fact I'm not even running the
affected scenario.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jwboyer at gmail.com  Wed Dec 10 19:16:31 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 10 Dec 2008 14:16:31 -0500
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812101351370.20073@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228931328.10235.56.camel@hughsie-work.lan>
	<alpine.LFD.2.00.0812101351370.20073@localhost.localdomain>
Message-ID: <20081210191631.GB1769@yoda.jdub.homelinux.org>

On Wed, Dec 10, 2008 at 01:52:18PM -0500, Seth Vidal wrote:
>
>
> On Wed, 10 Dec 2008, Richard Hughes wrote:
>
>>> I have an F10 installation, and have updates-testing enabled, but I
>>> almost never give any feedback in bodhi, because it is fairly hard to
>>> keep track of what updates are installed, which of them are in
>> testing,
>>> etc.
>>
>
> I think the idea is good. I don't think it helps us to store more  
> information in PK, though.

Agreed.

> If we're going to be storing where a package is installed from. It should 
> probably be in rpm.

We can't easily do that though, can we?  Given that the same binary RPMs
that are in updates-testing today will be in updates tomorrow without
changing...

josh



From pemboa at gmail.com  Wed Dec 10 19:17:34 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 10 Dec 2008 13:17:34 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <494011AA.5080107@gmail.com>
References: <49393DE3.1080707@redhat.com>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
	<1228868657.15367.138.camel@ignacio.lan>
	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>
	<1228908903.15367.180.camel@ignacio.lan>
	<16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>
	<49400AA3.1040701@gmail.com> <494011AA.5080107@gmail.com>
Message-ID: <16de708d0812101117p566ad1f3q6dd974332b8a56af@mail.gmail.com>

2008/12/10 Toshio Kuratomi <a.badger at gmail.com>:
> Les Mikesell wrote:
>> Arthur Pemberton wrote:
>>>
>>>> Well, most of the active members of the Python SIG have chimed in on
>>>> this, and we're all channeling Frankie.
>>>>
>>>> Now, I do believe this is an important subject and we do need to gauge
>>>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>>>> unequipped to do so at this time. I'd like to revisit this topic in
>>>> about a year (perhaps sooner, depending on circumstances), but for now
>>>> everyone just relax.
>>>
>>>
>>> Just to  be clear, does that mean no Python 3.0 in parallel either?
>>
>> How do you expect people to modify and test their own code without a
>> parallel install?
>>
> As stated multiple times, the initial port will be to python-2.6+ with
> python-3 features turned on.  Then we'll see where we're at.
>
> It's possible that the remaining porting work will be small at that
> point and we can migrate easily.  It's also possible that it's still a
> major undertaking to go from py-2.6 w/ python-3 features to py3.  But we
> won't know until code starts being ported so there's no use trying to
> guess what we need to do now.
>
> -Toshio

I think he meant "unofficial" work, as in not official porting of
packages. Just regular dev work.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From iarnell at gmail.com  Wed Dec 10 19:17:54 2008
From: iarnell at gmail.com (Iain Arnell)
Date: Wed, 10 Dec 2008 20:17:54 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927014.3863.38.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>

2008/12/10 Jesse Keating <jkeating at redhat.com>:
> Treat rawhide as your 'new code' land, leave the release trees as your
> 'testing and working' code.  That is don't be so goddamn eager to push
> new packages and new upstream releases to every freaking branch in
> existence.
>
> Of course, when I make suggestions like these, I become extremely
> unpopular.
>

doubleplusgood

As a recently sponsored contributor, I would suggest changing the
documented procedures.  I was more than happy to shove new packages
into rawhide only, but when confronted with
http://fedoraproject.org/wiki/PackageMaintainers/Join and
http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
felt obliged to request branches for F-9 and F-10 too (and pressure
during review to support EPEL too only adds to the problem).

Requests for new packages should only be permitted in rawhide by
default (and consequently, EPEL+1 whenever and whatever that may be).
Some form of additional review/sponsorship/bribery should be a
prerequisite for branches in already-released version.

-- 
Iain.



From skvidal at fedoraproject.org  Wed Dec 10 19:21:56 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 10 Dec 2008 14:21:56 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <20081210191631.GB1769@yoda.jdub.homelinux.org>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228931328.10235.56.camel@hughsie-work.lan>
	<alpine.LFD.2.00.0812101351370.20073@localhost.localdomain>
	<20081210191631.GB1769@yoda.jdub.homelinux.org>
Message-ID: <alpine.LFD.2.00.0812101420510.20073@localhost.localdomain>



On Wed, 10 Dec 2008, Josh Boyer wrote:

>> I think the idea is good. I don't think it helps us to store more
>> information in PK, though.
>
> Agreed.
>
>> If we're going to be storing where a package is installed from. It should
>> probably be in rpm.
>
> We can't easily do that though, can we?  Given that the same binary RPMs
> that are in updates-testing today will be in updates tomorrow without
> changing...

which is, of course, the problem.

-sv



From a.badger at gmail.com  Wed Dec 10 19:29:23 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 10 Dec 2008 11:29:23 -0800
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812101117p566ad1f3q6dd974332b8a56af@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>	<493EA2D8.90200@gmail.com>	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>	<1228868657.15367.138.camel@ignacio.lan>	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>	<1228908903.15367.180.camel@ignacio.lan>	<16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>	<49400AA3.1040701@gmail.com>
	<494011AA.5080107@gmail.com>
	<16de708d0812101117p566ad1f3q6dd974332b8a56af@mail.gmail.com>
Message-ID: <49401893.6040306@gmail.com>

Arthur Pemberton wrote:
> 2008/12/10 Toshio Kuratomi <a.badger at gmail.com>:
>> Les Mikesell wrote:
>>> Arthur Pemberton wrote:
>>>>> Well, most of the active members of the Python SIG have chimed in on
>>>>> this, and we're all channeling Frankie.
>>>>>
>>>>> Now, I do believe this is an important subject and we do need to gauge
>>>>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>>>>> unequipped to do so at this time. I'd like to revisit this topic in
>>>>> about a year (perhaps sooner, depending on circumstances), but for now
>>>>> everyone just relax.
>>>>
>>>> Just to  be clear, does that mean no Python 3.0 in parallel either?
>>> How do you expect people to modify and test their own code without a
>>> parallel install?
>>>
>> As stated multiple times, the initial port will be to python-2.6+ with
>> python-3 features turned on.  Then we'll see where we're at.
>>
>> It's possible that the remaining porting work will be small at that
>> point and we can migrate easily.  It's also possible that it's still a
>> major undertaking to go from py-2.6 w/ python-3 features to py3.  But we
>> won't know until code starts being ported so there's no use trying to
>> guess what we need to do now.
>>
>> -Toshio
> 
> I think he meant "unofficial" work, as in not official porting of
> packages. Just regular dev work.
> 
Pretty much the same answer.  Port to python-2.6 with python-3 features
turned on.  We don't, at this point, have enough information to tell if
that's sufficient or not.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/c3c3412c/attachment.sig>

From lesmikesell at gmail.com  Wed Dec 10 19:36:52 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 13:36:52 -0600
Subject: The looming Python 3(000) monster
In-Reply-To: <16de708d0812101117p566ad1f3q6dd974332b8a56af@mail.gmail.com>
References: <49393DE3.1080707@redhat.com>	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>	<493EA2D8.90200@gmail.com>	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>	<1228868657.15367.138.camel@ignacio.lan>	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>	<1228908903.15367.180.camel@ignacio.lan>	<16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>	<49400AA3.1040701@gmail.com>
	<494011AA.5080107@gmail.com>
	<16de708d0812101117p566ad1f3q6dd974332b8a56af@mail.gmail.com>
Message-ID: <49401A54.7080709@gmail.com>

Arthur Pemberton wrote:
>
>>>>> Well, most of the active members of the Python SIG have chimed in on
>>>>> this, and we're all channeling Frankie.
>>>>>
>>>>> Now, I do believe this is an important subject and we do need to gauge
>>>>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>>>>> unequipped to do so at this time. I'd like to revisit this topic in
>>>>> about a year (perhaps sooner, depending on circumstances), but for now
>>>>> everyone just relax.
>>>>
>>>> Just to  be clear, does that mean no Python 3.0 in parallel either?
>>> How do you expect people to modify and test their own code without a
>>> parallel install?
>>>
>> As stated multiple times, the initial port will be to python-2.6+ with
>> python-3 features turned on.  Then we'll see where we're at.
>>
>> It's possible that the remaining porting work will be small at that
>> point and we can migrate easily.  It's also possible that it's still a
>> major undertaking to go from py-2.6 w/ python-3 features to py3.  But we
>> won't know until code starts being ported so there's no use trying to
>> guess what we need to do now.
>>
> 
> I think he meant "unofficial" work, as in not official porting of
> packages. Just regular dev work.

Yes, I meant end users who have written their own code trusting that the 
interpreter you ship will continue to run it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From ivazqueznet at gmail.com  Wed Dec 10 19:40:02 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 10 Dec 2008 14:40:02 -0500
Subject: The looming Python 3(000) monster
In-Reply-To: <4940114B.3000208@leemhuis.info>
References: <49393DE3.1080707@redhat.com> <493D68D8.2000308@gmail.com>
	<1228762046.3545.2.camel@localhost.localdomain>
	<1228774767.25085.141.camel@localhost.localdomain>
	<16de708d0812081436k60faec18h25bdd62ff9aa3a0d@mail.gmail.com>
	<493EA2D8.90200@gmail.com>
	<16de708d0812091105n40f49c63y95e255a28efc32fc@mail.gmail.com>
	<1228868657.15367.138.camel@ignacio.lan>
	<16de708d0812091840x3a2f6b96s66f44b8be36d2274@mail.gmail.com>
	<1228908903.15367.180.camel@ignacio.lan>
	<16de708d0812100955y16fd7db4p42cb9eb4547813e7@mail.gmail.com>
	<1228932866.30148.15.camel@ignacio.lan>
	<4940114B.3000208@leemhuis.info>
Message-ID: <1228938002.30148.29.camel@ignacio.lan>

On Wed, 2008-12-10 at 19:58 +0100, Thorsten Leemhuis wrote:
> On 10.12.2008 19:14, Ignacio Vazquez-Abrams wrote:
> > Watch my blog if you
> > want a parallel-installable package for 3.x. I plan to update my SRPM to
> > final once the 2.6 work in Fedora is done.
> 
> Do you plan to submit it to RPM Fusion?

I... had not planned to, but I can if there's sufficient interest. I
have no interest in maintaining duplicates of all the modules however. I
will help with packaging though. *Help with*, not do.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/60fd5a10/attachment.sig>

From lesmikesell at gmail.com  Wed Dec 10 19:44:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 13:44:23 -0600
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812101420510.20073@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>	<1228931328.10235.56.camel@hughsie-work.lan>	<alpine.LFD.2.00.0812101351370.20073@localhost.localdomain>	<20081210191631.GB1769@yoda.jdub.homelinux.org>
	<alpine.LFD.2.00.0812101420510.20073@localhost.localdomain>
Message-ID: <49401C17.9060905@gmail.com>

Seth Vidal wrote:
> 
> 
>>> I think the idea is good. I don't think it helps us to store more
>>> information in PK, though.
>>
>> Agreed.
>>
>>> If we're going to be storing where a package is installed from. It 
>>> should
>>> probably be in rpm.
>>
>> We can't easily do that though, can we?  Given that the same binary RPMs
>> that are in updates-testing today will be in updates tomorrow without
>> changing...
> 
> which is, of course, the problem.

So what is the solution in terms of possibilities for yum?  Personally, 
I'd like to see a sane way to manage repeatable updates at any level to 
at least give an end user a chance to test on a spare machine or VM 
exactly what will be propagated in an update to a more critical box. But 
  even that might not be the right solution where an emergency fix needs 
to get pushed immediately.

There has to be some clever way to let the repos change at their own 
speed but give the end user control over what updates are installed on 
any particular machine by adjusting some sort of 'risk' factor.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From nathanael at gnat.ca  Wed Dec 10 19:45:03 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Wed, 10 Dec 2008 12:45:03 -0700
Subject: Making updates-testing more useful
In-Reply-To: <1228934415.3395.2.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228934415.3395.2.camel@localhost.localdomain>
Message-ID: <49401C3F.2050804@gnat.ca>

Without being able to know how to solve this problem, let me say as a 
enduser with only a small handful of bugs posted. I would more than 
likely setup all the machines I administer (~10) to do this if there 
seemed to be a quick and easy way to report breakage - and revert it.

I also know a handful of other linux users who have wondered how they 
could give back, without getting so immersed in stuff they don't 
understand... I told them about karma in bodhi or koji not knowing 
exactly where it was, and stated basically: 'I mean you may not know 
everything and may not be spending days and days helping, but every 
little bit you can give back makes a difference' This would definitely 
be an area where I could see more help coming from 'average' users.

-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From jkeating at redhat.com  Wed Dec 10 19:48:02 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 11:48:02 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <49400A28.9080508@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
Message-ID: <1228938482.3863.45.camel@localhost.localdomain>

On Wed, 2008-12-10 at 12:27 -0600, Les Mikesell wrote:
> That might work if very large numbers of users used updates-testing.  Is 
> that the case?  Without a large well-equipped (and paid?) QA team, and 
> maybe even with, there are always going to be at least two types of 
> problems that sneak by.  One is human error in deciding what to release 
> and another is the kind of bug that only affects certain hardware or 
> configurations that weren't tested.
> 
> Do you keep statistics on how many things fail to move from 
> updates-testing to updates?   Maybe batching the moves would be enough 
> to get the safety net effect.  What if updates-testing moved to updates 
> once a month with a requirement that packages had spent at least 2 weeks 
> in updates-testing or had been through a more stringent review to 
> enforce extra safety checks on anything that had to be pushed (time 
> values could be seasoned to taste), and an even more stringent policy 
> would control emergency fixes directly to updates.   That way the people 
> who want bleeding-edge would have to pull from updates-testing to get 
> them (and the longer the cycle the more you would encourage this) and 
> for machines where you have to avoid risks you could just not do updates 
>    near the scheduled times for the moves, allowing a chance for 
> emergency fixes to be pushed if needed.

If you're putting your potentially destabilizing feature adding version
change into updates-testing, I've already lost my plea.  Once in
-testing, it's presumed that it, or something even newer, will be
promoted to -updates, which ruins the whole thing.  

Seriously, if we could actually just focus on bugfixing for our released
trees, do the new package work in rawhide (and bugfixing of the new
packages there), our released trees might actually stabilize outside of
the heavy handed forced freezes during development.

It really really kills my motivation to make a release nice when a week
after the release happens the giant piles of updates makes the whole
thing more unstable than the pre-alpha.  Releases just become speedbumps
in the rawhide everywhere release mentality that seems pervasive in our
packagers.  I just get in the way of them doing whatever the hell they
wan to do, and things like structured updates tools are just busy work
and should be thrown out.

Maybe I'm a bit cynical here.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/1a05f806/attachment.sig>

From jkeating at redhat.com  Wed Dec 10 19:48:52 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 11:48:52 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
Message-ID: <1228938532.3863.46.camel@localhost.localdomain>

On Wed, 2008-12-10 at 20:17 +0100, Iain Arnell wrote:
> 2008/12/10 Jesse Keating <jkeating at redhat.com>:
> > Treat rawhide as your 'new code' land, leave the release trees as your
> > 'testing and working' code.  That is don't be so goddamn eager to push
> > new packages and new upstream releases to every freaking branch in
> > existence.
> >
> > Of course, when I make suggestions like these, I become extremely
> > unpopular.
> >
> 
> doubleplusgood
> 
> As a recently sponsored contributor, I would suggest changing the
> documented procedures.  I was more than happy to shove new packages
> into rawhide only, but when confronted with
> http://fedoraproject.org/wiki/PackageMaintainers/Join and
> http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
> felt obliged to request branches for F-9 and F-10 too (and pressure
> during review to support EPEL too only adds to the problem).
> 
> Requests for new packages should only be permitted in rawhide by
> default (and consequently, EPEL+1 whenever and whatever that may be).
> Some form of additional review/sponsorship/bribery should be a
> prerequisite for branches in already-released version.
> 
> -- 
> Iain.

Interesting idea!  Would you be willing to bring this topic to the next
FESCo meeting?  FESCo is the body responsible for such decisions.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/15fa8c86/attachment.sig>

From obi at unixkiste.org  Wed Dec 10 19:50:55 2008
From: obi at unixkiste.org (Stefan Held)
Date: Wed, 10 Dec 2008 20:50:55 +0100
Subject: Making updates-testing more useful
In-Reply-To: <49401066.2030403@gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<49401066.2030403@gmail.com>
Message-ID: <1228938655.10361.6.camel@localhost.localdomain>

Am Mittwoch, den 10.12.2008, 12:54 -0600 schrieb Les Mikesell:

> Could there be a way to throw everything in the same repo and give
> the 
> user/installer a choice of how 'well-tested' something should be
> before 
> installing it?  Preferably with a sliding scale instead of just 2 
> choices.  Normally on new installs and machines used explicitly for 
> testing I'd expect people to want the latest changes but become more 
> conservative on machines that are working well and used for important 
> work.  The 'well-tested' concept might have factors for age,
> feedback, 
> emergency overrides, etc.
> 
> -- 
>    Les Mikesell
>      lesmikesell at gmail.com

+1 

-- 

Stefan Held                    VI has only 2 Modes:
obi unixkiste org              The first one is for beeping all the time,
FreeNode: foo_bar              the second destroys the text.
---------------------------------------------------------------------------
Fedora Ambassador:              http://fedoraproject.org/wiki/StefanHeld
---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------




From jspaleta at gmail.com  Wed Dec 10 19:53:58 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 10 Dec 2008 10:53:58 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228938532.3863.46.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
Message-ID: <604aa7910812101153o114b2905i7303b2a7a4b05cfc@mail.gmail.com>

2008/12/10 Jesse Keating <jkeating at redhat.com>:
> Interesting idea!  Would you be willing to bring this topic to the next
> FESCo meeting?  FESCo is the body responsible for such decisions.

If that policy change sticks, what is it going to take to get the
KoPeRs feature up and running? Could KoPeRs be a hack event at
FUDCon11?

-jef



From jkeating at redhat.com  Wed Dec 10 19:59:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 11:59:33 -0800
Subject: The developers/maintainers
In-Reply-To: <493F3C12.2050605@gmail.com>
References: <493F3C12.2050605@gmail.com>
Message-ID: <1228939173.3863.48.camel@localhost.localdomain>

On Tue, 2008-12-09 at 22:48 -0500, David wrote:
> 
> IMO you have a fine product and you have nothing, absolutely
> nothing, to apologize for with your product.
> 
> Thank you for Fedora.

Thank you David, it's always nice to hear stories like this.  It's a
good break from the normal day to day arguing with eachother about who
broke the eggs and spilled the milk, and why the milk isn't in a
spillproof container, or why the eggs didn't come with a warning on them
that they might break, or why somebody couldn't just wait for all the
eggs to be mixed before they consume it or... (:

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/a52d1d2c/attachment.sig>

From abu_hurayrah at hidayahonline.org  Wed Dec 10 20:01:16 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Wed, 10 Dec 2008 22:01:16 +0200
Subject: [Ambassadors] Live CD & Localization (was: What Fedora makes
	sucking for me - or why I am NOT Fedora)
In-Reply-To: <1228927277.3863.41.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493E568E.3090404@kanarip.com>
	<1228927277.3863.41.camel@localhost.localdomain>
Message-ID: <1228939276.3572.51.camel@beta>

On Wed, 2008-12-10 at 08:41 -0800, Jesse Keating wrote:
> On Tue, 2008-12-09 at 12:29 +0100, Jeroen van Meeuwen wrote:
> > The Fedora Project however would still 
> > host the torrent tracker so they have control over revocation and/or 
> > modification of the spin/torrent.
> 
> The problem that this still leaves is currently to host the tracker, we
> have to host the bits, and when you start multiplying each spin by 3 or
> 5 for languages, that space adds up /really/ quickly.  And it's a /ton/
> of duplicate data.  The project just doesn't have the resources to host
> that many spins per release.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse, Jeroen was saying specifically that seeding would be the
responsibility of the maintainers of the spin & NOT the projects - only
the torrent would be needed for the tracker to host the spin, then.  He
was saying that FP still could revoke the spin by not tracking the
torrent, which would pull it out of official circulation.

Unless you meant something else, your concerns were addressed already...



From jkeating at redhat.com  Wed Dec 10 20:03:48 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 12:03:48 -0800
Subject: Making updates-testing more useful
In-Reply-To: <1228930549.3648.14.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
Message-ID: <1228939428.3863.50.camel@localhost.localdomain>

On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> What do you think ?

I could have sworn the bodhi userland client had a report-testable like
function that would tell you all the things on your system that came
from updates-testing.  Probably just simply uses a comparison of what's
in your rpmdb vs what's available from updates-testing (maybe even
looking at gpg key?).  Luke?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/a0a1f896/attachment.sig>

From obi at unixkiste.org  Wed Dec 10 20:04:21 2008
From: obi at unixkiste.org (Stefan Held)
Date: Wed, 10 Dec 2008 21:04:21 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228930226.30987.107.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org>
Message-ID: <1228939461.10361.8.camel@localhost.localdomain>

Am Mittwoch, den 10.12.2008, 12:30 -0500 schrieb James Antill:
> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
> > James Antill wrote:
> > >>  but it is the most 
> > >> obvious and adding a simple mechanism to yum to report the latest update 
> > >> timestamp or some repo transaction id(s) that could be fed to another 
> > >> instance to ensure it ignored subsequent changes to the repo(s) to 
> > >> perform an update to the same packages would be useful in its own right 
> > >> and appreciated when inherited by the enterprise versions.
> > > 

What about an Dialog: 

Dude, you try to run updates-testing, should we make a new lvm-snapshot
for /?

If then later something breaks one could easily reboot into a former
snapshot

</dream mode off>


-- 

Stefan Held                    VI has only 2 Modes:
obi unixkiste org              The first one is for beeping all the time,
FreeNode: foo_bar              the second destroys the text.
---------------------------------------------------------------------------
Fedora Ambassador:              http://fedoraproject.org/wiki/StefanHeld
---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------




From jkeating at redhat.com  Wed Dec 10 20:08:02 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 12:08:02 -0800
Subject: Making updates-testing more useful
In-Reply-To: <49401066.2030403@gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<49401066.2030403@gmail.com>
Message-ID: <1228939682.3863.54.camel@localhost.localdomain>

On Wed, 2008-12-10 at 12:54 -0600, Les Mikesell wrote:
> 
> Could there be a way to throw everything in the same repo and give the 
> user/installer a choice of how 'well-tested' something should be before 
> installing it?  Preferably with a sliding scale instead of just 2 
> choices.  Normally on new installs and machines used explicitly for 
> testing I'd expect people to want the latest changes but become more 
> conservative on machines that are working well and used for important 
> work.  The 'well-tested' concept might have factors for age, feedback, 
> emergency overrides, etc.

Take your sliding scale and multiply the various configurations that
have to be generated/tested by each stop on the scale.

Lets say for instance that we want to do a new xulrunner, very raw.
Every xulrunner dependent app will have to be built for that version and
included.  Then what if we want to do a new yelp that is pretty well
tested, but not perfect.  Now we have to build one for the well tested
scale stop, and keep the other one (what nvrs to use now?!) at the
untested slot.  Oh for fun, lets throw in something else that yelp
depends on, but is not in the xulrunner set, that is very well tested
and stable.  Now you've got a yelp for the very well tested stop, a yelp
for the medium stop, a yelp with tons of other stuff at the raw stop for
xulrunner.  What NVRs to apply to these, how many different ways can we
assemble packages to test for cohesive deps and upgrade paths, and how
to create a updates system that takes all this into consideration when
poor fred just wants to update his package?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/aded2344/attachment.sig>

From kevin at scrye.com  Wed Dec 10 20:21:40 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 10 Dec 2008 13:21:40 -0700
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
	<f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
Message-ID: <20081210132140.25e402bc@ohm.scrye.com>

On Fri, 5 Dec 2008 09:07:58 -0600 (CST)
limb at jcomserv.net ("Jon Ciesla") wrote:

> 
> >
> >> On Wed, Dec 03, 2008 at 03:27:48PM -0600, Jon Ciesla wrote:
> >>>
> >>> >> I suggest starting the NRM process:
> >>> >> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
> >>> >>
> >>> >
> >>> > It has already started. Bugs have been filed. Attempts to
> >>> > contact
> >>> have
> >>> > been made. It's been months with zero contact.
> >>> >
> >>> > I guess the next step is to ask: who can take up these packages?
> >>> >
> >>> I could take a crack at gallery2.
> >>
> >> Are you able to maintain an EPEL version as well?  At least for
> >> EL-5.
> >
> > Yes, I already do for Drupal and a few other PHP apps.
> 
> I think I've got an updated version of gallery2 ready.  When will the
> NRM process complete and the packages orphaned? It's somewhat
> academic as I'm a provenpackager, I just don't want to step on any
> toes.

I would say go ahead and push the updates now...Can you please do so? 

We can sort out the primary maintainer later?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/56bf7ea2/attachment.sig>

From lists at ralii.com  Wed Dec 10 20:23:08 2008
From: lists at ralii.com (Robert Locke)
Date: Wed, 10 Dec 2008 15:23:08 -0500
Subject: Making updates-testing more useful
In-Reply-To: <1228939428.3863.50.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228939428.3863.50.camel@localhost.localdomain>
Message-ID: <1228940588.3460.3.camel@localhost.localdomain>

On Wed, 2008-12-10 at 12:03 -0800, Jesse Keating wrote:
> On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> > What do you think ?
> 
> I could have sworn the bodhi userland client had a report-testable like
> function that would tell you all the things on your system that came
> from updates-testing.  Probably just simply uses a comparison of what's
> in your rpmdb vs what's available from updates-testing (maybe even
> looking at gpg key?).  Luke?

We should also probably stop "asking" a user for feedback for a package
which has already moved from updates-testing to updates (in the
intervening days) and that comparison (if not already written) would
help to "drop" the "asking"....

--Rob



From kevin at scrye.com  Wed Dec 10 20:25:23 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 10 Dec 2008 13:25:23 -0700
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <loom.20081205T173743-221@post.gmane.org>
References: <loom.20081203T184910-257@post.gmane.org>
	<loom.20081205T173743-221@post.gmane.org>
Message-ID: <20081210132523.1bc29454@ohm.scrye.com>

On Fri, 5 Dec 2008 17:42:16 +0000 (UTC)
cry_regarder at yahoo.com (Cry) wrote:

> Cry <cry_regarder <at> yahoo.com> writes:
> 
> > 
> > gallery2 has two new versions and outstanding security bugs.  I
> > have tried several times to email the maintainer John Berninger
> > with no replies to a few different addresses.  Is this software
> > dead in fedora? 
> 
> Just for form's sake in case it is necessary and can't be
> accelerated, The non-responsive maintainer process was initiated at
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=474870

Sounds good.

> Since fedora security loaded several of these bugs and they have CVE
> numbers assigned, why didn't they followup when the maintainer didn't
> respond?  Will the slow fix time for these bugs reflect negatively on
> fedora's stats?

Because the fedora security folks are focused on notifying maintainers
and helping them fix things, and making sure security updates are
correct. There isn't any policy in place to have them make the changes,
although if we can get enough people interested in helping that would
be a good thing to try and do. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/d2f2442b/attachment.sig>

From limb at jcomserv.net  Wed Dec 10 20:25:57 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 10 Dec 2008 14:25:57 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <20081210132140.25e402bc@ohm.scrye.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
	<f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
	<20081210132140.25e402bc@ohm.scrye.com>
Message-ID: <baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>


> On Fri, 5 Dec 2008 09:07:58 -0600 (CST)
> limb at jcomserv.net ("Jon Ciesla") wrote:
>
>>
>> >
>> >> On Wed, Dec 03, 2008 at 03:27:48PM -0600, Jon Ciesla wrote:
>> >>>
>> >>> >> I suggest starting the NRM process:
>> >>> >> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
>> >>> >>
>> >>> >
>> >>> > It has already started. Bugs have been filed. Attempts to
>> >>> > contact
>> >>> have
>> >>> > been made. It's been months with zero contact.
>> >>> >
>> >>> > I guess the next step is to ask: who can take up these packages?
>> >>> >
>> >>> I could take a crack at gallery2.
>> >>
>> >> Are you able to maintain an EPEL version as well?  At least for
>> >> EL-5.
>> >
>> > Yes, I already do for Drupal and a few other PHP apps.
>>
>> I think I've got an updated version of gallery2 ready.  When will the
>> NRM process complete and the packages orphaned? It's somewhat
>> academic as I'm a provenpackager, I just don't want to step on any
>> toes.
>
> I would say go ahead and push the updates now...Can you please do so?
>
> We can sort out the primary maintainer later?

Absolutely.  I'll also dig further into the jpegtran issue and file a bug
if need be.

> kevin
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From kevin at scrye.com  Wed Dec 10 20:28:46 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 10 Dec 2008 13:28:46 -0700
Subject: Can anyone contact missing John Beringer? (was: gallery2
 outstanding security bugs...)
In-Reply-To: <loom.20081205T183307-581@post.gmane.org>
References: <loom.20081203T184910-257@post.gmane.org>
	<loom.20081205T173743-221@post.gmane.org>
	<49396B37.7090806@cchtml.com>
	<af0bc9bbf7de5b21d71bb226fe64d20d.squirrel@mail.jcomserv.net>
	<loom.20081205T183307-581@post.gmane.org>
Message-ID: <20081210132846.063b1776@ohm.scrye.com>

On Fri, 5 Dec 2008 18:38:44 +0000 (UTC)
cry_regarder at yahoo.com (Cry) wrote:

> Jon Ciesla <limb <at> jcomserv.net> writes:
> >> From: Cry <cry_regarder <at> yahoo.com>
> >>> The non-responsive maintainer process was initiated at
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=474870
> > 
> > Indeed, it'd be good to link to all his packages.  Someone(s) will
> > need to take the others.
> 
> The other packages were added to the text of the above bug.  I don't
> know how to make a single bug cover additional packages though.
> 
> Packages:  gallery2, wordpress, bugzilla, squidguard, ratpoison
> 
> Since there are so many bugs with CVEs assigned to this person, can
> we shortcut the process a little and move to stage three "After 2
> attempts (2 weeks)..." mode at:
> 
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

I don't think there is any need to do that... lets follow the
procedure. 

However, if any of those packages are closed, I would be happy to open
them up to someone who can do the needed updates now. No harm in taking
care of the security issues, IMHO. Then, if John is still away, we can
reassign ownership per the procedure. 

> ?  Does anyone out there know how to reach John?  I've tried emailing
> him at his redhat and ncphotography addresses and searching on the
> web.

Sadly, I do not. ;( 

I hope he's ok. 

> Cry

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/c6c2cbc7/attachment.sig>

From lesmikesell at gmail.com  Wed Dec 10 20:29:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 14:29:50 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228939461.10361.8.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228930226.30987.107.camel@code.and.org>
	<1228939461.10361.8.camel@localhost.localdomain>
Message-ID: <494026BE.6060804@gmail.com>

Stefan Held wrote:
> 
>>>>>  but it is the most 
>>>>> obvious and adding a simple mechanism to yum to report the latest update 
>>>>> timestamp or some repo transaction id(s) that could be fed to another 
>>>>> instance to ensure it ignored subsequent changes to the repo(s) to 
>>>>> perform an update to the same packages would be useful in its own right 
>>>>> and appreciated when inherited by the enterprise versions.
> 
> What about an Dialog: 
> 
> Dude, you try to run updates-testing, should we make a new lvm-snapshot
> for /?
> 
> If then later something breaks one could easily reboot into a former
> snapshot
> 
> </dream mode off>

I'm not sure how practical that would be unless you could still mount 
and access the updated version after reverting.  Suppose you've done 
several days work before you trip over the showstopper bug that makes 
you want to revert.  Or the update makes format changes that aren't 
backwards compatible in files on other partitions?

I'd go for an option to install a spare matching partition for the 
system and have updates always rsync the previous to it before changing 
anything (both partitions always mounted, no lvm magic) but even that 
doesn't cover everything that can go wrong.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Wed Dec 10 20:33:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 12:33:32 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081210095550.4576b8c9@ohm.scrye.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<ghn23k$50a$1@ger.gmane.org>  <20081210095550.4576b8c9@ohm.scrye.com>
Message-ID: <1228941212.3863.55.camel@localhost.localdomain>

On Wed, 2008-12-10 at 09:55 -0700, Kevin Fenzi wrote:
> There has been some talk of removing this step, but I think it's
> usefull for the above reasons. I have seen security updates come in
> with no bug attached, no CVE, and text of 'security update'. This is
> not usefull to our users, IMHO. I might be in a minority here tho, so
> perhaps the step should be removed. 

I'd rather see it remain.  Especially if it's catching actual issues.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/3766fab4/attachment.sig>

From jkeating at redhat.com  Wed Dec 10 20:34:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 12:34:54 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812101153o114b2905i7303b2a7a4b05cfc@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<604aa7910812101153o114b2905i7303b2a7a4b05cfc@mail.gmail.com>
Message-ID: <1228941294.3863.56.camel@localhost.localdomain>

On Wed, 2008-12-10 at 10:53 -0900, Jeff Spaleta wrote:
> If that policy change sticks, what is it going to take to get the
> KoPeRs feature up and running? 

code

> Could KoPeRs be a hack event at
> FUDCon11?

Maybe?  I highly doubt I'll have any time/energy to put into kopers
during the f11 cycle.  There is far more useful work to be done in the
automated QA realm.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/ad8359a1/attachment.sig>

From obi at unixkiste.org  Wed Dec 10 20:36:30 2008
From: obi at unixkiste.org (Stefan Held)
Date: Wed, 10 Dec 2008 21:36:30 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <494026BE.6060804@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org>
	<1228939461.10361.8.camel@localhost.localdomain>
	<494026BE.6060804@gmail.com>
Message-ID: <1228941390.10361.25.camel@localhost.localdomain>

Am Mittwoch, den 10.12.2008, 14:29 -0600 schrieb Les Mikesell:

> I'm not sure how practical that would be unless you could still mount 
> and access the updated version after reverting.  Suppose you've done 
> several days work before you trip over the showstopper bug that makes 
> you want to revert.  Or the update makes format changes that aren't 
> backwards compatible in files on other partitions?

This is more than practical :)

To be honest, the solaris guys are doing this recently. Take a snapshot,
apply the updates. If something is wrong you can move backwards and
forwards in the snapshots for the root partition.

> I'd go for an option to install a spare matching partition for the 
> system and have updates always rsync the previous to it before changing 
> anything (both partitions always mounted, no lvm magic) but even that 
> doesn't cover everything that can go wrong.

This solution would be best with splitting /home into a own lvm
partition. I never heard of a system update breaking something serios
in /home :)

Your solution would use to much space in my opinion. 

-- 

Stefan Held                    VI has only 2 Modes:
obi unixkiste org              The first one is for beeping all the time,
FreeNode: foo_bar              the second destroys the text.
---------------------------------------------------------------------------
Fedora Ambassador:              http://fedoraproject.org/wiki/StefanHeld
---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------



From jkeating at redhat.com  Wed Dec 10 20:37:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 12:37:53 -0800
Subject: [Ambassadors] Live CD & Localization (was: What Fedora makes
 sucking for me - or why I am NOT Fedora)
In-Reply-To: <1228939276.3572.51.camel@beta>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493E568E.3090404@kanarip.com>
	<1228927277.3863.41.camel@localhost.localdomain>
	<1228939276.3572.51.camel@beta>
Message-ID: <1228941473.3863.59.camel@localhost.localdomain>

On Wed, 2008-12-10 at 22:01 +0200, Basil Mohamed Gohar wrote:
> Jesse, Jeroen was saying specifically that seeding would be the
> responsibility of the maintainers of the spin & NOT the projects - only
> the torrent would be needed for the tracker to host the spin, then.  He
> was saying that FP still could revoke the spin by not tracking the
> torrent, which would pull it out of official circulation.
> 
> Unless you meant something else, your concerns were addressed already...

As of yet, nobody has completed the ticket that would allow the fedora
torrent tracker to track the .torrent file only, and not have the bits
there as well.

I have other concerns which mostly revolve around timing of the release
of the spins, that the final moments before a compose becomes "gold" for
a given release we're often creating scratch repos of last minute
updates that need to be included in the spins.  Making these accessible
to all the various different places that could be making spins, and
keeping them coordinated is going to be a huge hurdle, unless we tell
these spin folks that they have to wait until after GA to make their
spins.

Then we run into the fun of "official" Fedora content being created on
machines outside the control of the Fedora Infrastructure.  Doesn't sit
very warm and fuzzy in my head.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/425fa416/attachment.sig>

From skvidal at fedoraproject.org  Wed Dec 10 20:40:02 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 10 Dec 2008 15:40:02 -0500 (EST)
Subject: [Ambassadors] Live CD & Localization (was: What Fedora makes
 sucking for me - or why I am NOT Fedora)
In-Reply-To: <1228941473.3863.59.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493E568E.3090404@kanarip.com>
	<1228927277.3863.41.camel@localhost.localdomain>
	<1228939276.3572.51.camel@beta>
	<1228941473.3863.59.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0812101539350.20073@localhost.localdomain>



On Wed, 10 Dec 2008, Jesse Keating wrote:

> On Wed, 2008-12-10 at 22:01 +0200, Basil Mohamed Gohar wrote:
>> Jesse, Jeroen was saying specifically that seeding would be the
>> responsibility of the maintainers of the spin & NOT the projects - only
>> the torrent would be needed for the tracker to host the spin, then.  He
>> was saying that FP still could revoke the spin by not tracking the
>> torrent, which would pull it out of official circulation.
>>
>> Unless you meant something else, your concerns were addressed already...
>
> As of yet, nobody has completed the ticket that would allow the fedora
> torrent tracker to track the .torrent file only, and not have the bits
> there as well.


?? The tracker can't track just the .torrent file?

Which ticket is this?

-sv



From jkeating at redhat.com  Wed Dec 10 20:45:58 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 12:45:58 -0800
Subject: [Ambassadors] Live CD & Localization (was: What Fedora makes
 sucking for me - or why I am NOT Fedora)
In-Reply-To: <alpine.LFD.2.00.0812101539350.20073@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493E568E.3090404@kanarip.com>
	<1228927277.3863.41.camel@localhost.localdomain>
	<1228939276.3572.51.camel@beta>
	<1228941473.3863.59.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812101539350.20073@localhost.localdomain>
Message-ID: <1228941958.3863.60.camel@localhost.localdomain>

On Wed, 2008-12-10 at 15:40 -0500, Seth Vidal wrote:
> 
> ?? The tracker can't track just the .torrent file?
> 
> Which ticket is this?

I don't know the details.  It was a ticket somewhere in the Fedora
Infrastructure trac, assigned to dgilmore, about being able to use our
tracker to track torrents hosted elsewhere.  Dennis?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/8fb3b2f2/attachment.sig>

From skvidal at fedoraproject.org  Wed Dec 10 20:50:24 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 10 Dec 2008 15:50:24 -0500 (EST)
Subject: [Ambassadors] Live CD & Localization (was: What Fedora makes
 sucking for me - or why I am NOT Fedora)
In-Reply-To: <1228941958.3863.60.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493E568E.3090404@kanarip.com>
	<1228927277.3863.41.camel@localhost.localdomain>
	<1228939276.3572.51.camel@beta>
	<1228941473.3863.59.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812101539350.20073@localhost.localdomain>
	<1228941958.3863.60.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0812101548560.20073@localhost.localdomain>



On Wed, 10 Dec 2008, Jesse Keating wrote:

> On Wed, 2008-12-10 at 15:40 -0500, Seth Vidal wrote:
>>
>> ?? The tracker can't track just the .torrent file?
>>
>> Which ticket is this?
>
> I don't know the details.  It was a ticket somewhere in the Fedora
> Infrastructure trac, assigned to dgilmore, about being able to use our
> tracker to track torrents hosted elsewhere.  Dennis?
>

Dennis, if you know the right number, ping me about it - I can take it 
over.

-sv



From orion at cora.nwra.com  Wed Dec 10 20:55:34 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 10 Dec 2008 13:55:34 -0700
Subject: Any chance of seeing GCC UPC in Fedora?
Message-ID: <49402CC6.6060006@cora.nwra.com>

Any chance of seeing the GCC UPC compiler in Fedora?  Could it be its 
own package even though it's basically a patch on top of GCC?

-- 
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 limb at jcomserv.net  Wed Dec 10 20:59:42 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 10 Dec 2008 14:59:42 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
	<f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
Message-ID: <5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>


>
>> On Fri, 5 Dec 2008 09:07:58 -0600 (CST)
>> limb at jcomserv.net ("Jon Ciesla") wrote:
>>
>>>
>>> >
>>> >> On Wed, Dec 03, 2008 at 03:27:48PM -0600, Jon Ciesla wrote:
>>> >>>
>>> >>> >> I suggest starting the NRM process:
>>> >>> >> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
>>> >>> >>
>>> >>> >
>>> >>> > It has already started. Bugs have been filed. Attempts to
>>> >>> > contact
>>> >>> have
>>> >>> > been made. It's been months with zero contact.
>>> >>> >
>>> >>> > I guess the next step is to ask: who can take up these packages?
>>> >>> >
>>> >>> I could take a crack at gallery2.
>>> >>
>>> >> Are you able to maintain an EPEL version as well?  At least for
>>> >> EL-5.
>>> >
>>> > Yes, I already do for Drupal and a few other PHP apps.
>>>
>>> I think I've got an updated version of gallery2 ready.  When will the
>>> NRM process complete and the packages orphaned? It's somewhat
>>> academic as I'm a provenpackager, I just don't want to step on any
>>> toes.
>>
>> I would say go ahead and push the updates now...Can you please do so?
>>
>> We can sort out the primary maintainer later?
>
> Absolutely.  I'll also dig further into the jpegtran issue and file a bug
> if need be.

Builds ongoing.

Re jpegtran, there is a bug, against RHEL5:
https://bugzilla.redhat.com/show_bug.cgi?id=475679

CCing Tom.  Tom, would you like me to work on adding this patch into
Fedora's libjpeg?

>> kevin
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
> --
> in your fear, speak only peace
> in your fear, seek only love
>
> -d. bowie
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From lesmikesell at gmail.com  Wed Dec 10 21:03:29 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 15:03:29 -0600
Subject: Making updates-testing more useful
In-Reply-To: <1228939682.3863.54.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>	<1228933404.2682.7.camel@scrappy.miketc.net>	<49401066.2030403@gmail.com>
	<1228939682.3863.54.camel@localhost.localdomain>
Message-ID: <49402EA1.3060203@gmail.com>

Jesse Keating wrote:
> On Wed, 2008-12-10 at 12:54 -0600, Les Mikesell wrote:
>> Could there be a way to throw everything in the same repo and give the 
>> user/installer a choice of how 'well-tested' something should be before 
>> installing it?  Preferably with a sliding scale instead of just 2 
>> choices.  Normally on new installs and machines used explicitly for 
>> testing I'd expect people to want the latest changes but become more 
>> conservative on machines that are working well and used for important 
>> work.  The 'well-tested' concept might have factors for age, feedback, 
>> emergency overrides, etc.
> 
> Take your sliding scale and multiply the various configurations that
> have to be generated/tested by each stop on the scale.

I was hoping this could work independently and unless something is 
replaced with an expedited fix, packages would just age into view.

> Lets say for instance that we want to do a new xulrunner, very raw.
> Every xulrunner dependent app will have to be built for that version and
> included.  Then what if we want to do a new yelp that is pretty well
> tested, but not perfect.  Now we have to build one for the well tested
> scale stop, and keep the other one (what nvrs to use now?!) at the
> untested slot.  Oh for fun, lets throw in something else that yelp
> depends on, but is not in the xulrunner set, that is very well tested
> and stable.  Now you've got a yelp for the very well tested stop, a yelp
> for the medium stop, a yelp with tons of other stuff at the raw stop for
> xulrunner.  What NVRs to apply to these, how many different ways can we
> assemble packages to test for cohesive deps and upgrade paths, and how
> to create a updates system that takes all this into consideration when
> poor fred just wants to update his package?

Perhaps I haven't thought it all the way through, but I'd expect most of 
this to take care of itself via the age factor with the updater ignoring 
anything that doesn't meet the selection criteria on a package or any 
dependencies.  As long as everything works, you'd just be able to get 
the same update the bleeding-edge machines got 2 weeks (or...?) ago. The 
only tricky part would be how to push expedited fixes ahead of the clock 
because they might drag along massive dependencies, but that should only 
be done in rare carefully-consdered cases anyway.  Negative feedback 
could just slow the clock down.

But, feel free to start from scratch on a working design that gives 
control to the end user.  I can't help thinking that a 
version-controlled (git/subversion) package list with tags to give 
snapshots-in-time would be the ultimate way to do it.  That could 
divorce the tool making the 'risk-factor' decisions from yum itself. 
You might build a new set of tags daily, recomputing the package lists 
that should appear in each level of risk and yum would work with the 
list instead of the repo contents.  That would introduce a new workload 
for the mirrors, though.

One other consideration a new package management scheme needs to turn 
this into reproducible updates is to remember the repo where each 
package lives (and understand that you don't know them all ahead of 
time...).


-- 
   Les Mikesell
    lesmikesell at gmail.com



From musuruan at gmail.com  Wed Dec 10 21:03:23 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Wed, 10 Dec 2008 22:03:23 +0100
Subject: GRUB hangs during boot after system update
Message-ID: <29fee02b0812101303s4a0ab734n74613f689bd78245@mail.gmail.com>

Hi all,
    I'd like to point out bug #472829, that, unluckily, just happened to me.

https://bugzilla.redhat.com/show_bug.cgi?id=472829

I think we have a very serious problem - a problem that is impacting
on end users!

Regards,

Andrea.



From iarnell at gmail.com  Wed Dec 10 21:09:48 2008
From: iarnell at gmail.com (Iain Arnell)
Date: Wed, 10 Dec 2008 22:09:48 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228938532.3863.46.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
Message-ID: <81487f820812101309r788efe4fp4d478336f9624b9d@mail.gmail.com>

2008/12/10 Jesse Keating <jkeating at redhat.com>:
> On Wed, 2008-12-10 at 20:17 +0100, Iain Arnell wrote:
>>
>> As a recently sponsored contributor, I would suggest changing the
>> documented procedures.  I was more than happy to shove new packages
>> into rawhide only, but when confronted with
>> http://fedoraproject.org/wiki/PackageMaintainers/Join and
>> http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
>> felt obliged to request branches for F-9 and F-10 too (and pressure
>> during review to support EPEL too only adds to the problem).
>>
>> Requests for new packages should only be permitted in rawhide by
>> default (and consequently, EPEL+1 whenever and whatever that may be).
>> Some form of additional review/sponsorship/bribery should be a
>> prerequisite for branches in already-released version.
>>
> Interesting idea!  Would you be willing to bring this topic to the next
> FESCo meeting?  FESCo is the body responsible for such decisions.
>

Unfortunately, I can't manage the next meeting, but I will make a
point of bringing it up in the new year.
-- 
Iain.



From jkeating at j2solutions.net  Wed Dec 10 21:11:09 2008
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 10 Dec 2008 13:11:09 -0800
Subject: Making updates-testing more useful
In-Reply-To: <49402EA1.3060203@gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>	<49401066.2030403@gmail.com>
	<1228939682.3863.54.camel@localhost.localdomain>
	<49402EA1.3060203@gmail.com>
Message-ID: <1228943469.3863.66.camel@localhost.localdomain>

On Wed, 2008-12-10 at 15:03 -0600, Les Mikesell wrote:
> Perhaps I haven't thought it all the way through, but I'd expect most of 
> this to take care of itself via the age factor with the updater ignoring 
> anything that doesn't meet the selection criteria on a package or any 
> dependencies.  As long as everything works, you'd just be able to get 
> the same update the bleeding-edge machines got 2 weeks (or...?) ago. The 
> only tricky part would be how to push expedited fixes ahead of the clock 
> because they might drag along massive dependencies, but that should only 
> be done in rare carefully-consdered cases anyway.  Negative feedback 
> could just slow the clock down.
> 
> But, feel free to start from scratch on a working design that gives 
> control to the end user.  I can't help thinking that a 
> version-controlled (git/subversion) package list with tags to give 
> snapshots-in-time would be the ultimate way to do it.  That could 
> divorce the tool making the 'risk-factor' decisions from yum itself. 
> You might build a new set of tags daily, recomputing the package lists 
> that should appear in each level of risk and yum would work with the 
> list instead of the repo contents.  That would introduce a new workload 
> for the mirrors, though.
> 
> One other consideration a new package management scheme needs to turn 
> this into reproducible updates is to remember the repo where each 
> package lives (and understand that you don't know them all ahead of 
> time...).
> 

The problem here is that these are descreet commits that one can pull or
cherry pick at will and integrate them into whatever current repo view
you have.  It's far more complicated than that with interdependencies
and upgrade paths to consider.

Please re-read my scenarios and try to come up with any possible way to
make it work.

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/95b11db8/attachment.sig>

From tgl at redhat.com  Wed Dec 10 21:11:23 2008
From: tgl at redhat.com (Tom Lane)
Date: Wed, 10 Dec 2008 16:11:23 -0500
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger? 
In-Reply-To: <5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net> 
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
	<f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
Message-ID: <7892.1228943483@sss.pgh.pa.us>

"Jon Ciesla" <limb at jcomserv.net> writes:
> Re jpegtran, there is a bug, against RHEL5:
> https://bugzilla.redhat.com/show_bug.cgi?id=475679
> CCing Tom.  Tom, would you like me to work on adding this patch into
> Fedora's libjpeg?

Actually, I had every intention of rejecting that bug WONTFIX.
I don't think it's a good idea to get into the business of carrying
nontrivial feature patches that aren't upstream.

(Yes, I know libjpeg upstream is kinda moribund, but if you want new
features in it you should be trying to revive upstream development,
not strongarm the Fedora package maintainer to take over development.)

			regards, tom lane



From lesmikesell at gmail.com  Wed Dec 10 21:16:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Dec 2008 15:16:49 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228941390.10361.25.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228930226.30987.107.camel@code.and.org>	<1228939461.10361.8.camel@localhost.localdomain>	<494026BE.6060804@gmail.com>
	<1228941390.10361.25.camel@localhost.localdomain>
Message-ID: <494031C1.7040503@gmail.com>

Stefan Held wrote:
> Am Mittwoch, den 10.12.2008, 14:29 -0600 schrieb Les Mikesell:
> 
>> I'm not sure how practical that would be unless you could still mount 
>> and access the updated version after reverting.  Suppose you've done 
>> several days work before you trip over the showstopper bug that makes 
>> you want to revert.  Or the update makes format changes that aren't 
>> backwards compatible in files on other partitions?
> 
> This is more than practical :)
> 
> To be honest, the solaris guys are doing this recently. Take a snapshot,
> apply the updates. If something is wrong you can move backwards and
> forwards in the snapshots for the root partition.
> 
>> I'd go for an option to install a spare matching partition for the 
>> system and have updates always rsync the previous to it before changing 
>> anything (both partitions always mounted, no lvm magic) but even that 
>> doesn't cover everything that can go wrong.
> 
> This solution would be best with splitting /home into a own lvm
> partition. I never heard of a system update breaking something serios
> in /home :)

I think that means you've never tried running multiple versions with an 
nfs mounted home.  All sorts of things twiddle their dot-files with 
changes that older copies don't like.  So once you have run the new 
version of a program you may not be able to go back.

> Your solution would use to much space in my opinion. 

Disk space is cheap in most cases - and regardless, an LVM would have to 
have space for the snapshot and it's cheaper than maintaining a separate 
test machine or VM image.  And as an option, anyone who didn't want it 
wouldn't have to.  The main downside I see is that you'd have to decide 
up front how big the system can grow and allocate 2 of them.

I do think it is better to focus on how to avoid breaking important 
machines in the first place - and that necessarily involves breaking 
more unimportant ones, but this could be another safety net.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mw_triad at users.sourceforge.net  Wed Dec 10 21:18:22 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 10 Dec 2008 15:18:22 -0600
Subject: The developers/maintainers
In-Reply-To: <1228939173.3863.48.camel@localhost.localdomain>
References: <493F3C12.2050605@gmail.com>
	<1228939173.3863.48.camel@localhost.localdomain>
Message-ID: <ghpbnj$2r0$1@ger.gmane.org>

Jesse Keating wrote:
> On Tue, 2008-12-09 at 22:48 -0500, David wrote:
>> IMO you have a fine product and you have nothing, absolutely
>> nothing, to apologize for with your product.
>>
>> Thank you for Fedora.
> 
> Thank you David, it's always nice to hear stories like this.  It's a
> good break from the normal day to day arguing with eachother about who
> broke the eggs and spilled the milk, and why the milk isn't in a
> spillproof container, or why the eggs didn't come with a warning on them
> that they might break, or why somebody couldn't just wait for all the
> eggs to be mixed before they consume it or... (:

Indeed. There are points of concern I have (as I'm sure readers know ;-) 
) with Fedora's direction, but gratuitous not-working is not one of 
them. I suppose I shouldn't be surprised that not everything works for 
everyone, but on the whole (except for problems with NVidia) I've had 
very few problems with Fedora. Despite two-and-counting in-place 
upgrades using yum :-D.

I'd also like to offer kudos for Cambridge, especially everyone that's 
responsible in any way for the fact that it *just works* (well, okay, 
except for the infamous suspend) on my Asus 900A. Frankly I'm pretty 
amazed with that, just as I was downright shocked when I stuck my 
LiveUSB in my Mom's laptop, and it not only detected but was able to use 
the CDMA modem with zero configuration (thereby beating my previous 
experience with Kubuntu live that failed to download the firmware it 
thought it needed).

Now, about that 'startup in 10 seconds' goal... ;-)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Who wants to sing?" -- Orcs (Warcraft II)



From konrad at tylerc.org  Wed Dec 10 21:23:59 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 10 Dec 2008 13:23:59 -0800
Subject: Any chance of seeing GCC UPC in Fedora?
In-Reply-To: <49402CC6.6060006@cora.nwra.com>
References: <49402CC6.6060006@cora.nwra.com>
Message-ID: <200812101323.59921.konrad@tylerc.org>

On Wednesday 10 December 2008 12:55:34 pm Orion Poplawski wrote:
> Any chance of seeing the GCC UPC compiler in Fedora?  Could it be its
> own package even though it's basically a patch on top of GCC?
>
> --
> 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

Is there any reason not to provide it as part of GCC given that it simply 
extends the functionality of GCC (adds another language frontend)? Does 
upstream plan to get its patches included in GCC upstream?

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From roland at redhat.com  Wed Dec 10 21:02:52 2008
From: roland at redhat.com (Roland McGrath)
Date: Wed, 10 Dec 2008 13:02:52 -0800 (PST)
Subject: Any chance of seeing GCC UPC in Fedora?
In-Reply-To: Orion Poplawski's message of  Wednesday,
	10 December 2008 13:55:34 -0700 <49402CC6.6060006@cora.nwra.com>
References: <49402CC6.6060006@cora.nwra.com>
Message-ID: <20081210210252.70326FC339@magilla.sf.frob.com>

It's its own package with its own upstream, regardless of that it happens
to include a lot of GCC source code.  Just package it following the
guidelines like any other.  If and when the upstream project merges with
upstream gcc, then it becomes an issue for the Fedora gcc packaging.


Thanks,
Roland



From jakub at redhat.com  Wed Dec 10 21:34:48 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 10 Dec 2008 22:34:48 +0100
Subject: Any chance of seeing GCC UPC in Fedora?
In-Reply-To: <200812101323.59921.konrad@tylerc.org>
References: <49402CC6.6060006@cora.nwra.com>
	<200812101323.59921.konrad@tylerc.org>
Message-ID: <20081210213448.GZ17496@tyan-ft48-01.lab.bos.redhat.com>

On Wed, Dec 10, 2008 at 01:23:59PM -0800, Conrad Meyer wrote:
> On Wednesday 10 December 2008 12:55:34 pm Orion Poplawski wrote:
> > Any chance of seeing the GCC UPC compiler in Fedora?  Could it be its
> > own package even though it's basically a patch on top of GCC?
> 
> Is there any reason not to provide it as part of GCC given that it simply 
> extends the functionality of GCC (adds another language frontend)? Does 

Yes, very important reason.  From what I see, it has been ported to GCC
4.2.x and 3.4.x, that's not sufficient for Fedora, where we'll soon be
switching to GCC 4.4.x.

> upstream plan to get its patches included in GCC upstream?

Unless they actually get them incorporated into upstream GCC, they won't
be in Fedora primary gcc packages.

	Jakub



From Matt_Domsch at dell.com  Wed Dec 10 21:35:46 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 10 Dec 2008 15:35:46 -0600
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <20081210143309.GB18314@nostromo.devel.redhat.com>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
Message-ID: <20081210213546.GD12080@auslistsprd01.us.dell.com>

On Wed, Dec 10, 2008 at 09:33:09AM -0500, Bill Nottingham wrote:
> Thomas Moschny (thomas.moschny at gmail.com) said: 
> > > https://bugzilla.redhat.com/userprefs.cgi?tab=email
> > >
> > > See 'user watching'.
> > >
> > > People can set up bugstalking filters to get e-mailed any time someone
> > > else would be e-mailed.
> > 
> > So, whom is he watching?
> 
> Myself, at least (which will cover most all the review tickets). You can see
> who's watching you on the same bugzilla pref page.

Now there's a masochist if ever I saw one.  Not only keeping up with
his own mail stream, but desiring to keep up with Bill's too!

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From tibbs at math.uh.edu  Wed Dec 10 21:40:07 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 10 Dec 2008 15:40:07 -0600
Subject: Any chance of seeing GCC UPC in Fedora?
In-Reply-To: <200812101323.59921.konrad@tylerc.org>
References: <49402CC6.6060006@cora.nwra.com>
	<200812101323.59921.konrad@tylerc.org>
Message-ID: <ufahc5bogjs.fsf@epithumia.math.uh.edu>

>>>>> "CM" == Conrad Meyer <konrad at tylerc.org> writes:

CM> Is there any reason not to provide it as part of GCC given that it
CM> simply extends the functionality of GCC (adds another language
CM> frontend)?

I imagine this won't happen for the same reason that GPC won't be
included as part of the Fedora GCC packages: it's a separate project,
with its own release schedule.  Until the sources actually get into
the main GCC tree, it would be quite difficult to keep them together.
That will almost certainly never happen with GPC; I don't know if UPC
would have better luck.

That said, I did a lot of work to get GPC to build and work in the
face of a changing GCC version that it may occasionally coincide with
(and thus needs to not conflict with).  I guess one day I need to get
back to it.

 - J<



From rc040203 at freenet.de  Wed Dec 10 21:46:49 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Dec 2008 22:46:49 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228927014.3863.38.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <1228945609.3394.10.camel@beck.corsepiu.local>

On Wed, 2008-12-10 at 08:36 -0800, Jesse Keating wrote:
> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
> > One way or another, if I were building a distribution that wanted to 
> > simultaneously claim that it is both new code and 'tested and working', 
> > I'd try to plan in a way that it wasn't a flip of the coin on every 
> > machine which you'll get today.
> 
> Now here's a crazy idea, that nobody seems to want to follow:
> 
> Treat rawhide as your 'new code' land, leave the release trees as your
> 'testing and working' code. 

... then wait until your immature and hardly tested "new code" from
"rawhide" automatically becomes the "release".

FC10 clearly demonstrates this effect.

Ralf





From rc040203 at freenet.de  Wed Dec 10 21:52:10 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Dec 2008 22:52:10 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228938532.3863.46.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
Message-ID: <1228945930.3394.15.camel@beck.corsepiu.local>

On Wed, 2008-12-10 at 11:48 -0800, Jesse Keating wrote:
> On Wed, 2008-12-10 at 20:17 +0100, Iain Arnell wrote:
> > 2008/12/10 Jesse Keating <jkeating at redhat.com>:

> > Requests for new packages should only be permitted in rawhide by
> > default (and consequently, EPEL+1 whenever and whatever that may be).
> > Some form of additional review/sponsorship/bribery should be a
> > prerequisite for branches in already-released version.

> Interesting idea!
IMO, a highly counterproductive idea:
* Most new packages don't cause malfunctionals to existing packages.

* Not letting new packages in released versions of Fedora
- reduces a package's exposure to users and thereby reduces
  possibilities to test a package and opportunities to find bugs.
- Renders Fedora less interesting to prospective contributors.

Ralf





From nicolas.mailhot at laposte.net  Wed Dec 10 22:20:40 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 10 Dec 2008 23:20:40 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228945609.3394.10.camel@beck.corsepiu.local>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
Message-ID: <1228947640.31448.39.camel@arekh.okg>

Le mercredi 10 d?cembre 2008 ? 22:46 +0100, Ralf Corsepius a ?crit :

> ... then wait until your immature and hardly tested "new code" from
> "rawhide" automatically becomes the "release".
> 
> FC10 clearly demonstrates this effect.

I don't think this is fair to releng and the QA teams. They expended a
lot of energy in trying to transform the betas in a solid 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/5434c6be/attachment.sig>

From katzj at redhat.com  Wed Dec 10 22:22:20 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 10 Dec 2008 17:22:20 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812101153o114b2905i7303b2a7a4b05cfc@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<604aa7910812101153o114b2905i7303b2a7a4b05cfc@mail.gmail.com>
Message-ID: <1228947740.12085.0.camel@aglarond.local>

On Wed, 2008-12-10 at 10:53 -0900, Jeff Spaleta wrote:
> 2008/12/10 Jesse Keating <jkeating at redhat.com>:
> > Interesting idea!  Would you be willing to bring this topic to the next
> > FESCo meeting?  FESCo is the body responsible for such decisions.
> 
> If that policy change sticks, what is it going to take to get the
> KoPeRs feature up and running? Could KoPeRs be a hack event at
> FUDCon11?

It sounds like a perfect thing to use FUDcon for at least hashing out
more of the details and a plan among people who are interested in
writing code to make it happen.

Jeremy



From rc040203 at freenet.de  Wed Dec 10 22:48:04 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Dec 2008 23:48:04 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228947640.31448.39.camel@arekh.okg>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
Message-ID: <1228949284.3394.36.camel@beck.corsepiu.local>

On Wed, 2008-12-10 at 23:20 +0100, Nicolas Mailhot wrote:
> Le mercredi 10 d?cembre 2008 ? 22:46 +0100, Ralf Corsepius a ?crit :
> 
> > ... then wait until your immature and hardly tested "new code" from
> > "rawhide" automatically becomes the "release".
> > 
> > FC10 clearly demonstrates this effect.
> 
> I don't think this is fair to releng and the QA teams. 
Why is this not fair? The technical facts on FC10 speak for themselves: 
Rawhide and Fedora's release procedures as means for "Fedora release
preparation testing" don't work out.

Ralf





From opensource at till.name  Wed Dec 10 23:00:24 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 00:00:24 +0100
Subject: Making updates-testing more useful
In-Reply-To: <1228939428.3863.50.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228939428.3863.50.camel@localhost.localdomain>
Message-ID: <200812110000.30013.opensource@till.name>

On Wed December 10 2008, Jesse Keating wrote:
> On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> > What do you think ?
>
> I could have sworn the bodhi userland client had a report-testable like
> function that would tell you all the things on your system that came
> from updates-testing.  Probably just simply uses a comparison of what's
> in your rpmdb vs what's available from updates-testing (maybe even
> looking at gpg key?).  Luke?

bodhi --help on F10 reports this:
|  -T, --testable        Display a list of installed updates that you could
|                        test and provide feedback for

Here it requires all the fedora certificates to work. On the machine I have 
this setup, I currently have no testing updates, which it correctly reports.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/4a63e125/attachment.sig>

From opensource at till.name  Wed Dec 10 23:02:59 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 00:02:59 +0100
Subject: Making updates-testing more useful
In-Reply-To: <1228939428.3863.50.camel@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228939428.3863.50.camel@localhost.localdomain>
Message-ID: <200812110002.59634.opensource@till.name>

On Wed December 10 2008, Jesse Keating wrote:

> from updates-testing.  Probably just simply uses a comparison of what's
> in your rpmdb vs what's available from updates-testing (maybe even
> looking at gpg key?).  Luke?

/usr/lib/python2.5/site-packages/fedora/client/bodhi.py contains a testable 
method that gets a list of testing updates from koji and checks for each, 
whether it is installed afaics.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/4bec4aa5/attachment.sig>

From jwboyer at gmail.com  Wed Dec 10 23:48:11 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 10 Dec 2008 18:48:11 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228938532.3863.46.camel@localhost.localdomain>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
Message-ID: <20081210234811.GA11018@zod.rchland.ibm.com>

On Wed, Dec 10, 2008 at 11:48:52AM -0800, Jesse Keating wrote:
>On Wed, 2008-12-10 at 20:17 +0100, Iain Arnell wrote:
>> 2008/12/10 Jesse Keating <jkeating at redhat.com>:
>> > Treat rawhide as your 'new code' land, leave the release trees as your
>> > 'testing and working' code.  That is don't be so goddamn eager to push
>> > new packages and new upstream releases to every freaking branch in
>> > existence.
>> >
>> > Of course, when I make suggestions like these, I become extremely
>> > unpopular.
>> >
>> 
>> doubleplusgood
>> 
>> As a recently sponsored contributor, I would suggest changing the
>> documented procedures.  I was more than happy to shove new packages
>> into rawhide only, but when confronted with
>> http://fedoraproject.org/wiki/PackageMaintainers/Join and
>> http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
>> felt obliged to request branches for F-9 and F-10 too (and pressure
>> during review to support EPEL too only adds to the problem).
>> 
>> Requests for new packages should only be permitted in rawhide by
>> default (and consequently, EPEL+1 whenever and whatever that may be).
>> Some form of additional review/sponsorship/bribery should be a
>> prerequisite for branches in already-released version.
>> 
>> -- 
>> Iain.
>
>Interesting idea!  Would you be willing to bring this topic to the next
>FESCo meeting?  FESCo is the body responsible for such decisions.

Do we have metrics on 'number of brand new packages going out as updates'
versus 'existing packages being bumped to new versions'?

If not, how hard would it be to get those?  They would be rather important
to reviewing this idea at a FESCo level.

josh



From jwboyer at gmail.com  Wed Dec 10 23:51:17 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 10 Dec 2008 18:51:17 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228949284.3394.36.camel@beck.corsepiu.local>
References: <493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
Message-ID: <20081210235117.GB11018@zod.rchland.ibm.com>

On Wed, Dec 10, 2008 at 11:48:04PM +0100, Ralf Corsepius wrote:
>On Wed, 2008-12-10 at 23:20 +0100, Nicolas Mailhot wrote:
>> Le mercredi 10 d?cembre 2008 ? 22:46 +0100, Ralf Corsepius a ?crit :
>> 
>> > ... then wait until your immature and hardly tested "new code" from
>> > "rawhide" automatically becomes the "release".
>> > 
>> > FC10 clearly demonstrates this effect.
>> 
>> I don't think this is fair to releng and the QA teams. 
>Why is this not fair? The technical facts on FC10 speak for themselves: 
>Rawhide and Fedora's release procedures as means for "Fedora release
>preparation testing" don't work out.

Examples of this?  Do you have bug report numbers, regression cases,
or any sort of data saying things are getting worse from a release
stability perspective?

I'm not saying you're wrong, but statements without facts are hard
to swallow.  If we're sucking it up, point us to where and how so
things can be fixed.  I have F10 on a number of machines and it's
working fine, so my personal experience may be different than yours.

josh



From cchance at redhat.com  Wed Dec 10 23:52:00 2008
From: cchance at redhat.com (Caius "kaio" Chance)
Date: Thu, 11 Dec 2008 09:52:00 +1000
Subject: Orphan package - emesene
Message-ID: <49405620.1050401@redhat.com>

Hi,

I would like to orphan the package 'emesene'.

emesene is another WLM(TM) / MSN(TM) compatible client.

Best Regards,
Caius

-- 
Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com
JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer



From bbaetz at acm.org  Wed Dec 10 23:55:33 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 11 Dec 2008 10:55:33 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081210234811.GA11018@zod.rchland.ibm.com>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
Message-ID: <ghpktm$vou$1@ger.gmane.org>

Josh Boyer wrote:

> 
> Do we have metrics on 'number of brand new packages going out as updates'
> versus 'existing packages being bumped to new versions'?
> 
> If not, how hard would it be to get those?  They would be rather important
> to reviewing this idea at a FESCo level.

I actually modified repodiff yesterday to look at the version string to 
work out what the change was (see attached).

F9 -> F9+updates:

Added Packages: 831
Removed Packages: 0 (0 obsoleted)
Modified Packages: 1608
         Major changes: 390
         Minor changes: 764
         Release changes: 445
         Release tag changes: 9

F9+updates -> F10+updates:

Added Packages: 258
Removed Packages: 105 (0 obsoleted)
Modified Packages: 4039
         Major changes: 457
         Minor changes: 673
         Release changes: 1334
         Release tag changes: 1575

F10 -> F10+updates:

Added Packages: 134
Removed Packages: 0 (0 obsoleted)
Modified Packages: 396
         Major changes: 61
         Minor changes: 202
         Release changes: 132
         Release tag changes: 1

This is using the Everything repo as the baseline, and I ran this 
yesterday. 'minor' is an update where only the last part of the version 
string (after the last .) changed, major is everything else. Its not a 
perfect heuristic - looking manually at the list, the major updates are 
being over reported a bit.

Changing this to look at comps to only consider the default package set 
is left as an exercise for the reader. Ditto for counting security 
updates separately, or for counting packages that were updated and then 
had another update come within a week...

I realise that some people want the latest and greatest at all times, 
but its not like releases aren't infrequent. Yes, new versions of 
packages fix bugs, but they also introduce risk. Yes, being the first 
distro to push a new package to stable means that fedora users can find 
and report bugs quickly, but anyone who wants to find bugs can run 
rawhide. And constant updates means that an update for a security issue 
doesn't leapfrog a bunch of versions, but I'm not sure that thats why 
the updates are happening.

When an update announcement comes in with the only description for the 
change is "new version" (with or without copying upstream's changelog), 
or no comment at all, then something is wrong with the process. I'm not 
suggesting that maintainers should have to cherrypick security/critical 
bugfixes only, like RHEL does. And I'm sure that new versions do fix 
bugs that people may be hitting but not reporting in bugzilla.

The yum-presto stuff will reduce the download size (An x86 machine I 
just updated from F8 to F10 downloaded over 1.2G via preupgrade and then 
about 400M of updates from the first couple of weeks of the F10 release 
- thats just wrong...), but while thats important its not the key issue.

Can someone who wants the new versions immediately explain why they 
don't want to wait an average of 3 months for the next fedora release?

Bradley

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: repodiff
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/47424783/attachment.ksh>

From bpepple at fedoraproject.org  Thu Dec 11 00:14:48 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 10 Dec 2008 19:14:48 -0500
Subject: FESCo Meeting Summary for 2008-12-10
Message-ID: <1228954488.7461.2.camel@localhost.localdomain>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Jon Stanley           (jds2001)
* Karsten Hopp          (kick_)
* Kevin Fenzi           (nirik)
* Josh Boyer            (jwb)
* Bill Nottingham       (notting)
* David Woodhouse       (dwmw2)
* Dennis Gilmore        (dgilmore)

== Summary ==
=== Sponsor Nominations  ===
      * FESCo approved the sponsor requests for Jose Matos (jamatos).
      * Note: 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

=== Features ===
      * FESCo approved the following features for Fedora 11:
              * https://fedoraproject.org/wiki/Features/Fingerprint
              * https://fedoraproject.org/wiki/Features/Python_2.6
              * https://fedoraproject.org/wiki/Features/DNSSEC
                      * FESCo had a couple of questions on this feature
                        that were added to the discussion page.
              * https://fedoraproject.org/wiki/Features/TightVNC

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-12-10.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/a88ae7cd/attachment.sig>

From triad at df.lth.se  Thu Dec 11 00:24:38 2008
From: triad at df.lth.se (Linus Walleij)
Date: Thu, 11 Dec 2008 01:24:38 +0100
Subject: Installing from Live CD is the new black?
Message-ID: <1228955078.3037.10.camel@fecusia>

Is it just me or doesn't everybody make their installs off the Live CD
these days?

The ordinary installer CD:s don't work at all for me on this system
(they don't even load Anaconda, some low-level problem after boot).

And I cannot switch to say harddisk or netinstall either, none of that
works as it should.

However installing to harddisk from the Live CD and then pulling the
rest from the regular repos works like a charm. So I'm sure think this
should be a recommended install method for newcomers.

(I would sure like to see something bigger like a Live DVD with a bigger
chunk of default software on, but I guess that's what the spins are
for.)

Linus Walleij



From rc040203 at freenet.de  Thu Dec 11 00:26:35 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 11 Dec 2008 01:26:35 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081210235117.GB11018@zod.rchland.ibm.com>
References: <493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
Message-ID: <1228955195.3394.69.camel@beck.corsepiu.local>

On Wed, 2008-12-10 at 18:51 -0500, Josh Boyer wrote:
> On Wed, Dec 10, 2008 at 11:48:04PM +0100, Ralf Corsepius wrote:
> >On Wed, 2008-12-10 at 23:20 +0100, Nicolas Mailhot wrote:
> >> Le mercredi 10 d?cembre 2008 ? 22:46 +0100, Ralf Corsepius a ?crit :
> >> 
> >> > ... then wait until your immature and hardly tested "new code" from
> >> > "rawhide" automatically becomes the "release".
> >> > 
> >> > FC10 clearly demonstrates this effect.
> >> 
> >> I don't think this is fair to releng and the QA teams. 
> >Why is this not fair? The technical facts on FC10 speak for themselves: 
> >Rawhide and Fedora's release procedures as means for "Fedora release
> >preparation testing" don't work out.
> 
> Examples of this? 

Some random examples, which I have been hit myself:

gnome-session: Currently doesn't provide "session save/restore"
  Official excuse: in process of a rewrite. 
  IMO, the current status should never have been released.

evolution: Suffers from many tiny issues, e.g.:
  https://bugzilla.redhat.com/show_bug.cgi?id=472640
  https://bugzilla.redhat.com/show_bug.cgi?id=472638
  How could these escape a QA? The FC10 version is bugged as evolution
  had been in its worst times. 

mkinitrd/kernel: https://bugzilla.redhat.com/show_bug.cgi?id=470628
  Minor issue, however it escapes me how such a highly visible bug 
  this could escape a "Fedora's testing group".

PackageKit: A trouble area of its own.
  https://bugzilla.redhat.com/show_bug.cgi?id=469293
  https://bugzilla.redhat.com/show_bug.cgi?id=469324
  IMO, PackageKit is too immature and has been prematurely rushed out.

To me, 
* the gnome-session, evolution and PackageKit examples are cases
demonstrating how "bugged SW", which should never have been made part of
a release, migrates from rawhide into releases.
* all 4 cases are demonstrating that rawhide as a release testing
platform doesn't work out.


Wrt. rel-eng:

Besides the numerous NEVR issues between Fedora release, which FC10 (as
usual) suffers from, this time another kind of repo screw up took place:

updates/10 contains packages with an older NEVR than Everything and
Fedora, e.g.:
releases/10/Everything/i386/os/Packages/smolt-1.1.1.1-9.fc10.noarch.rpm
releases/10/Everything/i386/os/Packages/smolt-server-1.1.1.1-9.fc10.noarch.rpm
releases/10/Everything/i386/os/Packages/kazehakase-base-0.5.6-1.fc10.1.i386.rpm
releases/10/Everything/i386/os/Packages/kazehakase-webkit-0.5.6-1.fc10.1.i386.rpm
releases/10/Everything/i386/os/Packages/kazehakase-hyperestraier-0.5.6-1.fc10.1.i386.rpm
releases/10/Everything/i386/os/Packages/kazehakase-0.5.6-1.fc10.1.i386.rpm
releases/10/Everything/i386/os/Packages/smolt-firstboot-1.1.1.1-9.fc10.noarch.rpm
releases/10/Everything/i386/os/Packages/kazehakase-ruby-0.5.6-1.fc10.1.i386.rpm
releases/10/Everything/i386/os/Packages/smolt-gui-1.1.1.1-9.fc10.noarch.rpm
updates/10/i386/kazehakase-webkit-0.5.6-1.fc10.i386.rpm
updates/10/i386/kazehakase-hyperestraier-0.5.6-1.fc10.i386.rpm
updates/10/i386/smolt-firstboot-1.1.1.1-8.fc10.noarch.rpm
updates/10/i386/smolt-server-1.1.1.1-8.fc10.noarch.rpm
updates/10/i386/smolt-1.1.1.1-8.fc10.noarch.rpm
updates/10/i386/kazehakase-0.5.6-1.fc10.i386.rpm
updates/10/i386/kazehakase-base-0.5.6-1.fc10.i386.rpm
updates/10/i386/smolt-gui-1.1.1.1-8.fc10.noarch.rpm
updates/10/i386/kazehakase-ruby-0.5.6-1.fc10.i386.rpm

Admitted, this is a minor issue without impact on users, nevertheless it
raises questions.


>  Do you have bug report numbers, regression cases,
> or any sort of data saying things are getting worse from a release
> stability perspective?
> 
> I'm not saying you're wrong, but statements without facts are hard
> to swallow.  If we're sucking it up, point us to where and how so
> things can be fixed.  I have F10 on a number of machines and it's
> working fine, so my personal experience may be different than yours.
Let me put it this way: I have been running machines equipped with FC10
since ca. Beta2, and am busy filing bugs since then. I haven't been
bookkeeping, but it's in the order of 0.5-1 per day.

Ralf






From jkeating at redhat.com  Thu Dec 11 00:42:49 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 16:42:49 -0800
Subject: Installing from Live CD is the new black?
In-Reply-To: <1228955078.3037.10.camel@fecusia>
References: <1228955078.3037.10.camel@fecusia>
Message-ID: <1228956169.3863.68.camel@localhost.localdomain>

On Thu, 2008-12-11 at 01:24 +0100, Linus Walleij wrote:
> Is it just me or doesn't everybody make their installs off the Live CD
> these days?
> 
> The ordinary installer CD:s don't work at all for me on this system
> (they don't even load Anaconda, some low-level problem after boot).
> 
> And I cannot switch to say harddisk or netinstall either, none of that
> works as it should.
> 
> However installing to harddisk from the Live CD and then pulling the
> rest from the regular repos works like a charm. So I'm sure think this
> should be a recommended install method for newcomers.
> 
> (I would sure like to see something bigger like a Live DVD with a bigger
> chunk of default software on, but I guess that's what the spins are
> for.)
> 
> Linus Walleij

Is this with F10 GA or...?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/33325cda/attachment.sig>

From jwboyer at gmail.com  Thu Dec 11 01:06:10 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 10 Dec 2008 20:06:10 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228955195.3394.69.camel@beck.corsepiu.local>
References: <1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
Message-ID: <20081211010610.GA2883@yoda.jdub.homelinux.org>

On Thu, Dec 11, 2008 at 01:26:35AM +0100, Ralf Corsepius wrote:
>On Wed, 2008-12-10 at 18:51 -0500, Josh Boyer wrote:
>> On Wed, Dec 10, 2008 at 11:48:04PM +0100, Ralf Corsepius wrote:
>> >On Wed, 2008-12-10 at 23:20 +0100, Nicolas Mailhot wrote:
>> >> Le mercredi 10 d?cembre 2008 ? 22:46 +0100, Ralf Corsepius a ?crit :
>> >> 
>> >> > ... then wait until your immature and hardly tested "new code" from
>> >> > "rawhide" automatically becomes the "release".
>> >> > 
>> >> > FC10 clearly demonstrates this effect.
>> >> 
>> >> I don't think this is fair to releng and the QA teams. 
>> >Why is this not fair? The technical facts on FC10 speak for themselves: 
>> >Rawhide and Fedora's release procedures as means for "Fedora release
>> >preparation testing" don't work out.
>> 
>> Examples of this? 
>
>Some random examples, which I have been hit myself:
>

<snip>

>To me, 
>* the gnome-session, evolution and PackageKit examples are cases
>demonstrating how "bugged SW", which should never have been made part of
>a release, migrates from rawhide into releases.
>* all 4 cases are demonstrating that rawhide as a release testing
>platform doesn't work out.

I'd exclude the kernel bug from that summary.  As for the others, I came
to the startling realization that I don't use any of the other 3 packages
at all because I generally either have no use for them or found them to
be buggy in the past and gave up on them (like evolution).

Which is sort of an agreement with you in some regards.  However I also
think one needs to keep in mind that for the majority of packages Fedora
gets what upstream delivers.  Fortunately, most of the upstreams we have
seem to be pretty good about fixing bugs as they are found.  QA can't find
them all, and I think your efforts here show exactly _why_ we need people
like you doing the bug reporting you are.

>Wrt. rel-eng:
>
>Besides the numerous NEVR issues between Fedora release, which FC10 (as
>usual) suffers from, this time another kind of repo screw up took place:

NEVR issues not getting caught are due to two things:  1) package maintainers
not paying attention, and 2) the lack of dep and upgrade path checking in
bodhi.

Number 2 is a rel-eng/infrastructure issue that is being worked on although
somewhat slowly.  Number 1 is something we need the maintainers to start
being accountable for.  Prevention after the fact is never better than being
proactive and cautious about what the maintainers are updating.

>updates/10 contains packages with an older NEVR than Everything and
>Fedora, e.g.:
>releases/10/Everything/i386/os/Packages/smolt-1.1.1.1-9.fc10.noarch.rpm
>releases/10/Everything/i386/os/Packages/smolt-server-1.1.1.1-9.fc10.noarch.rpm
>releases/10/Everything/i386/os/Packages/kazehakase-base-0.5.6-1.fc10.1.i386.rpm
>releases/10/Everything/i386/os/Packages/kazehakase-webkit-0.5.6-1.fc10.1.i386.rpm
>releases/10/Everything/i386/os/Packages/kazehakase-hyperestraier-0.5.6-1.fc10.1.i386.rpm
>releases/10/Everything/i386/os/Packages/kazehakase-0.5.6-1.fc10.1.i386.rpm
>releases/10/Everything/i386/os/Packages/smolt-firstboot-1.1.1.1-9.fc10.noarch.rpm
>releases/10/Everything/i386/os/Packages/kazehakase-ruby-0.5.6-1.fc10.1.i386.rpm
>releases/10/Everything/i386/os/Packages/smolt-gui-1.1.1.1-9.fc10.noarch.rpm
>updates/10/i386/kazehakase-webkit-0.5.6-1.fc10.i386.rpm
>updates/10/i386/kazehakase-hyperestraier-0.5.6-1.fc10.i386.rpm
>updates/10/i386/smolt-firstboot-1.1.1.1-8.fc10.noarch.rpm
>updates/10/i386/smolt-server-1.1.1.1-8.fc10.noarch.rpm
>updates/10/i386/smolt-1.1.1.1-8.fc10.noarch.rpm
>updates/10/i386/kazehakase-0.5.6-1.fc10.i386.rpm
>updates/10/i386/kazehakase-base-0.5.6-1.fc10.i386.rpm
>updates/10/i386/smolt-gui-1.1.1.1-8.fc10.noarch.rpm
>updates/10/i386/kazehakase-ruby-0.5.6-1.fc10.i386.rpm
>
>Admitted, this is a minor issue without impact on users, nevertheless it
>raises questions.

I don't know why that happened.  My best guess would be something like:
"An update was staged and then something happened that caused a newer
package to be pulled into the final release.  The maintainer forgot
about the pending update."

Again, no real clue though.

>>  Do you have bug report numbers, regression cases,
>> or any sort of data saying things are getting worse from a release
>> stability perspective?
>> 
>> I'm not saying you're wrong, but statements without facts are hard
>> to swallow.  If we're sucking it up, point us to where and how so
>> things can be fixed.  I have F10 on a number of machines and it's
>> working fine, so my personal experience may be different than yours.
>Let me put it this way: I have been running machines equipped with FC10
>since ca. Beta2, and am busy filing bugs since then. I haven't been
>bookkeeping, but it's in the order of 0.5-1 per day.

0.5-1 per day after release, or as an average over the time since Beta2?
Also, across a subset of packages or just in random things as you hit
them?

I know you aren't keeping track, but data like that would be useful to
indentify bug trends and problem packages.  I'm not asking you to actually
go answer those questions, but it's something the bug zappers could think
about.

josh



From jwboyer at gmail.com  Thu Dec 11 01:12:10 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 10 Dec 2008 20:12:10 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghpktm$vou$1@ger.gmane.org>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org>
Message-ID: <20081211011210.GB2883@yoda.jdub.homelinux.org>

On Thu, Dec 11, 2008 at 10:55:33AM +1100, Bradley Baetz wrote:
> Josh Boyer wrote:
>
>>
>> Do we have metrics on 'number of brand new packages going out as updates'
>> versus 'existing packages being bumped to new versions'?
>>
>> If not, how hard would it be to get those?  They would be rather important
>> to reviewing this idea at a FESCo level.
>
> I actually modified repodiff yesterday to look at the version string to  
> work out what the change was (see attached).
>
> F9 -> F9+updates:
>
> Added Packages: 831
> Removed Packages: 0 (0 obsoleted)
> Modified Packages: 1608
>         Major changes: 390
>         Minor changes: 764
>         Release changes: 445
>         Release tag changes: 9

Very interesting.  And to clarify, Modified Packages does not include
the packages in Added Packages, right?

> F9+updates -> F10+updates:
>
> Added Packages: 258
> Removed Packages: 105 (0 obsoleted)
> Modified Packages: 4039
>         Major changes: 457
>         Minor changes: 673
>         Release changes: 1334
>         Release tag changes: 1575

For the purpose of this discussion, this data set isn't really
relevant.  Good info in general though.

> F10 -> F10+updates:
>
> Added Packages: 134
> Removed Packages: 0 (0 obsoleted)
> Modified Packages: 396
>         Major changes: 61
>         Minor changes: 202
>         Release changes: 132
>         Release tag changes: 1

And I find this to be a bit scary.  134 new packages have gone into
F10 in 2 weeks via updates??

> This is using the Everything repo as the baseline, and I ran this  
> yesterday. 'minor' is an update where only the last part of the version  
> string (after the last .) changed, major is everything else. Its not a  
> perfect heuristic - looking manually at the list, the major updates are  
> being over reported a bit.

Does "Major" include "Release changes"?

> Can someone who wants the new versions immediately explain why they  
> don't want to wait an average of 3 months for the next fedora release?

6 months (unless you jump on Alpha/Beta).  But yeah, good question.

josh



From petersen at redhat.com  Thu Dec 11 01:20:53 2008
From: petersen at redhat.com (Jens Petersen)
Date: Wed, 10 Dec 2008 20:20:53 -0500 (EST)
Subject: new owner for emacspeak?
In-Reply-To: <1571154873.616341228958306320.JavaMail.root@zmail03.collab.prod.int.phx2.redhat.com>
Message-ID: <748292010.616491228958453590.JavaMail.root@zmail03.collab.prod.int.phx2.redhat.com>

Is anyone here interested in taking over emacspeak?

Do many fedora users use it?

Emacspeak (Emacs Speech interface) has been in RHL, FC and Fedora, and is a pretty low maintainence package.  I took it on the same time I became Emacs and XEmacs maintainer long ago and still own it even though I don't maintain our emacs or xemacs packages any more.

Contact me if you are interested in taking over this package.

Jens



From katzj at redhat.com  Thu Dec 11 02:42:26 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 10 Dec 2008 21:42:26 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081211011210.GB2883@yoda.jdub.homelinux.org>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org>
	<20081211011210.GB2883@yoda.jdub.homelinux.org>
Message-ID: <80753911-DE9C-4562-99B0-354951B32673@redhat.com>

On Dec 10, 2008, at 8:12 PM, Josh Boyer wrote:
> On Thu, Dec 11, 2008 at 10:55:33AM +1100, Bradley Baetz wrote:
>> Josh Boyer wrote:
>> Can someone who wants the new versions immediately explain why they
>> don't want to wait an average of 3 months for the next fedora  
>> release?
>
> 6 months (unless you jump on Alpha/Beta).  But yeah, good question.

It's up to six months, but the average value is 3 months.  </still-a- 
math-geek>

Jeremy



From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Dec 11 03:01:18 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 11 Dec 2008 12:01:18 +0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081211010610.GA2883@yoda.jdub.homelinux.org>
References: <1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<1228945609.3394.10.camel@beck.corsepiu.local>	<1228947640.31448.39.camel@arekh.okg>	<1228949284.3394.36.camel@beck.corsepiu.local>	<20081210235117.GB11018@zod.rchland.ibm.com>	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
Message-ID: <4940827E.5000508@ioa.s.u-tokyo.ac.jp>

Josh Boyer wrote, at 12/11/2008 10:06 AM +9:00:
>> updates/10 contains packages with an older NEVR than Everything and
>> Fedora, e.g.:
>> releases/10/Everything/i386/os/Packages/smolt-1.1.1.1-9.fc10.noarch.rpm
>> releases/10/Everything/i386/os/Packages/smolt-server-1.1.1.1-9.fc10.noarch.rpm
>> releases/10/Everything/i386/os/Packages/kazehakase-base-0.5.6-1.fc10.1.i386.rpm
>> releases/10/Everything/i386/os/Packages/kazehakase-webkit-0.5.6-1.fc10.1.i386.rpm
>> releases/10/Everything/i386/os/Packages/kazehakase-hyperestraier-0.5.6-1.fc10.1.i386.rpm
>> releases/10/Everything/i386/os/Packages/kazehakase-0.5.6-1.fc10.1.i386.rpm
>> releases/10/Everything/i386/os/Packages/smolt-firstboot-1.1.1.1-9.fc10.noarch.rpm
>> releases/10/Everything/i386/os/Packages/kazehakase-ruby-0.5.6-1.fc10.1.i386.rpm
>> releases/10/Everything/i386/os/Packages/smolt-gui-1.1.1.1-9.fc10.noarch.rpm
>> updates/10/i386/kazehakase-webkit-0.5.6-1.fc10.i386.rpm
>> updates/10/i386/kazehakase-hyperestraier-0.5.6-1.fc10.i386.rpm
>> updates/10/i386/smolt-firstboot-1.1.1.1-8.fc10.noarch.rpm
>> updates/10/i386/smolt-server-1.1.1.1-8.fc10.noarch.rpm
>> updates/10/i386/smolt-1.1.1.1-8.fc10.noarch.rpm
>> updates/10/i386/kazehakase-0.5.6-1.fc10.i386.rpm
>> updates/10/i386/kazehakase-base-0.5.6-1.fc10.i386.rpm
>> updates/10/i386/smolt-gui-1.1.1.1-8.fc10.noarch.rpm
>> updates/10/i386/kazehakase-ruby-0.5.6-1.fc10.i386.rpm
>>
>> Admitted, this is a minor issue without impact on users, nevertheless it
>> raises questions.
> 
> I don't know why that happened.  My best guess would be something like:
> "An update was staged and then something happened that caused a newer
> package to be pulled into the final release.  The maintainer forgot
> about the pending update."

For kazehakase (maintained by me)
- When F-10 tree was frozen the EVR tagged as f10-final was
  kazehakase-0.5.5-1.fc9.1
- I submitted 0.5.6-1.fc10 updates on 2008-11-05
- After that xulrunner was upgraded to 1.9.0.4-1.fc10 on
  2008-11-12, kazehakase was rebuilt by gecko maintainers
  and both are tagged as f10-final on 2008-11-17.
- My updates submit was left as it was... (I have to pull it down?)

Mamoru



From rc040203 at freenet.de  Thu Dec 11 03:04:55 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 11 Dec 2008 04:04:55 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081211010610.GA2883@yoda.jdub.homelinux.org>
References: <1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com> <1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
Message-ID: <1228964696.3394.311.camel@beck.corsepiu.local>

On Wed, 2008-12-10 at 20:06 -0500, Josh Boyer wrote:
> On Thu, Dec 11, 2008 at 01:26:35AM +0100, Ralf Corsepius wrote:
> >On Wed, 2008-12-10 at 18:51 -0500, Josh Boyer wrote:
> >> On Wed, Dec 10, 2008 at 11:48:04PM +0100, Ralf Corsepius wrote:
> >> >On Wed, 2008-12-10 at 23:20 +0100, Nicolas Mailhot wrote:
> >> >> Le mercredi 10 d?cembre 2008 ? 22:46 +0100, Ralf Corsepius a ?crit :
> >> >> 
> >> >> > ... then wait until your immature and hardly tested "new code" from
> >> >> > "rawhide" automatically becomes the "release".
> >> >> > 
> >> >> > FC10 clearly demonstrates this effect.
> >> >> 
> >> >> I don't think this is fair to releng and the QA teams. 
> >> >Why is this not fair? The technical facts on FC10 speak for themselves: 
> >> >Rawhide and Fedora's release procedures as means for "Fedora release
> >> >preparation testing" don't work out.
> >> 
> >> Examples of this? 
> >
> >Some random examples, which I have been hit myself:
> >
> 
> <snip>
> 
> >To me, 
> >* the gnome-session, evolution and PackageKit examples are cases
> >demonstrating how "bugged SW", which should never have been made part of
> >a release, migrates from rawhide into releases.
> >* all 4 cases are demonstrating that rawhide as a release testing
> >platform doesn't work out.
> 
> I'd exclude the kernel bug from that summary. 
Having 70+ subscribers on a single BZ speaks a clear language, does it? 

... I have been facing this issue on 4 out of 5 (completely different)
machines I currently have FC10 installed ...

>  As for the others, I came
> to the startling realization that I don't use any of the other 3 packages
> at all because I generally either have no use for them or found them to
> be buggy in the past and gave up on them (like evolution).
Well, these had just been examples ... I could easily extend this
list :(

> Which is sort of an agreement with you in some regards.  However I also
> think one needs to keep in mind that for the majority of packages Fedora
> gets what upstream delivers.
Right, but blindly relying on upstreams is not of much help either.

Instead, package maintainers, testers and rel-engs can not avoid to
build up opinions of their own and to compromise. This may mean to skip
one or more upstream release, to modify it, or ... in extreme cases,
even to abandon a package.

The really problematic cases however are those in which developer and
user perception on a packager/upstream's quality diverge and those in
which political/economical motives or wishful thinking overrule obvious
facts.

>   Fortunately, most of the upstreams we have
> seem to be pretty good about fixing bugs as they are found.  QA can't find
> them all, and I think your efforts here show exactly _why_ we need people
> like you doing the bug reporting you are.
Hmm, all I actually do is to report what I stumble over when using the
OS or when working with components the OS consists of. This works fine,
as long as bugs are being fixed in reasonable time frames and not pushed
aside as "FIXEDRAWHIDE" or "UPSTREAM".

> >Wrt. rel-eng:
> >
> >Besides the numerous NEVR issues between Fedora release, which FC10 (as
> >usual) suffers from, this time another kind of repo screw up took place:
> 
> NEVR issues not getting caught are due to two things:  1) package maintainers
> not paying attention, and 2) the lack of dep and upgrade path checking in
> bodhi.
[snip]
> I don't know why that happened.  My best guess would be something like:
> "An update was staged and then something happened that caused a newer
> package to be pulled into the final release.  The maintainer forgot
> about the pending update."
> 
> Again, no real clue though.
My explanation: rel-eng has lost focus on the real issues.

Or more direct: Why haven't they developed a set of tools related to
detect packaging issues, such as NEVR conflicts, throughout all the
years Fedora is around?

> >>  Do you have bug report numbers, regression cases,
> >> or any sort of data saying things are getting worse from a release
> >> stability perspective?
> >> 
> >> I'm not saying you're wrong, but statements without facts are hard
> >> to swallow.  If we're sucking it up, point us to where and how so
> >> things can be fixed.  I have F10 on a number of machines and it's
> >> working fine, so my personal experience may be different than yours.
> >Let me put it this way: I have been running machines equipped with FC10
> >since ca. Beta2, and am busy filing bugs since then. I haven't been
> >bookkeeping, but it's in the order of 0.5-1 per day.
> 
> 0.5-1 per day after release, or as an average over the time since Beta2?
The later. It has been more or less a constant flow of 3-4 new BZs at
average per week. So far, without any tendency to decrease or increase.

> Also, across a subset of packages or just in random things as you hit
> them?
Most of them are "random things" I trip over when using/trying to us
packages as "ordinary user".

> I know you aren't keeping track, but data like that would be useful to
> indentify bug trends and problem packages. 
Well, with previous releases, I feel there had been a clear tendency: 
Initial releases (the CDs/DVDs) had been almost unusable. After ca. 4-8
weeks of lifetime, when most major packages in Fedora had at least been
replaced once, Fedora had matured into a shape one could recommend to
use it.

>  I'm not asking you to actually
> go answer those questions, but it's something the bug zappers could think
> about.
IMO, the bug zappers are a problem of their own, I should better not
comment on at this point in time.

Ralf





From rc040203 at freenet.de  Thu Dec 11 03:09:21 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 11 Dec 2008 04:09:21 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4940827E.5000508@ioa.s.u-tokyo.ac.jp>
References: <1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
	<4940827E.5000508@ioa.s.u-tokyo.ac.jp>
Message-ID: <1228964961.3394.318.camel@beck.corsepiu.local>

On Thu, 2008-12-11 at 12:01 +0900, Mamoru Tasaka wrote:
> Josh Boyer wrote, at 12/11/2008 10:06 AM +9:00:
> >> updates/10 contains packages with an older NEVR than Everything and
> >> Fedora, e.g.:
> >> releases/10/Everything/i386/os/Packages/smolt-1.1.1.1-9.fc10.noarch.rpm
> >> releases/10/Everything/i386/os/Packages/smolt-server-1.1.1.1-9.fc10.noarch.rpm
> >> releases/10/Everything/i386/os/Packages/kazehakase-base-0.5.6-1.fc10.1.i386.rpm
> >> releases/10/Everything/i386/os/Packages/kazehakase-webkit-0.5.6-1.fc10.1.i386.rpm
> >> releases/10/Everything/i386/os/Packages/kazehakase-hyperestraier-0.5.6-1.fc10.1.i386.rpm
> >> releases/10/Everything/i386/os/Packages/kazehakase-0.5.6-1.fc10.1.i386.rpm
> >> releases/10/Everything/i386/os/Packages/smolt-firstboot-1.1.1.1-9.fc10.noarch.rpm
> >> releases/10/Everything/i386/os/Packages/kazehakase-ruby-0.5.6-1.fc10.1.i386.rpm
> >> releases/10/Everything/i386/os/Packages/smolt-gui-1.1.1.1-9.fc10.noarch.rpm
> >> updates/10/i386/kazehakase-webkit-0.5.6-1.fc10.i386.rpm
> >> updates/10/i386/kazehakase-hyperestraier-0.5.6-1.fc10.i386.rpm
> >> updates/10/i386/smolt-firstboot-1.1.1.1-8.fc10.noarch.rpm
> >> updates/10/i386/smolt-server-1.1.1.1-8.fc10.noarch.rpm
> >> updates/10/i386/smolt-1.1.1.1-8.fc10.noarch.rpm
> >> updates/10/i386/kazehakase-0.5.6-1.fc10.i386.rpm
> >> updates/10/i386/kazehakase-base-0.5.6-1.fc10.i386.rpm
> >> updates/10/i386/smolt-gui-1.1.1.1-8.fc10.noarch.rpm
> >> updates/10/i386/kazehakase-ruby-0.5.6-1.fc10.i386.rpm
> >>
> >> Admitted, this is a minor issue without impact on users, nevertheless it
> >> raises questions.
> > 
> > I don't know why that happened.  My best guess would be something like:
> > "An update was staged and then something happened that caused a newer
> > package to be pulled into the final release.  The maintainer forgot
> > about the pending update."
> 
> For kazehakase (maintained by me)
> - When F-10 tree was frozen the EVR tagged as f10-final was
>   kazehakase-0.5.5-1.fc9.1
> - I submitted 0.5.6-1.fc10 updates on 2008-11-05
> - After that xulrunner was upgraded to 1.9.0.4-1.fc10 on
>   2008-11-12, kazehakase was rebuilt by gecko maintainers
>   and both are tagged as f10-final on 2008-11-17.
> - My updates submit was left as it was... (I have to pull it down?)
Why should YOU do this?

IMO, composing and maintaining the repos is rel-eng's job.

Ralf



From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Dec 11 03:15:07 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 11 Dec 2008 12:15:07 +0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4940827E.5000508@ioa.s.u-tokyo.ac.jp>
References: <1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<1228945609.3394.10.camel@beck.corsepiu.local>	<1228947640.31448.39.camel@arekh.okg>	<1228949284.3394.36.camel@beck.corsepiu.local>	<20081210235117.GB11018@zod.rchland.ibm.com>	<1228955195.3394.69.camel@beck.corsepiu.local>	<20081211010610.GA2883@yoda.jdub.homelinux.org>
	<4940827E.5000508@ioa.s.u-tokyo.ac.jp>
Message-ID: <494085BB.9020509@ioa.s.u-tokyo.ac.jp>

A small fix:

Mamoru Tasaka wrote, at 12/11/2008 12:01 PM +9:00:
> For kazehakase (maintained by me)
> - When F-10 tree was frozen the EVR tagged as f10-final was
>  kazehakase-0.5.5-1.fc9.1

This was kazehakase-0.5.5-2.svn3509_trunk.fc10

> - I submitted 0.5.6-1.fc10 updates on 2008-11-05
> - After that xulrunner was upgraded to 1.9.0.4-1.fc10 on
>  2008-11-12, kazehakase was rebuilt by gecko maintainers
>  and both are tagged as f10-final on 2008-11-17.
> - My updates submit was left as it was... (I have to pull it down?)
> 
> Mamoru

Mamoru



From jkeating at redhat.com  Thu Dec 11 03:21:48 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 19:21:48 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228964696.3394.311.camel@beck.corsepiu.local>
References: <1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com> <1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
	<1228964696.3394.311.camel@beck.corsepiu.local>
Message-ID: <1228965708.3863.70.camel@localhost.localdomain>

On Thu, 2008-12-11 at 04:04 +0100, Ralf Corsepius wrote:
> 
> Or more direct: Why haven't they developed a set of tools related to
> detect packaging issues, such as NEVR conflicts, throughout all the
> years Fedora is around?

Probably because we're trying to cope with the near exponential growth
of software in Fedora, the desires of the community to carve it up in 50
different ways, the sheer volume of updates to attempt to push around,
assisting in large distro wide changes such as python-2.*, gcc, rpm,
etc... and much much more, all while taking heaping helpings of crap
from the likes of you.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/600fcea3/attachment.sig>

From jkeating at redhat.com  Thu Dec 11 03:23:22 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Dec 2008 19:23:22 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228964696.3394.311.camel@beck.corsepiu.local>
References: <1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com> <1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
	<1228964696.3394.311.camel@beck.corsepiu.local>
Message-ID: <1228965802.3863.71.camel@localhost.localdomain>

On Thu, 2008-12-11 at 04:04 +0100, Ralf Corsepius wrote:
> My explanation: rel-eng has lost focus on the real issues.

rel-eng is an open team of volunteers, with public meetings,
discussions, code, etc...  If you'd like to see more focus in the areas
you speak of, by all means join the team and give a helping hand.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081210/245c88bd/attachment.sig>

From jwboyer at gmail.com  Thu Dec 11 03:28:48 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 10 Dec 2008 22:28:48 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228964696.3394.311.camel@beck.corsepiu.local>
References: <1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
	<1228964696.3394.311.camel@beck.corsepiu.local>
Message-ID: <20081211032848.GA19602@zod.rchland.ibm.com>

On Thu, Dec 11, 2008 at 04:04:55AM +0100, Ralf Corsepius wrote:
>>  As for the others, I came
>> to the startling realization that I don't use any of the other 3 packages
>> at all because I generally either have no use for them or found them to
>> be buggy in the past and gave up on them (like evolution).
>Well, these had just been examples ... I could easily extend this
>list :(
>
>> Which is sort of an agreement with you in some regards.  However I also
>> think one needs to keep in mind that for the majority of packages Fedora
>> gets what upstream delivers.
>Right, but blindly relying on upstreams is not of much help either.
>
>Instead, package maintainers, testers and rel-engs can not avoid to
>build up opinions of their own and to compromise. This may mean to skip
>one or more upstream release, to modify it, or ... in extreme cases,
>even to abandon a package.

Yes.  But that is again mostly package maintainers.  There is a level of
trust that needs to be there, otherwise the project doesn't scale and
the package set will be trimmed down to 'stuff that the small set of
people that compose the QA and rel-eng groups can test themselves'.

>
>The really problematic cases however are those in which developer and
>user perception on a packager/upstream's quality diverge and those in
>which political/economical motives or wishful thinking overrule obvious
>facts.
>
>>   Fortunately, most of the upstreams we have
>> seem to be pretty good about fixing bugs as they are found.  QA can't find
>> them all, and I think your efforts here show exactly _why_ we need people
>> like you doing the bug reporting you are.
>Hmm, all I actually do is to report what I stumble over when using the
>OS or when working with components the OS consists of. This works fine,
>as long as bugs are being fixed in reasonable time frames and not pushed
>aside as "FIXEDRAWHIDE" or "UPSTREAM".

You would be surprised at how many people don't bother.  So thanks.

>> >Wrt. rel-eng:
>> >
>> >Besides the numerous NEVR issues between Fedora release, which FC10 (as
>> >usual) suffers from, this time another kind of repo screw up took place:
>> 
>> NEVR issues not getting caught are due to two things:  1) package maintainers
>> not paying attention, and 2) the lack of dep and upgrade path checking in
>> bodhi.
>[snip]
>> I don't know why that happened.  My best guess would be something like:
>> "An update was staged and then something happened that caused a newer
>> package to be pulled into the final release.  The maintainer forgot
>> about the pending update."
>> 
>> Again, no real clue though.
>My explanation: rel-eng has lost focus on the real issues.

I wouldn't put it that way.  There is no lack of focus on NEVR and dep
issues.  There is simply a lack of time in the day for the people
involved.  So they work on it when they have time, like most of us do
with Fedora contributions.

>Or more direct: Why haven't they developed a set of tools related to
>detect packaging issues, such as NEVR conflicts, throughout all the
>years Fedora is around?

They have actually.  The results are published quite often and the tools
are located in the rel-eng repo.  They just have to be run.

Though again, this needs to be done before the repos are created, not
after.  Work is on-going here.

>> >>  Do you have bug report numbers, regression cases,
>> >> or any sort of data saying things are getting worse from a release
>> >> stability perspective?
>> >> 
>> >> I'm not saying you're wrong, but statements without facts are hard
>> >> to swallow.  If we're sucking it up, point us to where and how so
>> >> things can be fixed.  I have F10 on a number of machines and it's
>> >> working fine, so my personal experience may be different than yours.
>> >Let me put it this way: I have been running machines equipped with FC10
>> >since ca. Beta2, and am busy filing bugs since then. I haven't been
>> >bookkeeping, but it's in the order of 0.5-1 per day.
>> 
>> 0.5-1 per day after release, or as an average over the time since Beta2?
>The later. It has been more or less a constant flow of 3-4 new BZs at
>average per week. So far, without any tendency to decrease or increase.

Ok.

>> Also, across a subset of packages or just in random things as you hit
>> them?
>Most of them are "random things" I trip over when using/trying to us
>packages as "ordinary user".

Ok.

>> I know you aren't keeping track, but data like that would be useful to
>> indentify bug trends and problem packages. 
>Well, with previous releases, I feel there had been a clear tendency: 
>Initial releases (the CDs/DVDs) had been almost unusable. After ca. 4-8
>weeks of lifetime, when most major packages in Fedora had at least been
>replaced once, Fedora had matured into a shape one could recommend to
>use it.

I've not had that experience, but my usecases are pretty limited and I
tend to lag a bit behind the release GA and when I actually install it.

>
>>  I'm not asking you to actually
>> go answer those questions, but it's something the bug zappers could think
>> about.
>IMO, the bug zappers are a problem of their own, I should better not
>comment on at this point in time.

s/bug zappers/anyone that likes statistical data mining ;)

josh



From vonbrand at inf.utfsm.cl  Thu Dec 11 04:15:08 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 11 Dec 2008 01:15:08 -0300
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493F7368.9010005@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>
	<493F6B8F.8010209@gmail.com>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com>
Message-ID: <200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:

[...]

> But I wouldn't envision marking an update as 'bad' although that's an
> interesting concept itself.  I was thinking that there would be a
> specified time when all normal updates enter the repository, followed
> by a time when only critical bug and security fix updates could be
> added, so towards the end of that interval, packages that hadn't been
> replaced with 'better' updates would automatically be assumed 'good'
> and it would be fairly safe to update machines where you want less
> risk.  Then a new cycle of 'new feature' updates could start.

And presumably you (and everybody else) would wait out the "until known
good" period; and as nobody tried it before, get to keep the pieces of the
resulting breakage...
-- 
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 vonbrand at inf.utfsm.cl  Thu Dec 11 04:16:18 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 11 Dec 2008 01:16:18 -0300
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <493F7BCA.3030405@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>
	<493F6B8F.8010209@gmail.com>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com> <ghns71$ss5$1@ger.gmane.org>
	<493F7BCA.3030405@gmail.com>
Message-ID: <200812110416.mBB4GIYu005393@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:

[...]

> This would be to catch the things that get past updates-testing but
> can be fixed quickly.  You'd probably have the default set to pull all
> updates (which will keep a big base of users) but once you have a
> machine running nicely and doing important work you'd have a setting
> to make it be more conservative there.  I don't think it's as nice as
> repeatable updates, but it would not take much infrastructure change.

That is already on hand. It's called RHEL.
-- 
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 kevin.kofler at chello.at  Thu Dec 11 05:05:38 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 06:05:38 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
Message-ID: <ghq732$5to$1@ger.gmane.org>

Jesse Keating wrote:
> Now here's a crazy idea, that nobody seems to want to follow:
> 
> Treat rawhide as your 'new code' land, leave the release trees as your
> 'testing and working' code.  That is don't be so goddamn eager to push
> new packages and new upstream releases to every freaking branch in
> existence.

I strongly disagree with that idea, IMHO the version upgrades to released
versions are the main distinctive point of Fedora, many people (including
me) use Fedora for that very reason.

And the problem in this thread wasn't even such an update, it was a security
fix! Even if it had been backported to D-Bus 1.2.4 instead of an upgrade to
1.2.6, it would still have caused the same issue! So the problem we're
seeing has absolutely nothing to do with feature upgrades.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Dec 11 05:07:35 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 06:07:35 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228931026.30987.121.camel@code.and.org>
Message-ID: <ghq76n$5to$2@ger.gmane.org>

James Antill wrote:
> ...if you are just asking nicely then #1 and #2 create a feedback loop
> which perpetuates the current updates firehose, if we want to do this we
> need to start forcing updates to not happen (ie. policy saying that
> updates _won't_ happen unless they qualify under XYZ).
>  Maybe we could introduce this with usable KOPERS, so people can put
> their updates/non-critical-fixes into those repos.
> 
>  And as a Fedora user, an upstream developer and a Fedora packager ... I
> would welcome a policy to that effect.

I wouldn't. Let's not make Fedora a bureaucracy like Debian stable. It would
immensely reduce its usefulness. People who don't want non-criticial
updates should be using CentOS, not Fedora.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Dec 11 05:14:14 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 06:14:14 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<1228945930.3394.15.camel@beck.corsepiu.local>
Message-ID: <ghq7j6$5to$4@ger.gmane.org>

Ralf Corsepius wrote:

> On Wed, 2008-12-10 at 11:48 -0800, Jesse Keating wrote:
>> On Wed, 2008-12-10 at 20:17 +0100, Iain Arnell wrote:
>> > 2008/12/10 Jesse Keating <jkeating at redhat.com>:
> 
>> > Requests for new packages should only be permitted in rawhide by
>> > default (and consequently, EPEL+1 whenever and whatever that may be).
>> > Some form of additional review/sponsorship/bribery should be a
>> > prerequisite for branches in already-released version.
> 
>> Interesting idea!
> IMO, a highly counterproductive idea:
> * Most new packages don't cause malfunctionals to existing packages.
> 
> * Not letting new packages in released versions of Fedora
> - reduces a package's exposure to users and thereby reduces
>   possibilities to test a package and opportunities to find bugs.
> - Renders Fedora less interesting to prospective contributors.

+1

The ability to get new packages as soon as they're introduced, on a released
Fedora version, was one of the great things about Extras which lead to its
popularity and thus the merge. If you kill it know, we will need a new
Extras! (And I don't think that makes any sense. The current system just
works.) And I really don't see what a new package which doesn't have any
Obsoletes for existing packages can break!

New packages should be allowed at any time. (OK, the ban during the last
month before EOL makes sense, but we shouldn't go any farther than that.)

        Kevin Kofler



From kevin.kofler at chello.at  Thu Dec 11 05:09:48 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 06:09:48 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
Message-ID: <ghq7as$5to$3@ger.gmane.org>

Jesse Keating wrote:
> Seriously, if we could actually just focus on bugfixing for our released
> trees, do the new package work in rawhide (and bugfixing of the new
> packages there), our released trees might actually stabilize outside of
> the heavy handed forced freezes during development.

But often it's impossible to fix some bugs without a version upgrade. For
example, the upgrade to KDE 4.1 in F9 fixed many bugs in 4.0.

        Kevin Kofler



From bbaetz at acm.org  Thu Dec 11 05:21:51 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 11 Dec 2008 16:21:51 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081211011210.GB2883@yoda.jdub.homelinux.org>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<20081211011210.GB2883@yoda.jdub.homelinux.org>
Message-ID: <ghq81g$98v$1@ger.gmane.org>

Josh Boyer wrote:
> On Thu, Dec 11, 2008 at 10:55:33AM +1100, Bradley Baetz wrote:

>> I actually modified repodiff yesterday to look at the version string to  
>> work out what the change was (see attached).

> Very interesting.  And to clarify, Modified Packages does not include
> the packages in Added Packages, right?

Correct.

>> F9+updates -> F10+updates:

> For the purpose of this discussion, this data set isn't really
> relevant.  Good info in general though.

Well, not necessarily. Before I ran it I was expecting to find out that 
most packages in F10 had already been pushed to F9 - ie that 
F9->F9+updates was actually a bigger upgrade than F9->F10. I'm pleased 
that that doesn't seem to be the case, but it would be interesting to 
compare just the base install packages.

>> F10 -> F10+updates:

> And I find this to be a bit scary.  134 new packages have gone into
> F10 in 2 weeks via updates??

A lot of them were zero-day 'new package didn't make the freeze so chuck 
it in ASAP' updates. Again, you can argue that new packages don't break 
anything, but it comes back to the 'what is fedora's goal' discussion 
that happens whenever this discussion happens....

Note that these are numbers from SRPMS, so package reshuffles don't count.

>> This is using the Everything repo as the baseline, and I ran this  
>> yesterday. 'minor' is an update where only the last part of the version  
>> string (after the last .) changed, major is everything else. Its not a  
>> perfect heuristic - looking manually at the list, the major updates are  
>> being over reported a bit.
> 
> Does "Major" include "Release changes"?

No - all the categories are separate (except 'modified' includes all the 
different modifications) - release means the R in NVR (and also doesn't 
include release tag-only changes)

>> Can someone who wants the new versions immediately explain why they  
>> don't want to wait an average of 3 months for the next fedora release?
> 
> 6 months (unless you jump on Alpha/Beta).  But yeah, good question.

An average of 3, although you could argue that the downside of not 
having the package available for 6 months is more than missing it for 
one month.

Bradley



From kevin.kofler at chello.at  Thu Dec 11 05:21:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 06:21:02 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org>
Message-ID: <ghq7vu$5to$5@ger.gmane.org>

Bradley Baetz wrote:
> Can someone who wants the new versions immediately explain why they
> don't want to wait an average of 3 months for the next fedora release?

Because if you need the bugfix or the new feature now, any wait is too long.

Also because you'll then also get those major changes which were
intentionally not pushed as updates to that release, e.g. KDE 4 for Fedora
9, kdepim 4, Amarok 2, digiKam 0.10 and Krusader 2 for Fedora 10, probably
KOffice 2 for Fedora 11.

And because if you don't want new versions, you can use CentOS or Debian
stable or Ubuntu or openSUSE or any other distribution which does not push
version updates to releases. Why take away Fedora's unique selling point?
If you don't like the way Fedora works, you should be using another
distribution, not trying to strong-arm Fedora into working the way you
want.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Dec 11 05:27:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 06:27:46 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<1228945609.3394.10.camel@beck.corsepiu.local>	<1228947640.31448.39.camel@arekh.okg>	<1228949284.3394.36.camel@beck.corsepiu.local>	<20081210235117.GB11018@zod.rchland.ibm.com>	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
	<4940827E.5000508@ioa.s.u-tokyo.ac.jp>
Message-ID: <ghq8ci$5to$6@ger.gmane.org>

Mamoru Tasaka wrote:
> - My updates submit was left as it was... (I have to pull it down?)

You should have done it, but it's too late now.

Anyway, it doesn't really matter, yum will pick up the higher EVR from
Everything anyway.

        Kevin Kofler



From skvidal at fedoraproject.org  Thu Dec 11 05:31:29 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 00:31:29 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq8ci$5to$6@ger.gmane.org>
References: <1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
	<4940827E.5000508@ioa.s.u-tokyo.ac.jp> <ghq8ci$5to$6@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0812110031050.12077@localhost.localdomain>



On Thu, 11 Dec 2008, Kevin Kofler wrote:

> Mamoru Tasaka wrote:
>> - My updates submit was left as it was... (I have to pull it down?)
>
> You should have done it, but it's too late now.
>
> Anyway, it doesn't really matter, yum will pick up the higher EVR from
> Everything anyway.
>

Writing a plugin to exclude the latest version (if there are more than 
one) is not very difficult. It's just questionably useful.

-sv



From kevin.kofler at chello.at  Thu Dec 11 05:45:01 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 06:45:01 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<20081211011210.GB2883@yoda.jdub.homelinux.org>
	<ghq81g$98v$1@ger.gmane.org>
Message-ID: <ghq9cu$brb$1@ger.gmane.org>

Bradley Baetz wrote:
> A lot of them were zero-day 'new package didn't make the freeze so chuck
> it in ASAP' updates. Again, you can argue that new packages don't break
> anything, but it comes back to the 'what is fedora's goal' discussion
> that happens whenever this discussion happens....

But why do you want to ban something which doesn't hurt?

What will happen with your proposed ban is that many users will
use --enablerepo=rawhide to get the packages they need and break their
systems that way (one should NEVER use --enablerepo=rawhide except to
upgrade the ENTIRE system to Rawhide (yum --enablerepo=rawhide upgrade),
and that carries the usual Rawhide risks). It is not possible to just
install an arbitrary package from Rawhide because that will in many cases
depend on other packages from Rawhide (right now it's Python 2.6, sometimes
it's a new OpenSSL, OpenLDAP or whatever core library), and upgrading those
in turn also forces the upgrade of everything else depending on those (e.g.
if the upgrade drags in Python 2.6, it will also drag in all the other
Python stuff including yum!).

You can't tell users to just wait for the next release, in many cases they
can't or don't want to wait.

        Kevin Kofler



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 05:48:56 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 22:48:56 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>
	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
Message-ID: <1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
> [...]
> 
>> But I wouldn't envision marking an update as 'bad' although that's an
>> interesting concept itself.  I was thinking that there would be a
>> specified time when all normal updates enter the repository, followed
>> by a time when only critical bug and security fix updates could be
>> added, so towards the end of that interval, packages that hadn't been
>> replaced with 'better' updates would automatically be assumed 'good'
>> and it would be fairly safe to update machines where you want less
>> risk.  Then a new cycle of 'new feature' updates could start.
> 
> And presumably you (and everybody else) would wait out the "until known
> good" period; and as nobody tried it before, get to keep the pieces of the
> resulting breakage...

If that is true, then it would mean there's nobody who wants bleeding
edge. That in turn would mean that Fedora should be redefined to not be
bleeding edge, because nobody wants it that way...



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 05:49:54 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 22:49:54 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq7as$5to$3@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
Message-ID: <1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>

Kevin Kofler wrote:
> Jesse Keating wrote:
>> Seriously, if we could actually just focus on bugfixing for our released
>> trees, do the new package work in rawhide (and bugfixing of the new
>> packages there), our released trees might actually stabilize outside of
>> the heavy handed forced freezes during development.
> 
> But often it's impossible to fix some bugs without a version upgrade. For
> example, the upgrade to KDE 4.1 in F9 fixed many bugs in 4.0.

That's an argument for not having introduced the alpha/beta-quality
release KDE 4.0 into Fedora in the first place.



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 05:52:19 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 22:52:19 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq7vu$5to$5@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org>
Message-ID: <1228974732.17799.TMDA@tmda.severn.wwwdotorg.org>

Kevin Kofler wrote:
> Bradley Baetz wrote:
>> Can someone who wants the new versions immediately explain why they
>> don't want to wait an average of 3 months for the next fedora release?
> 
> Because if you need the bugfix or the new feature now, any wait is too long.

If it's a bugfix, backport it.

If it's a new feature, just install the devel rpm. Don't force breakage
upon other users.



From pemboa at gmail.com  Thu Dec 11 05:53:21 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 10 Dec 2008 23:53:21 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>

On Wed, Dec 10, 2008 at 11:49 PM, Stephen Warren
<s-t-rhbugzilla at wwwdotorg.org> wrote:
> Kevin Kofler wrote:
>> Jesse Keating wrote:
>>> Seriously, if we could actually just focus on bugfixing for our released
>>> trees, do the new package work in rawhide (and bugfixing of the new
>>> packages there), our released trees might actually stabilize outside of
>>> the heavy handed forced freezes during development.
>>
>> But often it's impossible to fix some bugs without a version upgrade. For
>> example, the upgrade to KDE 4.1 in F9 fixed many bugs in 4.0.
>
> That's an argument for not having introduced the alpha/beta-quality
> release KDE 4.0 into Fedora in the first place.


And that's an arguement for turning Fedora into something useless.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From kevin.kofler at chello.at  Thu Dec 11 05:55:31 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 06:55:31 +0100
Subject: Making updates-testing more useful
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<49401066.2030403@gmail.com>
Message-ID: <ghqa0j$brb$2@ger.gmane.org>

Les Mikesell wrote:
> Could there be a way to throw everything in the same repo and give the
> user/installer a choice of how 'well-tested' something should be before
> installing it?  Preferably with a sliding scale instead of just 2
> choices.  Normally on new installs and machines used explicitly for
> testing I'd expect people to want the latest changes but become more
> conservative on machines that are working well and used for important
> work.  The 'well-tested' concept might have factors for age, feedback,
> emergency overrides, etc.

This is horribly overengineered and just can't work (for the reasons Jesse
Keating already pointed out, so I won't repeat them).

I think the added complexity would also confuse end users, but we don't even
have to get that far with the discussion because it is impossible to
implement anyway.

        Kevin Kofler



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 05:57:15 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 22:57:15 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
Message-ID: <1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>

Arthur Pemberton wrote:
> On Wed, Dec 10, 2008 at 11:49 PM, Stephen Warren
> <s-t-rhbugzilla at wwwdotorg.org> wrote:
>> Kevin Kofler wrote:
>>> Jesse Keating wrote:
>>>> Seriously, if we could actually just focus on bugfixing for our released
>>>> trees, do the new package work in rawhide (and bugfixing of the new
>>>> packages there), our released trees might actually stabilize outside of
>>>> the heavy handed forced freezes during development.
>>> But often it's impossible to fix some bugs without a version upgrade. For
>>> example, the upgrade to KDE 4.1 in F9 fixed many bugs in 4.0.
>>
>> That's an argument for not having introduced the alpha/beta-quality
>> release KDE 4.0 into Fedora in the first place.
> 
> And that's an arguement for turning Fedora into something useless.

What, usable software is useless? You can't possibly argue that KDE 4.0
was a good choice given the need to replace it with 4.1 so quickly.



From lesmikesell at gmail.com  Thu Dec 11 06:01:30 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 00:01:30 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>
	<493F6B8F.8010209@gmail.com>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com>
	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
Message-ID: <4940ACBA.4030005@gmail.com>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
> [...]
> 
>> But I wouldn't envision marking an update as 'bad' although that's an
>> interesting concept itself.  I was thinking that there would be a
>> specified time when all normal updates enter the repository, followed
>> by a time when only critical bug and security fix updates could be
>> added, so towards the end of that interval, packages that hadn't been
>> replaced with 'better' updates would automatically be assumed 'good'
>> and it would be fairly safe to update machines where you want less
>> risk.  Then a new cycle of 'new feature' updates could start.
> 
> And presumably you (and everybody else) would wait out the "until known
> good" period; and as nobody tried it before, get to keep the pieces of the
> resulting breakage...

I'd expect everyone with more than one machine to choose different 
settings per machine, depending on how well it was currently working and 
how important its operation is.   But if, as you are suggesting, 
everyone did choose the more conservative alternative, would you agree 
that the way fedora updates is not what people want?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Thu Dec 11 06:02:21 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 07:02:21 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org>
	<1228974732.17799.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <ghqadd$brb$3@ger.gmane.org>

Stephen Warren wrote:
> If it's a new feature, just install the devel rpm. Don't force breakage
> upon other users.

You're assuming that new features necessarily introduce breakage, which is
not true.

        Kevin Kofler



From pemboa at gmail.com  Thu Dec 11 06:04:39 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 00:04:39 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>

On Wed, Dec 10, 2008 at 11:57 PM, Stephen Warren
<s-t-rhbugzilla at wwwdotorg.org> wrote:
> Arthur Pemberton wrote:
>> On Wed, Dec 10, 2008 at 11:49 PM, Stephen Warren
>> <s-t-rhbugzilla at wwwdotorg.org> wrote:
>>> Kevin Kofler wrote:
>>>> Jesse Keating wrote:
>>>>> Seriously, if we could actually just focus on bugfixing for our released
>>>>> trees, do the new package work in rawhide (and bugfixing of the new
>>>>> packages there), our released trees might actually stabilize outside of
>>>>> the heavy handed forced freezes during development.
>>>> But often it's impossible to fix some bugs without a version upgrade. For
>>>> example, the upgrade to KDE 4.1 in F9 fixed many bugs in 4.0.
>>>
>>> That's an argument for not having introduced the alpha/beta-quality
>>> release KDE 4.0 into Fedora in the first place.
>>
>> And that's an arguement for turning Fedora into something useless.
>
> What, usable software is useless? You can't possibly argue that KDE 4.0
> was a good choice given the need to replace it with 4.1 so quickly.


First of all, these kind of discussions piss me off a bit, so if I
fail to be clear on something let me know and I will try to reexplain.

I never send usable software is useless. I said changing Fedora in
that way would make Fedora useless. There would be no meaningful
differentiation between Fedora and other popular distros, and that
would render it entirely useless to the myself, and I would argue, the
Linux community. I see very little between what is being suggesting
and making Fedora "like Ubuntu". The community already has a "like
Ubuntu".

Yes, I can possible argue that KDE 4.0 was a good choice. The fact
that it was updated to 4.1 as soon as possible should in no way be a
negative. I use Fedora to have the latest software possible as soon as
possible. If I wanted shrink wrapped and slow, there are other distros
for that.

Tell me this, after all your changes have been made to Fedora, what
would make it different and uniquely useful? Having "usable" software,
doesn't make it uniquely useful.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 06:09:05 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 23:09:05 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqadd$brb$3@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>	<ghq7vu$5to$5@ger.gmane.org>	<1228974732.17799.TMDA@tmda.severn.wwwdotorg.org>
	<ghqadd$brb$3@ger.gmane.org>
Message-ID: <1228975738.18251.TMDA@tmda.severn.wwwdotorg.org>

Kevin Kofler wrote:
> Stephen Warren wrote:
>> If it's a new feature, just install the devel rpm. Don't force breakage
>> upon other users.
> 
> You're assuming that new features necessarily introduce breakage, which is
> not true.

Agreed. However, there is certainly a lot *more* risk of breakage, even
if the extremes aren't guaranteed 0% v.s. 100%.



From kevin.kofler at chello.at  Thu Dec 11 06:06:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 07:06:37 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <ghqald$brb$4@ger.gmane.org>

Stephen Warren wrote:

> Arthur Pemberton wrote:
>> On Wed, Dec 10, 2008 at 11:49 PM, Stephen Warren
>>>
>>> That's an argument for not having introduced the alpha/beta-quality
>>> release KDE 4.0 into Fedora in the first place.
>> 
>> And that's an arguement for turning Fedora into something useless.
> 
> What, usable software is useless? You can't possibly argue that KDE 4.0
> was a good choice given the need to replace it with 4.1 so quickly.

Useless in the light of the fact that there are dozens of other conservative
distributions; the whole point of Fedora is to be fast-moving.

And having something to replace with 4.1 when it's ready was one of the
reasons we decided on 4.0, upgrading 3.5 to 4.1 post release would not have
been feasible, 4.0 to 4.1 was. Nobody was forced to upgrade to F9 the day
of the release. That said, I used F9 with 4.0.x on my laptop and it was
perfectly usable as well.

        Kevin Kofler



From pemboa at gmail.com  Thu Dec 11 06:15:01 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 00:15:01 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqald$brb$4@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<ghqald$brb$4@ger.gmane.org>
Message-ID: <16de708d0812102215r595d6fafje7212f40139ac132@mail.gmail.com>

On Thu, Dec 11, 2008 at 12:06 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Stephen Warren wrote:
>
>> Arthur Pemberton wrote:
>>> On Wed, Dec 10, 2008 at 11:49 PM, Stephen Warren
>>>>
>>>> That's an argument for not having introduced the alpha/beta-quality
>>>> release KDE 4.0 into Fedora in the first place.
>>>
>>> And that's an arguement for turning Fedora into something useless.
>>
>> What, usable software is useless? You can't possibly argue that KDE 4.0
>> was a good choice given the need to replace it with 4.1 so quickly.
>
> Useless in the light of the fact that there are dozens of other conservative
> distributions; the whole point of Fedora is to be fast-moving.

This is exactly my point. A slow-moving Fedora makes it "just another distro".


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From kevin.kofler at chello.at  Thu Dec 11 06:15:34 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 07:15:34 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>
	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <ghqb66$brb$5@ger.gmane.org>

Stephen Warren wrote:

> Horst H. von Brand wrote:
>
>> And presumably you (and everybody else) would wait out the "until known
>> good" period; and as nobody tried it before, get to keep the pieces of
>> the resulting breakage...
> 
> If that is true, then it would mean there's nobody who wants bleeding
> edge. That in turn would mean that Fedora should be redefined to not be
> bleeding edge, because nobody wants it that way...

The problem is that users are asking for contradictory/impossible things:
they want new versions as soon as possible, i.e. the day upstream releases
them, but also updates tested for weeks. Fedora currently has a good
compromise (new versions normally get 1-2 weeks of testing, and major
changes known to break things are only pushed to Rawhide), people who need
something more conservative should be using a more conservative
distribution.

And there's also a Prisoner's Dilemma problem here: users moving to the
conservative update stream => fewer testers for updates-testing and updates
=> more breakage => more users moving to the conservative update stream and
the vicious circle is complete.

        Kevin Kofler



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 06:19:28 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 23:19:28 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
Message-ID: <1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>

Arthur Pemberton wrote:
> On Wed, Dec 10, 2008 at 11:57 PM, Stephen Warren
> <s-t-rhbugzilla at wwwdotorg.org> wrote:
>> Arthur Pemberton wrote:
>>> On Wed, Dec 10, 2008 at 11:49 PM, Stephen Warren
>>> <s-t-rhbugzilla at wwwdotorg.org> wrote:
>>>> Kevin Kofler wrote:
>>>>> Jesse Keating wrote:
>>>>>> Seriously, if we could actually just focus on bugfixing for our released
>>>>>> trees, do the new package work in rawhide (and bugfixing of the new
>>>>>> packages there), our released trees might actually stabilize outside of
>>>>>> the heavy handed forced freezes during development.
>>>>> But often it's impossible to fix some bugs without a version upgrade. For
>>>>> example, the upgrade to KDE 4.1 in F9 fixed many bugs in 4.0.
>>>> That's an argument for not having introduced the alpha/beta-quality
>>>> release KDE 4.0 into Fedora in the first place.
>>> And that's an arguement for turning Fedora into something useless.
>> What, usable software is useless? You can't possibly argue that KDE 4.0
>> was a good choice given the need to replace it with 4.1 so quickly.
> 
> 
> First of all, these kind of discussions piss me off a bit, so if I
> fail to be clear on something let me know and I will try to reexplain.
> 
> I never send usable software is useless. I said changing Fedora in
> that way would make Fedora useless. There would be no meaningful
> differentiation between Fedora and other popular distros, and that
> would render it entirely useless to the myself, and I would argue, the
> Linux community. I see very little between what is being suggesting
> and making Fedora "like Ubuntu". The community already has a "like
> Ubuntu".

So, if the idea of Fedora's differentiation is to keep throwing the
latest stuff into the latest non-devel release essentially in order to
always have the latest stuff, or close to it, what is the point of
having releases - why not just have a completely rolling distro?

The only things I can see that a release gives are:

* Creates devel/rawhide as a staging area for the next release, allowing
large upgrades like KDE 4, Perl 5.xx, Python 2.6 to be put in place
piece-py-piece without disrupting users. This could also be achieved by
creating "feature" branches from the distro, making these invasive
changes, then merging back into the single release branch once
everything was done.

* An an installer. Given that Fedora creates beta/preview/RC installers
with minimal locks on devel, it seems that working installers could
still be created even without numbered releases (or perhaps the packages
on the installer lag the top-of-tree by a month or so to allow
stabilization in an installer branch).

Alternatively (to a rolling distro), we could increase the frequency of
Fedora releases. It seems that the main reason people want the latest
stuff thrown into Fedora $latest is because they don't want to wait for
the next release in just 3 months time on average. So, make "the next
release" happen every 3, or 2, or 1 months (-> wait is 1.5, 1, 0.5
months average). I don't know about capacity-wise, but the Fedora
infra-structure certainly seems to have the logic in place now for
managing arbitrary numbers of current releases.



From bbaetz at acm.org  Thu Dec 11 06:22:11 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 11 Dec 2008 17:22:11 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq9cu$brb$1@ger.gmane.org>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>	<20081211011210.GB2883@yoda.jdub.homelinux.org>	<ghq81g$98v$1@ger.gmane.org>
	<ghq9cu$brb$1@ger.gmane.org>
Message-ID: <ghqbik$gbe$1@ger.gmane.org>

Kevin Kofler wrote:
> Bradley Baetz wrote:
>> A lot of them were zero-day 'new package didn't make the freeze so chuck
>> it in ASAP' updates. Again, you can argue that new packages don't break
>> anything, but it comes back to the 'what is fedora's goal' discussion
>> that happens whenever this discussion happens....
> 
> But why do you want to ban something which doesn't hurt?

I wasn't suggesting to ban new packages, just commenting on why the 
number was so high - my personal concern is with the level of updates 
and how frequently they break stuff.

Bradley



From lesmikesell at gmail.com  Thu Dec 11 06:23:44 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 00:23:44 -0600
Subject: Making updates-testing more useful
In-Reply-To: <ghqa0j$brb$2@ger.gmane.org>
References: <1228930549.3648.14.camel@localhost.localdomain>	<1228933404.2682.7.camel@scrappy.miketc.net>	<49401066.2030403@gmail.com>
	<ghqa0j$brb$2@ger.gmane.org>
Message-ID: <4940B1F0.2050702@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> Could there be a way to throw everything in the same repo and give the
>> user/installer a choice of how 'well-tested' something should be before
>> installing it?  Preferably with a sliding scale instead of just 2
>> choices.  Normally on new installs and machines used explicitly for
>> testing I'd expect people to want the latest changes but become more
>> conservative on machines that are working well and used for important
>> work.  The 'well-tested' concept might have factors for age, feedback,
>> emergency overrides, etc.
> 
> This is horribly overengineered and just can't work (for the reasons Jesse
> Keating already pointed out, so I won't repeat them).

I still don't follow the reason it can't work - unless you remove or 
rename packages within the window covered, it should be possible to 
pretend newer packages don't exist and get the exactly same package set 
that an earlier updater taking everything would have.

> I think the added complexity would also confuse end users, but we don't even
> have to get that far with the discussion because it is impossible to
> implement anyway.

How about brute force with only 2 choices then?  For every visible state 
of the repository that syncs to the mirrors, make a snapshot copy that 
normally ages a month and then appears as a 'safer' repository.  In the 
abnormal case you could have a procedure to 'fix' things that turned out 
to be mistakes, or just skip letting certain instances appear at all. I 
think there should be some simpler way to get this effect by 
manipulating lists of package names, or using heuristics to ignore some 
from a repository contain the full set, but brute force could certainly 
work.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pemboa at gmail.com  Thu Dec 11 06:23:45 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 00:23:45 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>

On Thu, Dec 11, 2008 at 12:19 AM, Stephen Warren
<s-t-rhbugzilla at wwwdotorg.org> wrote:
> Arthur Pemberton wrote:
>> On Wed, Dec 10, 2008 at 11:57 PM, Stephen Warren
>> <s-t-rhbugzilla at wwwdotorg.org> wrote:
>>> Arthur Pemberton wrote:
>>>> On Wed, Dec 10, 2008 at 11:49 PM, Stephen Warren
>>>> <s-t-rhbugzilla at wwwdotorg.org> wrote:
>>>>> Kevin Kofler wrote:
>>>>>> Jesse Keating wrote:
>>>>>>> Seriously, if we could actually just focus on bugfixing for our released
>>>>>>> trees, do the new package work in rawhide (and bugfixing of the new
>>>>>>> packages there), our released trees might actually stabilize outside of
>>>>>>> the heavy handed forced freezes during development.
>>>>>> But often it's impossible to fix some bugs without a version upgrade. For
>>>>>> example, the upgrade to KDE 4.1 in F9 fixed many bugs in 4.0.
>>>>> That's an argument for not having introduced the alpha/beta-quality
>>>>> release KDE 4.0 into Fedora in the first place.
>>>> And that's an arguement for turning Fedora into something useless.
>>> What, usable software is useless? You can't possibly argue that KDE 4.0
>>> was a good choice given the need to replace it with 4.1 so quickly.
>>
>>
>> First of all, these kind of discussions piss me off a bit, so if I
>> fail to be clear on something let me know and I will try to reexplain.
>>
>> I never send usable software is useless. I said changing Fedora in
>> that way would make Fedora useless. There would be no meaningful
>> differentiation between Fedora and other popular distros, and that
>> would render it entirely useless to the myself, and I would argue, the
>> Linux community. I see very little between what is being suggesting
>> and making Fedora "like Ubuntu". The community already has a "like
>> Ubuntu".
>
> So, if the idea of Fedora's differentiation is to keep throwing the
> latest stuff into the latest non-devel release essentially in order to
> always have the latest stuff, or close to it, what is the point of
> having releases - why not just have a completely rolling distro?

This is a non issue to me.

> Alternatively (to a rolling distro), we could increase the frequency of
> Fedora releases. It seems that the main reason people want the latest
> stuff thrown into Fedora $latest is because they don't want to wait for
> the next release in just 3 months time on average.


You keep saying this. Aren't the releases every 6 months?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 06:25:41 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 23:25:41 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqb66$brb$5@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>
	<ghqb66$brb$5@ger.gmane.org>
Message-ID: <1228976734.18757.TMDA@tmda.severn.wwwdotorg.org>

Kevin Kofler wrote:
> Stephen Warren wrote:
> 
>> Horst H. von Brand wrote:
>>
>>> And presumably you (and everybody else) would wait out the "until known
>>> good" period; and as nobody tried it before, get to keep the pieces of
>>> the resulting breakage...
>> If that is true, then it would mean there's nobody who wants bleeding
>> edge. That in turn would mean that Fedora should be redefined to not be
>> bleeding edge, because nobody wants it that way...
> 
> The problem is that users are asking for contradictory/impossible things:
> they want new versions as soon as possible, i.e. the day upstream releases
> them, but also updates tested for weeks.

> Fedora currently has a good
> compromise (new versions normally get 1-2 weeks of testing, and major
> changes known to break things are only pushed to Rawhide),

In theory. However, does anything/one enforce that? I guess it'd be
difficult to do that programatically in Bodhi. Is this theory emphasized
enough to maintainers? I don't remember reading that it should work this
way, although it's been a while since I read the packaging wiki thoroughly.

I'm sure there are plenty updates that have gone straight to devel, F
$lastest, F $latest-1 at the same time.

> people who need
> something more conservative should be using a more conservative
> distribution.
> 
> And there's also a Prisoner's Dilemma problem here: users moving to the
> conservative update stream => fewer testers for updates-testing and updates
> => more breakage => more users moving to the conservative update stream and
> the vicious circle is complete.
> 
>         Kevin Kofler
> 



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 06:31:31 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 23:31:31 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
Message-ID: <1228977085.18890.TMDA@tmda.severn.wwwdotorg.org>

Arthur Pemberton wrote:
>> Alternatively (to a rolling distro), we could increase the frequency of
>> Fedora releases. It seems that the main reason people want the latest
>> stuff thrown into Fedora $latest is because they don't want to wait for
>> the next release in just 3 months time on average.
> 
> You keep saying this. Aren't the releases every 6 months?

I think I only said it once before, but anyway.

If releases are every 6 months (as they are, yes), then assuming a
uniform distribution of when some new software comes out[1] or some user
decides they want some new feature in some software and is the first to
desire the new feature and request an upgrade, then they'll request the
upgrade equally spread throughout the 6 month duration between releases,
and hence on average only be 3 months from the next release.

[1] This may not apply to major packages, which might be roughly
synchronized with Fedora releases (or Fedora might sync to them).
However, I'm guessing the vast majority of Fedora packages are much
smaller self-contained apps without such a sync'd release cycle.



From kevin.kofler at chello.at  Thu Dec 11 06:31:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 07:31:47 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
Message-ID: <ghqc4j$brb$11@ger.gmane.org>

Arthur Pemberton wrote:

> On Thu, Dec 11, 2008 at 12:19 AM, Stephen Warren
>
>> Alternatively (to a rolling distro), we could increase the frequency of
>> Fedora releases. It seems that the main reason people want the latest
>> stuff thrown into Fedora $latest is because they don't want to wait for
>> the next release in just 3 months time on average.
> 
> You keep saying this. Aren't the releases every 6 months?

Releases every 6 months => the wait is 6/2=3 months on average, 6 months
worst case (and I'd argue the worst case is what really counts here).

        Kevin Kofler



From kevin.kofler at chello.at  Thu Dec 11 06:25:26 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 07:25:26 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <ghqbom$brb$9@ger.gmane.org>

Stephen Warren wrote:
> Alternatively (to a rolling distro), we could increase the frequency of
> Fedora releases. It seems that the main reason people want the latest
> stuff thrown into Fedora $latest is because they don't want to wait for
> the next release in just 3 months time on average. So, make "the next
> release" happen every 3, or 2, or 1 months (-> wait is 1.5, 1, 0.5
> months average). I don't know about capacity-wise, but the Fedora
> infra-structure certainly seems to have the logic in place now for
> managing arbitrary numbers of current releases.

That's not really feasible, it would be a lot more work to maintain and
require a lot more bandwidth and disk space for mirrors. And it wouldn't
bring any benefits over the current system.

As for a rolling release model, that may be more feasible, but again what
are the benefits over the current model? And it'd have the major drawback
that users could no longer decide on their own when to upgrade e.g. to KDE
4 (for which right now they have a window of ~7 months).

        Kevin Kofler



From bbaetz at acm.org  Thu Dec 11 06:39:39 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 11 Dec 2008 17:39:39 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq7vu$5to$5@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org>
Message-ID: <ghqcjc$iea$1@ger.gmane.org>

Kevin Kofler wrote:
> Bradley Baetz wrote:
>> Can someone who wants the new versions immediately explain why they
>> don't want to wait an average of 3 months for the next fedora release?
> 
> Because if you need the bugfix or the new feature now, any wait is too long.

Why is waiting for a new feature for 3 months too long? Excluding 
support for new hardware, if you want a bleeding edge feature run rawhide.

Note that I'm *NOT* objecting to bugfixes, or new packages, or trying to 
force maintainers to backport individual fixes.

> Also because you'll then also get those major changes which were
> intentionally not pushed as updates to that release, e.g. KDE 4 for Fedora
> 9, kdepim 4, Amarok 2, digiKam 0.10 and Krusader 2 for Fedora 10, probably
> KOffice 2 for Fedora 11.

So you want the latest and greatest new version, as long as its not too new?

> And because if you don't want new versions, you can use CentOS or Debian
> stable or Ubuntu or openSUSE or any other distribution which does not push
> version updates to releases. Why take away Fedora's unique selling point?
> If you don't like the way Fedora works, you should be using another
> distribution, not trying to strong-arm Fedora into working the way you
> want.

There's a difference between pushing new versions that fix bugs, and 
pushing them the day after an upstream release to stable and rawhide 
simultaneously, with a comment of 'new version'.

I enable updates-testing on occasion, and test updates, and file bugs. 
But I do that knowing that stuff has a higher risk of breaking, and its 
my choice. Similarly, when I upgrade from F9 to F10 I expect something 
won't work right (whether or not that's a good thing is a different 
question that I don't want to get into).

I don't think its unreasonable for a user, once they've installed a 
distribution, to keep using it and its stable updates without wireless 
breaking (multiple times), printers to stop working, NM to stop working, 
or gphoto to stop talking to my camera.

None of those are hypothetical, BTW. And yes, I filed bugs, bisected 
upstream git trees, and supplied patches, but I shouldn't have to wonder 
what each stable push will break - if I wanted that I'd use rawhide. 
Yes, finding and fixing those bugs in F9 meant that the bug wasn't in 
F10, but to a user who just wants to Get Stuff Done and isn't going to 
upgrade to F10 on release day, thats not a positive.

My point is that every update may fix things, but it may also break 
things. There's a risk/reward tradeoff that is different for different 
packages and maybe there's a sample bias too (ie we only see the 
packages that go out when they break stuff, and never have several 
hundred post threads about packages that are held back for rawhide).

Bradley



From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 06:42:27 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Dec 2008 23:42:27 -0700
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqbom$brb$9@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<ghqbom$brb$9@ger.gmane.org>
Message-ID: <1228977740.19197.TMDA@tmda.severn.wwwdotorg.org>

Kevin Kofler wrote:
> Stephen Warren wrote:
>> Alternatively (to a rolling distro), we could increase the frequency of
>> Fedora releases. It seems that the main reason people want the latest
>> stuff thrown into Fedora $latest is because they don't want to wait for
>> the next release in just 3 months time on average. So, make "the next
>> release" happen every 3, or 2, or 1 months (-> wait is 1.5, 1, 0.5
>> months average). I don't know about capacity-wise, but the Fedora
>> infra-structure certainly seems to have the logic in place now for
>> managing arbitrary numbers of current releases.
> 
> That's not really feasible, it would be a lot more work to maintain and
> require a lot more bandwidth and disk space for mirrors. And it wouldn't
> bring any benefits over the current system.

The benefit would be waiting less time for significant package updates
(i.e. new versions for the sake of new features, or significant new
versions for the sake of bugfixes) if Fedora had a policy that each
release should be somewhat stable during its lifetime, and updates in a
release should be minimal/stable/...

> As for a rolling release model, that may be more feasible, but again what
> are the benefits over the current model? And it'd have the major drawback
> that users could no longer decide on their own when to upgrade e.g. to KDE
> 4 (for which right now they have a window of ~7 months).

I didn't propose that so much because it had benefits, but more because
if maintainers are free to (and even encouraged, because Fedora is
bleeding edge, and that's what it takes to be bleeding edge) to keep F
$latest updated with the latest releases of some/most/all software, then
we essentially already have a rolling release (it just gets renamed F8,
F9, F10 every 6 months), so why not just be explicit/honest about it.



From nicu_fedora at nicubunu.ro  Thu Dec 11 06:52:14 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 11 Dec 2008 08:52:14 +0200
Subject: Installing from Live CD is the new black?
In-Reply-To: <1228955078.3037.10.camel@fecusia>
References: <1228955078.3037.10.camel@fecusia>
Message-ID: <4940B89E.8050400@nicubunu.ro>

Linus Walleij wrote:
> Is it just me or doesn't everybody make their installs off the Live CD
> these days?

I still prefer the install DVD, it has so much applications I need which 
are not available on the Live CD and I prefer the install to be fast 
(not waiting for important large packages to be downloaded durinr or 
after the install).

> The ordinary installer CD:s don't work at all for me on this system
> (they don't even load Anaconda, some low-level problem after boot).

At F9 they worked.

> And I cannot switch to say harddisk or netinstall either, none of that
> works as it should.

I had troubles with the hard disk install too for F10, I wanted to 
perform the install without burning a DVD but it refused to play.

-- 
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 lesmikesell at gmail.com  Thu Dec 11 06:54:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 00:54:34 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqc4j$brb$11@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org>
Message-ID: <4940B92A.1030403@gmail.com>

Kevin Kofler wrote:
> Arthur Pemberton wrote:
> 
>> On Thu, Dec 11, 2008 at 12:19 AM, Stephen Warren
>>
>>> Alternatively (to a rolling distro), we could increase the frequency of
>>> Fedora releases. It seems that the main reason people want the latest
>>> stuff thrown into Fedora $latest is because they don't want to wait for
>>> the next release in just 3 months time on average.
>> You keep saying this. Aren't the releases every 6 months?
> 
> Releases every 6 months => the wait is 6/2=3 months on average, 6 months
> worst case (and I'd argue the worst case is what really counts here).

And yet, you suggest the only alternative to the too-fast push is to 
switch to RHEL or Centos.  What's that do to your worst case if you 
think 6 months is too long?

-- 
   Les Mikesell
     lesmikesell at gmail.com




From pemboa at gmail.com  Thu Dec 11 06:56:23 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 00:56:23 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqcjc$iea$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org> <ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org>
Message-ID: <16de708d0812102256s742daabn825d281f965bf001@mail.gmail.com>

On Thu, Dec 11, 2008 at 12:39 AM, Bradley Baetz <bbaetz at acm.org> wrote:
> Kevin Kofler wrote:
>>
>> Bradley Baetz wrote:
>>>
>>> Can someone who wants the new versions immediately explain why they
>>> don't want to wait an average of 3 months for the next fedora release?
>>
>> Because if you need the bugfix or the new feature now, any wait is too
>> long.
>
> Why is waiting for a new feature for 3 months too long? Excluding support
> for new hardware, if you want a bleeding edge feature run rawhide.

I would definitely say that waiting 6 months (I don't agree with this
lowball of 3 months) is too long for new and useful software. Taking
the example of OpenOffice, my windows machine has a more up to date
version of OO.org than my Fedora machines. I find this weird and
unfortunate.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From nicolas.mailhot at laposte.net  Thu Dec 11 06:56:18 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Dec 2008 07:56:18 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq81g$98v$1@ger.gmane.org>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<20081211011210.GB2883@yoda.jdub.homelinux.org>
	<ghq81g$98v$1@ger.gmane.org>
Message-ID: <1228978578.5538.0.camel@arekh.okg>

Hi,

The problem with those numbers is they don't count packages that are
updated several times in a release life.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/18c2cf9e/attachment.sig>

From kevin.kofler at chello.at  Thu Dec 11 06:59:10 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 07:59:10 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<ghqbom$brb$9@ger.gmane.org>
	<1228977740.19197.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <ghqdnu$k67$1@ger.gmane.org>

Stephen Warren wrote:

> Kevin Kofler wrote:
>> 
>> That's not really feasible, it would be a lot more work to maintain and
>> require a lot more bandwidth and disk space for mirrors. And it wouldn't
>> bring any benefits over the current system.
> 
> The benefit would be waiting less time for significant package updates
> (i.e. new versions for the sake of new features, or significant new
> versions for the sake of bugfixes) if Fedora had a policy that each
> release should be somewhat stable during its lifetime, and updates in a
> release should be minimal/stable/...

But the _current_ system does _not_ have such a policy, so you'd be solving
a problem you introduced yourself.

>> As for a rolling release model, that may be more feasible, but again what
>> are the benefits over the current model? And it'd have the major drawback
>> that users could no longer decide on their own when to upgrade e.g. to
>> KDE 4 (for which right now they have a window of ~7 months).
> 
> I didn't propose that so much because it had benefits, but more because
> if maintainers are free to (and even encouraged, because Fedora is
> bleeding edge, and that's what it takes to be bleeding edge) to keep F
> $latest updated with the latest releases of some/most/all software, then
> we essentially already have a rolling release (it just gets renamed F8,
> F9, F10 every 6 months), so why not just be explicit/honest about it.

We don't already have a rolling release. The policy is clear: if it breaks
things, keep it to Rawhide, otherwise, push to testing and once it's
confirmed not to cause trouble push to stable. (If you think that's not
clear enough, it should be made so.) But these decisions are at the
maintainer's discretion, because those are the ones who best know what
breaks things and what doesn't. (In particular, I don't think we should be
definining "breaks things", it's a matter of common sense.) Forcing an
inflexible policy would cause more problems than it would solve. There are
exceptions to every rule.

        Kevin Kofler



From pemboa at gmail.com  Thu Dec 11 06:59:38 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 00:59:38 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228978578.5538.0.camel@arekh.okg>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org>
	<20081211011210.GB2883@yoda.jdub.homelinux.org>
	<ghq81g$98v$1@ger.gmane.org> <1228978578.5538.0.camel@arekh.okg>
Message-ID: <16de708d0812102259x4d449ad7mdc4e6e2bfc4f6162@mail.gmail.com>

2008/12/11 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> Hi,
>
> The problem with those numbers is they don't count packages that are
> updated several times in a release life.


However, a lot of the very useful packages do not see major updates
within a release life.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From bbaetz at acm.org  Thu Dec 11 07:07:22 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 11 Dec 2008 18:07:22 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228978578.5538.0.camel@arekh.okg>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>	<20081211011210.GB2883@yoda.jdub.homelinux.org>	<ghq81g$98v$1@ger.gmane.org>
	<1228978578.5538.0.camel@arekh.okg>
Message-ID: <ghqe7b$lu5$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Hi,
> 
> The problem with those numbers is they don't count packages that are
> updated several times in a release life.

True, but repodiff was simple to modify, and I don't think that bodhi 
exposes that info.

Like I said, its a heuristic.

Bradley



From lesmikesell at gmail.com  Thu Dec 11 07:09:45 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 01:09:45 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqb66$brb$5@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>
	<ghqb66$brb$5@ger.gmane.org>
Message-ID: <4940BCB9.9070408@gmail.com>

Kevin Kofler wrote:
>
>>> And presumably you (and everybody else) would wait out the "until known
>>> good" period; and as nobody tried it before, get to keep the pieces of
>>> the resulting breakage...
>> If that is true, then it would mean there's nobody who wants bleeding
>> edge. That in turn would mean that Fedora should be redefined to not be
>> bleeding edge, because nobody wants it that way...
> 
> The problem is that users are asking for contradictory/impossible things:
> they want new versions as soon as possible, i.e. the day upstream releases
> them, but also updates tested for weeks.

That's only contradictory because you make it so. In the lifespan of a 
fedora package, it will exist as a barely-tested release or feature 
update, perhaps quickly followed by many updates with needed fixes, then 
aging into being mostly well-tested code. But by bundling all the 
packages together in rolling updates you make it impossible to avoid the 
  barely-tested instances on machines where you can't risk them even 
though they may only have a short lifespan.

 > Fedora currently has a good
> compromise (new versions normally get 1-2 weeks of testing, and major
> changes known to break things are only pushed to Rawhide), people who need
> something more conservative should be using a more conservative
> distribution.

Can you back that up with statistics that show your initial package 
releases to updates rarely need fixes?

> And there's also a Prisoner's Dilemma problem here: users moving to the
> conservative update stream => fewer testers for updates-testing and updates
> => more breakage => more users moving to the conservative update stream and
> the vicious circle is complete.

I think you have that completely backwards.  If I had some reason to 
think that tomorrow's update wouldn't crash my machine or lose access to 
some of my devices, I'd run fedora on a lot more machines, and I'd run 
at least one for testing things as soon as possible.  And I'd expect the 
same from others.  That is, if you can make it possible to get either 
just-released or aged/tested packages out of the repo, you'll get more 
of both kinds of users.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From bbaetz at acm.org  Thu Dec 11 07:17:01 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 11 Dec 2008 18:17:01 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812102256s742daabn825d281f965bf001@mail.gmail.com>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org>	<ghqcjc$iea$1@ger.gmane.org>
	<16de708d0812102256s742daabn825d281f965bf001@mail.gmail.com>
Message-ID: <ghqepe$n8v$1@ger.gmane.org>

Arthur Pemberton wrote:

> I would definitely say that waiting 6 months (I don't agree with this
> lowball of 3 months) is too long for new and useful software. Taking
> the example of OpenOffice, my windows machine has a more up to date
> version of OO.org than my Fedora machines. I find this weird and
> unfortunate.

But what, specifically, were you missing?

Personally, one of the reasons I upgraded to F10 before it was released 
was for office2007 support in openoffice 3. (I wish it wasn't, but....)

I've been using RH (and now fedora) as my main OS since version 
5.<mumble> and I'm having trouble thinking of more than one or two 
features that I really wanted ASAP. Maybe I'm not adventurous enough? ;)

Bradley



From pemboa at gmail.com  Thu Dec 11 07:28:54 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 01:28:54 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqepe$n8v$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org> <ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org>
	<16de708d0812102256s742daabn825d281f965bf001@mail.gmail.com>
	<ghqepe$n8v$1@ger.gmane.org>
Message-ID: <16de708d0812102328o4d6f459apa84eb3246335d850@mail.gmail.com>

On Thu, Dec 11, 2008 at 1:17 AM, Bradley Baetz <bbaetz at acm.org> wrote:
> Arthur Pemberton wrote:
>
>> I would definitely say that waiting 6 months (I don't agree with this
>> lowball of 3 months) is too long for new and useful software. Taking
>> the example of OpenOffice, my windows machine has a more up to date
>> version of OO.org than my Fedora machines. I find this weird and
>> unfortunate.
>
> But what, specifically, were you missing?
>
> Personally, one of the reasons I upgraded to F10 before it was released was
> for office2007 support in openoffice 3. (I wish it wasn't, but....)
>
> I've been using RH (and now fedora) as my main OS since version 5.<mumble>
> and I'm having trouble thinking of more than one or two features that I
> really wanted ASAP. Maybe I'm not adventurous enough? ;)
>
> Bradley


I also use Fedora as my primary OS, and seeing as most OSS software
brings new features and bug fixes with each release, what's not to
want with a new update? Shouldn't one be able to stay within the
package management system and be as up to date with Windows/Mac
software where packages are manually downloaded?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From kevin.kofler at chello.at  Thu Dec 11 07:35:49 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 08:35:49 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org> <ghqcjc$iea$1@ger.gmane.org>
Message-ID: <ghqfsl$pnm$1@ger.gmane.org>

Bradley Baetz wrote:
> Why is waiting for a new feature for 3 months too long?

Because the user has work to do which requires the new feature.

> Excluding support for new hardware, if you want a bleeding edge feature
> run rawhide. 

If you want a conservative distro, run CentOS.

>> Also because you'll then also get those major changes which were
>> intentionally not pushed as updates to that release, e.g. KDE 4 for
>> Fedora 9, kdepim 4, Amarok 2, digiKam 0.10 and Krusader 2 for Fedora 10,
>> probably KOffice 2 for Fedora 11.
> 
> So you want the latest and greatest new version, as long as its not too
> new?

I want the latest and greatest new version, as long as it:
* understands all the configuration settings from the previous version,
* does not remove any features (or render them so buggy as to make them
effectively useless) from the previous version.
(Those are the criteria for applications, for libraries there's of course
also: the soname either stays the same or all the dependent packages get
rebuilt. Updates which break dependencies are a no-go.)

In the case of KDE, upgrades of the N.n -> N.n+1 type (e.g. 4.0->4.1)
basically fit that description, upgrades of the N.n->N+1.m type (e.g.
3.5->4.0) don't. I don't know how it is for other packages, but that's
precisely why this has to be the maintainer's call, they are the ones who
know such things best.

Major rewrites should only go into new Fedora releases, but I don't see "add
feature X" type upgrades as a problem.

> There's a difference between pushing new versions that fix bugs, and
> pushing them the day after an upstream release to stable and rawhide
> simultaneously, with a comment of 'new version'.

Well, I agree with you on this point:
* Updates should contain a description of:
- what's new (a link to the upstream changelog will do, or the maintainer
can sum up the changes him/herself) and
- where not immediately obvious ("This bugfix release was pushed to fix the
bugs in the previous release.", duh), why the update is being pushed
(e.g. "new version of libfoo needed for the latest bugfix version of bar").
* If the update fixes a bug filed in Fedora, the Bugzilla reference should
be present.
* Non-critical, non-trivial updates (and in most cases version upgrades are
neither critical nor trivial, but there are exceptions) should stay in
updates-testing for at least a week.

I'm completely OK with enforcing the above rules (though it should be the
maintainer's call to decide what's critical or trivial, so I don't think
that particular rule can be enforced, it should just be made clear to the
maintainers; descriptive update comments _are_ enforceable though), but
they are a very far cry from banning version updates entirely!

> I don't think its unreasonable for a user, once they've installed a
> distribution, to keep using it and its stable updates without wireless
> breaking (multiple times), printers to stop working, NM to stop working,
> or gphoto to stop talking to my camera.

That sucks indeed. One of the issues is that the kernel updates usually get
pushed even if they have a lot of negative feedback for common hardware
like iwl4965. Maybe something can be done there. But then it becomes an act
of balancing the hardware for which the kernel fixes things vs. the
hardware for which it breaks things.

On the other hand, while regressions tend to annoy users a lot (I know I
hate them), objectively considered, a regression is not as bad as an
unfixed bug, because one can always revert to the working version, whereas
for an unfixed bug, there's no working version to revert to. Imagine the
broken kernel was the one in the release: would you be happy if you had
broken wireless for the entire lifetime of that Fedora release? (And there
were several examples of issues with some hardware in the release kernel
which were fixed by one of the updates.)

> My point is that every update may fix things, but it may also break
> things. There's a risk/reward tradeoff that is different for different
> packages and maybe there's a sample bias too (ie we only see the
> packages that go out when they break stuff, and never have several
> hundred post threads about packages that are held back for rawhide).

If we started holding back packages where there is no obvious reason to,
there might be a lot more such threads. I remember the "Where is KDE 3.5?"
thread in the FC4 times, just because Than didn't push out the upgrade
right away (he eventually did). There were also plenty of "Where is KDE
4.1?" threads when the update was delayed first because we found some
issues during testing which we had to fix (because in KDE SIG we *don't*
push out known-broken updates!) and then because of the infrastructure
breakdown due to the intrusion.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Dec 11 07:38:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 08:38:37 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
Message-ID: <ghqg1t$pnm$2@ger.gmane.org>

Les Mikesell wrote:
> And yet, you suggest the only alternative to the too-fast push is to
> switch to RHEL or Centos.  What's that do to your worst case if you
> think 6 months is too long?

You have to decide: do you want updates or do you not want them? If you
don't want to wait for the next CentOS release, then obviously you need the
update quickly, so you are in Fedora's target base. But then you can't
complain that you get updates too quickly! You can't have both ways.
(You're one of those users with contradictory requirements I mentioned
elsewhere in this thread.)

        Kevin Kofler



From bbaetz at acm.org  Thu Dec 11 07:51:24 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 11 Dec 2008 18:51:24 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812102328o4d6f459apa84eb3246335d850@mail.gmail.com>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org>	<ghqcjc$iea$1@ger.gmane.org>	<16de708d0812102256s742daabn825d281f965bf001@mail.gmail.com>	<ghqepe$n8v$1@ger.gmane.org>
	<16de708d0812102328o4d6f459apa84eb3246335d850@mail.gmail.com>
Message-ID: <ghqgpt$rup$1@ger.gmane.org>

Arthur Pemberton wrote:
> On Thu, Dec 11, 2008 at 1:17 AM, Bradley Baetz <bbaetz at acm.org> wrote:
>> But what, specifically, were you missing?
> 
> I also use Fedora as my primary OS, and seeing as most OSS software
> brings new features and bug fixes with each release, what's not to
> want with a new update?

The pain of breaking something that was already working as part of 
getting security and other critical bugfixes?

Again, I agree that one of Fedora's strengths is the ability to deliver 
new features and bug fixes to existing releases. I'm just saying that 
the risks mean that there needs to be a reason apart from the fact that 
there *are* new features to push an update.

> Shouldn't one be able to stay within the
> package management system and be as up to date with Windows/Mac
> software where packages are manually downloaded?

I guess that depends on whether you consider Fedora to be a distribution 
method for a collection of separate packages, which are all able to be 
updated to the latest and greatest, or if you consider it as a product 
that, as an implementation detail, happens to contain lots of separate 
projects' work.

Fedora-the-product has a set of features. Some of its components get new 
features upstream, and then Fedora-the-product+1 gets those too. 
Fedora-the-packageset has a lot of packages that are always able to be 
updated, and Fedora-the-packageset+1 is published in a more convenient 
form that the previous version+updates, with new features that were 
mostly omitted from updates for logistical reasons.

Of course, reality is somewhere in between the two.

Bradley



From lesmikesell at gmail.com  Thu Dec 11 08:12:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 02:12:59 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqg1t$pnm$2@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>	<ghqc4j$brb$11@ger.gmane.org>
	<4940B92A.1030403@gmail.com> <ghqg1t$pnm$2@ger.gmane.org>
Message-ID: <4940CB8B.4060107@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> And yet, you suggest the only alternative to the too-fast push is to
>> switch to RHEL or Centos.  What's that do to your worst case if you
>> think 6 months is too long?
> 
> You have to decide: do you want updates or do you not want them?

I would want them if I had some reason to believe they wouldn't break my 
machine.  But I have my reasons to not believe that.

> If you
> don't want to wait for the next CentOS release, then obviously you need the
> update quickly, so you are in Fedora's target base. But then you can't
> complain that you get updates too quickly!

I'd still complain when it breaks.

 > You can't have both ways.

Why not?  Most of the time it isn't broken.  Why isn't there a way to 
avoid the times when it is on the machines where you care?

> (You're one of those users with contradictory requirements I mentioned
> elsewhere in this thread.)

I think most people would prefer that certain machines never break - and 
many would be willing to test on a less critical machine if exactly what 
they tested would later be reproduced on their more important machines, 
but with random rolling updates it doesn't work.

-- 
   Les Mikeell
    lesmikesell at gmail.com



From bbaetz at acm.org  Thu Dec 11 08:25:48 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 11 Dec 2008 19:25:48 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqfsl$pnm$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>	<ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org> <ghqfsl$pnm$1@ger.gmane.org>
Message-ID: <ghqiqd$1h2$1@ger.gmane.org>

Kevin Kofler wrote:
> Bradley Baetz wrote:
>> Why is waiting for a new feature for 3 months too long?
> 
> Because the user has work to do which requires the new feature.

Sometimes, sure. But (again excluding new hardware) how often does that 
happen?

>> Excluding support for new hardware, if you want a bleeding edge feature
>> run rawhide. 
> 
> If you want a conservative distro, run CentOS.

Theres a difference between a conservative distro that only enables 
tried and tested features and brings releases every 18 months and a 
distro like fedora that adds new bleeding edge features and does 
frequent releases.

But the difference that I'm talking about is the difference between what 
happens during a particular release. If the only difference between a 
stable release and rawhide is for application rewrites, then all users 
miss out.

I use Fedora because of the first part, but I'm going overseas in a few 
days and don't plan to upgrade my laptop until I stop travelling because 
of the second.

> I want the latest and greatest new version, as long as it:
> * understands all the configuration settings from the previous version,
> * does not remove any features (or render them so buggy as to make them
> effectively useless) from the previous version.

But how do you know that its buggy? updates-testing helps, but some bugs 
aren't immediately visible, or only happen in certain cases.

> In the case of KDE, upgrades of the N.n -> N.n+1 type (e.g. 4.0->4.1)
> basically fit that description, upgrades of the N.n->N+1.m type (e.g.
> 3.5->4.0) don't. I don't know how it is for other packages, but that's
> precisely why this has to be the maintainer's call, they are the ones who
> know such things best.

I don't use KDE, but KDE is a bit different in that its a collection of 
programs that are pushed as a set, which isn't the regular situation.

> Major rewrites should only go into new Fedora releases, but I don't see "add
> feature X" type upgrades as a problem.

The problem is that very few features are standalone and no risk. I'm 
not suggesting that Fedora says 'no version updates in stable releases', 
I'm just saying that package maintainers should think about the 
potential risks a bit more.

>> I don't think its unreasonable for a user, once they've installed a
>> distribution, to keep using it and its stable updates without wireless
>> breaking (multiple times), printers to stop working, NM to stop working,
>> or gphoto to stop talking to my camera.
> 
> That sucks indeed. One of the issues is that the kernel updates usually get
> pushed even if they have a lot of negative feedback for common hardware
> like iwl4965. Maybe something can be done there. But then it becomes an act
> of balancing the hardware for which the kernel fixes things vs. the
> hardware for which it breaks things.

Sure, but the maintainer can't balance the hardware thats fixed vs the 
hardware thats broken because the maintainer doesn't *know* which 
hardware will be broken by an update.

(Although some of my examples were caused when new hardware support was 
added, I did exclude hardware support from a 'feature' earlier)

> On the other hand, while regressions tend to annoy users a lot (I know I
> hate them), objectively considered, a regression is not as bad as an
> unfixed bug, because one can always revert to the working version, whereas
> for an unfixed bug, there's no working version to revert to. Imagine the
> broken kernel was the one in the release: would you be happy if you had
> broken wireless for the entire lifetime of that Fedora release? (And there
> were several examples of issues with some hardware in the release kernel
> which were fixed by one of the updates.)

Sure, and my wireless was broken in an F8 update and for the initial F9 
release and fixed in an update. (Then broken again, and so I was running 
an older kernel for a very long time)

gphoto in F9 doesn't work with some canon cameras (and I just looked and 
there never was a fixed package pushed to stable, so its still broken in 
F9...).

Yes, there is the choice to run an older version, but I'm not sure that 
its a good choice. Its hard to downgrade since the updates are pulled, 
and there are sometimes flow-on dependancies.

> 
>> My point is that every update may fix things, but it may also break
>> things. There's a risk/reward tradeoff that is different for different
>> packages and maybe there's a sample bias too (ie we only see the
>> packages that go out when they break stuff, and never have several
>> hundred post threads about packages that are held back for rawhide).
> 
> If we started holding back packages where there is no obvious reason to,
> there might be a lot more such threads.

Possibly more threads, but how many people wanted KDE4.1 because it was 
the latest available, and how many had a specific bug or feature that 
they wanted fixed?

Bradley



From hughsient at gmail.com  Thu Dec 11 09:40:36 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 11 Dec 2008 09:40:36 +0000
Subject: Making updates-testing more useful
In-Reply-To: <1228931001.10235.55.camel@hughsie-work.lan>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228931001.10235.55.camel@hughsie-work.lan>
Message-ID: <1228988436.3378.6.camel@hughsie-work.lan>

On Wed, 2008-12-10 at 17:43 +0000, Richard Hughes wrote:
> Also, this would imply automatically turning on updates-testing,
> downloading metadata, and disabling updates-testing all behind the
> users back. A few people might get upset by this.

I've been prototyping something like this, but it doesn't seem to work:

    repos = self.yumbase.repos.repos.values()
    repos_enabled = []
    repos_disabled = []

    pkgs = []
    yb._up = None
    ygl = yb.doPackageLists(pkgnarrow='updates')
    pkgs.extend(ygl.updates)
    ygl = yb.doPackageLists(pkgnarrow='obsoletes')
    pkgs.extend(ygl.obsoletes)

    print pkgs

    for repo in repos:
        if repo.id.endswith('testing'):
            if not repo.isEnabled():
                repo.enablePersistent()
                repos_enabled.append(repo)
        else:
            if repo.isEnabled():
                repo.disablePersistent()
                repos_disabled.append(repo)

    pkgs = []
    yb._up = None
    ygl = yb.doPackageLists(pkgnarrow='updates')
    pkgs.extend(ygl.updates)
    ygl = yb.doPackageLists(pkgnarrow='obsoletes')
    pkgs.extend(ygl.obsoletes)

    print pkgs

    for repo in repos_enabled:
        repo.disablePersistent()
    for repo in repos_disabled:
        repo.enablePersistent()

I'm already clearing the update list by doing "yb._up = None", but I
can't seem to get the "testing" updates in the second pass. Any ideas?

Richard.




From opensource at till.name  Thu Dec 11 10:14:49 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 11:14:49 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4940827E.5000508@ioa.s.u-tokyo.ac.jp>
References: <1228849604.30987.31.camel@code.and.org>
	<20081211010610.GA2883@yoda.jdub.homelinux.org>
	<4940827E.5000508@ioa.s.u-tokyo.ac.jp>
Message-ID: <200812111114.59335.opensource@till.name>

On Thu December 11 2008, Mamoru Tasaka wrote:
> Josh Boyer wrote, at 12/11/2008 10:06 AM +9:00:

> > I don't know why that happened.  My best guess would be something like:
> > "An update was staged and then something happened that caused a newer
> > package to be pulled into the final release.  The maintainer forgot
> > about the pending update."
>
> For kazehakase (maintained by me)
> - When F-10 tree was frozen the EVR tagged as f10-final was
>   kazehakase-0.5.5-1.fc9.1
> - I submitted 0.5.6-1.fc10 updates on 2008-11-05
> - After that xulrunner was upgraded to 1.9.0.4-1.fc10 on
>   2008-11-12, kazehakase was rebuilt by gecko maintainers
>   and both are tagged as f10-final on 2008-11-17.
> - My updates submit was left as it was... (I have to pull it down?)

Here is a ticket for this:
https://fedorahosted.org/bodhi/ticket/274

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/3a14932e/attachment.sig>

From rc040203 at freenet.de  Thu Dec 11 10:57:49 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 11 Dec 2008 11:57:49 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqiqd$1h2$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org> <ghqcjc$iea$1@ger.gmane.org>
	<ghqfsl$pnm$1@ger.gmane.org>  <ghqiqd$1h2$1@ger.gmane.org>
Message-ID: <1228993069.3394.841.camel@beck.corsepiu.local>

On Thu, 2008-12-11 at 19:25 +1100, Bradley Baetz wrote:
> Kevin Kofler wrote:
> > Bradley Baetz wrote:
> >> Why is waiting for a new feature for 3 months too long?
> > 
> > Because the user has work to do which requires the new feature.
> 
> Sometimes, sure. But (again excluding new hardware) how often does that 
> happen?
More often than you might think. 

More precisely, as a developer, to me, this is the #1 motivation to use
Fedora. Otherwise, I could use a different distro.

As a participant in Fedora, other almost equally important aspects comes
into play: Tayloring the distro to meet my personal demands and having a
possibilities fix bugs quickly.

Having to wait for "at average 3 months", would widely waste these
aspects and render Fedora non-interesting to me.

Ralf
 





From aph at redhat.com  Thu Dec 11 11:05:40 2008
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Dec 2008 11:05:40 +0000
Subject: Any chance of seeing GCC UPC in Fedora?
In-Reply-To: <20081210213448.GZ17496@tyan-ft48-01.lab.bos.redhat.com>
References: <49402CC6.6060006@cora.nwra.com>	<200812101323.59921.konrad@tylerc.org>
	<20081210213448.GZ17496@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <4940F404.8080505@redhat.com>

Jakub Jelinek wrote:
> On Wed, Dec 10, 2008 at 01:23:59PM -0800, Conrad Meyer wrote:
>> On Wednesday 10 December 2008 12:55:34 pm Orion Poplawski wrote:
>>> Any chance of seeing the GCC UPC compiler in Fedora?  Could it be its
>>> own package even though it's basically a patch on top of GCC?
>> Is there any reason not to provide it as part of GCC given that it simply 
>> extends the functionality of GCC (adds another language frontend)? Does 
> 
> Yes, very important reason.  From what I see, it has been ported to GCC
> 4.2.x and 3.4.x, that's not sufficient for Fedora, where we'll soon be
> switching to GCC 4.4.x.
> 
>> upstream plan to get its patches included in GCC upstream?
> 
> Unless they actually get them incorporated into upstream GCC, they won't
> be in Fedora primary gcc packages.

Yes, this is a crazy situation.  They're condemned forever to be scrambling
to keep up with gcc unless they submit the patches upstream.

Everything I've seen in the upc/ dir is marked
"Copyright (C) XXXX  Free Software Foundation, Inc."

... so presumably thay have no objection to submitting it.

Baffled,
Andrew.



From jwboyer at gmail.com  Thu Dec 11 11:28:19 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 11 Dec 2008 06:28:19 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqe7b$lu5$1@ger.gmane.org>
References: <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org>
	<20081211011210.GB2883@yoda.jdub.homelinux.org>
	<ghq81g$98v$1@ger.gmane.org> <1228978578.5538.0.camel@arekh.okg>
	<ghqe7b$lu5$1@ger.gmane.org>
Message-ID: <20081211112819.GA3416@zod.rchland.ibm.com>

On Thu, Dec 11, 2008 at 06:07:22PM +1100, Bradley Baetz wrote:
> Nicolas Mailhot wrote:
>> Hi,
>>
>> The problem with those numbers is they don't count packages that are
>> updated several times in a release life.
>
> True, but repodiff was simple to modify, and I don't think that bodhi  
> exposes that info.
>
> Like I said, its a heuristic.

And I was after totally new packages anyway, given that someone proposed
to disallow those going into stable releaes branches via updates as a
way to lessen the updates churn.

josh



From opensource at till.name  Thu Dec 11 11:42:09 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 12:42:09 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqcjc$iea$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<ghq7vu$5to$5@ger.gmane.org> <ghqcjc$iea$1@ger.gmane.org>
Message-ID: <200812111242.15428.opensource@till.name>

On Thu December 11 2008, Bradley Baetz wrote:
> Kevin Kofler wrote:
> > Bradley Baetz wrote:
> >> Can someone who wants the new versions immediately explain why they
> >> don't want to wait an average of 3 months for the next fedora release?
> >
> > Because if you need the bugfix or the new feature now, any wait is too
> > long.
>
> Why is waiting for a new feature for 3 months too long? Excluding
> support for new hardware, if you want a bleeding edge feature run rawhide.

For me it would render my Fedora involvment in many cases useless, e.g. why 
should I push a new package into Fedora, if I have to create my own repo 
anyways to use it? Also if I get upstream to include a feature I need into an 
application I want to use, then I want to use it asap. Otherwise I would 
probably not spend much time on writing a patch or convincing upstream.

Also running rawhide is not an option, because it is way more broken than 
Fedora stable, where it seems to me the majority of updates do not break 
stuff. The worst annoyance/breakage in F8 I remember was to use a new gpg key 
for updates and glables not properly working with old glables templates. And 
there were also updates that I was missing, e.g. when I first started using 
Mercurial, it did not support symlinks. For me this is a major missing feature 
for a SCM, luckily it was already fixed upstream and the update was included 
in Fedora.

Regards,
Till




-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/e2fea20c/attachment.sig>

From kevin.kofler at chello.at  Thu Dec 11 11:45:01 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 12:45:01 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>	<ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org> <ghqfsl$pnm$1@ger.gmane.org>
	<ghqiqd$1h2$1@ger.gmane.org>
Message-ID: <ghqufu$441$1@ger.gmane.org>

Bradley Baetz wrote:
> But the difference that I'm talking about is the difference between what
> happens during a particular release. If the only difference between a
> stable release and rawhide is for application rewrites, then all users
> miss out.

That's an assertion which has to be proven.

> Sure, but the maintainer can't balance the hardware thats fixed vs the
> hardware thats broken because the maintainer doesn't *know* which
> hardware will be broken by an update.

In the case of the kernel, in most cases they did, from Bodhi comments
during testing. The updates were pushed out to stable anyway.

> Possibly more threads, but how many people wanted KDE4.1 because it was
> the latest available, and how many had a specific bug or feature that
> they wanted fixed?

In the case of 4.1, there were indeed important bugfixes and important
features added, but that just justifies our pushing it. :-)

But looking back to 3.5, the reason that one was requested back in FC4 was
mostly "because it was the latest available". 3.4 did not have issues of
the kind 4.0 did, and people were still asking for 3.5 (and got it - I
think pushing 3.5 was the plan all along, Than just didn't get around to it
faster). So this phenomenon is not specific to 4.1.

        Kevin Kofler



From opensource at till.name  Thu Dec 11 11:49:16 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 12:49:16 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqiqd$1h2$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<ghqfsl$pnm$1@ger.gmane.org> <ghqiqd$1h2$1@ger.gmane.org>
Message-ID: <200812111249.16961.opensource@till.name>

On Thu December 11 2008, Bradley Baetz wrote:

> Possibly more threads, but how many people wanted KDE4.1 because it was
> the latest available, and how many had a specific bug or feature that
> they wanted fixed?

I would bet it is the majority, because KDE 4.0 was not very stable and 
already had a lot of bugs in the upstream bugtracker, that would have annoyed 
me a lot, if I was forced to use it. I only saw it on a friends notebook. Now 
KDE 4.1 is a lot more usable, e.g. I am using it now. But e.g. it is still not 
possible to receive gpg encrypted messages with kopete, which is a major 
regression, because the alternatives are only to not use Instant messaging or 
to use a different client. Also if you look at the Fedora Bugtracker, there 
are a lot of bugs that people would like to have fixed in general, they 
probably do not really want to wait always want to wait 6 months to get it 
fixed.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/aa1aee8a/attachment.sig>

From kevin.kofler at chello.at  Thu Dec 11 12:36:29 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 13:36:29 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<ghqfsl$pnm$1@ger.gmane.org> <ghqiqd$1h2$1@ger.gmane.org>
	<200812111249.16961.opensource@till.name>
Message-ID: <ghr1gd$d8j$1@ger.gmane.org>

Till Maas wrote:
> But e.g. it is still not possible to receive gpg encrypted messages with
> kopete, which is a major regression, because the alternatives are only to
> not use Instant messaging or to use a different client.

The kopete-cryptography package which adds this was pushed out to F10
updates-testing this week. (I'll have to see if I can get it to build on
F9. It appears to require some library from kdepim 4, which is not
available in F9, so it probably won't build on F9, at least not without
some form of hackery. We'll see.)

> Also if you look at the Fedora Bugtracker, there are a lot of bugs that
> people would like to have fixed in general, they probably do not really
> want to wait always want to wait 6 months to get it fixed.

Yes, one of the big problems with strict "no new versions" policies is that
it prevents bugfixes too. Debian stable and even Ubuntu tend to have many
bugs which could be fixed by simply upgrading to a bugfix version, yet they
won't do it.

        Kevin Kofler



From robert at fedoraproject.org  Thu Dec 11 12:45:23 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 11 Dec 2008 13:45:23 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
Message-ID: <20081211124523.GA31161@hurricane.linuxnetz.de>

On Mon, 08 Dec 2008, Jon Stanley wrote:
> CD's are as slow as the reader, which is agonizingly slow on any
> computer, not really restricted to older ones.  Obviously newer
> computers would probably have faster drives, more RAM, etc, and I've
> found various LiveCD's acceptable on newer hardware. I unfortunately
> don't have anything to test on that would be considered "older
> hardware" - I did before I moved to a tiny apartment, but that stuff
> had to stay behind :)

Even a Fedora 9 Live-CD (GNOME) took on a 2.x GHz laptop with 40x CD-ROM
drive and 4 GB RAM ~ 7 minutes to boot. And when opening up e.g. the GNOME
menu, further 5-10 seconds were needed to open the menu. The hardware is
something, that already can be named as "older". At least it is no bleeding
edge hardware ;-)
 
> I certainly don't think that, even though I'm an American.  This
> really falls into the area of usability and QA.  Most of our QA
> contributors are in the US, and I didn't have as much time as I would
> have liked this time around due to $DAYJOB constraints.  However, my
> local mirror is set up in MirrorManager, such that it gets delivered
> to me first in mirrorlists, so I likely wouldn't have noticed this
> anyway, unfortuantely.

Well yes, for Fedora Mirror Manager maybe does the job depending on the
IP range. But as Anaconda from Fedora will go to RHEL and Mirror Manager
and RHEL (or CentOS) will likely not exist the same way as Fedora and the
Mirror Manager do, there really should be some dialog as before, maybe as
"Advanced" option or similar.

> MirrorManager was designed for use in Fedora Infrastructure, which
> happens to run on RHEL5.  No one ever claimed that it was possible to
> run it on RHEL4, however efforts were made to get it working for you.

That's maybe the problem. But software like Mirror Manager has a much wider
distribution as maybe thought. Mirror Manager seems to be exactly developed
for the need of the Fedora Project but no bit more, like for other repos
such as RPM Fusion or their contributors as I'm as well. So we're lacking
the flexibility somehow here.

I already got some pings after that mail by webteam and infrastructure on
IRC to investigate a bit more and hopefully solve it. 

> Package pushes continue to b e a manual process. However, the last
> package that I pushed took less than 24 hours.

Lucky guy. But that's not always the case - especially in the past when
excluding e.g. the last month maybe.

> No need to kill bodhi, simply implement a signing server in a secure
> fashion.

If a signing server solves that issue, we should go there.

> Again, I can't really comment on this except for the last part.  We
> are not wanting to "beat" Ubuntu to anything - there's not an arms
> race here or anything like that.  We are simply normally the first to
> adopt

Well, "Package management has to improve in Fedora to be competitive with
Ubuntu." seems for me to be some case of race and "beating" something. Or
am I such wrong when reading that from the citate?

> You are free to turn them off if you find that you don't need them. How
> else would you suggest we implement these services?

The mcstransd was implemented before as non-daemon. But for some reason it
got a daemon and since, the performance is more poor. Yum-updatesd could
get a cronjob - I think being up-to-date is nice, but being too up-to-date
can hurt very much for a Fedora user nowadays (e.g. dbus).

> Ubuntu also simply uses the compatibility mode.  Some features of upstart
> to enable us to make more use of it did not make it into 0.5, so we're
> continuing in compatibility mode.  Casey Dahlin could shed more light on
> this.

But why do we use upstart, if we only use compatibility mode and if there
seems to be no progress at all?


Greetings,
  Robert



From robert at fedoraproject.org  Thu Dec 11 12:57:27 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 11 Dec 2008 13:57:27 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081209100229.GD3833@free.fr>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr>
Message-ID: <20081211125727.GA1488@hurricane.linuxnetz.de>

On Tue, 09 Dec 2008, Patrice Dumas wrote:
> Sometime it is better to push directly to stable, when the package is
> already broken, when it is a security fix, or for packages with few
> users.

I agree with that so far, but such unluckily gotten base packages as dbus
(you know, I dislike dbus) need definately more love and especially much
more QA before getting stable. Such base packages IMHO need to succeed
several defined test cases, before they ever should make it into stable -
including security packages. The broken dbus brought us nice results in
and around Fedora.

I don't want to blame the package maintainer or upstream for that, but we
as Fedora need to do better QA before getting such updates into stable.


Greetings,
  Robert



From drago01 at gmail.com  Thu Dec 11 12:59:16 2008
From: drago01 at gmail.com (drago01)
Date: Thu, 11 Dec 2008 13:59:16 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081211124523.GA31161@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
Message-ID: <f6ca9fed0812110459h239b4350te09daa2306c45bc7@mail.gmail.com>

On Thu, Dec 11, 2008 at 1:45 PM, Robert Scheck <robert at fedoraproject.org> wrote:

> The mcstransd was implemented before as non-daemon. But for some reason it
> got a daemon and since, the performance is more poor.

That's not true a daemon that runs does not automatically degrade
performance ... most of them spend 99.9% of the time sleeping, waiting
to wake up when something happens.
Now tell me how does this affect performance in any way?
Increased start up time is the only thing .. as for memory they will
be simply paged out when a non sleeping process needs the memory.

> Yum-updatesd could
> get a cronjob - I think being up-to-date is nice, but being too up-to-date
> can hurt very much for a Fedora user nowadays (e.g. dbus).

Bugs happen and this was not a feature update but a security! one that
broke things, so doing "just bugfixes" wouldn't have avoided this ..

Having new software/features/drivers without having to wait ~3 months
is one of the reasons why I (and many others) use fedora.



From opensource at till.name  Thu Dec 11 13:01:09 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 14:01:09 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghr1gd$d8j$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<200812111249.16961.opensource@till.name> <ghr1gd$d8j$1@ger.gmane.org>
Message-ID: <200812111401.14407.opensource@till.name>

On Thu December 11 2008, Kevin Kofler wrote:
> Till Maas wrote:
> > But e.g. it is still not possible to receive gpg encrypted messages with
> > kopete, which is a major regression, because the alternatives are only to
> > not use Instant messaging or to use a different client.
>
> The kopete-cryptography package which adds this was pushed out to F10
> updates-testing this week. (I'll have to see if I can get it to build on

I know, because I reviewed it, but it won't work, because kopete from 
kdenetwork is also broken, which is also mentioned in the review request. 
Therefore it is totally unknown, when it will be possible to use it. 

It would be also interesting to know, why the plugin was even released at 
upstream, because there are like two features it has (sending and receiving 
encrypted messages) and it fails with one.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/6939dc69/attachment.sig>

From robert at fedoraproject.org  Thu Dec 11 13:01:30 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 11 Dec 2008 14:01:30 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <200812091149.02184.opensource@till.name>
References: <200812091149.02184.opensource@till.name>
Message-ID: <20081211130130.GB1488@hurricane.linuxnetz.de>

On Tue, 09 Dec 2008, Till Maas wrote:
> This is something that hit me, too. While F10 was not released, I booted a 
> live medium several times and sound worked there better than with F8 (A 
> soundcard I considered dead started working again), but then after I install 
> F10 Gold, I experience the same problems as you. 

Aside from that, I experienced something similar for the proprietary ATI
driver. Worked pre F10 including beta (IIRC until preview) and afterwards
there are now issues such e.g. just a black screen resulting in unusable;
so RPM Fusion even removed it from F10. I don't know what changed between
Beta and Final, but was that chance really necessary to break the (slow)
work and more less slower progress of the ATI guys? ;-)


Greetings,
  Robert



From robert at fedoraproject.org  Thu Dec 11 13:09:18 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 11 Dec 2008 14:09:18 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <f6ca9fed0812110459h239b4350te09daa2306c45bc7@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<f6ca9fed0812110459h239b4350te09daa2306c45bc7@mail.gmail.com>
Message-ID: <20081211130918.GA3093@hurricane.linuxnetz.de>

On Thu, 11 Dec 2008, drago01 wrote:
> That's not true a daemon that runs does not automatically degrade
> performance ... most of them spend 99.9% of the time sleeping, waiting
> to wake up when something happens.
> Now tell me how does this affect performance in any way?
> Increased start up time is the only thing .. as for memory they will
> be simply paged out when a non sleeping process needs the memory.

In theory that's all correct. But anyway there are bugs and/or issues
inside of mcstransd (when taking it here as an example), which are not
really fixed and still exist, even that the bug report is maybe closed
now. Reproducing that is as far as I know still possible as described
there.

 - https://bugzilla.redhat.com/show_bug.cgi?id=195916
 - https://bugzilla.redhat.com/show_bug.cgi?id=457179

> Bugs happen and this was not a feature update but a security! one that
> broke things, so doing "just bugfixes" wouldn't have avoided this ..

Didn't we learn in the beginnung of my started thread, that it takes anyway
~ 24 hours for a push? So why then a daemon which checks more often? Sorry,
but the possible reason of "having some own repository" still makes IMHO
not necessary to check more often than once or at least twice per 24 hours
for available updates...


Greetings,
  Robert



From pertusus at free.fr  Thu Dec 11 13:17:59 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 11 Dec 2008 14:17:59 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081211125727.GA1488@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr>
	<20081211125727.GA1488@hurricane.linuxnetz.de>
Message-ID: <20081211131759.GA2647@free.fr>

On Thu, Dec 11, 2008 at 01:57:27PM +0100, Robert Scheck wrote:
> On Tue, 09 Dec 2008, Patrice Dumas wrote:
> > Sometime it is better to push directly to stable, when the package is
> > already broken, when it is a security fix, or for packages with few
> > users.
> 
> I agree with that so far, but such unluckily gotten base packages as dbus
> (you know, I dislike dbus) need definately more love and especially much
> more QA before getting stable. Such base packages IMHO need to succeed

I don't disagree with that. I personnally avoid at best pushing to
stable releases. What I mean is that there is not a 'one size fits all'
policy for package updates.

But I fully agree that fedora is moving too fast (in stable releases)
without proper QA and integration, and I have repeatedly said so.

--
Pat



From limb at jcomserv.net  Thu Dec 11 13:45:29 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 11 Dec 2008 07:45:29 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <7892.1228943483@sss.pgh.pa.us>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
	<f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
Message-ID: <a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>


> "Jon Ciesla" <limb at jcomserv.net> writes:
>> Re jpegtran, there is a bug, against RHEL5:
>> https://bugzilla.redhat.com/show_bug.cgi?id=475679
>> CCing Tom.  Tom, would you like me to work on adding this patch into
>> Fedora's libjpeg?
>
> Actually, I had every intention of rejecting that bug WONTFIX.
> I don't think it's a good idea to get into the business of carrying
> nontrivial feature patches that aren't upstream.
>
> (Yes, I know libjpeg upstream is kinda moribund, but if you want new
> features in it you should be trying to revive upstream development,
> not strongarm the Fedora package maintainer to take over development.)

I agree strongly with that principle.  Two questions:

A. What has been done thusfar WTR reviving upstream development?

B. In the meantime, how should I support jpegtran?  Bundle a custom binary
in the subpackage and patch the module, or let it sit with known partial
functionality?

On a tangential note IIRC this patch is in Debian's libjpeg, not that that
should be any sort of guideline for us, I'm just putting it out there.

> 			regards, tom lane
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From rakesh.pandit at gmail.com  Thu Dec 11 13:57:58 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Thu, 11 Dec 2008 19:27:58 +0530
Subject: Pakaging enthought tool suite
Message-ID: <b401d2530812110557y6c1a70cam4a78fa55da9bf2d0@mail.gmail.com>

On Thu, 10 Apr 2008 23:49:18 +0200, Gael Varoquaux wrote:
>On Thu, Apr 10, 2008 at 01:43:34PM -0800, Jeff Spaleta wrote:
>> >  The tarballs of each released packages are located on

> >>  http://code.enthought.com/enstaller/eggs/source/

> >>  You do need a dependency graph to be able to make some sense of this. I
> >>  am making good progress on making a nice one.

>> Just for clarification... the eggs are completely source...and don't
>> contain binary blobs of any sort?

>Yes. I am not an Enthought employee. I have no financial interest or
>other interest than promoting high-quality open-source scientific
[..]

I am packaging mayavi2

My current mayavi spec state is:
http://rakesh.fedorapeople.org/misc/python-mayavi2.spec  It does not
build, but I am working on it and would love help or patches. ;)

I have already filed python-Traits:
https://bugzilla.redhat.com/show_bug.cgi?id=475098

There is an issue probably with mesa libraries which prevents
importing vtk. So, if you try building mayavi2 on F10, disable selinux
until this bug is resolved.

https://bugzilla.redhat.com/show_bug.cgi?id=475146

--
Regards,
Rakesh Pandit



From rawhide at fedoraproject.org  Thu Dec 11 14:07:26 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 11 Dec 2008 14:07:26 +0000 (UTC)
Subject: rawhide report: 20081211 changes
Message-ID: <20081211140726.CBCC11F823B@releng2.fedora.phx.redhat.com>

Compose started at Thu Dec 11 06:01:11 UTC 2008

New package examiner
        Utility to disassemble and comment foreign executable binaries
New package haddock
        Haddock documentation tool for annotated Haskell source code
New package mod_limitipconn
        Simultaneous connection limiting module for Apache
New package nwsclient
        NetWorkSpaces Client for Python
New package nxtvepg
        A nexTView EPG decoder and browser
New package perl-AutoXS-Header
        Container for the AutoXS header files
New package perl-Class-Unload
        Unload given Class
New package perl-Text-FindIndent
        Heuristically determine the indent style
New package python-relatorio
        A templating library able to output odt and pdf files
New package swingx
        A collection of Swing components
New package xcb-util
        Convenience libraries sitting on top of libxcb
New package xloadimage
        Image viewer and processor
New package xmbdfed
        Bitmap Font Editor
New package xmms2
        A modular audio framework and plugin architecture
Updated Packages:

ImageMagick-6.4.5.5-4.fc11
--------------------------
* Wed Dec 10 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.4.5.5-4
- Do not pass -jX to make when building, this breaks PerlMagick (rh 475554)


ORBit2-2.14.16-2.fc11
---------------------
* Wed Dec 10 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.16-2
- Merge review trivia


OpenIPMI-2.0.14-8.fc11
----------------------
* Wed Dec 10 17:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-8
- shorter probe interval is used in init script, making the service startup
  quicker in most situations (#475101)


alex-2.3.1-1.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 2.3.1-1
- update to 2.3.1
- no longer need alex-2.3-base3.patch


at-spi-1.25.2-5.fc11
--------------------
* Wed Dec 10 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.25.2-5
- ...but keep all the needed deps


bodhi-0.5.13-1.fc11
-------------------
* Wed Dec 10 17:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.13-1
- Latest upstream release to fix various metrics/rss issues


bzr-1.10-1.fc11
---------------
* Wed Dec 10 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 1.10-1
- Update to 1.10


bzrtools-1.10.0-1.fc11
----------------------
* Wed Dec 10 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 1.10-1
- Update to 0.10.0


contact-lookup-applet-0.17-1.fc11
---------------------------------
* Wed Dec 10 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.17-1
- Update to 0.17.
- Add BR on intltool.
- Drop search patch. Fixed upstream.
- Drop sources patch. Fixed upsteam.


corosync-0.92-4.svn1707.fc11
----------------------------
* Wed Dec 10 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 0.92-4.svn1707
- Update to svn trunk at revision 1707 from upstream.
- Update spec file to include new lcrso services and include file.

* Mon Oct 13 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.92-3
- remove ExclusiveArch line


dbus-1.2.8-3.fc11
-----------------
* Wed Dec 10 17:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.8-3
- Add back working syslog patch

* Tue Dec  9 17:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.8-2
- Remove accidentally added syslog patch

* Tue Dec  9 17:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.8-1
- New upstream 1.2.8
  Allows signals by default.


eclipse-changelog-2.6.3-2.fc10
------------------------------
* Mon Nov 24 17:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 2.6.3-2
- Disable building of eclipse-changelog-debuginfo since gcj AOT bits are
  no longer built for this package.


eclipse-egit-0.4.0-1.fc11
-------------------------
* Wed Dec 10 17:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 0.4.0-1
- Update to 0.4.0.


emacspeak-29.0-1.fc11
---------------------
* Thu Dec 11 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 29.0-1
- update to 29.0
- no longer need emacspeak-28.0-no-httpd.patch and emacspeak-28.0-tmpfile.patch


emma-2.0.5312-2.fc11
--------------------
* Wed Dec 10 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 0:2.0.5312-2
- Add patch to fix 64-bit AIOOB.


fbterm-1.2-2.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 1.2-2
- Summary simplified.


ffcall-1.10-2.20080704cvs.fc11.1
--------------------------------
* Wed Dec 10 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> - 1.10-2.20080704cvs.1
- Fix -FPIC issue (BZ #475112)


fuse-emulator-utils-0.10.0-2.fc11
---------------------------------
* Wed Dec 10 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.10.0-2
- upstream released broken package (missing files)

* Fri Dec  5 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.10.0-1
- new upstream 0.10.0 release


gallery2-2.3-1.fc11
-------------------
* Thu Dec  4 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 2.3-1
- Update to new upstream.
- Rebased on tarball now that perl path issue is fixed.
- Added buildroot wipe to start of install.
- Escaped macros in changelog.


glibmm24-2.18.1-2.fc11
----------------------
* Thu Dec 11 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.18.1-2
- Rebuild for pkgconfig provides


gnome-settings-daemon-2.25.2-8.fc11
-----------------------------------
* Wed Dec 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-8
- Shutdown cleanly when bus goes away (bug 445898 again)

* Wed Dec 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-7
- Don't map touch pad tap to right-click for left-handed
  users (bug 324721)

* Wed Dec 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-6
- Listen for DeviceAdded signals when configuring mouse
  (in addition to DeviceEnabled).  This may help with
  bug 474758.


gnustep-make-2.0.6-14.fc11
--------------------------
* Wed Dec 10 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> - 2.0.6-14
- Remove libcombo stuff
- Make sure the libraries are going to /usr/lib64 on x86_64 architecure


gpsbabel-1.3.6-1.fc10
---------------------

gtkmm24-2.14.3-2.fc11
---------------------
* Thu Dec 11 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.14.3-2
- Rebuild for pkgconfig provides


javasqlite-20081006-4.fc11
--------------------------
* Wed Dec 10 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 20081006-4
- Revert previous change, arch specific links break in %{_datadir}.


jd-2.1.0-0.1.svn2553_trunk.fc11
-------------------------------
* Thu Dec 11 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2553


libsigc++20-2.2.2-2.fc11
------------------------
* Thu Dec 11 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.2.2-2
- Rebuild for pkgconfig provides


libsqlite3x-20071018-4.fc10
---------------------------

linuxwacom-0.8.0.3-6.fc10
-------------------------
* Fri Nov 14 17:00:00 2008 Aristeu Rozanski <aris at redhat.com> 0.8.0.3-6
- rebuild

* Fri Nov 14 17:00:00 2008 Aristeu Rozanski <aris at redhat.com> 0.8.0.3-5
- don't call devproc with DEVICE_OFF in Uninit in new X servers


meanwhile-1.1.0-0.fc10
----------------------
* Mon Nov 17 17:00:00 2008 Josh Boyer <jwboyer at gmail.com> - 1.1.0-0
- Update to meanwhile_v1_1_0 branch from upstream CVS


nted-1.4.17-1.fc11
------------------
* Wed Dec 10 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.4.17-1
- Update to upstream's 1.4.17 release.


octave-3.0.3-1.fc11
-------------------
* Wed Dec 10 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 3.0.3-1
- Update to latest upstream (3.0.3)


openais-0.91-3.svn1667.fc11
---------------------------
* Wed Dec 10 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 0.91-3.svn1667
- Update to svn trunk at revision 1667 from upstream.
- Update spec file to support alpha tag versioning.
- Tight dependencies (both build and runtime) with corosync to avoid
  internal ABI issues.


perl-Sub-Uplevel-0.2002-1.fc11
------------------------------
* Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.2002-1
- Update to 0.2002.
- BR Test::More.


perl-Test-Base-0.55-1.fc11
--------------------------
* Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.55-1
- Update to 0.55.
- Explicitly BR Test::More >= 0.62.
- BR YAML.


perl-Test-Class-0.31-1.fc11
---------------------------
* Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.31-1
- Update to 0.31.
- BR Test::Builder.
- Add versioned dependencies to Test::Builder::Tester and Test::More.


perl-Test-Output-0.12-1.fc11
----------------------------
* Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.12-1
- Update to 0.12.
- BR Test::More.
- Fix typo in description.
- Include TODO in docs.


perl-Test-Prereq-1.034-1.fc11
-----------------------------
* Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 1.034-1
- Update to 1.034.


perl-Text-CSV_XS-0.58-1.fc11
----------------------------
* Wed Dec 10 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.58-1
- Update to latest upstream
- SvUPGRADE patch upstreamed


perl-YAML-0.68-1.fc11
---------------------
* Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.68-1
- Update to 0.68.
- COMPATIBILITY went away.
- ysh moved to YAML::Shell.


picviz-0.4-2.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4-2
- Rebuild for Python 2.6


policycoreutils-2.0.60-5.fc11
-----------------------------
* Wed Dec 10 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.60-5
- Fix Japanese translations


python-2.6-2.fc11
-----------------
* Wed Dec 10 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.6-2
- Enable -lcrypt for cryptmodule


python-libgmail-0.1.10-3.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.10-3
- Rebuild for Python 2.6


python-mechanize-0.1.10-1.fc11
------------------------------
* Wed Dec 10 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.10-1
- Update to 0.1.10


python-nevow-0.9.32-1.fc11
--------------------------
* Wed Dec 10 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.32-1
- Update to 0.9.32

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.31-2
- Rebuild for Python 2.6


python-rdflib-2.4.0-8.fc11
--------------------------
* Wed Dec 10 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4.0-8
- Rebuild for Python 2.6


python-tgcaptcha-0.11-4.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11-4
- Rebuild for Python 2.6


python-turboflot-0.1.1-2.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1-2
- Rebuild for Python 2.6


rafkill-1.2.3-3.fc11
--------------------
* Wed Dec 10 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.2.3-3
- Re-diffed fuzzy shatter patch.


ruby-RMagick-2.8.0-1.fc11
-------------------------
* Wed Dec 10 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.8.0-1
- 2.8.0


scim-chewing-0.3.3-0.fc11
-------------------------
* Thu Dec 11 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 0.3.3-0
- Upstream update.


selinux-policy-3.6.1-9.fc11
---------------------------
* Tue Dec  9 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-9
- Add cron_role back to user domains


setup-2.7.5-2.fc11
------------------
* Wed Dec 10 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2.7.5-2
- do not export PATH twice(#449286 NOTABUG revert)
- do not export INPUTRC(to respect just created ~/.inputrc)
  (#443717)


tomcat5-5.5.27-6.1.fc10
-----------------------
* Wed Dec 10 17:00:00 2008 David Walluck <dwalluck at redhat.com> 0:5.5.27-6.1
- fix bug #473755
- fix extra newline in initscript


xine-plugin-1.0.2-1.fc11
------------------------
* Thu Dec 11 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 1.0.2-1
- new upstreame release 
- should fix rhbz #473830


xlog-1.8.1-3.fc11
-----------------
* Wed Dec 10 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.8.1-3
- modify patch to correctly display documentation


xorg-x11-drv-geode-2.11.0-1.fc11
--------------------------------
* Wed Dec 10 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.11.0-1
- update to 2.11.0 adds xrandr-1.2 and fixes cursor issues


xorg-x11-xdm-1.1.6-6.fc10
-------------------------
* Fri Nov  7 17:00:00 2008 Mat??j Cepl <mcepl at redhat.com> - 1.1.6-6
- Wrong Xresources generated (bug 470348)

* Thu Oct 30 18:00:00 2008 Soren Sandmann <ssp at redhat.com> 1.1.6-5
- Fix xdm.pamd (bug 388431)


xpdf-3.02-9.fc11
----------------
* Wed Dec 10 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1:3.02-9
- apply debian patches

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1:3.02-8
- Fix Patch0:/%patch mismatch.


Summary:
Added Packages: 14
Removed Packages: 0
Modified Packages: 60
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	bzrtools-1.10.0-1.fc11.i386 requires bzr < 0:1.9
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.i386 requires ghc = 0:6.8.3
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.i386 requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	bzrtools-1.10.0-1.fc11.x86_64 requires bzr < 0:1.9
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.x86_64 requires ghc = 0:6.8.3
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.x86_64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	bzrtools-1.10.0-1.fc11.ppc requires bzr < 0:1.9
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.ppc requires ghc = 0:6.8.3
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	bzrtools-1.10.0-1.fc11.ppc64 requires bzr < 0:1.9
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From limb at jcomserv.net  Thu Dec 11 14:08:11 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 11 Dec 2008 08:08:11 -0600 (CST)
Subject: Push problems?
Message-ID: <8a3c4dbe33ca34beb433ea68ba118ea0.squirrel@mail.jcomserv.net>

I saw that we had a push Tuesday, and one last night.  I still don't see
any of the F-10 packages announced Tuesday, but all the ones for Thursday
are there.

Is there a problem?

-Jon


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From ivazqueznet at gmail.com  Thu Dec 11 14:15:30 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 11 Dec 2008 09:15:30 -0500
Subject: Python deps (was: Re: rawhide report: 20081211 changes)
In-Reply-To: <20081211140726.CBCC11F823B@releng2.fedora.phx.redhat.com>
References: <20081211140726.CBCC11F823B@releng2.fedora.phx.redhat.com>
Message-ID: <1229004930.30148.131.camel@ignacio.lan>

On Thu, 2008-12-11 at 14:07 +0000, Rawhide Report wrote:
> Broken deps for i386
> ----------------------------------------------------------

At this point, anything that has deps on Python should be a FTBFS not
based on Python, or where I lack permissions to rebuild. I'll be glad to
step in to help once the maintainer hits an actual Python issue.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/0e6dd4ac/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Dec 11 14:26:14 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 11 Dec 2008 23:26:14 +0900
Subject: Push problems?
In-Reply-To: <8a3c4dbe33ca34beb433ea68ba118ea0.squirrel@mail.jcomserv.net>
References: <8a3c4dbe33ca34beb433ea68ba118ea0.squirrel@mail.jcomserv.net>
Message-ID: <49412306.7070904@ioa.s.u-tokyo.ac.jp>

Jon Ciesla wrote, at 12/11/2008 11:08 PM +9:00:
> I saw that we had a push Tuesday, and one last night.  I still don't see
> any of the F-10 packages announced Tuesday, but all the ones for Thursday
> are there.
> 
> Is there a problem?

I've already reported this issue on:
https://fedorahosted.org/rel-eng/ticket/1133

I guess rel-eng team is working on this.

Mamoru



From skvidal at fedoraproject.org  Thu Dec 11 14:27:04 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 09:27:04 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <1228988436.3378.6.camel@hughsie-work.lan>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228931001.10235.55.camel@hughsie-work.lan>
	<1228988436.3378.6.camel@hughsie-work.lan>
Message-ID: <alpine.LFD.2.00.0812110925230.12077@localhost.localdomain>



On Thu, 11 Dec 2008, Richard Hughes wrote:

> On Wed, 2008-12-10 at 17:43 +0000, Richard Hughes wrote:
>> Also, this would imply automatically turning on updates-testing,
>> downloading metadata, and disabling updates-testing all behind the
>> users back. A few people might get upset by this.
>
> I've been prototyping something like this, but it doesn't seem to work:
>
>    repos = self.yumbase.repos.repos.values()
>    repos_enabled = []
>    repos_disabled = []
>
>    pkgs = []
>    yb._up = None
>    ygl = yb.doPackageLists(pkgnarrow='updates')
>    pkgs.extend(ygl.updates)
>    ygl = yb.doPackageLists(pkgnarrow='obsoletes')
>    pkgs.extend(ygl.obsoletes)
>
>    print pkgs
>
>    for repo in repos:
>        if repo.id.endswith('testing'):
>            if not repo.isEnabled():
>                repo.enablePersistent()
>                repos_enabled.append(repo)
>        else:
>            if repo.isEnabled():
>                repo.disablePersistent()
>                repos_disabled.append(repo)
>
>    pkgs = []
>    yb._up = None
>    ygl = yb.doPackageLists(pkgnarrow='updates')
>    pkgs.extend(ygl.updates)
>    ygl = yb.doPackageLists(pkgnarrow='obsoletes')
>    pkgs.extend(ygl.obsoletes)
>
>    print pkgs
>
>    for repo in repos_enabled:
>        repo.disablePersistent()
>    for repo in repos_disabled:
>        repo.enablePersistent()
>
> I'm already clearing the update list by doing "yb._up = None", but I
> can't seem to get the "testing" updates in the second pass. Any ideas?

two things:
1. yb.up has a property() setter so you can do yb.up = None
2. you need to do the doRepoSetup(thisrepo=repo) for the repo to get 
picked up.

-sv



From limb at jcomserv.net  Thu Dec 11 14:31:20 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 11 Dec 2008 08:31:20 -0600 (CST)
Subject: Push problems?
In-Reply-To: <49412306.7070904@ioa.s.u-tokyo.ac.jp>
References: <8a3c4dbe33ca34beb433ea68ba118ea0.squirrel@mail.jcomserv.net>
	<49412306.7070904@ioa.s.u-tokyo.ac.jp>
Message-ID: <9efd05e2c65317fe6ae0325239b96150.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote, at 12/11/2008 11:08 PM +9:00:
>> I saw that we had a push Tuesday, and one last night.  I still don't see
>> any of the F-10 packages announced Tuesday, but all the ones for
>> Thursday
>> are there.
>>
>> Is there a problem?
>
> I've already reported this issue on:
> https://fedorahosted.org/rel-eng/ticket/1133
>
> I guess rel-eng team is working on this.

Great, thanks!

> Mamoru
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From tcallawa at redhat.com  Thu Dec 11 14:54:32 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 11 Dec 2008 09:54:32 -0500
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <20081210213546.GD12080@auslistsprd01.us.dell.com>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
Message-ID: <1229007272.3537.23.camel@localhost.localdomain>

On Wed, 2008-12-10 at 15:35 -0600, Matt Domsch wrote:
> On Wed, Dec 10, 2008 at 09:33:09AM -0500, Bill Nottingham wrote:
> > Thomas Moschny (thomas.moschny at gmail.com) said: 
> > > > https://bugzilla.redhat.com/userprefs.cgi?tab=email
> > > >
> > > > See 'user watching'.
> > > >
> > > > People can set up bugstalking filters to get e-mailed any time someone
> > > > else would be e-mailed.
> > > 
> > > So, whom is he watching?
> > 
> > Myself, at least (which will cover most all the review tickets). You can see
> > who's watching you on the same bugzilla pref page.
> 
> Now there's a masochist if ever I saw one.  Not only keeping up with
> his own mail stream, but desiring to keep up with Bill's too!

He seems to be tracking most/all of mine as well. 

~spot



From limb at jcomserv.net  Thu Dec 11 15:01:09 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 11 Dec 2008 09:01:09 -0600 (CST)
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <1229007272.3537.23.camel@localhost.localdomain>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
	<1229007272.3537.23.camel@localhost.localdomain>
Message-ID: <f0e3903aa00e4aa70244ef1b16225fcd.squirrel@mail.jcomserv.net>


> On Wed, 2008-12-10 at 15:35 -0600, Matt Domsch wrote:
>> On Wed, Dec 10, 2008 at 09:33:09AM -0500, Bill Nottingham wrote:
>> > Thomas Moschny (thomas.moschny at gmail.com) said:
>> > > > https://bugzilla.redhat.com/userprefs.cgi?tab=email
>> > > >
>> > > > See 'user watching'.
>> > > >
>> > > > People can set up bugstalking filters to get e-mailed any time
>> someone
>> > > > else would be e-mailed.
>> > >
>> > > So, whom is he watching?
>> >
>> > Myself, at least (which will cover most all the review tickets). You
>> can see
>> > who's watching you on the same bugzilla pref page.
>>
>> Now there's a masochist if ever I saw one.  Not only keeping up with
>> his own mail stream, but desiring to keep up with Bill's too!
>
> He seems to be tracking most/all of mine as well.

Perhaps it's the Dark Lord's brother.

> ~spot
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From skvidal at fedoraproject.org  Thu Dec 11 15:01:43 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 10:01:43 -0500 (EST)
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <1229007272.3537.23.camel@localhost.localdomain>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
	<1229007272.3537.23.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>



On Thu, 11 Dec 2008, Tom \"spot\" Callaway wrote:

> On Wed, 2008-12-10 at 15:35 -0600, Matt Domsch wrote:
>> On Wed, Dec 10, 2008 at 09:33:09AM -0500, Bill Nottingham wrote:
>>> Thomas Moschny (thomas.moschny at gmail.com) said:
>>>>> https://bugzilla.redhat.com/userprefs.cgi?tab=email
>>>>>
>>>>> See 'user watching'.
>>>>>
>>>>> People can set up bugstalking filters to get e-mailed any time someone
>>>>> else would be e-mailed.
>>>>
>>>> So, whom is he watching?
>>>
>>> Myself, at least (which will cover most all the review tickets). You can see
>>> who's watching you on the same bugzilla pref page.
>>
>> Now there's a masochist if ever I saw one.  Not only keeping up with
>> his own mail stream, but desiring to keep up with Bill's too!
>
> He seems to be tracking most/all of mine as well.
>

Spam Harvester?


it'd be a good way to pickup email addresses.

-sv



From mcepl at redhat.com  Wed Dec 10 10:58:51 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 10 Dec 2008 11:58:51 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
Message-ID: <b0k416xn77.ln2@ppp1053.in.ipex.cz>

On 2008-12-09, 12:03 GMT, Sven Lankes wrote:
> We should try to get the bohdi-karma-mechanism more popular. 

IMNSHO we should get rid of it -- there is already one very good 
mechanism for registering bugs in the software and it is 
bugzilla. Trying to develop another bugzilla in bodhi is asking 
for failure. Even worse would be if you succeed and somebody 
would actually start to use it, because they would expect 
maintainers to take it into account.

Yes, there should be some mechanism how Bodhi should stop package 
from entering updates, but I guess bodhi developers will have to 
work a little bit harder than putting yet another stupid form on 
the website somewhere, which doesn't integrate with anything than 
with itself.

Sorry, for being offensive, but rewriting in the polished tone 
would take too much time (and I would have to cool down myself 
first ;-)). Bodhi developers, don't take this personally please.

Best,

Mat?j



From kevin.kofler at chello.at  Thu Dec 11 15:13:20 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 16:13:20 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<200812111249.16961.opensource@till.name>
	<ghr1gd$d8j$1@ger.gmane.org>
	<200812111401.14407.opensource@till.name>
Message-ID: <ghramg$ch1$1@ger.gmane.org>

Till Maas wrote:
> I know, because I reviewed it, but it won't work, because kopete from
> kdenetwork is also broken, which is also mentioned in the review request.
> Therefore it is totally unknown, when it will be possible to use it.

A kdenetwork update with the fixes is pending.

        Kevin Kofler



From mcepl at redhat.com  Wed Dec 10 11:14:24 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 10 Dec 2008 12:14:24 +0100
Subject: use fcron as default scheduler in Fedora?
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<a2e85ed0812090100o347e9e2j293310f7f85d82ca@mail.gmail.com>
Message-ID: <gtk416xo18.ln2@ppp1053.in.ipex.cz>

On 2008-12-09, 09:00 GMT, Nikolay Vladimirov wrote:
> It likes to be the standard editor.

But you know it isn't, right? You surely know what is The 
Standard Text Editor, don't you?

Mat?j



From kevin.kofler at chello.at  Thu Dec 11 15:14:31 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 16:14:31 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <200812091149.02184.opensource@till.name>
	<20081211130130.GB1488@hurricane.linuxnetz.de>
Message-ID: <ghraon$ch1$2@ger.gmane.org>

Robert Scheck wrote:
> Aside from that, I experienced something similar for the proprietary ATI
> driver. Worked pre F10 including beta (IIRC until preview) and afterwards
> there are now issues such e.g. just a black screen resulting in unusable;
> so RPM Fusion even removed it from F10. I don't know what changed between
> Beta and Final, but was that chance really necessary to break the (slow)
> work and more less slower progress of the ATI guys? ;-)

Proprietary drivers are not, have never been and will never be supported in
Fedora.

        Kevin Kofler



From mcepl at redhat.com  Wed Dec 10 10:15:02 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 10 Dec 2008 11:15:02 +0100
Subject: Server SIG - work areas
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
	<20081209104858.GG3833@free.fr>
	<9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>
	<9497e9990812090502v40665382sf157e54783286033@mail.gmail.com>
Message-ID: <6eh416x6s5.ln2@ppp1053.in.ipex.cz>

On 2008-12-09, 13:02 GMT, Mat Booth wrote:
> Sorry for replying to myself, but another thought occurred 
> after I hit send: Maybe I don't understand *why* you need 
> bleeding edge if what you want is stability...

Well, isn't it obvious what he needs? He just needs the latest 
bleeding edge without any bugs. What is so difficult on it to 
explain?

Mat?j



From mcepl at redhat.com  Wed Dec 10 10:24:19 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 10 Dec 2008 11:24:19 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<20081209143215.GC3395@redhat.com>
Message-ID: <jvh416x6s5.ln2@ppp1053.in.ipex.cz>

On 2008-12-09, 14:32 GMT, John W. Linville wrote:
> Wireless wasn't on the list -- hooray!!!!
>
> Sorry, just needed some humor...

Did I tell you how much wifi sucks? And I am quite sure it is 
*YOUR* fault!!!

On every other resume, I either manage to get to console fast 
enough to modprobe -v -r iwl3945 and restart NetworkManager or 
I end in the hard frozen notebook (Power off required).

Seriously, I will file a bug.

Mat?j

(Did I forget to say that my wife's BCM4318 works like a charm?  
THANK YOU)



From rdieter at math.unl.edu  Thu Dec 11 15:27:19 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 11 Dec 2008 09:27:19 -0600
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
Message-ID: <ghrbgn$ha9$1@ger.gmane.org>

Matej Cepl wrote:

> On 2008-12-09, 12:03 GMT, Sven Lankes wrote:
>> We should try to get the bohdi-karma-mechanism more popular.
> 
> IMNSHO we should get rid of it -- there is already one very good
> mechanism for registering bugs in the software and it is
> bugzilla.

Bodhi feedback is a *complement* to bugzilla, not a replacement.

-- rex




From opensource at till.name  Thu Dec 11 15:33:19 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 16:33:19 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghramg$ch1$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<200812111401.14407.opensource@till.name> <ghramg$ch1$1@ger.gmane.org>
Message-ID: <200812111633.34276.opensource@till.name>

On Thu December 11 2008, Kevin Kofler wrote:
> Till Maas wrote:
> > I know, because I reviewed it, but it won't work, because kopete from
> > kdenetwork is also broken, which is also mentioned in the review request.
> > Therefore it is totally unknown, when it will be possible to use it.
>
> A kdenetwork update with the fixes is pending.

That's fantastic. But wouldn't it be more appropriate to include both packages 
in one update then? Also I guess the kopete-cryptography package should then 
have a Requires: on the new kdenetwork package.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/d44013ee/attachment.sig>

From kevin.kofler at chello.at  Thu Dec 11 15:36:10 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Dec 2008 16:36:10 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
Message-ID: <ghrc1b$gs0$1@ger.gmane.org>

Matej Cepl wrote:
> Even worse would be if you succeed and somebody would actually start to
> use it, because they would expect maintainers to take it into account.

Actually, they already do, and rightly so. It doesn't make sense to push
updates to stable when they're known to break things, figuring that out is
what updates-testing is for, if the feedback gets ignored, we can just as
well shut it down and push everything to stable. (No, I'm not suggesting
doing that. ;-) )

        Kevin Kofler



From pertusus at free.fr  Thu Dec 11 15:38:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 11 Dec 2008 16:38:20 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <ghrbgn$ha9$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <ghrbgn$ha9$1@ger.gmane.org>
Message-ID: <20081211153820.GC2647@free.fr>

On Thu, Dec 11, 2008 at 09:27:19AM -0600, Rex Dieter wrote:
> Matej Cepl wrote:
> 
> > On 2008-12-09, 12:03 GMT, Sven Lankes wrote:
> >> We should try to get the bohdi-karma-mechanism more popular.
> > 
> > IMNSHO we should get rid of it -- there is already one very good
> > mechanism for registering bugs in the software and it is
> > bugzilla.
> 
> Bodhi feedback is a *complement* to bugzilla, not a replacement.

For gnash and kchmviewer, I have noticed that users give feedback in
bugzilla. But maybe bodhi is more suiteable for tester testing integration 
issues, as opposed with testing one application. they may be subscribed 
to bodhi changes and giving feedback in bodhi may be a relevant workflow
in that case.

--
Pat



From rc040203 at freenet.de  Thu Dec 11 15:40:46 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 11 Dec 2008 16:40:46 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <ghrbgn$ha9$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>  <ghrbgn$ha9$1@ger.gmane.org>
Message-ID: <1229010046.3394.1149.camel@beck.corsepiu.local>

On Thu, 2008-12-11 at 09:27 -0600, Rex Dieter wrote:
> Matej Cepl wrote:
> 
> > On 2008-12-09, 12:03 GMT, Sven Lankes wrote:
> >> We should try to get the bohdi-karma-mechanism more popular.
> > 
> > IMNSHO we should get rid of it

+1. It's superfluous.

>  -- there is already one very good
> > mechanism for registering bugs in the software and it is
> > bugzilla.
Agreed. Bug reporters report success/failure through bugzilla.

> Bodhi feedback is a *complement* to bugzilla, not a replacement.

Feedback has nothing to do with "bodhi's karma counters".

Ralf





From rdieter at math.unl.edu  Thu Dec 11 15:55:23 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 11 Dec 2008 09:55:23 -0600
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <ghrbgn$ha9$1@ger.gmane.org>
	<1229010046.3394.1149.camel@beck.corsepiu.local>
Message-ID: <ghrd5b$ne2$1@ger.gmane.org>

Ralf Corsepius wrote:

>> Bodhi feedback is a *complement* to bugzilla, not a replacement.
> 
> Feedback has nothing to do with "bodhi's karma counters".

Shrug, karma is optional. Many maintainers appreciate it (I do), if you
don't, then don't use it.

-- Rex




From sven at lank.es  Thu Dec 11 16:08:11 2008
From: sven at lank.es (Sven Lankes)
Date: Thu, 11 Dec 2008 17:08:11 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <b0k416xn77.ln2@ppp1053.in.ipex.cz>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081211160811.GG21424@killefiz>

On Wed, Dec 10, 2008 at 11:58:51AM +0100, Matej Cepl wrote:

>> We should try to get the bohdi-karma-mechanism more popular. 
 
> IMNSHO we should get rid of it -- there is already one very good 
> mechanism for registering bugs in the software and it is 
> bugzilla.

Which can cater for negative feedback. I don't think most people would
be too happy with bz-entries created just containing 'works for me'.

-- 
sven === jabber/xmpp: sven at lankes.net



From hughsient at gmail.com  Thu Dec 11 16:15:52 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 11 Dec 2008 16:15:52 +0000
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812110925230.12077@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228931001.10235.55.camel@hughsie-work.lan>
	<1228988436.3378.6.camel@hughsie-work.lan>
	<alpine.LFD.2.00.0812110925230.12077@localhost.localdomain>
Message-ID: <1229012152.15110.20.camel@hughsie-work.lan>

On Thu, 2008-12-11 at 09:27 -0500, Seth Vidal wrote:
> two things:
> 1. yb.up has a property() setter so you can do yb.up = None

Ahh, changed, thanks.

> 2. you need to do the doRepoSetup(thisrepo=repo) for the repo to get 
> picked up.

Tried that, and also tried
self.yumbase.repos.doSetup(thisrepo=repo.id) but neither forced a
reload. I had to do "yb.pkgSack = None" to get the new updates.

Richard.




From benny+usenet at amorsen.dk  Thu Dec 11 16:29:31 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 11 Dec 2008 17:29:31 +0100
Subject: Server SIG - work areas
In-Reply-To: <9497e9990812090502v40665382sf157e54783286033@mail.gmail.com>
	(Mat Booth's message of "Tue\, 9 Dec 2008 13\:02\:16 +0000")
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
	<20081209104858.GG3833@free.fr>
	<9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>
	<9497e9990812090502v40665382sf157e54783286033@mail.gmail.com>
Message-ID: <m3abb24qvo.fsf@ursa.amorsen.dk>

"Mat Booth" <fedora at matbooth.co.uk> writes:

> Sorry for replying to myself, but another thought occurred after I hit
> send: Maybe I don't understand *why* you need bleeding edge if what
> you want is stability...

I want bleeding edge when we first develop new systems, so I get all
the new shiny features for the beta testers to play with... Then when
the bugs have been found, everything should stay stable without
needing significant care for a few years, until the system is replaced
with a new even shinier one and the cycle continues.

Red Hat Enterprise Linux provides stability. Fedora provides bleeding
edge. Lots of people, including me, want both.

That doesn't mean we get to have both.


/Benny

PS Ponies. Why doesn't Fedora provides ponies?



From jkeating at redhat.com  Thu Dec 11 16:40:58 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 08:40:58 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq76n$5to$2@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228931026.30987.121.camel@code.and.org> <ghq76n$5to$2@ger.gmane.org>
Message-ID: <1229013658.3863.74.camel@localhost.localdomain>

On Thu, 2008-12-11 at 06:07 +0100, Kevin Kofler wrote:
> 
> I wouldn't. Let's not make Fedora a bureaucracy like Debian stable. It would
> immensely reduce its usefulness. People who don't want non-criticial
> updates should be using CentOS, not Fedora.

There is a big difference between critical only updates and what I would
rather see done in Fedora.  I'd like to see something closer to bugfix
only and self contained minor enhancements.  Major changes and wide
reaching changes are very destabilizing and when you release say F10
with a set of software that acts one way, maybe even document it, then
suddenly change the way that software works in an update, what does that
do to the documentation, any possible training, or any actual meaning to
the "release"?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/bbd716c1/attachment.sig>

From jkeating at redhat.com  Thu Dec 11 16:43:51 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 08:43:51 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq7as$5to$3@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
Message-ID: <1229013831.3863.76.camel@localhost.localdomain>

On Thu, 2008-12-11 at 06:09 +0100, Kevin Kofler wrote:
> 
> But often it's impossible to fix some bugs without a version upgrade. For
> example, the upgrade to KDE 4.1 in F9 fixed many bugs in 4.0.

To an extent, that's acceptable.  Superfluous and gratuitous major
version changes aren't.  Also, there is a difference between doing 4.0
to 4.1 and doing something like 3.5 to 4.1.  I'm pretty sure you
understand the spirit of what I'm pushing for, and aren't just trying to
find fault in the specific words I've used (since every upstream is
different and use numbers in different ways to express different
things). 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/d7c5bebb/attachment.sig>

From jkeating at redhat.com  Thu Dec 11 16:49:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 08:49:25 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqg1t$pnm$2@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
Message-ID: <1229014165.3863.79.camel@localhost.localdomain>

On Thu, 2008-12-11 at 08:38 +0100, Kevin Kofler wrote:
> You have to decide: do you want updates or do you not want them? If you
> don't want to wait for the next CentOS release, then obviously you need the
> update quickly, so you are in Fedora's target base. But then you can't
> complain that you get updates too quickly! You can't have both ways.
> (You're one of those users with contradictory requirements I mentioned
> elsewhere in this thread.)

Updates != upgrades.

I think frequent updates to given package set to fix bugs is great.
Frequent upgrades to a package set for new upstream features, behavior,
bugs, incompatibilities is not so great.

With the 6 month cycle of Fedora, and our willingness to break things
like crazy in the rawhide world, we're still a very very fast distro and
unique in the distro space for early adoption of software.  This all
comes /without/ even considering what we do for updates to our releases.
Even if our releases only got bugfixes, we're still uniquely agile to
new software and technologies and very fast to new releases using those
things.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/fe6840d5/attachment.sig>

From rc040203 at freenet.de  Thu Dec 11 16:52:34 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 11 Dec 2008 17:52:34 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <20081211160811.GG21424@killefiz>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <20081211160811.GG21424@killefiz>
Message-ID: <1229014354.3394.1226.camel@beck.corsepiu.local>

On Thu, 2008-12-11 at 17:08 +0100, Sven Lankes wrote:
> On Wed, Dec 10, 2008 at 11:58:51AM +0100, Matej Cepl wrote:
> 
> >> We should try to get the bohdi-karma-mechanism more popular. 
>  
> > IMNSHO we should get rid of it -- there is already one very good 
> > mechanism for registering bugs in the software and it is 
> > bugzilla.
> 
> Which can cater for negative feedback. I don't think most people would
> be too happy with bz-entries created just containing 'works for me'.
But this is exactly what is happening.

Cf. https://bugzilla.redhat.com/show_bug.cgi?id=475943
for a real world case.

... no matter which karma a package would get, it would still be the
maintainer who overrules.

Ralf




From jkeating at redhat.com  Thu Dec 11 16:57:45 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 08:57:45 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812102328o4d6f459apa84eb3246335d850@mail.gmail.com>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org> <ghqcjc$iea$1@ger.gmane.org>
	<16de708d0812102256s742daabn825d281f965bf001@mail.gmail.com>
	<ghqepe$n8v$1@ger.gmane.org>
	<16de708d0812102328o4d6f459apa84eb3246335d850@mail.gmail.com>
Message-ID: <1229014665.3863.81.camel@localhost.localdomain>

On Thu, 2008-12-11 at 01:28 -0600, Arthur Pemberton wrote:
> 
> I also use Fedora as my primary OS, and seeing as most OSS software
> brings new features and bug fixes with each release, what's not to
> want with a new update? Shouldn't one be able to stay within the
> package management system and be as up to date with Windows/Mac
> software where packages are manually downloaded?

Particularly with OpenOffice.org there really needs to be a compelling
reason to jump on every upstream drop.  It's a huge package that costs
a /ton/ of bandwidth to mirror and for users to download and update.
The maintainer rightly determines when the update is worth the cost.

Newest numbers for the sake of newest numbers is just idiocy.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/5f14055a/attachment.sig>

From rc040203 at freenet.de  Thu Dec 11 16:56:32 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 11 Dec 2008 17:56:32 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <ghrd5b$ne2$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <ghrbgn$ha9$1@ger.gmane.org>
	<1229010046.3394.1149.camel@beck.corsepiu.local>
	<ghrd5b$ne2$1@ger.gmane.org>
Message-ID: <1229014592.3394.1235.camel@beck.corsepiu.local>

On Thu, 2008-12-11 at 09:55 -0600, Rex Dieter wrote:
> Ralf Corsepius wrote:
> 
> >> Bodhi feedback is a *complement* to bugzilla, not a replacement.
> > 
> > Feedback has nothing to do with "bodhi's karma counters".
> 
> Shrug, karma is optional. Many maintainers appreciate it (I do), if
> you don't, then don't use it.
Well, I don't care about them, because
* hardly anybody uses them,
* it requires maintainers to explicitly redirect BZ reporters to them.
* they are questionable wealth.

Ralf





From jkeating at redhat.com  Thu Dec 11 17:02:49 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 09:02:49 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq732$5to$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<ghq732$5to$1@ger.gmane.org>
Message-ID: <1229014969.3863.85.camel@localhost.localdomain>

On Thu, 2008-12-11 at 06:05 +0100, Kevin Kofler wrote:
> 
> I strongly disagree with that idea, IMHO the version upgrades to released
> versions are the main distinctive point of Fedora, many people (including
> me) use Fedora for that very reason.

You know as well as I do that "version" upgrades can be twisted to mean
anything you want, depending on the upstream.  The gist of what I'm
trying to express distaste with is egregious update spamming just to
have the highest number everywhere, rather than calculated updates
balancing the risk of new code and the cost of bandwidth and storage vs
what the latest number /actually/ brings to users.

I mean, I just recently saw a maintainer build a package from F9,10, and
11 just to update a summary.  Was that seriously worth a build?  I
haven't yet seen if the maintainer has queued up bodhi updates for that,
but come on, seriously?  That type of change can certainly wait until
there is a more compelling reason to consume the resources of an update.

> 
> And the problem in this thread wasn't even such an update, it was a security
> fix! Even if it had been backported to D-Bus 1.2.4 instead of an upgrade to
> 1.2.6, it would still have caused the same issue! So the problem we're
> seeing has absolutely nothing to do with feature upgrades.

While that's true of the originating topic of this thread, we've moved
on to a more general discussion of how Fedora releases should be
treated.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/16e1f8e9/attachment.sig>

From jspaleta at gmail.com  Thu Dec 11 17:04:16 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 08:04:16 -0900
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <ghrd5b$ne2$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <ghrbgn$ha9$1@ger.gmane.org>
	<1229010046.3394.1149.camel@beck.corsepiu.local>
	<ghrd5b$ne2$1@ger.gmane.org>
Message-ID: <604aa7910812110904i3f8e04a3lee8929cb34862e42@mail.gmail.com>

On Thu, Dec 11, 2008 at 6:55 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
> Shrug, karma is optional. Many maintainers appreciate it (I do), if you
> don't, then don't use it.

Technically.... bugzilla is optional too.  I'm doing a good job of ignoring it.

And I think this line of argumentation is sort of moot. I think the
problem is we aren't getting enough feedback into bodhi to know
whether or not bodhi is competing with bugzilla.

I don't think the problem is the design of bodhi "the webservice", I
think the problem is we don't have a streamlined way to pull feedback
from users in a timely manner to impact updates-testing.

In aggregate how many karma votes do we get averaged for all current
updates-testing packages in a given week?

1) We need bodhi integration into PK, so people who choose to use
updates-testing get timely reminders and client side help in send in
feedback for each and every update in testing they consume.

2) We need updates-testing enablement to be an in your face install
time option, where we make the case to users to use updates-testing to
help other users avoid problems

3)...

4) profit


-jef



From jkeating at redhat.com  Thu Dec 11 17:06:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 09:06:17 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghqfsl$pnm$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<ghq7vu$5to$5@ger.gmane.org> <ghqcjc$iea$1@ger.gmane.org>
	<ghqfsl$pnm$1@ger.gmane.org>
Message-ID: <1229015177.3863.87.camel@localhost.localdomain>

On Thu, 2008-12-11 at 08:35 +0100, Kevin Kofler wrote:
> Well, I agree with you on this point:
> * Updates should contain a description of:
> - what's new (a link to the upstream changelog will do, or the maintainer
> can sum up the changes him/herself) and
> - where not immediately obvious ("This bugfix release was pushed to fix the
> bugs in the previous release.", duh), why the update is being pushed
> (e.g. "new version of libfoo needed for the latest bugfix version of bar").
> * If the update fixes a bug filed in Fedora, the Bugzilla reference should
> be present.
> * Non-critical, non-trivial updates (and in most cases version upgrades are
> neither critical nor trivial, but there are exceptions) should stay in
> updates-testing for at least a week.

These are a pretty reasonable start to a set of guidelines to help users
determine when and what to push as updates.

Kevin, you seem to have a pretty strong stake in this discussion,
perhaps you and I and any others that are interested can get together on
IRC and try to hash out a set of guidelines like the above to put in a
wiki place somewhere that new (and existing) contributors can reference
when deciding if they should do an update or not?

I think one of the big problems we have is new maintainer training, and
lack of guidelines like the above.  We just expect them to "figure it
out" and we shouldn't be surprised when something goes wrong.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/22323351/attachment.sig>

From s-t-rhbugzilla at wwwdotorg.org  Thu Dec 11 17:11:57 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Dec 2008 10:11:57 -0700 (MST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229014165.3863.79.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
Message-ID: <1229015518.2753.TMDA@tmda.severn.wwwdotorg.org>

On Thu, December 11, 2008 9:49 am, Jesse Keating wrote:
> On Thu, 2008-12-11 at 08:38 +0100, Kevin Kofler wrote:
>> You have to decide: do you want updates or do you not want them? If you
>> don't want to wait for the next CentOS release, then obviously you need
>> the
>> update quickly, so you are in Fedora's target base. But then you can't
>> complain that you get updates too quickly! You can't have both ways.
>> (You're one of those users with contradictory requirements I mentioned
>> elsewhere in this thread.)
>
> Updates != upgrades.
>
> I think frequent updates to given package set to fix bugs is great.
> Frequent upgrades to a package set for new upstream features, behavior,
> bugs, incompatibilities is not so great.
>
> With the 6 month cycle of Fedora, and our willingness to break things
> like crazy in the rawhide world, we're still a very very fast distro and
> unique in the distro space for early adoption of software.  This all
> comes /without/ even considering what we do for updates to our releases.
> Even if our releases only got bugfixes, we're still uniquely agile to
> new software and technologies and very fast to new releases using those
> things.

I think this eloquently states exactly what some people are trying to say.
Especially the first sentence of the last paragraph I quoted.



From jkeating at redhat.com  Thu Dec 11 17:12:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 09:12:25 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghr1gd$d8j$1@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<ghqfsl$pnm$1@ger.gmane.org> <ghqiqd$1h2$1@ger.gmane.org>
	<200812111249.16961.opensource@till.name> <ghr1gd$d8j$1@ger.gmane.org>
Message-ID: <1229015545.3863.88.camel@localhost.localdomain>

On Thu, 2008-12-11 at 13:36 +0100, Kevin Kofler wrote:
> 
> Yes, one of the big problems with strict "no new versions" policies is that
> it prevents bugfixes too. Debian stable and even Ubuntu tend to have many
> bugs which could be fixed by simply upgrading to a bugfix version, yet they
> won't do it.

I'm not asking for a strict and inflexible policy.  Please don't imagine
the worst scenario in the world.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/c3376fe7/attachment.sig>

From jkeating at redhat.com  Thu Dec 11 17:15:57 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 09:15:57 -0800
Subject: Installing from Live CD is the new black?
In-Reply-To: <4940B89E.8050400@nicubunu.ro>
References: <1228955078.3037.10.camel@fecusia> <4940B89E.8050400@nicubunu.ro>
Message-ID: <1229015757.3863.89.camel@localhost.localdomain>

On Thu, 2008-12-11 at 08:52 +0200, Nicu Buculei wrote:
> 
> > And I cannot switch to say harddisk or netinstall either, none of
> that
> > works as it should.
> 
> I had troubles with the hard disk install too for F10, I wanted to 
> perform the install without burning a DVD but it refused to play.

The setup for harddrive or network iso has changed, such that you now
need an images/ directory with the install.img file within it at the
same level as the directory of your isos.  We no longer crack open the
isos in loader to find a image to use to bring up anaconda.  This is in
the install guide for F10.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/f331e945/attachment.sig>

From lesmikesell at gmail.com  Thu Dec 11 17:18:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 11:18:50 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228993069.3394.841.camel@beck.corsepiu.local>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>	<ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org>	<ghqfsl$pnm$1@ger.gmane.org>
	<ghqiqd$1h2$1@ger.gmane.org>
	<1228993069.3394.841.camel@beck.corsepiu.local>
Message-ID: <49414B7A.1060903@gmail.com>

Ralf Corsepius wrote:
> On Thu, 2008-12-11 at 19:25 +1100, Bradley Baetz wrote:
>> Kevin Kofler wrote:
>>> Bradley Baetz wrote:
>>>> Why is waiting for a new feature for 3 months too long?
>>> Because the user has work to do which requires the new feature.
>> Sometimes, sure. But (again excluding new hardware) how often does that 
>> happen?
> More often than you might think. 

But, balance that against the advice given here to people who complained 
about KDE 4.0 not being ready for prime time, which was that "nobody 
forced you to upgrade to F9".

> More precisely, as a developer, to me, this is the #1 motivation to use
> Fedora. Otherwise, I could use a different distro.
> 
> As a participant in Fedora, other almost equally important aspects comes
> into play: Tayloring the distro to meet my personal demands and having a
> possibilities fix bugs quickly.
> 
> Having to wait for "at average 3 months", would widely waste these
> aspects and render Fedora non-interesting to me.

But pushing broken stuff may force people to wait even longer to get 
something they can use, plus all the trouble of having to back out 
updates or upgrades which has no convenient mechanism.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From james at fedoraproject.org  Thu Dec 11 17:19:18 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 11 Dec 2008 12:19:18 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4940BCB9.9070408@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>
	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>
	<493F6B8F.8010209@gmail.com>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com>
	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>
	<ghqb66$brb$5@ger.gmane.org>  <4940BCB9.9070408@gmail.com>
Message-ID: <1229015958.30987.133.camel@code.and.org>

On Thu, 2008-12-11 at 01:09 -0600, Les Mikesell wrote:
> Kevin Kofler wrote:
> >
> >>> And presumably you (and everybody else) would wait out the "until known
> >>> good" period; and as nobody tried it before, get to keep the pieces of
> >>> the resulting breakage...
> >> If that is true, then it would mean there's nobody who wants bleeding
> >> edge. That in turn would mean that Fedora should be redefined to not be
> >> bleeding edge, because nobody wants it that way...
> > 
> > The problem is that users are asking for contradictory/impossible things:
> > they want new versions as soon as possible, i.e. the day upstream releases
> > them, but also updates tested for weeks.
> 
> That's only contradictory because you make it so.

 It's contradictory because that's the way the world works. Look at Eg.
RHEL-5 updates vs. Fedora 9 updates. Some of them have even had
basically the same code, at the beginning.
 But the RHEL-5 updates go through a 6-9+ month (depending on how you
count) window of testing, and thus. the end result is drastically
different. If the end result is actually better or worse than what is in
Fedora 10 (or even Fedora 9 testing, now) is very much a matter of
opinion, and depends on how far along the line of slow/conservative vs.
faster/liberal you actually want to be.

 There is no magic pixie dust which will turn 9+ months of work into a
few days (even assuming an equal QA resource).

>  In the lifespan of a 
> fedora package, it will exist as a barely-tested release or feature 
> update, perhaps quickly followed by many updates with needed fixes, then 
> aging into being mostly well-tested code. But by bundling all the 
> packages together in rolling updates you make it impossible to avoid the 
>   barely-tested instances on machines where you can't risk them even 
> though they may only have a short lifespan.

 Even if this was strictly true, which it isn't, yum allows you to do
more than either "do nothing" or "yum upgrade -y".
 However in reality packages don't neatly fit into the above boxes
equally for all users.

-- 
James Antill <james at fedoraproject.org>
Fedora



From pertusus at free.fr  Thu Dec 11 17:20:58 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 11 Dec 2008 18:20:58 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229015177.3863.87.camel@localhost.localdomain>
References: <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org> <ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org> <ghqfsl$pnm$1@ger.gmane.org>
	<1229015177.3863.87.camel@localhost.localdomain>
Message-ID: <20081211172058.GG2647@free.fr>

On Thu, Dec 11, 2008 at 09:06:17AM -0800, Jesse Keating wrote:
> 
> These are a pretty reasonable start to a set of guidelines to help users
> determine when and what to push as updates.

I think that it is already pretty good in:
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users
though I don't know what is the approval status of this document.
In general I think that
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility
is well balanced and gives a taste of what are the best practices
without being too binding. 

Problem is that those practices are at odd with what many maintainers do, 
they don't care about regressions or even don't fix bugs, nor ask for 
help and don't consider patches. They don't help fixing other packages 
before they hit stable.

> I think one of the big problems we have is new maintainer training, and
> lack of guidelines like the above.  We just expect them to "figure it
> out" and we shouldn't be surprised when something goes wrong.

I don't think the most problematic updates are those from new
maintainers, the problematic ones are those corresponding with packages
that are used by other packages (non leave packages), or leave packages 
with significant user base, and those are not maintained by new
maintainers.

That being said I think that inded the policies part of the wiki 
http://fedoraproject.org/wiki/PackageMaintainers/Policy
should be up to date, and as easy to read as possible, and should
contain
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility
and indeed new maintainers should read those, but new maintainers rarely
break fedora.

--
Pat



From opensource at till.name  Thu Dec 11 17:27:49 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 18:27:49 +0100
Subject: Installing from Live CD is the new black?
In-Reply-To: <1229015757.3863.89.camel@localhost.localdomain>
References: <1228955078.3037.10.camel@fecusia> <4940B89E.8050400@nicubunu.ro>
	<1229015757.3863.89.camel@localhost.localdomain>
Message-ID: <200812111828.00512.opensource@till.name>

On Thu December 11 2008, Jesse Keating wrote:

> The setup for harddrive or network iso has changed, such that you now
> need an images/ directory with the install.img file within it at the
> same level as the directory of your isos.  We no longer crack open the
> isos in loader to find a image to use to bring up anaconda.  This is in
> the install guide for F10.

Will this be restored for F11? It was very helpful when using a usb medium to 
install from. Btw. shouldn't it be mentioned in the release notes? It is imho 
big change in anaconda.

http://docs.fedoraproject.org/release-
notes/f10/en_US/What_is_New_for_Installation_and_Live_Images.html#sn-
Changes_in_Anaconda

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/8e2a18b8/attachment.sig>

From a.badger at gmail.com  Thu Dec 11 17:26:55 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 11 Dec 2008 09:26:55 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228938482.3863.45.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
Message-ID: <49414D5F.4010202@gmail.com>

Jesse Keating wrote:
> If you're putting your potentially destabilizing feature adding version
> change into updates-testing, I've already lost my plea.  Once in
> -testing, it's presumed that it, or something even newer, will be
> promoted to -updates, which ruins the whole thing.  
>

Unfortunately, this is driven to some extent by upstreams and their
level of sanity.

For instance, I'm packaging a project that does one-month time based
releases.  These releases can have new features and speed improvements.
They also have bugfixes.  They also have new on-disk formats.  The
project is a (python) library and commandline tool.  The library API can
change incompatibly with new releases.

So we have two bad choices here.  In the course of a released Fedora's
life, there are roughly twelve updates from upstream.  If those fix
major bugs or add a new on-disk formats I pretty much have to update
otherwise our end-users suffer (from not being able to communicate with
people using Ubuntu, Debian, or upstream).  If they change API
incompatibly then I'm possibly breaking third-party tools.

So here we've lost whether or not we make updates.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/0eea5370/attachment.sig>

From christoph.wickert at googlemail.com  Thu Dec 11 17:34:36 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 11 Dec 2008 18:34:36 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <1229010046.3394.1149.camel@beck.corsepiu.local>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>  <ghrbgn$ha9$1@ger.gmane.org>
	<1229010046.3394.1149.camel@beck.corsepiu.local>
Message-ID: <1229016876.3381.42.camel@wicktop.localdomain>

Am Donnerstag, den 11.12.2008, 16:40 +0100 schrieb Ralf Corsepius:
> On Thu, 2008-12-11 at 09:27 -0600, Rex Dieter wrote:
> > Matej Cepl wrote:
> > 
> > > On 2008-12-09, 12:03 GMT, Sven Lankes wrote:
> > >> We should try to get the bohdi-karma-mechanism more popular.
> > > 
> > > IMNSHO we should get rid of it
> 
> +1. It's superfluous.
> 
> >  -- there is already one very good
> > > mechanism for registering bugs in the software and it is
> > > bugzilla.
> Agreed. Bug reporters report success/failure through bugzilla.

How is this supposed to work? File a bug "your package works fine" each
and every time?

_If_ we wanted to use bugzilla to provide feedback it needs to be much
smarter, faster and more easy to use than now. And to be honest I have
no idea how to do that.

> > Bodhi feedback is a *complement* to bugzilla, not a replacement.
> 
> Feedback has nothing to do with "bodhi's karma counters".

It has, only nothing to do with automatically pushing updates based on
karma.

> 
> Ralf

Regards,
Christoph



From christoph.wickert at googlemail.com  Thu Dec 11 17:41:50 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 11 Dec 2008 18:41:50 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <1229014354.3394.1226.camel@beck.corsepiu.local>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
Message-ID: <1229017310.3381.48.camel@wicktop.localdomain>

Am Donnerstag, den 11.12.2008, 17:52 +0100 schrieb Ralf Corsepius:
> On Thu, 2008-12-11 at 17:08 +0100, Sven Lankes wrote:
> > On Wed, Dec 10, 2008 at 11:58:51AM +0100, Matej Cepl wrote:
> > 
> > >> We should try to get the bohdi-karma-mechanism more popular. 
> >  
> > > IMNSHO we should get rid of it -- there is already one very good 
> > > mechanism for registering bugs in the software and it is 
> > > bugzilla.
> > 
> > Which can cater for negative feedback. I don't think most people would
> > be too happy with bz-entries created just containing 'works for me'.
> But this is exactly what is happening.
> 
> Cf. https://bugzilla.redhat.com/show_bug.cgi?id=475943
> for a real world case.

Huh? This does not look like positive feedback to me but like a normal
bug report.

> ... no matter which karma a package would get, it would still be the
> maintainer who overrules.

+1. Let's get rid of karma automatism, at least no enabled by default.
> 
> Ralf

Regards,
Christoph



From hughsient at gmail.com  Thu Dec 11 17:42:12 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 11 Dec 2008 17:42:12 +0000
Subject: Making updates-testing more useful
In-Reply-To: <1228933404.2682.7.camel@scrappy.miketc.net>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
Message-ID: <1229017332.15913.3.camel@hughsie-work.lan>

On Wed, 2008-12-10 at 12:23 -0600, Mike Chambers wrote:
> And I guess (not to get too detailed into something not created yet)
> those updates would stay polluted in the GUI until you make a comment
> or remove it yourself (this would help show what you have left to
> comment on so you can remember)?

What about the attached mockup? This would tell people there are updates
available, but not configured. Comments welcome.

Richard.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-1 (copy).jpg
Type: image/jpeg
Size: 17542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/f4e39053/attachment.jpg>

From james at fedoraproject.org  Thu Dec 11 17:45:23 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 11 Dec 2008 12:45:23 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081211124523.GA31161@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
Message-ID: <1229017523.30987.138.camel@code.and.org>

On Thu, 2008-12-11 at 13:45 +0100, Robert Scheck wrote:
>  Yum-updatesd could
> get a cronjob - I think being up-to-date is nice, but being too up-to-date
> can hurt very much for a Fedora user nowadays (e.g. dbus).

 The main reason? it was a daemon initially is that pirut/pupplet spoke
to it over dbus.
 Changing yum-cron to use yum-updatesd --oneshot was on my TODO list a
long time ago, but it turned out to be non-trivial and keep backwards
compat. with both pieces ... so nothing happened to either piece.


? One other feature is that we wanted "hourly" but with a random start,
so if everyone turned their computer on at 9am it wouldn't slam the
repo. ... this might be possible in newer cron's though.

-- 
James Antill <james at fedoraproject.org>
Fedora



From lesmikesell at gmail.com  Thu Dec 11 17:45:47 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 11:45:47 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <200812111242.15428.opensource@till.name>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org>
	<200812111242.15428.opensource@till.name>
Message-ID: <494151CB.3020605@gmail.com>

Till Maas wrote:
> 
>>>> Can someone who wants the new versions immediately explain why they
>>>> don't want to wait an average of 3 months for the next fedora release?
>>> Because if you need the bugfix or the new feature now, any wait is too
>>> long.
>> Why is waiting for a new feature for 3 months too long? Excluding
>> support for new hardware, if you want a bleeding edge feature run rawhide.
> 
> For me it would render my Fedora involvment in many cases useless, e.g. why 
> should I push a new package into Fedora, if I have to create my own repo 
> anyways to use it?

As has been mentioned before, a totally new package has little risk. 
The problem comes when you push an update that breaks existing 
usability.  Since there is no policy or mechanism to prevent that, every 
user is forced to create their own repo and run a test machine to have 
any chance of avoiding them - or just not use fedora at all.

> Also if I get upstream to include a feature I need into an 
> application I want to use, then I want to use it asap. Otherwise I would 
> probably not spend much time on writing a patch or convincing upstream.

Anyone who _wants_ todays bugs from upstream can always grab their 
tarball and build it under /usr/local/ with the big advantage of having 
a way back when they find it doesn't quite work.

> Also running rawhide is not an option, because it is way more broken than 
> Fedora stable, where it seems to me the majority of updates do not break 
> stuff.

Majority?  It only takes one broken update to wreck your machine.

-- 
  Les Mikesell
   lesmikesell at gmail.com



From jspaleta at gmail.com  Thu Dec 11 17:52:13 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 08:52:13 -0900
Subject: Making updates-testing more useful
In-Reply-To: <1229017332.15913.3.camel@hughsie-work.lan>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
Message-ID: <604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>

2008/12/11 Richard Hughes <hughsient at gmail.com>:
> What about the attached mockup? This would tell people there are updates
> available, but not configured. Comments welcome.

I think that's an interesting approach to communicating the existence
of testing.

I would appreciate some text which invited them to enable the
corresponding repository to help with testing and an Amazon patented
One-Click way of enabling testing if they so choose in that dialog.  I
also want a pony if you weren't already aware.

-jef



From james at fedoraproject.org  Thu Dec 11 17:56:31 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 11 Dec 2008 12:56:31 -0500
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <604aa7910812110904i3f8e04a3lee8929cb34862e42@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <ghrbgn$ha9$1@ger.gmane.org>
	<1229010046.3394.1149.camel@beck.corsepiu.local>
	<ghrd5b$ne2$1@ger.gmane.org>
	<604aa7910812110904i3f8e04a3lee8929cb34862e42@mail.gmail.com>
Message-ID: <1229018191.30987.146.camel@code.and.org>

On Thu, 2008-12-11 at 08:04 -0900, Jeff Spaleta wrote:
> On Thu, Dec 11, 2008 at 6:55 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
> > Shrug, karma is optional. Many maintainers appreciate it (I do), if you
> > don't, then don't use it.
> 
> Technically.... bugzilla is optional too.  I'm doing a good job of ignoring it.
> 
> And I think this line of argumentation is sort of moot. I think the
> problem is we aren't getting enough feedback into bodhi to know
> whether or not bodhi is competing with bugzilla.
> 
> I don't think the problem is the design of bodhi "the webservice", I
> think the problem is we don't have a streamlined way to pull feedback
> from users in a timely manner to impact updates-testing.
> 
> In aggregate how many karma votes do we get averaged for all current
> updates-testing packages in a given week?
> 
> 1) We need bodhi integration into PK, so people who choose to use
> updates-testing get timely reminders and client side help in send in
> feedback for each and every update in testing they consume.

 Yes! ... but good luck.

> 2) We need updates-testing enablement to be an in your face install
> time option, where we make the case to users to use updates-testing to
> help other users avoid problems

 No, what you really want is your package manager integration so you can
say:

1. "You searched for FOO", there is version 1-1 in your Fedora release
version 1-2 has been in testing for X days and has Y karma, and version
2-1 is in "rawhide" but is installable with no / Z number of required
packages.

2. I noticed that FOO package just crashed, there is an update available
in testing which fixes these BugZillas:

12234666 - Random crashes when doing XYZ

etc.

...but, again, it doesn't fit into the design/philosophy of PK so it'll
be a huge amount of work.

-- 
James Antill <james at fedoraproject.org>
Fedora



From fedora at matbooth.co.uk  Thu Dec 11 18:02:32 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Thu, 11 Dec 2008 18:02:32 +0000
Subject: Server SIG - work areas
In-Reply-To: <m3abb24qvo.fsf@ursa.amorsen.dk>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
	<20081209104858.GG3833@free.fr>
	<9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>
	<9497e9990812090502v40665382sf157e54783286033@mail.gmail.com>
	<m3abb24qvo.fsf@ursa.amorsen.dk>
Message-ID: <9497e9990812111002g1702037q6839bb384aed9e9@mail.gmail.com>

On Thu, Dec 11, 2008 at 4:29 PM, Benny Amorsen wrote:
> PS Ponies. Why doesn't Fedora provides ponies?
>

Because they're too big to fit in the bikeshed. ;-)


-- 
Mat Booth
www.matbooth.co.uk



From james at fedoraproject.org  Thu Dec 11 18:02:55 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 11 Dec 2008 13:02:55 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghq9cu$brb$1@ger.gmane.org>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>
	<20081211011210.GB2883@yoda.jdub.homelinux.org>
	<ghq81g$98v$1@ger.gmane.org>  <ghq9cu$brb$1@ger.gmane.org>
Message-ID: <1229018575.30987.150.camel@code.and.org>

On Thu, 2008-12-11 at 06:45 +0100, Kevin Kofler wrote:
> Bradley Baetz wrote:
> > A lot of them were zero-day 'new package didn't make the freeze so chuck
> > it in ASAP' updates. Again, you can argue that new packages don't break
> > anything, but it comes back to the 'what is fedora's goal' discussion
> > that happens whenever this discussion happens....
> 
> But why do you want to ban something which doesn't hurt?

 I agree with this, much like new drivers in the kernel I think you have
to decide that new packages are different from real updates.

> What will happen with your proposed ban is that many users will
> use --enablerepo=rawhide to get the packages they need and break their
> systems that way (one should NEVER use --enablerepo=rawhide except to
> upgrade the ENTIRE system to Rawhide (yum --enablerepo=rawhide upgrade),
> and that carries the usual Rawhide risks). It is not possible to just
> install an arbitrary package from Rawhide because that will in many cases
> depend on other packages from Rawhide (right now it's Python 2.6, sometimes
> it's a new OpenSSL, OpenLDAP or whatever core library), and upgrading those
> in turn also forces the upgrade of everything else depending on those (e.g.
> if the upgrade drags in Python 2.6, it will also drag in all the other
> Python stuff including yum!).

 That's not true, I've used that all the time (I was testing the new PK
versions on Fedora 9 for months using that method) ... although
obviously when a glibc/python/whatever update happens and yum wants to
bring in 666 other packages, you want to say no at the prompt.

-- 
James Antill <james at fedoraproject.org>
Fedora



From james at fedoraproject.org  Thu Dec 11 18:06:44 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 11 Dec 2008 13:06:44 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081211011210.GB2883@yoda.jdub.homelinux.org>
References: <604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org>
	<20081211011210.GB2883@yoda.jdub.homelinux.org>
Message-ID: <1229018804.30987.155.camel@code.and.org>

On Wed, 2008-12-10 at 20:12 -0500, Josh Boyer wrote:
> On Thu, Dec 11, 2008 at 10:55:33AM +1100, Bradley Baetz wrote:

> > F9 -> F9+updates:
> >
> > Added Packages: 831
> > Removed Packages: 0 (0 obsoleted)
> > Modified Packages: 1608
[...]
> > F10 -> F10+updates:
> >
> > Added Packages: 134
> > Removed Packages: 0 (0 obsoleted)
> > Modified Packages: 396
[...]
> And I find this to be a bit scary.  134 new packages have gone into
> F10 in 2 weeks via updates??

 Why is this scarey? It's roughly the same as the F9 number,
proportionally.
 F9 is (roughly) 28 weeks old and has 831 added, F10 is 2 weeks old
(with 2-3 weeks between freeze and GA in both cases). That's about 30
packages a week.

-- 
James Antill <james at fedoraproject.org>
Fedora



From chris.stone at gmail.com  Thu Dec 11 18:09:52 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 11 Dec 2008 10:09:52 -0800
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
	<1229007272.3537.23.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
Message-ID: <d9c612bf0812111009s23538e2bu218bdc759a3016d3@mail.gmail.com>

On Thu, Dec 11, 2008 at 7:01 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> Spam Harvester?

Maybe he is trying to pick up security vulnerabilities in bug reports
before the bug can be marked as unviewible.



From opensource at till.name  Thu Dec 11 17:44:12 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 18:44:12 +0100
Subject: Package Review Stats for the week ending December  7, 2008
In-Reply-To: <1228770379.5346.3.camel@localhost.localdomain>
References: <1228770379.5346.3.camel@localhost.localdomain>
Message-ID: <200812111844.22764.opensource@till.name>

On Mon December 8 2008, Brian Pepple wrote:
> Top four FAS account holders who have completed reviewing "Package
> review" components on bugzilla for the week ending December 7th, 2008
> were Parag AN(????), Jason Tibbitts, Michael Schwendt, and Patrice
> Dumas.  Below is the number of completed package reviews done.

If it is not too much work, can you maybe mention how many merge reviews were 
done?

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/781a2401/attachment.sig>

From jamundso at gmail.com  Thu Dec 11 18:16:08 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Thu, 11 Dec 2008 12:16:08 -0600
Subject: Server SIG - work areas
In-Reply-To: <m3abb24qvo.fsf@ursa.amorsen.dk>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<1228141690.3451.65.camel@beta> <1228816621.1673.6.camel@moose>
	<1228819287.3626.62.camel@eagle.danny.cz>
	<20081209104858.GG3833@free.fr>
	<9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>
	<9497e9990812090502v40665382sf157e54783286033@mail.gmail.com>
	<m3abb24qvo.fsf@ursa.amorsen.dk>
Message-ID: <6d06ce20812111016o795bee9fkd97a64dca5311b85@mail.gmail.com>

On Thu, Dec 11, 2008 at 10:29 AM, Benny Amorsen <benny+usenet at amorsen.dk> wrote:
> "Mat Booth" <fedora at matbooth.co.uk> writes:
>
>> Sorry for replying to myself, but another thought occurred after I hit
>> send: Maybe I don't understand *why* you need bleeding edge if what
>> you want is stability...
>
> I want bleeding edge when we first develop new systems, so I get all
> the new shiny features for the beta testers to play with... Then when
> the bugs have been found, everything should stay stable without
> needing significant care for a few years, until the system is replaced
> with a new even shinier one and the cycle continues.
>
> Red Hat Enterprise Linux provides stability. Fedora provides bleeding
> edge. Lots of people, including me, want both.
>
> That doesn't mean we get to have both.

No, that doesn't mean we *can't* have both.

The infrastructure needed is close.
The quality of people is about right, but the quantity is a few short.
With some *cooperation* from all sides, and maybe a kick in the ...,
er, some gentle nudging from leaders, we can implement both. We _need_
to implement both.

jerry

-- 
Store in cool, dry place. Rotate stock.



From clumens at redhat.com  Thu Dec 11 18:16:31 2008
From: clumens at redhat.com (Chris Lumens)
Date: Thu, 11 Dec 2008 13:16:31 -0500
Subject: Installing from Live CD is the new black?
In-Reply-To: <200812111828.00512.opensource@till.name>
References: <1228955078.3037.10.camel@fecusia> <4940B89E.8050400@nicubunu.ro>
	<1229015757.3863.89.camel@localhost.localdomain>
	<200812111828.00512.opensource@till.name>
Message-ID: <20081211181630.GA27793@localhost.localdomain>

> Will this be restored for F11?

No.

> It was very helpful when using a usb medium to install from.

If you could describe the problem  you're having with the new mechanism
and USB disks, I can work on fixing it in time for F11.  It may even be
fixable for F10 with an updates.img.  I'd be interested to see what
you're doing and exactly how it's going wrong.

> Btw. shouldn't it be mentioned in the release notes? It is imho 
> big change in anaconda.
> 
> http://docs.fedoraproject.org/release-
> notes/f10/en_US/What_is_New_for_Installation_and_Live_Images.html#sn-
> Changes_in_Anaconda

Yes, it most certainly should have, and that's probably my fault.  As
Jesse stated, it is at least mentioned in the install guide:

   http://docs.fedoraproject.org/install-guide/f10/en_US/sn-installing-from-harddrive.html

I probably got confused about where and how many times that needed to be
described.  Sorry.

- Chris



From clumens at redhat.com  Thu Dec 11 18:18:57 2008
From: clumens at redhat.com (Chris Lumens)
Date: Thu, 11 Dec 2008 13:18:57 -0500
Subject: Installing from Live CD is the new black?
In-Reply-To: <1228955078.3037.10.camel@fecusia>
References: <1228955078.3037.10.camel@fecusia>
Message-ID: <20081211181856.GB27793@localhost.localdomain>

> Is it just me or doesn't everybody make their installs off the Live CD
> these days?

I do kind of wish everyone used live CDs, but that's probably never
going to be the way it works.

> And I cannot switch to say harddisk or netinstall either, none of that
> works as it should.

This is likely due to the changes I made in how we find the install.img.
Please refer to my other post in this thread, which references the
install guide.

- Chris



From skvidal at fedoraproject.org  Thu Dec 11 18:17:30 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 13:17:30 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229017523.30987.138.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
Message-ID: <alpine.LFD.2.00.0812111314480.14070@localhost.localdomain>



On Thu, 11 Dec 2008, James Antill wrote:

> On Thu, 2008-12-11 at 13:45 +0100, Robert Scheck wrote:
>>  Yum-updatesd could
>> get a cronjob - I think being up-to-date is nice, but being too up-to-date
>> can hurt very much for a Fedora user nowadays (e.g. dbus).
>
> The main reason? it was a daemon initially is that pirut/pupplet spoke
> to it over dbus.
> Changing yum-cron to use yum-updatesd --oneshot was on my TODO list a
> long time ago, but it turned out to be non-trivial and keep backwards
> compat. with both pieces ... so nothing happened to either piece.
>
>
> ? One other feature is that we wanted "hourly" but with a random start,
> so if everyone turned their computer on at 9am it wouldn't slam the
> repo. ... this might be possible in newer cron's though.
>

Amusingly yum has had this for a long time:

yum -R <minutes>

:)

yum-cron has used it in the past.

I'll be honest the everything-as-its-own-daemon thing is not interesting 
until you want to do desktop notifications. Only then do you need things 
to not rely on cron. For servers yum-updatesd and the various daemons 
don't make a lot of sense. Just having yum-cron run to notify and/or 
auto-update security updates is pretty reasonable, if you're not going to 
have set times when you apply updates weekly/biweekly/monthly/quarterly, 
etc

-sv

From jspaleta at gmail.com  Thu Dec 11 18:26:15 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 09:26:15 -0900
Subject: Installing from Live CD is the new black?
In-Reply-To: <20081211181856.GB27793@localhost.localdomain>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
Message-ID: <604aa7910812111026q45f15904h93a9ce09c4b105d5@mail.gmail.com>

On Thu, Dec 11, 2008 at 9:18 AM, Chris Lumens <clumens at redhat.com> wrote:
> I do kind of wish everyone used live CDs, but that's probably never
> going to be the way it works.

Live CDs are sooooo 2002.  You need to start using the phrase Live SDs

-jef



From james at fedoraproject.org  Thu Dec 11 18:28:50 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 11 Dec 2008 13:28:50 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <alpine.LFD.2.00.0812111314480.14070@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<alpine.LFD.2.00.0812111314480.14070@localhost.localdomain>
Message-ID: <1229020130.30987.162.camel@code.and.org>

On Thu, 2008-12-11 at 13:17 -0500, Seth Vidal wrote:
> 
> On Thu, 11 Dec 2008, James Antill wrote:
> 
> > On Thu, 2008-12-11 at 13:45 +0100, Robert Scheck wrote:
> >>  Yum-updatesd could
> >> get a cronjob - I think being up-to-date is nice, but being too up-to-date
> >> can hurt very much for a Fedora user nowadays (e.g. dbus).
> >
> > The main reason? it was a daemon initially is that pirut/pupplet spoke
> > to it over dbus.
> > Changing yum-cron to use yum-updatesd --oneshot was on my TODO list a
> > long time ago, but it turned out to be non-trivial and keep backwards
> > compat. with both pieces ... so nothing happened to either piece.
> >
> >
> > ? One other feature is that we wanted "hourly" but with a random start,
> > so if everyone turned their computer on at 9am it wouldn't slam the
> > repo. ... this might be possible in newer cron's though.
> >
> 
> Amusingly yum has had this for a long time:
> 
> yum -R <minutes>
> 
> :)

 I am aware of that :p~

 Maybe my explanation was bad, what you have is this:

1. Start of "cron like" service for getting updates/whatever.

2. Run of "cron like" service.

3. sleep for 1 hour, then goto #2.

...here we want #1 to have a random-ish start, but the 2<=>3 loop to be
on a simple 1 hour cycle.
 Yum -R is great, and used by yum-cron, but there's no good way to get
the above behaviour with it (doing yum -R 60 every hour means you can
have almost a 2 hour window between runs).

-- 
James Antill <james at fedoraproject.org>
Fedora



From hughsient at gmail.com  Thu Dec 11 18:28:00 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 11 Dec 2008 18:28:00 +0000
Subject: Making updates-testing more useful
In-Reply-To: <604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
Message-ID: <1229020080.26965.0.camel@hughsie-work.lan>

On Thu, 2008-12-11 at 08:52 -0900, Jeff Spaleta wrote:
> I would appreciate some text which invited them to enable the
> corresponding repository to help with testing and an Amazon patented
> One-Click way of enabling testing if they so choose in that dialog.  I
> also want a pony if you weren't already aware.

Yes, we can easily enable the testing repos with a small button and a
more info link. The real question is, will this clutter the UI and
confuse new users?

You're on your own for the pony.

Richard.




From pemboa at gmail.com  Thu Dec 11 18:32:12 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 12:32:12 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229014165.3863.79.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
Message-ID: <16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>

2008/12/11 Jesse Keating <jkeating at redhat.com>:
> On Thu, 2008-12-11 at 08:38 +0100, Kevin Kofler wrote:
>> You have to decide: do you want updates or do you not want them? If you
>> don't want to wait for the next CentOS release, then obviously you need the
>> update quickly, so you are in Fedora's target base. But then you can't
>> complain that you get updates too quickly! You can't have both ways.
>> (You're one of those users with contradictory requirements I mentioned
>> elsewhere in this thread.)
>
> Updates != upgrades.
>
> I think frequent updates to given package set to fix bugs is great.
> Frequent upgrades to a package set for new upstream features, behavior,
> bugs, incompatibilities is not so great.
>
> With the 6 month cycle of Fedora, and our willingness to break things
> like crazy in the rawhide world, we're still a very very fast distro and
> unique in the distro space for early adoption of software.  This all
> comes /without/ even considering what we do for updates to our releases.
> Even if our releases only got bugfixes, we're still uniquely agile to
> new software and technologies and very fast to new releases using those
> things.


6 months is a pretty long time to wait for a major release. I
understand the rationale, but if this is going to be the new Fedora,
best announce this and let  everyone know so that they can reevaluate
if Fedora is for them. As things are, I feel that we are being _too_
conservative. Any further move to more conservatism seriously affects
Fedora's usefulness to me.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From nicolas.mailhot at laposte.net  Thu Dec 11 18:47:32 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Dec 2008 19:47:32 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <49414D5F.4010202@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<49414D5F.4010202@gmail.com>
Message-ID: <1229021252.6236.15.camel@arekh.okg>

Le jeudi 11 d?cembre 2008 ? 09:26 -0800, Toshio Kuratomi a ?crit :

> For instance, I'm packaging a project that does one-month time based
> releases.  These releases can have new features and speed improvements.
> They also have bugfixes.  They also have new on-disk formats.  The
> project is a (python) library and commandline tool.  The library API can
> change incompatibly with new releases.
> 
> So we have two bad choices here.  In the course of a released Fedora's
> life, there are roughly twelve updates from upstream.  If those fix
> major bugs or add a new on-disk formats I pretty much have to update
> otherwise our end-users suffer (from not being able to communicate with
> people using Ubuntu, Debian, or upstream).  If they change API
> incompatibly then I'm possibly breaking third-party tools.

I'm packaging a project that does monthly releases too (or did, it
slowed down a little). Each new release brings bug fixes and features
part of our userbase cares about. Anyone not having the latest features
may have problems communicating with someone who does. Some releases
have made changes that made people complain in the past. This package is
in the default install set and should be installed on 90%+ of our
userbase.

And you know what? I don't push updates to stable releases. I haven't
for a long time. Users can wait a little. The world does not end.

Just say *NO* to systematic stable pushes. It's easy. It does not hurt.
It makes users, releng, doc, and QA happy with you. It gives you more
time to work on better versions of your next packages. It helps upstream
plan when a release need to be stable for Fedora or not.

6 months is really nothing except for update junkies. And update junkies
will be happier with rawhide anyway.

Anything but a major bug fix or initial import has no place in Fedora
updates. Other stuff helps very advanced users who can manage update
breakage and hurts pretty much everyone else.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/7f45641a/attachment.sig>

From lesmikesell at gmail.com  Thu Dec 11 18:50:43 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 12:50:43 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228930226.30987.107.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org>
Message-ID: <49416103.6050900@gmail.com>

James Antill wrote:

>> If you tracked changes in a repo, yum could use that to ensure that it 
>> didn't pull newer packages when you were trying to reproduce a tested 
>> update.
> 
>  Or, without re-writting the entire world ... it could just use the
> NEVRA information that is already there.
> 
>> ... how is that different from a
>>> local mirror. Even better question how is it _better_.
>> Ummm, it saves every user a boatload of work and disk space... More to 
>> the point it is something that they might actually do.
> 
>  Again, transaction ids are just a way of saying "turn a yum repo. into
> a git repo. ... with branches etc." ... but doing that it _still_
> requires the "old" packages, which we don't have.

So, what is the correct plan to avoid getting a broken update onto a 
machine you care about?  Take the one towards the end of FC6 that broke 
machines with certain SCSI adapters as an example.  It was quickly fixed 
but it ruined my day and finalized my opinion of fedora. I'm not 
planning to use fedora again until I see some reason to think that won't 
be repeated.

> And if we did have
> them, then we don't need to integrate git functionality into yum to get
> the behaviour of being able to install older tested packages.

OK, repeatable yum updates would work. Can you maintain an archive 
somewhere?

>  The advantage of a local repo. (with an upstream source) is that you
> have to do minimal work, and you can control when the data changes.

First, maintaining my own repo mirror, _and_ a test machine is just too 
much work to avoid breakage that shouldn't be present anyway, and even 
if I did that, how do you propose that I get the snapshot I want into my 
repository if it changes all the time?  What if I miss the update 
version I really wanted?

>>>  Everyone who spends five minutes thinking about it comes up with "I
>>> know we'll merge the functionality of git and yum, so that you can
>>> follow branches in a repo. etc." ... which _might_ be fine, if _they'd_
>>> actually have to implement it. But I fail to see the significant
>>> advantages over doing all of this work on the repo. side (and possibly
>>> creating tools there, to help -- again, feel free to if you want this).
>> Yes, it is clear that you need version control capability in a package 
>> manager.
> 
>  No, it isn't.

Well someone has to do it.

>>>  By "avoid some of the bugs" I'm going to assume you mean "I want other
>>> people to do work" ... which is nice, but not how it works.
>> No, I have said I would do much more testing if given a design where I 
>> knew I could subsequently update a working machine to exactly the same 
>> set of packages I had tested.  I'm just not willing to mirror a whole 
>> repository to deal with this on my own.
> 
>  Again, other people don't need this extra behaviour ...

What percentage of the world's computers run fedora? .01%?  I'd argue 
that nearly all "other people" need stability fedora doesn't deliver.

>> You misunderstood.  I'm not prepared to be the only tester. I mean "if 
>> you do X, many more people will test".  Basically everyone who runs 
>> fedora needs to do X unless they can afford to be down a while.
> 
>  Again, there are people testing already ... I run many updates from
> updates-testing. What you desire is not required to test things from
> updates-testing.

Can you guarantee that what happened at the end of FC6 won't happen 
again?  If I had a duplicate machine just for testing, what interval of 
updates/tests would I have had to run to have caught and noticed the 
broken update in FC6?  What procedure would I have followed to be sure 
it didn't hit my working system?

>>   Again, why do you expect anyone to test, 
>> whether from updates-testing or elsewhere without a mechanism to use 
>> exactly the package set that they tested on their working machines?
> 
>  Because most people don't need that feature to test, they trust that
> the package owners aren't going to put X-1 into updates-testing and then
> quickly put X-666 into updates, which is completely different, when
> noone is looking.
>  In the _vast_ majority of cases this trust is not misplaced.

If I didn't care whether my machine worked or not, such a sweeping 
generality might sound nice.  But, can you tell me you are certain a 
fedora update will never break something I need to have working again? 
And if not, will you at least admit the need for a mechanism to improve 
that? "Trust" just doesn't trump experience...  And this thread wouldn't 
exist if my experience was unique.

>  As many other people have already told you, many times. If you don't
> trust Fedora, aren't prepared to help test it and think that it isn't
> tested enough for your use ... why don't you just use CentOS/whatever?

As I've said, I'm not willing to test configurations that are 
reproducible because I don't think that makes any sense, and I'm not 
going to maintain my own mirrors of many arbitrary snapshots of a 
rolling repository hoping that sometime I'll catch a good one.

Basically I do use Centos, but didn't someone say that some of the new 
code is useful? I'd like to be able to try it...  As you've pointed out, 
it is 'mostly' usable, but I won't use it until there is some reason to 
think I can avoid the small number of mistakes that happen on the 
machines I care about.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From jspaleta at gmail.com  Thu Dec 11 18:51:14 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 09:51:14 -0900
Subject: Making updates-testing more useful
In-Reply-To: <1229020080.26965.0.camel@hughsie-work.lan>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
Message-ID: <604aa7910812111051r1c2bce57q4aab9f7e5f16fb4e@mail.gmail.com>

On Thu, Dec 11, 2008 at 9:28 AM, Richard Hughes <hughsient at gmail.com> wrote:
> The real question is, will this clutter the UI and
> confuse new users?

Perfectly valid questions, that I am most definitely the wrong person
to look for an answer. Since all the UI's I design are designed to be
user unfriendly.

I am still interesting in the nag notifications if I can get them once
updates-testing is enabled. As an updates-testing user...being nagged
as to what testing things I have installed which deserve some
feedback..would really help me remember to provide feedback.

-jef



From drago01 at gmail.com  Thu Dec 11 18:46:52 2008
From: drago01 at gmail.com (drago01)
Date: Thu, 11 Dec 2008 19:46:52 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
Message-ID: <f6ca9fed0812111046w12807e00i4e2869e4555e089@mail.gmail.com>

On Thu, Dec 11, 2008 at 7:32 PM, Arthur Pemberton <pemboa at gmail.com> wrote:

> 6 months is a pretty long time to wait for a major release. I
> understand the rationale, but if this is going to be the new Fedora,
> best announce this and let  everyone know so that they can reevaluate
> if Fedora is for them. As things are, I feel that we are being _too_
> conservative.

you are kidding right? if not you can just use rawhide.



From jspaleta at gmail.com  Thu Dec 11 19:08:34 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 10:08:34 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <49416103.6050900@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org> <49416103.6050900@gmail.com>
Message-ID: <604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>

On Thu, Dec 11, 2008 at 9:50 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> So, what is the correct plan to avoid getting a broken update onto a machine
> you care about?

How did you know it was a broken update before you installed it?

Assuming you know ahead of time that specific updates are broken you can use
yum exclude directive to exclude specific packages

man yum.conf

-jef



From lesmikesell at gmail.com  Thu Dec 11 19:08:43 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 13:08:43 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229015958.30987.133.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>	<ghqb66$brb$5@ger.gmane.org>
	<4940BCB9.9070408@gmail.com>
	<1229015958.30987.133.camel@code.and.org>
Message-ID: <4941653B.1070509@gmail.com>

James Antill wrote:
> 
>>> The problem is that users are asking for contradictory/impossible things:
>>> they want new versions as soon as possible, i.e. the day upstream releases
>>> them, but also updates tested for weeks.
>> That's only contradictory because you make it so.
> 
>  It's contradictory because that's the way the world works.

No, it is just the way fedora works, randomizing fixes and breakage into 
the same repository over the same time intervals.

> Look at Eg.
> RHEL-5 updates vs. Fedora 9 updates. Some of them have even had
> basically the same code, at the beginning.
>  But the RHEL-5 updates go through a 6-9+ month (depending on how you
> count) window of testing, and thus. the end result is drastically
> different. If the end result is actually better or worse than what is in
> Fedora 10 (or even Fedora 9 testing, now) is very much a matter of
> opinion, and depends on how far along the line of slow/conservative vs.
> faster/liberal you actually want to be.

You are confusing a bunch of different issues here.  One is the time 
cycle.  Fedora could work 'like' RHEL but with a faster cycle, but in 
fact it is nothing like that.  RHEL (A) maintains all packages that have 
ever been introduced to the repository so you can install back-rev 
versions or duplicate a tested configuration and (B) makes a concerted 
effort not to introduce untested new-feature code within a major version 
so stability increases over time.  Fedora does neither.

>  There is no magic pixie dust which will turn 9+ months of work into a
> few days (even assuming an equal QA resource).

No one is asking for that.  The problems with fedora are that there is 
no reason to expect any better stability at the end of a fedora version 
than at the beginning, and there is no way to avoid the breakage 
introduced.  Even if you know a set of working package revisions you 
can't update a new machine just to that set once the repo changes.

>>  In the lifespan of a 
>> fedora package, it will exist as a barely-tested release or feature 
>> update, perhaps quickly followed by many updates with needed fixes, then 
>> aging into being mostly well-tested code. But by bundling all the 
>> packages together in rolling updates you make it impossible to avoid the 
>>   barely-tested instances on machines where you can't risk them even 
>> though they may only have a short lifespan.
> 
>  Even if this was strictly true, which it isn't, yum allows you to do
> more than either "do nothing" or "yum upgrade -y".

But what it can do depends on the repository still having the package 
you want, where the reason you want it is that you know it has been 
tested under the conditions you have.

>  However in reality packages don't neatly fit into the above boxes
> equally for all users.

But that is largely because you throw all the packages in the same box 
and keep shaking it up.  There's no way to know what you'll get next and 
no way back if you don't like it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Thu Dec 11 19:13:49 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 10:13:49 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4941653B.1070509@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493F6B8F.8010209@gmail.com>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com>
	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>
	<ghqb66$brb$5@ger.gmane.org> <4940BCB9.9070408@gmail.com>
	<1229015958.30987.133.camel@code.and.org> <4941653B.1070509@gmail.com>
Message-ID: <604aa7910812111113t350a69aan472d5eafe71953b0@mail.gmail.com>

On Thu, Dec 11, 2008 at 10:08 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> No, it is just the way fedora works, randomizing fixes and breakage into the
> same repository over the same time intervals.

As someone who researches the dynamics of stochastic processes I take
issue with the simplistic use of the word random.


-jef"Fedora Update: tochastic innovation at work"spaleta



From lesmikesell at gmail.com  Thu Dec 11 19:14:18 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 13:14:18 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <alpine.LFD.2.00.0812111314480.14070@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<20081211124523.GA31161@hurricane.linuxnetz.de>	<1229017523.30987.138.camel@code.and.org>
	<alpine.LFD.2.00.0812111314480.14070@localhost.localdomain>
Message-ID: <4941668A.8060600@gmail.com>

Seth Vidal wrote:
>  
> I'll be honest the everything-as-its-own-daemon thing is not interesting 
> until you want to do desktop notifications.

Can't you have something conceptually like inetd as a generic listener 
daemon that starts other processes as needed?

-- 
   Les Mikesell
    lesmikesell at gmail.com




From mw_triad at users.sourceforge.net  Thu Dec 11 19:15:35 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 11 Dec 2008 13:15:35 -0600
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
References: <20081209223300.GA32716@thinkpad>	<20081210031750.GB21432@nostromo.devel.redhat.com>	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>	<20081210143309.GB18314@nostromo.devel.redhat.com>	<20081210213546.GD12080@auslistsprd01.us.dell.com>	<1229007272.3537.23.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
Message-ID: <ghrosn$462$1@ger.gmane.org>

Seth Vidal wrote:
> On Thu, 11 Dec 2008, Tom \"spot\" Callaway wrote:
>> He seems to be tracking most/all of mine as well.
> 
> Spam Harvester?

Given the domain name, that was my first thought as well. I'm glad 
someone else mentioned it.

I've been reluctant to say anything, but does anyone actually *know* 
this person?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
|-\ /-\ \ | -+-   |-\  +  \ | -+- /-\
| | | | |\|  |    |-/ /-\ |\|  |  |
|-/ \-/ | \  |    |   | | | \ -+- \-/



From skvidal at fedoraproject.org  Thu Dec 11 19:25:03 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 14:25:03 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4941668A.8060600@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<alpine.LFD.2.00.0812111314480.14070@localhost.localdomain>
	<4941668A.8060600@gmail.com>
Message-ID: <alpine.LFD.2.00.0812111424500.14070@localhost.localdomain>



On Thu, 11 Dec 2008, Les Mikesell wrote:

> Seth Vidal wrote:
>>  I'll be honest the everything-as-its-own-daemon thing is not interesting 
>> until you want to do desktop notifications.
>
> Can't you have something conceptually like inetd as a generic listener daemon 
> that starts other processes as needed?

That's what dbus is supposed to be able to do.

-sv



From lesmikesell at gmail.com  Thu Dec 11 19:28:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 13:28:02 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229014165.3863.79.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228927014.3863.38.camel@localhost.localdomain>	<49400A28.9080508@gmail.com>	<1228938482.3863.45.camel@localhost.localdomain>	<ghq7as$5to$3@ger.gmane.org>	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>	<ghqc4j$brb$11@ger.gmane.org>
	<4940B92A.1030403@gmail.com>	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
Message-ID: <494169C2.7060305@gmail.com>

Jesse Keating wrote:
> On Thu, 2008-12-11 at 08:38 +0100, Kevin Kofler wrote:
>> You have to decide: do you want updates or do you not want them? If you
>> don't want to wait for the next CentOS release, then obviously you need the
>> update quickly, so you are in Fedora's target base. But then you can't
>> complain that you get updates too quickly! You can't have both ways.
>> (You're one of those users with contradictory requirements I mentioned
>> elsewhere in this thread.)
> 
> Updates != upgrades.
> 
> I think frequent updates to given package set to fix bugs is great.
> Frequent upgrades to a package set for new upstream features, behavior,
> bugs, incompatibilities is not so great.
> 
> With the 6 month cycle of Fedora, and our willingness to break things
> like crazy in the rawhide world, we're still a very very fast distro and
> unique in the distro space for early adoption of software.  This all
> comes /without/ even considering what we do for updates to our releases.
> Even if our releases only got bugfixes, we're still uniquely agile to
> new software and technologies and very fast to new releases using those
> things.

That would also be the simplest possible solution to the scenario of 
satisfying both people who want bleeding-edge and stability.  If the 
first 3 months of a cycle were dedicated to getting the 'best' code 
possible (including new features, etc.) and the subsequent life was to 
the extent possible, restricted to only bug/security fixes, you could 
simply wait to upgrade the more important machines until the system 
stabilized.  And for people who want the new features you are now down 
to a worst-case of only 3 months to the next release.  This is, of 
course, complicated by upstream developers bundling features and fixes 
and the decisions really have to be left to the packagers but some 
generic policy in this direction might help.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Thu Dec 11 19:33:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 13:33:14 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812111113t350a69aan472d5eafe71953b0@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>	<ghqb66$brb$5@ger.gmane.org>
	<4940BCB9.9070408@gmail.com>	<1229015958.30987.133.camel@code.and.org>
	<4941653B.1070509@gmail.com>
	<604aa7910812111113t350a69aan472d5eafe71953b0@mail.gmail.com>
Message-ID: <49416AFA.1000001@gmail.com>

Jeff Spaleta wrote:
> On Thu, Dec 11, 2008 at 10:08 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> No, it is just the way fedora works, randomizing fixes and breakage into the
>> same repository over the same time intervals.
> 
> As someone who researches the dynamics of stochastic processes I take
> issue with the simplistic use of the word random.

Do you have a better explanation of why an update that changed (and 
broke) scsi device detection entered the update repository late in FC6's 
life?  That feature clearly wasn't needed on any machine that was 
already running, and clearly wasn't tested on a variety of hardware 
before being pushed.  From this side of the repo it looks random.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From skvidal at fedoraproject.org  Thu Dec 11 19:34:48 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 14:34:48 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229020130.30987.162.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<alpine.LFD.2.00.0812111314480.14070@localhost.localdomain>
	<1229020130.30987.162.camel@code.and.org>
Message-ID: <alpine.LFD.2.00.0812111433350.14070@localhost.localdomain>



On Thu, 11 Dec 2008, James Antill wrote:

>
> Maybe my explanation was bad, what you have is this:
>
> 1. Start of "cron like" service for getting updates/whatever.
>
> 2. Run of "cron like" service.
>
> 3. sleep for 1 hour, then goto #2.
>
> ...here we want #1 to have a random-ish start, but the 2<=>3 loop to be
> on a simple 1 hour cycle.
> Yum -R is great, and used by yum-cron, but there's no good way to get
> the above behaviour with it (doing yum -R 60 every hour means you can
> have almost a 2 hour window between runs).

Then you have the first run be random, and it marks when it last ran and 
spaces them out for the rest of the time 1 hour later, each.


-sv



From mw_triad at users.sourceforge.net  Thu Dec 11 19:35:30 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 11 Dec 2008 13:35:30 -0600
Subject: Server SIG - work areas
In-Reply-To: <9497e9990812111002g1702037q6839bb384aed9e9@mail.gmail.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>	<1228141690.3451.65.camel@beta>
	<1228816621.1673.6.camel@moose>	<1228819287.3626.62.camel@eagle.danny.cz>	<20081209104858.GG3833@free.fr>	<9497e9990812090500m5fdfddbas70d543edbbc517d6@mail.gmail.com>	<9497e9990812090502v40665382sf157e54783286033@mail.gmail.com>	<m3abb24qvo.fsf@ursa.amorsen.dk>
	<9497e9990812111002g1702037q6839bb384aed9e9@mail.gmail.com>
Message-ID: <ghrq27$96v$1@ger.gmane.org>

Mat Booth wrote:
> On Thu, Dec 11, 2008 at 4:29 PM, Benny Amorsen wrote:
>> PS Ponies. Why doesn't Fedora provides ponies?
>>
> 
> Because they're too big to fit in the bikeshed. ;-)

No they aren't. We're talking about /ponies/, not clydesdales :-). (And 
even if they are, that just means we need to build a bigger bike shed. 
To think! We spend so much time arguing about the color that we've been 
ignoring the much (if you'll excuse the pun) bigger problem of what size 
to make it!)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
|-\ /-\ \ | -+-   |-\  +  \ | -+- /-\
| | | | |\|  |    |-/ /-\ |\|  |  |
|-/ \-/ | \  |    |   | | | \ -+- \-/



From lesmikesell at gmail.com  Thu Dec 11 19:39:01 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 13:39:01 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228930226.30987.107.camel@code.and.org>
	<49416103.6050900@gmail.com>
	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>
Message-ID: <49416C55.6010900@gmail.com>

Jeff Spaleta wrote:
> On Thu, Dec 11, 2008 at 9:50 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> So, what is the correct plan to avoid getting a broken update onto a machine
>> you care about?
> 
> How did you know it was a broken update before you installed it?

That's a separate problem.  It would be nice if only the first person to 
try it had to experience the brokenness, but let's assume I have a test 
machine and I'm the first to notice.  How do I save my production 
machine from the same fate (and on a side note, everyone else)?

> Assuming you know ahead of time that specific updates are broken you can use
> yum exclude directive to exclude specific packages
> 
> man yum.conf

That doesn't sound like something that scales very well.  Can I get the 
package set I want by excluding all other possibilities?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Thu Dec 11 19:42:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 13:42:19 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <alpine.LFD.2.00.0812111424500.14070@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<20081211124523.GA31161@hurricane.linuxnetz.de>	<1229017523.30987.138.camel@code.and.org>	<alpine.LFD.2.00.0812111314480.14070@localhost.localdomain>	<4941668A.8060600@gmail.com>
	<alpine.LFD.2.00.0812111424500.14070@localhost.localdomain>
Message-ID: <49416D1B.5000502@gmail.com>

Seth Vidal wrote:
> 
> 
> On Thu, 11 Dec 2008, Les Mikesell wrote:
> 
>> Seth Vidal wrote:
>>>  I'll be honest the everything-as-its-own-daemon thing is not 
>>> interesting until you want to do desktop notifications.
>>
>> Can't you have something conceptually like inetd as a generic listener 
>> daemon that starts other processes as needed?
> 
> That's what dbus is supposed to be able to do.

But I thought the topic here was that numerous daemons were being 
started just to listen for dbus notifications.  Do you need something 
already connected to your session?

-- 
    Les Mikesell
     lesmikesell at gmail.com



From jamundso at gmail.com  Thu Dec 11 19:54:12 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Thu, 11 Dec 2008 13:54:12 -0600
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <ghrosn$462$1@ger.gmane.org>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
	<1229007272.3537.23.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
	<ghrosn$462$1@ger.gmane.org>
Message-ID: <6d06ce20812111154s5ca7a15bx76c38b365f294a11@mail.gmail.com>

On Thu, Dec 11, 2008 at 1:15 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Seth Vidal wrote:
>>
>> On Thu, 11 Dec 2008, Tom \"spot\" Callaway wrote:
>>>
>>> He seems to be tracking most/all of mine as well.
>>
>> Spam Harvester?
>
> Given the domain name, that was my first thought as well. I'm glad someone
> else mentioned it.
>
> I've been reluctant to say anything, but does anyone actually *know* this
> person?

No, but I had this hair-brained idea to actually e-mail him... :-)
His response:

On Thu, Dec 11, 2008 at 1:40 PM, Marc Riddle <mriddle at valueclick.com> wrote:
> My name is Marc Riddle, I'm a sysadmin @ ValueClick (a redhat customer).
> Just read the thread you're referring to, I had been watching a couple
> addresses @ bugzilla.redhat.com for a bit (a habit I picked up from our
> local BZ instance, gives me plenty of reading material on my PDA when I'm
> out and bored :) ).
>
> Originally just watching a couple maintainers of packages I'm particularly
> interested in, although I added a couple high-volume addrs to my watch list.
> The mails go to a folder with aggressive archiving rules, so I'd completely
> forgotten about them for the last couple months. Sorry if anyone got freaked
> out by my watching, I'll go ahead and drop the bulk of them for now...
>
> Marc Riddle

jerry

-- 
Store in cool, dry place. Rotate stock.



From jspaleta at gmail.com  Thu Dec 11 19:56:49 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 10:56:49 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <49416C55.6010900@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org> <49416103.6050900@gmail.com>
	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>
	<49416C55.6010900@gmail.com>
Message-ID: <604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>

On Thu, Dec 11, 2008 at 10:39 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> That doesn't sound like something that scales very well.  Can I get the
> package set I want by excluding all other possibilities?

config files on client systems don't scale?

exclude as a directive not flexible enough for you?

man yum.conf search for includepkgs

instead of excluding the world, you can include narrowly..as narrowly
as you want...on a per repository basis... on a per client system
basis.

-jef



From skvidal at fedoraproject.org  Thu Dec 11 19:57:00 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 14:57:00 -0500 (EST)
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <6d06ce20812111154s5ca7a15bx76c38b365f294a11@mail.gmail.com>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
	<1229007272.3537.23.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
	<ghrosn$462$1@ger.gmane.org>
	<6d06ce20812111154s5ca7a15bx76c38b365f294a11@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812111456440.14070@localhost.localdomain>



On Thu, 11 Dec 2008, Jerry Amundson wrote:

> On Thu, Dec 11, 2008 at 1:15 PM, Matthew Woehlke
> <mw_triad at users.sourceforge.net> wrote:
>> Seth Vidal wrote:
>>>
>>> On Thu, 11 Dec 2008, Tom \"spot\" Callaway wrote:
>>>>
>>>> He seems to be tracking most/all of mine as well.
>>>
>>> Spam Harvester?
>>
>> Given the domain name, that was my first thought as well. I'm glad someone
>> else mentioned it.
>>
>> I've been reluctant to say anything, but does anyone actually *know* this
>> person?
>
> No, but I had this hair-brained idea to actually e-mail him... :-)
> His response:

Jerry,
  :)

well done.

-sv



From steven.moix at axianet.ch  Thu Dec 11 19:46:22 2008
From: steven.moix at axianet.ch (Steven Moix)
Date: Thu, 11 Dec 2008 20:46:22 +0100
Subject: yum --skip-broken update by default?
Message-ID: <1229024782.7518.7.camel@hp6710.axianet.ch>

Hello,

Last night I had an idea, why not alias "yum update" to "yum
--skip-broken update" by default? This simple hack could prevent a lot
of recurring support questions on the forums:

1) People who have dependency problem won't see them anymore.
2) It doesn't change anything for the rest of the people.

What do you think about that?

Steven



From skvidal at fedoraproject.org  Thu Dec 11 20:09:03 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 15:09:03 -0500 (EST)
Subject: yum --skip-broken update by default?
In-Reply-To: <1229024782.7518.7.camel@hp6710.axianet.ch>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
Message-ID: <alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>



On Thu, 11 Dec 2008, Steven Moix wrote:

> Hello,
>
> Last night I had an idea, why not alias "yum update" to "yum
> --skip-broken update" by default? This simple hack could prevent a lot
> of recurring support questions on the forums:
>
> 1) People who have dependency problem won't see them anymore.

b/c we need to get the dep problems reported, too.

> 2) It doesn't change anything for the rest of the people.
>

sure it does, it means that you think you're updated completely, but 
you're not.

-sv



From notting at redhat.com  Thu Dec 11 20:18:42 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 11 Dec 2008 15:18:42 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
Message-ID: <20081211201842.GA5741@nostromo.devel.redhat.com>

Seth Vidal (skvidal at fedoraproject.org) said: 
>> 1) People who have dependency problem won't see them anymore.
>
> b/c we need to get the dep problems reported, too.

Then you also enable by default the yum-email-dep-problems-to-fedora-devel
plugin.

Bill



From skvidal at fedoraproject.org  Thu Dec 11 20:20:44 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 15:20:44 -0500 (EST)
Subject: yum --skip-broken update by default?
In-Reply-To: <20081211201842.GA5741@nostromo.devel.redhat.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<20081211201842.GA5741@nostromo.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0812111520200.14070@localhost.localdomain>



On Thu, 11 Dec 2008, Bill Nottingham wrote:

> Seth Vidal (skvidal at fedoraproject.org) said:
>>> 1) People who have dependency problem won't see them anymore.
>>
>> b/c we need to get the dep problems reported, too.
>
> Then you also enable by default the yum-email-dep-problems-to-fedora-devel
> plugin.

Do we have an anonymous bug filer account we can use? If so, then, 
well,yes, we can do that.

-sv



From sgallagh at redhat.com  Thu Dec 11 20:24:23 2008
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Thu, 11 Dec 2008 15:24:23 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <alpine.LFD.2.00.0812111520200.14070@localhost.localdomain>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>	<20081211201842.GA5741@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0812111520200.14070@localhost.localdomain>
Message-ID: <494176F7.6010804@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seth Vidal wrote:
> 
> 
> On Thu, 11 Dec 2008, Bill Nottingham wrote:
> 
>> Seth Vidal (skvidal at fedoraproject.org) said:
>>>> 1) People who have dependency problem won't see them anymore.
>>>
>>> b/c we need to get the dep problems reported, too.
>>
>> Then you also enable by default the
>> yum-email-dep-problems-to-fedora-devel
>> plugin.
> 
> Do we have an anonymous bug filer account we can use? If so, then,
> well,yes, we can do that.
> 
> -sv
> 

I would hope that this would be opt-in as well, or we're going to make a
lot of people angry. Some people don't necessarily want to broadcast the
list of packages they have or want on their system - broken or not.

- --

- --------------------
Stephen Gallagher
RHCE 804006346421761
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklBdvcACgkQeiVVYja6o6PexwCdFCLllW5MtWeAysPiTXjpnNpD
NPgAnRrDzWNDrlVxrRVvsujvHyIykk1E
=obDj
-----END PGP SIGNATURE-----



From skvidal at fedoraproject.org  Thu Dec 11 20:25:33 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 11 Dec 2008 15:25:33 -0500 (EST)
Subject: yum --skip-broken update by default?
In-Reply-To: <494176F7.6010804@redhat.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<20081211201842.GA5741@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0812111520200.14070@localhost.localdomain>
	<494176F7.6010804@redhat.com>
Message-ID: <alpine.LFD.2.00.0812111524550.14070@localhost.localdomain>



On Thu, 11 Dec 2008, Stephen Gallagher wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Seth Vidal wrote:
>>
>>
>> On Thu, 11 Dec 2008, Bill Nottingham wrote:
>>
>>> Seth Vidal (skvidal at fedoraproject.org) said:
>>>>> 1) People who have dependency problem won't see them anymore.
>>>>
>>>> b/c we need to get the dep problems reported, too.
>>>
>>> Then you also enable by default the
>>> yum-email-dep-problems-to-fedora-devel
>>> plugin.
>>
>> Do we have an anonymous bug filer account we can use? If so, then,
>> well,yes, we can do that.
>>
>> -sv
>>
>
> I would hope that this would be opt-in as well, or we're going to make a
> lot of people angry. Some people don't necessarily want to broadcast the
> list of packages they have or want on their system - broken or not.

What in fedora is NOT opt-in? Moreover, it's a plugin.

-sv



From thomas.moschny at gmail.com  Thu Dec 11 20:26:46 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 11 Dec 2008 21:26:46 +0100
Subject: yum --skip-broken update by default?
In-Reply-To: <1229024782.7518.7.camel@hp6710.axianet.ch>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
Message-ID: <a9d183c80812111226s2d858562u783f910df7387192@mail.gmail.com>

2008/12/11 Steven Moix <steven.moix at axianet.ch>:
> Last night I had an idea, why not alias "yum update" to "yum
> --skip-broken update" by default? This simple hack could prevent a lot
> of recurring support questions on the forums:
>
> 1) People who have dependency problem won't see them anymore.
> 2) It doesn't change anything for the rest of the people.
>
> What do you think about that?

Originally thought that as well, but then I saw yum --skip-broken
running into an endless loop with the dependency problems yesterday
(and not reacting well to crtl-c), so maybe this is not a good idea.

- Thomas



From dr.diesel at gmail.com  Thu Dec 11 20:29:35 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Thu, 11 Dec 2008 15:29:35 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <494176F7.6010804@redhat.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<20081211201842.GA5741@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0812111520200.14070@localhost.localdomain>
	<494176F7.6010804@redhat.com>
Message-ID: <2a28d2ab0812111229t7fddbe88y59eb7e53475a3507@mail.gmail.com>

On Thu, Dec 11, 2008 at 3:24 PM, Stephen Gallagher <sgallagh at redhat.com>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Seth Vidal wrote:
> >
> >
> > On Thu, 11 Dec 2008, Bill Nottingham wrote:
> >
> >> Seth Vidal (skvidal at fedoraproject.org) said:
> >>>> 1) People who have dependency problem won't see them anymore.
> >>>
> >>> b/c we need to get the dep problems reported, too.
> >>
> >> Then you also enable by default the
> >> yum-email-dep-problems-to-fedora-devel
> >> plugin.
> >
> > Do we have an anonymous bug filer account we can use? If so, then,
> > well,yes, we can do that.
> >
> > -sv
> >
>
> I would hope that this would be opt-in as well, or we're going to make a
> lot of people angry. Some people don't necessarily want to broadcast the
> list of packages they have or want on their system - broken or not.
>

Its not really a problem to simply add --skip-broken when something is
broke.  But I'd be OK with yum automatically using the --skip-broken
feature, explaining what is broke at the end, then asking if it is ok to
report it anonymously.


-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/3fbd2d18/attachment.htm>

From lesmikesell at gmail.com  Thu Dec 11 20:32:01 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 14:32:01 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228930226.30987.107.camel@code.and.org>
	<49416103.6050900@gmail.com>	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>	<49416C55.6010900@gmail.com>
	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>
Message-ID: <494178C1.3040002@gmail.com>

Jeff Spaleta wrote:
> 
>> That doesn't sound like something that scales very well.  Can I get the
>> package set I want by excluding all other possibilities?
> 
> config files on client systems don't scale?
> 
> exclude as a directive not flexible enough for you?
> 
> man yum.conf search for includepkgs
> 
> instead of excluding the world, you can include narrowly..as narrowly
> as you want...on a per repository basis... on a per client system
> basis.

More to the point, how can I expect this to work after the thing I want 
goes away in the repository, replaced by a mistaken push of something 
broken?  I think it is unreasonable to assume that such mistakes will 
never happen.  What's the plan to avoid/recover from this?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Thu Dec 11 20:33:08 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 11:33:08 -0900
Subject: yum --skip-broken update by default?
In-Reply-To: <a9d183c80812111226s2d858562u783f910df7387192@mail.gmail.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<a9d183c80812111226s2d858562u783f910df7387192@mail.gmail.com>
Message-ID: <604aa7910812111233x65e578e7h62d97fad4d462e1e@mail.gmail.com>

On Thu, Dec 11, 2008 at 11:26 AM, Thomas Moschny
<thomas.moschny at gmail.com> wrote:
> Originally thought that as well, but then I saw yum --skip-broken
> running into an endless loop with the dependency problems yesterday
> (and not reacting well to crtl-c), so maybe this is not a good idea.

I bug in software to protect you from encountering bugs in other software.....
oh the irony.

-jef



From jspaleta at gmail.com  Thu Dec 11 20:36:22 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 11:36:22 -0900
Subject: yum --skip-broken update by default?
In-Reply-To: <2a28d2ab0812111229t7fddbe88y59eb7e53475a3507@mail.gmail.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<20081211201842.GA5741@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0812111520200.14070@localhost.localdomain>
	<494176F7.6010804@redhat.com>
	<2a28d2ab0812111229t7fddbe88y59eb7e53475a3507@mail.gmail.com>
Message-ID: <604aa7910812111236q3f5af21ub37b3b8550557c54@mail.gmail.com>

2008/12/11 Dr. Diesel <dr.diesel at gmail.com>:
> Its not really a problem to simply add --skip-broken when something is
> broke.  But I'd be OK with yum automatically using the --skip-broken
> feature, explaining what is broke at the end, then asking if it is ok to
> report it anonymously.

That seems like a reasonable trade-off. IF we can set up an anonymous
drop point that we can easily turn off its being abused with spam.

Don't forget to wrap that in UI for PK as well.

-jef



From jspaleta at gmail.com  Thu Dec 11 20:43:03 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 11:43:03 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <494178C1.3040002@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EE81B.6000909@gmail.com> <1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com> <1228930226.30987.107.camel@code.and.org>
	<49416103.6050900@gmail.com>
	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>
	<49416C55.6010900@gmail.com>
	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>
	<494178C1.3040002@gmail.com>
Message-ID: <604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>

On Thu, Dec 11, 2008 at 11:32 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> More to the point, how can I expect this to work after the thing I want goes
> away in the repository, replaced by a mistaken push of something broken?  I
> think it is unreasonable to assume that such mistakes will never happen.
>  What's the plan to avoid/recover from this?

You keep mixing up different questions. There are different questions

1) How do you know its broken?
... still waiting for you to even explain how you know something is
broken before you install it.

2) Once you know its broken how prevent it from going on to a client system
.... yum's configuration options work just fine for that.

3) If you found out its broken after you installed it on a client
system how do you revert to a previous update?
... you keep a local cache of previously installed updates. yum lets
you keep a local cache..per client. The caching is off by default but
it can be turned on.

-jef



From opensource at till.name  Thu Dec 11 20:56:13 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 21:56:13 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <494151CB.3020605@gmail.com>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<200812111242.15428.opensource@till.name> <494151CB.3020605@gmail.com>
Message-ID: <200812112156.23471.opensource@till.name>

On Thu December 11 2008, Les Mikesell wrote:

> As has been mentioned before, a totally new package has little risk.
> The problem comes when you push an update that breaks existing
> usability.  Since there is no policy or mechanism to prevent that, every
> user is forced to create their own repo and run a test machine to have
> any chance of avoiding them - or just not use fedora at all.

Nobody is forced to install all updates from Fedora. It is easily possible to 
cherry pick the updates one wants to have. Security updates and Bugs from 
Fedoras Bugzilla fixed are usually announced with each update. There exist 
also plugins to help you with this. You could also find a group of people who 
want to cherry pick updates and e.g. announce them in a way that a yum plugin 
only installs them.

> Anyone who _wants_ todays bugs from upstream can always grab their
> tarball and build it under /usr/local/ with the big advantage of having
> a way back when they find it doesn't quite work.

You can also uninstall broken packages with rpm or even better create an 
update with bugs fixed and install it. Also building the tarball does not help 
to verify, whether the package really builds with Fedora, e.g. because of the 
RPM_OPT_FLAGS and it also does not scale if one has more than one machine.

> Majority?  It only takes one broken update to wreck your machine.

I haver had to reinstall any Fedora machine since I began using it with FC4 
because of a broken update and even if it happens once, it is a risk I am 
willing to take. If I have to live with even more unfixed bugs for a long 
period, this would be way worse.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/415552d9/attachment.sig>

From opensource at till.name  Thu Dec 11 21:00:46 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 22:00:46 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <49416103.6050900@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228930226.30987.107.camel@code.and.org> <49416103.6050900@gmail.com>
Message-ID: <200812112200.46965.opensource@till.name>

On Thu December 11 2008, Les Mikesell wrote:

> So, what is the correct plan to avoid getting a broken update onto a
> machine you care about?  Take the one towards the end of FC6 that broke

You can not update at all or only install security related updates and then 
only the ones that fix something, your machine is really vulnerable to.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/9cecf0f4/attachment.sig>

From mschwendt at gmail.com  Thu Dec 11 20:54:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 11 Dec 2008 21:54:33 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <1229010046.3394.1149.camel@beck.corsepiu.local>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <ghrbgn$ha9$1@ger.gmane.org>
	<1229010046.3394.1149.camel@beck.corsepiu.local>
Message-ID: <20081211215433.159b285c.mschwendt@gmail.com>

On Thu, 11 Dec 2008 16:40:46 +0100, Ralf wrote:

> On Thu, 2008-12-11 at 09:27 -0600, Rex Dieter wrote:
> > Matej Cepl wrote:
> > 
> > > On 2008-12-09, 12:03 GMT, Sven Lankes wrote:
> > >> We should try to get the bohdi-karma-mechanism more popular.
> > > 
> > > IMNSHO we should get rid of it
> 
> +1. It's superfluous.

The positive votes are superfluous. This voting method only draws the
attention of users who want to speed up the release of updates, because
they can't get enough. Fedora without hundreds of updates every week
seems to be boring.

The pkgdb "list of open bugs" feature is superior anyway:

  http://bugz.fedoraproject.org/SOURCE_RPM_NAME_HERE

All we need is a convenient way to tag update tickets in bodhi with
bugzilla ticket numbers. Else packagers continue to ignore problem
reports in bugzilla and push pending updates to stable.



From tmus at tmus.dk  Thu Dec 11 21:01:46 2008
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Thu, 11 Dec 2008 18:01:46 -0300
Subject: yum --skip-broken update by default?
In-Reply-To: <20081211201842.GA5741@nostromo.devel.redhat.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<20081211201842.GA5741@nostromo.devel.redhat.com>
Message-ID: <49417FBA.7000008@tmus.dk>

Bill Nottingham wrote:
> Seth Vidal (skvidal at fedoraproject.org) said: 
>>> 1) People who have dependency problem won't see them anymore.
>> b/c we need to get the dep problems reported, too.
> 
> Then you also enable by default the yum-email-dep-problems-to-fedora-devel
> plugin.
> 
> Bill
> 
Hmmm, I'm not sure exactly what kind of repository information you can 
query from a yum plugin, but this plugin would need to be fairly 
specific to the fedora repositories and would need to ignore 
dep-problems on peoples on-site mirrors and such. Otherwise we'd get a 
lot of bugs filed, caused by the use of such repos.

/Thomas



From mw_triad at users.sourceforge.net  Thu Dec 11 21:01:51 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 11 Dec 2008 15:01:51 -0600
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <6d06ce20812111154s5ca7a15bx76c38b365f294a11@mail.gmail.com>
References: <20081209223300.GA32716@thinkpad>	<20081210031750.GB21432@nostromo.devel.redhat.com>	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>	<20081210143309.GB18314@nostromo.devel.redhat.com>	<20081210213546.GD12080@auslistsprd01.us.dell.com>	<1229007272.3537.23.camel@localhost.localdomain>	<alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>	<ghrosn$462$1@ger.gmane.org>
	<6d06ce20812111154s5ca7a15bx76c38b365f294a11@mail.gmail.com>
Message-ID: <ghrv3v$r71$2@ger.gmane.org>

Jerry Amundson wrote:
> On Thu, Dec 11, 2008 at 1:15 PM, Matthew Woehlke
> <mw_triad at speaking.of.spam> wrote:

Please don't do that ^^.

>> I've been reluctant to say anything, but does anyone actually *know* this
>> person?
> 
> No, but I had this hair-brained idea to actually e-mail him... :-)
> His response:
> [snip response]

Hehe... thanks :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
|-\ /-\ \ | -+-   |-\  +  \ | -+- /-\
| | | | |\|  |    |-/ /-\ |\|  |  |
|-/ \-/ | \  |    |   | | | \ -+- \-/



From mschwendt at gmail.com  Thu Dec 11 21:06:50 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 11 Dec 2008 22:06:50 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
Message-ID: <20081211220650.e89782d5.mschwendt@gmail.com>

On Thu, 11 Dec 2008 12:32:12 -0600, Arthur wrote:

> 6 months is a pretty long time to wait for a major release. I
> understand the rationale, but if this is going to be the new Fedora,
> best announce this and let  everyone know so that they can reevaluate
> if Fedora is for them. As things are, I feel that we are being _too_
> conservative. Any further move to more conservatism seriously affects
> Fedora's usefulness to me.

Why?



From steven.moix at axianet.ch  Thu Dec 11 21:07:35 2008
From: steven.moix at axianet.ch (Steven Moix)
Date: Thu, 11 Dec 2008 22:07:35 +0100
Subject: yum --skip-broken update by default?
In-Reply-To: <alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
Message-ID: <1229029655.7914.4.camel@hp6710.axianet.ch>

On Thu, 2008-12-11 at 15:09 -0500, Seth Vidal wrote:
> 
> On Thu, 11 Dec 2008, Steven Moix wrote:
> 
> > Hello,
> >
> > Last night I had an idea, why not alias "yum update" to "yum
> > --skip-broken update" by default? This simple hack could prevent a lot
> > of recurring support questions on the forums:
> >
> > 1) People who have dependency problem won't see them anymore.
> 
> b/c we need to get the dep problems reported, too.
> 
> > 2) It doesn't change anything for the rest of the people.
> >
> 
> sure it does, it means that you think you're updated completely, but 
> you're not.
> 
> -sv
> 

Ok, you have a point. 

I was suggesting this from a guy-who-reads-user-forums standpoint. The
Fedora update mirrors are often out of sync for 1-3 days, which fills
the forums almost every day with users who don't understand what's going
on when they have dependency problems. 

I'm fully aware that this is a dirty hack, but it could solve just that
problem, now there are side effects of course.

Steven



From lesmikesell at gmail.com  Thu Dec 11 21:12:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 15:12:02 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org>	<49416103.6050900@gmail.com>	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>	<49416C55.6010900@gmail.com>	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>	<494178C1.3040002@gmail.com>
	<604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>
Message-ID: <49418222.307@gmail.com>

Jeff Spaleta wrote:

> On Thu, Dec 11, 2008 at 11:32 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> More to the point, how can I expect this to work after the thing I want goes
>> away in the repository, replaced by a mistaken push of something broken?  I
>> think it is unreasonable to assume that such mistakes will never happen.
>>  What's the plan to avoid/recover from this?
> 
> You keep mixing up different questions. There are different questions
> 
> 1) How do you know its broken?
> ... still waiting for you to even explain how you know something is
> broken before you install it.

That wasn't a question.  I'll figure out how to test for brokenness 
after you tell me how to reproduce exact tested, non-broken states. Or 
maybe I'll watch the mail list for subjects like 'sucking' or "dbus 
disaster" before doing any updates.

> 2) Once you know its broken how prevent it from going on to a client system
> .... yum's configuration options work just fine for that.

No, I have to know a lot more than "it's broken" to do anything with a 
yum configurations.  What I'd rather do is find an "it works", tested 
set and duplicate that and only that.

> 3) If you found out its broken after you installed it on a client
> system how do you revert to a previous update?
> ... you keep a local cache of previously installed updates. yum lets
> you keep a local cache..per client. The caching is off by default but
> it can be turned on.

Is that really the plan you expect users to follow?  Has anyone even 
tried that to see if it works in the general case?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From opensource at till.name  Thu Dec 11 21:12:33 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 22:12:33 +0100
Subject: Server SIG - work areas
In-Reply-To: <9497e9990812111002g1702037q6839bb384aed9e9@mail.gmail.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<m3abb24qvo.fsf@ursa.amorsen.dk>
	<9497e9990812111002g1702037q6839bb384aed9e9@mail.gmail.com>
Message-ID: <200812112212.34232.opensource@till.name>

On Thu December 11 2008, Mat Booth wrote:
> On Thu, Dec 11, 2008 at 4:29 PM, Benny Amorsen wrote:
> > PS Ponies. Why doesn't Fedora provides ponies?
>
> Because they're too big to fit in the bikeshed. ;-)

Unless the bikeshed is blue. ;-)

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/54e2157e/attachment.sig>

From lesmikesell at gmail.com  Thu Dec 11 21:23:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 15:23:24 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <200812112200.46965.opensource@till.name>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228930226.30987.107.camel@code.and.org>
	<49416103.6050900@gmail.com>
	<200812112200.46965.opensource@till.name>
Message-ID: <494184CC.1020104@gmail.com>

Till Maas wrote:
> On Thu December 11 2008, Les Mikesell wrote:
> 
>> So, what is the correct plan to avoid getting a broken update onto a
>> machine you care about?  Take the one towards the end of FC6 that broke
> 
> You can not update at all or only install security related updates and then 
> only the ones that fix something, your machine is really vulnerable to.

That sort of assumes that there is some defined stable state that I'd 
know that I didn't want to migrate from - and I've never seen a fedora 
initial release that was close to that.   How am I supposed to know when 
this state arrives?  And if there's no reason to pick up those other 
updates, why push them in the first place.  My point is that mistakes 
are going to happen and there should be a planned way to avoid or fix 
them that doesn't include downtime on every machine that runs the 
distribution.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From opensource at till.name  Thu Dec 11 21:24:44 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 22:24:44 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <f6ca9fed0812111046w12807e00i4e2869e4555e089@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<f6ca9fed0812111046w12807e00i4e2869e4555e089@mail.gmail.com>
Message-ID: <200812112225.00620.opensource@till.name>

On Thu December 11 2008, drago01 wrote:
> On Thu, Dec 11, 2008 at 7:32 PM, Arthur Pemberton <pemboa at gmail.com> wrote:
> > 6 months is a pretty long time to wait for a major release. I
> > understand the rationale, but if this is going to be the new Fedora,
> > best announce this and let  everyone know so that they can reevaluate
> > if Fedora is for them. As things are, I feel that we are being _too_
> > conservative.
>
> you are kidding right? if not you can just use rawhide.

Except that Rawhide is not as usable as the current Fedora release we have.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/60b9e9b7/attachment.sig>

From jspaleta at gmail.com  Thu Dec 11 21:26:12 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 12:26:12 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <49418222.307@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493F0BA8.1050300@gmail.com> <1228930226.30987.107.camel@code.and.org>
	<49416103.6050900@gmail.com>
	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>
	<49416C55.6010900@gmail.com>
	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>
	<494178C1.3040002@gmail.com>
	<604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>
	<49418222.307@gmail.com>
Message-ID: <604aa7910812111326oddf020eh6c17b26ad531b313@mail.gmail.com>

On Thu, Dec 11, 2008 at 12:12 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> That wasn't a question.  I'll figure out how to test for brokenness after
> you tell me how to reproduce exact tested, non-broken states. Or maybe I'll
> watch the mail list for subjects like 'sucking' or "dbus disaster" before
> doing any updates.

You are the one that introduced the "known broken" terminology and
have used in for like 3.2 million posts in this thread. Its your
concept. Not mine.

>
>> 2) Once you know its broken how prevent it from going on to a client
>> system
>> .... yum's configuration options work just fine for that.
>
> No, I have to know a lot more than "it's broken" to do anything with a yum
> configurations.  What I'd rather do is find an "it works", tested set and
> duplicate that and only that.

If I tell you that "it works" is that enough for you? Are you willing
to trust me on that? Are you willing to trust any individual
maintainer on that? I'll just write an auto-fire script to send you
email every time I install an update telling you it works.  How do you
define what qualifies as working well enough for you before YOU
install it? What specifically do YOU need to see happen for you to
feel an update is vetted enough for you to install?  And once you tell
us what those things are... are YOU going to help implement them?

>
>> 3) If you found out its broken after you installed it on a client
>> system how do you revert to a previous update?
>> ... you keep a local cache of previously installed updates. yum lets
>> you keep a local cache..per client. The caching is off by default but
>> it can be turned on.
>
> Is that really the plan you expect users to follow?  Has anyone even tried
> that to see if it works in the general case?

I've used it. On my systems running Fedora which I maintain to be used
and updated primarily by other people (like my wife's desktop).. I do
in fact keep a local cache of previously installed updates which I
purge based on my local administration policy judgement.  When there
is an update that breaks functionality for her I am able to manually
install the cached older version and then set an exclude. I don't have
to use it often.

-jef



From jamundso at gmail.com  Thu Dec 11 21:45:28 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Thu, 11 Dec 2008 15:45:28 -0600
Subject: [OT] Re: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <ghrv3v$r71$2@ger.gmane.org>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
	<1229007272.3537.23.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
	<ghrosn$462$1@ger.gmane.org>
	<6d06ce20812111154s5ca7a15bx76c38b365f294a11@mail.gmail.com>
	<ghrv3v$r71$2@ger.gmane.org>
Message-ID: <6d06ce20812111345i2857d21cx2f6303c124c919f3@mail.gmail.com>

On Thu, Dec 11, 2008 at 3:01 PM, Matthew Woehlke <caughtmyself at thistime> wrote:
> Jerry Amundson wrote:
>>
>> On Thu, Dec 11, 2008 at 1:15 PM, Matthew Woehlke
>> <mw_triad at speaking.of.spam> wrote:
>
> Please don't do that ^^.

Doh! Sorry!

jerry

-- 
Store in cool, dry place. Rotate stock.



From opensource at till.name  Thu Dec 11 21:48:49 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 22:48:49 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <494184CC.1020104@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<200812112200.46965.opensource@till.name> <494184CC.1020104@gmail.com>
Message-ID: <200812112248.55542.opensource@till.name>

On Thu December 11 2008, Les Mikesell wrote:

> That sort of assumes that there is some defined stable state that I'd
> know that I didn't want to migrate from - and I've never seen a fedora
> initial release that was close to that.   How am I supposed to know when
> this state arrives?

You can start with updating only packages that update packages you are not 
satisfied with. To get as much bugs fixed as possible in the initial release, 
you have to do more testing and report bugs.

> And if there's no reason to pick up those other
> updates, why push them in the first place.  

There are other people interested in the updates.

> My point is that mistakes
> are going to happen and there should be a planned way to avoid or fix
> them that doesn't include downtime on every machine that runs the
> distribution.

I agree here. I already mentioned some methods in another e-mail. Another 
possibility I just thought of would be to create reverse delta rpms, i.e. 
before an rpm is installed, a delta to the current state is created and stored 
somewhere. This can then used to restore the previous state. Of course someone 
needs to write this. :-)

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/c2f6ea68/attachment.sig>

From jspaleta at gmail.com  Thu Dec 11 21:50:10 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 12:50:10 -0900
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <1229018191.30987.146.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <ghrbgn$ha9$1@ger.gmane.org>
	<1229010046.3394.1149.camel@beck.corsepiu.local>
	<ghrd5b$ne2$1@ger.gmane.org>
	<604aa7910812110904i3f8e04a3lee8929cb34862e42@mail.gmail.com>
	<1229018191.30987.146.camel@code.and.org>
Message-ID: <604aa7910812111350y8dcf635o5f27e2d62ec05406@mail.gmail.com>

On Thu, Dec 11, 2008 at 8:56 AM, James Antill <james at fedoraproject.org> wrote:
>  No, what you really want is your package manager integration so you can
> say:
>
> 1. "You searched for FOO", there is version 1-1 in your Fedora release
> version 1-2 has been in testing for X days and has Y karma, and version
> 2-1 is in "rawhide" but is installable with no / Z number of required
> packages.
>
> 2. I noticed that FOO package just crashed, there is an update available
> in testing which fixes these BugZillas:
>
> 12234666 - Random crashes when doing XYZ

I dont want it to say all that.  In fact I'd be fine if there was
another dbus agent which testers could choose to install which
provided detailed information like that which listened to PK messages
on the bus.

For right now, I just want a nag reminder that I have packages from
testing installed that could use some karma love. Because from my own
experience that is what I feel I need to push feedback back into
bodhi.

-jef



From opensource at till.name  Thu Dec 11 21:05:14 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 22:05:14 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <494178C1.3040002@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>
	<494178C1.3040002@gmail.com>
Message-ID: <200812112205.14901.opensource@till.name>

On Thu December 11 2008, Les Mikesell wrote:

> More to the point, how can I expect this to work after the thing I want
> goes away in the repository, replaced by a mistaken push of something
> broken?  I think it is unreasonable to assume that such mistakes will
> never happen.  What's the plan to avoid/recover from this?

So many possibilities: Use keepcache=1 in your yum.conf, write a yum plugin 
that keeps at least X old revisions of your rpms, use a proxy that stores all 
rpms your clients ever downloaded (does InstantMirror do this?), fetch the rpm 
from koji or cvs co the package you want from cvs and run "make local".

Regards,
Till

-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/897e2f37/attachment.sig>

From opensource at till.name  Thu Dec 11 20:40:00 2008
From: opensource at till.name (Till Maas)
Date: Thu, 11 Dec 2008 21:40:00 +0100
Subject: Installing from Live CD is the new black?
In-Reply-To: <20081211181630.GA27793@localhost.localdomain>
References: <1228955078.3037.10.camel@fecusia>
	<200812111828.00512.opensource@till.name>
	<20081211181630.GA27793@localhost.localdomain>
Message-ID: <200812112140.11914.opensource@till.name>

On Thu December 11 2008, Chris Lumens wrote:
> > Will this be restored for F11?
>
> No.

That's sad. :-(

> > It was very helpful when using a usb medium to install from.
>
> If you could describe the problem  you're having with the new mechanism
> and USB disks, I can work on fixing it in time for F11.  It may even be
> fixable for F10 with an updates.img.  I'd be interested to see what
> you're doing and exactly how it's going wrong.

The problems I had are probably not USB disk related, then. I as usually used 
the live-iso-to-disk script to get the bootloader from the DVD to my USB stick 
and then only needed to copy the iso on the USB stick. Then I could use the 
USB stick to either install from it or to distribute the iso image to others. 
Now I would need an even bigger USB stick if I want to have it bootable and 
containing the iso.

But anaconda screwed up somehow else. With German locales the text did not 
really fit on the screen and after I tried to use the harddisk as installation 
source and it did not work, I could not select any other installation method. 
I believe I could only go back to change language and keyboard layout and 
going forward from there made anaconda ask me about a driver disk. I then 
skipped this and used the LiveCD. But I can try to reproduce this with a 
virtual machine, which I planned anyways to do, but not that soon.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/5016e577/attachment.sig>

From jkeating at redhat.com  Thu Dec 11 22:13:16 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 14:13:16 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <200812112225.00620.opensource@till.name>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<f6ca9fed0812111046w12807e00i4e2869e4555e089@mail.gmail.com>
	<200812112225.00620.opensource@till.name>
Message-ID: <1229033596.3863.104.camel@localhost.localdomain>

On Thu, 2008-12-11 at 22:24 +0100, Till Maas wrote:
> Except that Rawhide is not as usable as the current Fedora release we
> have.

With everybody treating the current Fedora release as a thinly veiled
rawhide, it's not very usable either.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/6b97922b/attachment.sig>

From cra at WPI.EDU  Thu Dec 11 22:27:03 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 11 Dec 2008 17:27:03 -0500
Subject: rawhide report: 20081211 changes
In-Reply-To: <20081211140726.CBCC11F823B@releng2.fedora.phx.redhat.com>
References: <20081211140726.CBCC11F823B@releng2.fedora.phx.redhat.com>
Message-ID: <20081211222703.GA4818@angus.ind.WPI.EDU>

a

On Thu, Dec 11, 2008 at 02:07:26PM +0000, Rawhide Report wrote:
> Compose started at Thu Dec 11 06:01:11 UTC 2008
> 
> New package examiner
>         Utility to disassemble and comment foreign executable binaries
> New package haddock
>         Haddock documentation tool for annotated Haskell source code
> New package mod_limitipconn
>         Simultaneous connection limiting module for Apache
> New package nwsclient
>         NetWorkSpaces Client for Python
> New package nxtvepg
>         A nexTView EPG decoder and browser
> New package perl-AutoXS-Header
>         Container for the AutoXS header files
> New package perl-Class-Unload
>         Unload given Class
> New package perl-Text-FindIndent
>         Heuristically determine the indent style
> New package python-relatorio
>         A templating library able to output odt and pdf files
> New package swingx
>         A collection of Swing components
> New package xcb-util
>         Convenience libraries sitting on top of libxcb
> New package xloadimage
>         Image viewer and processor
> New package xmbdfed
>         Bitmap Font Editor
> New package xmms2
>         A modular audio framework and plugin architecture
> Updated Packages:
> 
> ImageMagick-6.4.5.5-4.fc11
> --------------------------
> * Wed Dec 10 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.4.5.5-4
> - Do not pass -jX to make when building, this breaks PerlMagick (rh 475554)
> 
> 
> ORBit2-2.14.16-2.fc11
> ---------------------
> * Wed Dec 10 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.16-2
> - Merge review trivia
> 
> 
> OpenIPMI-2.0.14-8.fc11
> ----------------------
> * Wed Dec 10 17:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-8
> - shorter probe interval is used in init script, making the service startup
>   quicker in most situations (#475101)
> 
> 
> alex-2.3.1-1.fc11
> -----------------
> * Thu Dec 11 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 2.3.1-1
> - update to 2.3.1
> - no longer need alex-2.3-base3.patch
> 
> 
> at-spi-1.25.2-5.fc11
> --------------------
> * Wed Dec 10 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.25.2-5
> - ...but keep all the needed deps
> 
> 
> bodhi-0.5.13-1.fc11
> -------------------
> * Wed Dec 10 17:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.13-1
> - Latest upstream release to fix various metrics/rss issues
> 
> 
> bzr-1.10-1.fc11
> ---------------
> * Wed Dec 10 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 1.10-1
> - Update to 1.10
> 
> 
> bzrtools-1.10.0-1.fc11
> ----------------------
> * Wed Dec 10 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 1.10-1
> - Update to 0.10.0
> 
> 
> contact-lookup-applet-0.17-1.fc11
> ---------------------------------
> * Wed Dec 10 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.17-1
> - Update to 0.17.
> - Add BR on intltool.
> - Drop search patch. Fixed upstream.
> - Drop sources patch. Fixed upsteam.
> 
> 
> corosync-0.92-4.svn1707.fc11
> ----------------------------
> * Wed Dec 10 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 0.92-4.svn1707
> - Update to svn trunk at revision 1707 from upstream.
> - Update spec file to include new lcrso services and include file.
> 
> * Mon Oct 13 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.92-3
> - remove ExclusiveArch line
> 
> 
> dbus-1.2.8-3.fc11
> -----------------
> * Wed Dec 10 17:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.8-3
> - Add back working syslog patch
> 
> * Tue Dec  9 17:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.8-2
> - Remove accidentally added syslog patch
> 
> * Tue Dec  9 17:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.8-1
> - New upstream 1.2.8
>   Allows signals by default.
> 
> 
> eclipse-changelog-2.6.3-2.fc10
> ------------------------------
> * Mon Nov 24 17:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 2.6.3-2
> - Disable building of eclipse-changelog-debuginfo since gcj AOT bits are
>   no longer built for this package.
> 
> 
> eclipse-egit-0.4.0-1.fc11
> -------------------------
> * Wed Dec 10 17:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 0.4.0-1
> - Update to 0.4.0.
> 
> 
> emacspeak-29.0-1.fc11
> ---------------------
> * Thu Dec 11 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 29.0-1
> - update to 29.0
> - no longer need emacspeak-28.0-no-httpd.patch and emacspeak-28.0-tmpfile.patch
> 
> 
> emma-2.0.5312-2.fc11
> --------------------
> * Wed Dec 10 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 0:2.0.5312-2
> - Add patch to fix 64-bit AIOOB.
> 
> 
> fbterm-1.2-2.fc11
> -----------------
> * Thu Dec 11 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 1.2-2
> - Summary simplified.
> 
> 
> ffcall-1.10-2.20080704cvs.fc11.1
> --------------------------------
> * Wed Dec 10 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> - 1.10-2.20080704cvs.1
> - Fix -FPIC issue (BZ #475112)
> 
> 
> fuse-emulator-utils-0.10.0-2.fc11
> ---------------------------------
> * Wed Dec 10 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.10.0-2
> - upstream released broken package (missing files)
> 
> * Fri Dec  5 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.10.0-1
> - new upstream 0.10.0 release
> 
> 
> gallery2-2.3-1.fc11
> -------------------
> * Thu Dec  4 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 2.3-1
> - Update to new upstream.
> - Rebased on tarball now that perl path issue is fixed.
> - Added buildroot wipe to start of install.
> - Escaped macros in changelog.
> 
> 
> glibmm24-2.18.1-2.fc11
> ----------------------
> * Thu Dec 11 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.18.1-2
> - Rebuild for pkgconfig provides
> 
> 
> gnome-settings-daemon-2.25.2-8.fc11
> -----------------------------------
> * Wed Dec 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-8
> - Shutdown cleanly when bus goes away (bug 445898 again)
> 
> * Wed Dec 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-7
> - Don't map touch pad tap to right-click for left-handed
>   users (bug 324721)
> 
> * Wed Dec 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-6
> - Listen for DeviceAdded signals when configuring mouse
>   (in addition to DeviceEnabled).  This may help with
>   bug 474758.
> 
> 
> gnustep-make-2.0.6-14.fc11
> --------------------------
> * Wed Dec 10 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> - 2.0.6-14
> - Remove libcombo stuff
> - Make sure the libraries are going to /usr/lib64 on x86_64 architecure
> 
> 
> gpsbabel-1.3.6-1.fc10
> ---------------------
> 
> gtkmm24-2.14.3-2.fc11
> ---------------------
> * Thu Dec 11 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.14.3-2
> - Rebuild for pkgconfig provides
> 
> 
> javasqlite-20081006-4.fc11
> --------------------------
> * Wed Dec 10 17:00:00 2008 Ville Skytt? <ville.skytta at iki.fi> - 20081006-4
> - Revert previous change, arch specific links break in %{_datadir}.
> 
> 
> jd-2.1.0-0.1.svn2553_trunk.fc11
> -------------------------------
> * Thu Dec 11 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
> - rev 2553
> 
> 
> libsigc++20-2.2.2-2.fc11
> ------------------------
> * Thu Dec 11 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.2.2-2
> - Rebuild for pkgconfig provides
> 
> 
> libsqlite3x-20071018-4.fc10
> ---------------------------
> 
> linuxwacom-0.8.0.3-6.fc10
> -------------------------
> * Fri Nov 14 17:00:00 2008 Aristeu Rozanski <aris at redhat.com> 0.8.0.3-6
> - rebuild
> 
> * Fri Nov 14 17:00:00 2008 Aristeu Rozanski <aris at redhat.com> 0.8.0.3-5
> - don't call devproc with DEVICE_OFF in Uninit in new X servers
> 
> 
> meanwhile-1.1.0-0.fc10
> ----------------------
> * Mon Nov 17 17:00:00 2008 Josh Boyer <jwboyer at gmail.com> - 1.1.0-0
> - Update to meanwhile_v1_1_0 branch from upstream CVS
> 
> 
> nted-1.4.17-1.fc11
> ------------------
> * Wed Dec 10 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.4.17-1
> - Update to upstream's 1.4.17 release.
> 
> 
> octave-3.0.3-1.fc11
> -------------------
> * Wed Dec 10 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 3.0.3-1
> - Update to latest upstream (3.0.3)
> 
> 
> openais-0.91-3.svn1667.fc11
> ---------------------------
> * Wed Dec 10 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 0.91-3.svn1667
> - Update to svn trunk at revision 1667 from upstream.
> - Update spec file to support alpha tag versioning.
> - Tight dependencies (both build and runtime) with corosync to avoid
>   internal ABI issues.
> 
> 
> perl-Sub-Uplevel-0.2002-1.fc11
> ------------------------------
> * Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.2002-1
> - Update to 0.2002.
> - BR Test::More.
> 
> 
> perl-Test-Base-0.55-1.fc11
> --------------------------
> * Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.55-1
> - Update to 0.55.
> - Explicitly BR Test::More >= 0.62.
> - BR YAML.
> 
> 
> perl-Test-Class-0.31-1.fc11
> ---------------------------
> * Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.31-1
> - Update to 0.31.
> - BR Test::Builder.
> - Add versioned dependencies to Test::Builder::Tester and Test::More.
> 
> 
> perl-Test-Output-0.12-1.fc11
> ----------------------------
> * Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.12-1
> - Update to 0.12.
> - BR Test::More.
> - Fix typo in description.
> - Include TODO in docs.
> 
> 
> perl-Test-Prereq-1.034-1.fc11
> -----------------------------
> * Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 1.034-1
> - Update to 1.034.
> 
> 
> perl-Text-CSV_XS-0.58-1.fc11
> ----------------------------
> * Wed Dec 10 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.58-1
> - Update to latest upstream
> - SvUPGRADE patch upstreamed
> 
> 
> perl-YAML-0.68-1.fc11
> ---------------------
> * Wed Dec 10 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.68-1
> - Update to 0.68.
> - COMPATIBILITY went away.
> - ysh moved to YAML::Shell.
> 
> 
> picviz-0.4-2.fc11
> -----------------
> * Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.4-2
> - Rebuild for Python 2.6
> 
> 
> policycoreutils-2.0.60-5.fc11
> -----------------------------
> * Wed Dec 10 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.60-5
> - Fix Japanese translations
> 
> 
> python-2.6-2.fc11
> -----------------
> * Wed Dec 10 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.6-2
> - Enable -lcrypt for cryptmodule
> 
> 
> python-libgmail-0.1.10-3.fc11
> -----------------------------
> * Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.10-3
> - Rebuild for Python 2.6
> 
> 
> python-mechanize-0.1.10-1.fc11
> ------------------------------
> * Wed Dec 10 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.10-1
> - Update to 0.1.10
> 
> 
> python-nevow-0.9.32-1.fc11
> --------------------------
> * Wed Dec 10 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.32-1
> - Update to 0.9.32
> 
> * Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9.31-2
> - Rebuild for Python 2.6
> 
> 
> python-rdflib-2.4.0-8.fc11
> --------------------------
> * Wed Dec 10 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4.0-8
> - Rebuild for Python 2.6
> 
> 
> python-tgcaptcha-0.11-4.fc11
> ----------------------------
> * Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11-4
> - Rebuild for Python 2.6
> 
> 
> python-turboflot-0.1.1-2.fc11
> -----------------------------
> * Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.1-2
> - Rebuild for Python 2.6
> 
> 
> rafkill-1.2.3-3.fc11
> --------------------
> * Wed Dec 10 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.2.3-3
> - Re-diffed fuzzy shatter patch.
> 
> 
> ruby-RMagick-2.8.0-1.fc11
> -------------------------
> * Wed Dec 10 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.8.0-1
> - 2.8.0
> 
> 
> scim-chewing-0.3.3-0.fc11
> -------------------------
> * Thu Dec 11 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 0.3.3-0
> - Upstream update.
> 
> 
> selinux-policy-3.6.1-9.fc11
> ---------------------------
> * Tue Dec  9 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-9
> - Add cron_role back to user domains
> 
> 
> setup-2.7.5-2.fc11
> ------------------
> * Wed Dec 10 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2.7.5-2
> - do not export PATH twice(#449286 NOTABUG revert)
> - do not export INPUTRC(to respect just created ~/.inputrc)
>   (#443717)
> 
> 
> tomcat5-5.5.27-6.1.fc10
> -----------------------
> * Wed Dec 10 17:00:00 2008 David Walluck <dwalluck at redhat.com> 0:5.5.27-6.1
> - fix bug #473755
> - fix extra newline in initscript
> 
> 
> xine-plugin-1.0.2-1.fc11
> ------------------------
> * Thu Dec 11 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 1.0.2-1
> - new upstreame release 
> - should fix rhbz #473830
> 
> 
> xlog-1.8.1-3.fc11
> -----------------
> * Wed Dec 10 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.8.1-3
> - modify patch to correctly display documentation
> 
> 
> xorg-x11-drv-geode-2.11.0-1.fc11
> --------------------------------
> * Wed Dec 10 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.11.0-1
> - update to 2.11.0 adds xrandr-1.2 and fixes cursor issues
> 
> 
> xorg-x11-xdm-1.1.6-6.fc10
> -------------------------
> * Fri Nov  7 17:00:00 2008 Mat?j Cepl <mcepl at redhat.com> - 1.1.6-6
> - Wrong Xresources generated (bug 470348)
> 
> * Thu Oct 30 18:00:00 2008 Soren Sandmann <ssp at redhat.com> 1.1.6-5
> - Fix xdm.pamd (bug 388431)
> 
> 
> xpdf-3.02-9.fc11
> ----------------
> * Wed Dec 10 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1:3.02-9
> - apply debian patches
> 
> * Sun Sep 21 18:00:00 2008 Ville Skytt? <ville.skytta at iki.fi> - 1:3.02-8
> - Fix Patch0:/%patch mismatch.
> 
> 
> Summary:
> Added Packages: 14
> Removed Packages: 0
> Modified Packages: 60
> Broken deps for i386
> ----------------------------------------------------------
> 	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
> 	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
> 	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
> 	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
> 	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
> 	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
> 	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
> 	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
> 	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
> 	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
> 	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
> 	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
> 	bzrtools-1.10.0-1.fc11.i386 requires bzr < 0:1.9
> 	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
> 	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
> 	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
> 	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
> 	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
> 	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
> 	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
> 	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
> 	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
> 	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
> 	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
> 	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
> 	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
> 	ghc-haddock-2.0.0.0-3.fc10.i386 requires ghc = 0:6.8.3
> 	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
> 	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
> 	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
> 	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
> 	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
> 	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
> 	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
> 	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
> 	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
> 	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
> 	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
> 	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
> 	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
> 	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
> 	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
> 	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
> 	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
> 	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
> 	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
> 	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
> 	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
> 	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
> 	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
> 	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
> 	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
> 	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
> 	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
> 	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
> 	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
> 	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
> 	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
> 	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
> 	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
> 	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
> 	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
> 	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
> 	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
> 	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
> 	player-2.1.1-5.fc10.i386 requires libltdl.so.3
> 	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
> 	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
> 	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
> 	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
> 	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
> 	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
> 	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
> 	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
> 	python-basemap-0.99-6.fc11.i386 requires libgeos-3.0.1.so
> 	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
> 	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
> 	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
> 	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
> 	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
> 	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
> 	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
> 	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
> 	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
> 	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
> 	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
> 	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
> 	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
> 	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
> 	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
> 	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
> 	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
> 	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
> 	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
> 	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
> 	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
> 	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
> 	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
> 	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
> 	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
> 	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
> 	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
> 	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
> 	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
> 	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
> 	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
> 	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
> 	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
> 	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
> 	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
> 	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
> 	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
> 	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
> 	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
> 	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
> 	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
> 	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
> 	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
> 	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
> 	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
> 
> 
> 
> Broken deps for x86_64
> ----------------------------------------------------------
> 	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
> 	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
> 	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
> 	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
> 	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
> 	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
> 	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
> 	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
> 	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
> 	bzrtools-1.10.0-1.fc11.x86_64 requires bzr < 0:1.9
> 	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
> 	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
> 	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
> 	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
> 	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
> 	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
> 	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
> 	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
> 	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
> 	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
> 	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
> 	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
> 	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
> 	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
> 	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
> 	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
> 	ghc-haddock-2.0.0.0-3.fc10.x86_64 requires ghc = 0:6.8.3
> 	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
> 	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
> 	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
> 	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
> 	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
> 	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
> 	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
> 	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
> 	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
> 	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
> 	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
> 	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
> 	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
> 	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
> 	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
> 	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
> 	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
> 	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
> 	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
> 	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
> 	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
> 	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
> 	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
> 	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
> 	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
> 	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
> 	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
> 	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
> 	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
> 	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
> 	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
> 	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
> 	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
> 	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
> 	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
> 	player-2.1.1-5.fc10.i386 requires libltdl.so.3
> 	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
> 	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
> 	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
> 	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
> 	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
> 	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
> 	python-basemap-0.99-6.fc11.x86_64 requires libgeos-3.0.1.so()(64bit)
> 	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
> 	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
> 	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
> 	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
> 	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
> 	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
> 	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
> 	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
> 	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
> 	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
> 	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
> 	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
> 	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
> 	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
> 	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
> 	qgis-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
> 	qgis-grass-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
> 	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
> 	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
> 	qgis-python-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
> 	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
> 	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
> 	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
> 	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
> 	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
> 	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
> 	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
> 	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
> 	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
> 	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
> 	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
> 	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
> 	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
> 	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
> 	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
> 	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
> 	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
> 	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
> 	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
> 	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
> 	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(liboil-0.3)
> 	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libexif)
> 	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(libpng)
> 	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
> 	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(liboil-0.3)
> 	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libexif)
> 	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(libpng)
> 	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
> 	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
> 
> 
> 
> Broken deps for ppc
> ----------------------------------------------------------
> 	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
> 	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
> 	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
> 	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
> 	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
> 	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
> 	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
> 	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
> 	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
> 	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
> 	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
> 	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
> 	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
> 	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
> 	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
> 	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
> 	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
> 	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
> 	bzrtools-1.10.0-1.fc11.ppc requires bzr < 0:1.9
> 	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
> 	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
> 	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
> 	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
> 	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
> 	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
> 	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
> 	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
> 	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
> 	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
> 	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
> 	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
> 	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
> 	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
> 	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
> 	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
> 	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
> 	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
> 	ghc-haddock-2.0.0.0-3.fc10.ppc requires ghc = 0:6.8.3
> 	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
> 	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
> 	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
> 	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
> 	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
> 	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
> 	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
> 	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
> 	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
> 	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
> 	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
> 	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
> 	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
> 	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
> 	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
> 	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
> 	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
> 	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
> 	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
> 	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
> 	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
> 	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
> 	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
> 	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
> 	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
> 	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
> 	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
> 	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
> 	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
> 	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
> 	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
> 	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
> 	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
> 	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
> 	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
> 	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
> 	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
> 	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
> 	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
> 	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
> 	player-2.1.1-5.fc10.ppc requires libltdl.so.3
> 	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
> 	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
> 	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
> 	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
> 	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
> 	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
> 	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
> 	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
> 	python-basemap-0.99-6.fc11.ppc requires libgeos-3.0.1.so
> 	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
> 	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
> 	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
> 	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
> 	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
> 	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
> 	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
> 	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
> 	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
> 	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
> 	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
> 	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
> 	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
> 	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
> 	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
> 	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
> 	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
> 	qgis-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
> 	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-grass-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
> 	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
> 	qgis-python-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
> 	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
> 	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
> 	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
> 	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
> 	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
> 	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
> 	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
> 	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
> 	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
> 	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
> 	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
> 	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
> 	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
> 	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
> 	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
> 	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
> 	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
> 	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
> 	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
> 	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
> 	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
> 	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
> 	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
> 	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
> 	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(liboil-0.3)
> 	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libexif)
> 	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(libpng)
> 	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
> 	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
> 	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
> 	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
> 	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
> 	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
> 
> 
> 
> Broken deps for ppc64
> ----------------------------------------------------------
> 	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
> 	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
> 	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
> 	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
> 	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
> 	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
> 	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
> 	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
> 	bzrtools-1.10.0-1.fc11.ppc64 requires bzr < 0:1.9
> 	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
> 	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
> 	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
> 	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
> 	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
> 	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
> 	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
> 	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
> 	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
> 	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
> 	gpodder-0.13.1-2.1.fc11.noarch requires python-bluez
> 	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
> 	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
> 	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
> 	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
> 	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
> 	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
> 	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
> 	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
> 	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
> 	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
> 	livecd-tools-019-2.fc11.ppc64 requires yaboot
> 	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
> 	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
> 	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
> 	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
> 	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
> 	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
> 	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
> 	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
> 	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
> 	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
> 	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
> 	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
> 	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
> 	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
> 	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
> 	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
> 	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
> 	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
> 	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
> 	python-basemap-0.99-6.fc11.ppc64 requires libgeos-3.0.1.so()(64bit)
> 	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
> 	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
> 	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
> 	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
> 	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
> 	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
> 	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
> 	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
> 	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
> 	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
> 	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
> 	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
> 	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
> 	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
> 	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
> 	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
> 	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
> 	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
> 	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
> 	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
> 	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
> 	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
> 	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
> 	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
> 	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
> 	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
> 	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
> 	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
> 	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
> 	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
> 	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
> 	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
> 	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(liboil-0.3)
> 	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libexif)
> 	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(libpng)
> 	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
> 	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
> 
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From james at fedoraproject.org  Thu Dec 11 22:28:45 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 11 Dec 2008 17:28:45 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <1229029655.7914.4.camel@hp6710.axianet.ch>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<1229029655.7914.4.camel@hp6710.axianet.ch>
Message-ID: <1229034525.30987.174.camel@code.and.org>

On Thu, 2008-12-11 at 22:07 +0100, Steven Moix wrote:

> I was suggesting this from a guy-who-reads-user-forums standpoint. The
> Fedora update mirrors are often out of sync for 1-3 days, which fills
> the forums almost every day with users who don't understand what's going
> on when they have dependency problems. 

 My understanding was the MM wanted mirrors to be in sync. within a day,
and as long as the metadata is within sync. it is almost "free" to
switch mirrors to find metadata/packages now (just get 404s and move
along).

> I'm fully aware that this is a dirty hack, but it could solve just that
> problem, now there are side effects of course.

 To be fair, there is a much less dirty hack of just setting
"skip_broken = true" in yum.conf (it's in the man page :p). And this
might be turned on a some point, but as other people have said before
that happens we really want:

. Lots of checking server side (repoclosure type stuff) to make sure
what we push is good.

. Lots of testing to make sure skip-broken doesn't make the problem
worse (many cases of infinite loops in the past, although it's getting
close now).

-- 
James Antill <james at fedoraproject.org>
Fedora



From pemboa at gmail.com  Thu Dec 11 22:35:44 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 16:35:44 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <f6ca9fed0812111046w12807e00i4e2869e4555e089@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<f6ca9fed0812111046w12807e00i4e2869e4555e089@mail.gmail.com>
Message-ID: <16de708d0812111435q4f4dae53g33cbb92a4b14005f@mail.gmail.com>

On Thu, Dec 11, 2008 at 12:46 PM, drago01 <drago01 at gmail.com> wrote:
> On Thu, Dec 11, 2008 at 7:32 PM, Arthur Pemberton <pemboa at gmail.com> wrote:
>
>> 6 months is a pretty long time to wait for a major release. I
>> understand the rationale, but if this is going to be the new Fedora,
>> best announce this and let  everyone know so that they can reevaluate
>> if Fedora is for them. As things are, I feel that we are being _too_
>> conservative.
>
> you are kidding right? if not you can just use rawhide.


Yes, obviously I tool time out of my day to kid you. There is no
attempt to have rawhide be useable for actual work, nor am I
suggesting that it should be made into such. I have a box dedicated to
rawhide for stuff I need to test out or mess with. So I'm familiar
with what rawhide provides, thank you.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pemboa at gmail.com  Thu Dec 11 22:38:16 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 16:38:16 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229033596.3863.104.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<f6ca9fed0812111046w12807e00i4e2869e4555e089@mail.gmail.com>
	<200812112225.00620.opensource@till.name>
	<1229033596.3863.104.camel@localhost.localdomain>
Message-ID: <16de708d0812111438w3e933870s2b33a3add8c81a03@mail.gmail.com>

2008/12/11 Jesse Keating <jkeating at redhat.com>:
> On Thu, 2008-12-11 at 22:24 +0100, Till Maas wrote:
>> Except that Rawhide is not as usable as the current Fedora release we
>> have.
>
> With everybody treating the current Fedora release as a thinly veiled
> rawhide, it's not very usable either.


I find Fedora as if both useful and useable. But if the majority
doesn't and want to slow things down fine. All I'm saying is, once
this decision is come to, don't quietly do this and have people like
myself wondering what happened to all the updates.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From bbaetz at acm.org  Thu Dec 11 23:11:23 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Fri, 12 Dec 2008 10:11:23 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229014969.3863.85.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<ghq732$5to$1@ger.gmane.org>
	<1229014969.3863.85.camel@localhost.localdomain>
Message-ID: <ghs6mt$ll3$1@ger.gmane.org>

Jesse Keating wrote:
> On Thu, 2008-12-11 at 06:05 +0100, Kevin Kofler wrote:
>> And the problem in this thread wasn't even such an update, it was a security
>> fix! Even if it had been backported to D-Bus 1.2.4 instead of an upgrade to
>> 1.2.6, it would still have caused the same issue! So the problem we're
>> seeing has absolutely nothing to do with feature upgrades.
> 
> While that's true of the originating topic of this thread, we've moved
> on to a more general discussion of how Fedora releases should be
> treated.

But to pull it back slightly, is there a way to quickly unpush a 
package? Even though the tree compose takes a while, is keeping a copy 
of yesterday's updates dir a simpler problem for these sorts of things?

For me (in .au) the package was known to be broken before it hit my 
local mirror, so if it had been pulled before the rsync I wouldn't have 
seen anything broken at all....

Bradley



From jkeating at redhat.com  Thu Dec 11 23:25:44 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 15:25:44 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghs6mt$ll3$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<ghq732$5to$1@ger.gmane.org>
	<1229014969.3863.85.camel@localhost.localdomain>
	<ghs6mt$ll3$1@ger.gmane.org>
Message-ID: <1229037944.3863.108.camel@localhost.localdomain>

On Fri, 2008-12-12 at 10:11 +1100, Bradley Baetz wrote:
> But to pull it back slightly, is there a way to quickly unpush a 
> package? Even though the tree compose takes a while, is keeping a copy 
> of yesterday's updates dir a simpler problem for these sorts of things?
> 
> For me (in .au) the package was known to be broken before it hit my 
> local mirror, so if it had been pulled before the rsync I wouldn't have 
> seen anything broken at all....

Without bypassing a lot of the process and making assumptions with
regard to multilib, no, the time it takes to produce repos minus an
update is on par with the time it takes to produce repos with fixed
versions of the package.  That is, 12 hours for the whole boat of
F8->F10 updates and updates-testing.  Quite a bit less if we're just
going to do say f10-updates only, but still /hours/.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/5ff45022/attachment.sig>

From tgl at redhat.com  Thu Dec 11 23:31:47 2008
From: tgl at redhat.com (Tom Lane)
Date: Thu, 11 Dec 2008 18:31:47 -0500
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger? 
In-Reply-To: <a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net> 
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
	<f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
Message-ID: <13600.1229038307@sss.pgh.pa.us>

"Jon Ciesla" <limb at jcomserv.net> writes:
>> (Yes, I know libjpeg upstream is kinda moribund, but if you want new
>> features in it you should be trying to revive upstream development,
>> not strongarm the Fedora package maintainer to take over development.)

> I agree strongly with that principle.  Two questions:

> A. What has been done thusfar WTR reviving upstream development?

Well, at one point I had more or less formally blessed Guido Vollbeding
as the new lead maintainer, but if he's actually put out a release I
haven't heard about it :-(.  You could try bugging the people associated
with the sourceforge libjpeg project.

> B. In the meantime, how should I support jpegtran?  Bundle a custom binary
> in the subpackage and patch the module, or let it sit with known partial
> functionality?

The right fix would be to pester upstream to not depend on nonstandard
functionality, but with no active upstream on that side either, I'm not
sure what you do about it :-(.  How critical is that particular
functionality to gallery2, anyway?  If you could just dike it out that
would seem to be an appropriate short-term fix.

> On a tangential note IIRC this patch is in Debian's libjpeg, not that that
> should be any sort of guideline for us, I'm just putting it out there.

Yeah, Debian seems to have no qualms about carrying big patches without
any upstream connection ...

			regards, tom lane



From bbaetz at acm.org  Thu Dec 11 23:33:50 2008
From: bbaetz at acm.org (Bradley Baetz)
Date: Fri, 12 Dec 2008 10:33:50 +1100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229037944.3863.108.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228834384.6701.15.camel@hughsie-work.lan>	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<ghq732$5to$1@ger.gmane.org>	<1229014969.3863.85.camel@localhost.localdomain>	<ghs6mt$ll3$1@ger.gmane.org>
	<1229037944.3863.108.camel@localhost.localdomain>
Message-ID: <ghs80v$pdk$1@ger.gmane.org>

Jesse Keating wrote:
> On Fri, 2008-12-12 at 10:11 +1100, Bradley Baetz wrote:
>> But to pull it back slightly, is there a way to quickly unpush a 
>> package? Even though the tree compose takes a while, is keeping a copy 
>> of yesterday's updates dir a simpler problem for these sorts of things?
>>
>> For me (in .au) the package was known to be broken before it hit my 
>> local mirror, so if it had been pulled before the rsync I wouldn't have 
>> seen anything broken at all....
> 
> Without bypassing a lot of the process and making assumptions with
> regard to multilib, no, the time it takes to produce repos minus an
> update is on par with the time it takes to produce repos with fixed
> versions of the package.  That is, 12 hours for the whole boat of
> F8->F10 updates and updates-testing.  Quite a bit less if we're just
> going to do say f10-updates only, but still /hours/.

No, I mean just restore the tree to the previously run compose 
(basically, restore from backup/snapshot/etc) Although updates that 
break like this don't happen very frequently, I wonder how many F10 
users just use PK and don't follow fedora lists, so aren't going to get 
any more updates unless they notice that there haven't been updates for 
a while and look into it. Was there a post to fedora-announce about this?

(Plus it took 2 days for me - I got PackageKit pushed but couldn't 
update because gnome-packagekit wasn't pushed, plus the mirror update lag)

Bradley



From opensource at till.name  Thu Dec 11 23:35:12 2008
From: opensource at till.name (Till Maas)
Date: Fri, 12 Dec 2008 00:35:12 +0100
Subject: Packaging dtds
Message-ID: <200812120035.18974.opensource@till.name>

Hiyas,

I would like to package a dtd for a package of mine: pam_mount. It has an xml 
config file that has this dtd line:

<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">

Where do I now have to install the dtd? Is it 
/usr/share/xml/dtds/pam_mount/pam_mount.conf.xml.dtd? I guess I will also have 
to create some XML catalog file, probably with xmlcatalog to make xmllint find 
the dtd automatically. This seems to work:

# for /etc/catalog and xmlcatalog
Requires:         xml-common
Requires(post):   xml-common libxml2
Requires(postun): xml-common libxml2

%post
/usr/bin/xmlcatalog --noout --add "rewriteSystem" pam_mount.conf.xml.dtd 
file:///usr/share/xml/pam_mount/dtds/pam_mount.conf.xml.dtd /etc/xml/catalog 
&> /dev/null || :

%postun
if [ $1 = 0 ]; then
/usr/bin/xmlcatalog --noout --add "rewriteSystem" pam_mount.conf.xml.dtd 
file:///usr/share/xml/pam_mount/dtds/pam_mount.conf.xml.dtd /etc/xml/catalog
fi

If this is good, I will suggest to include this in the Guidelines or add it 
somewhere else in the wiki. Or is there already some guidance that I did not 
find?

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/8acd9982/attachment.sig>

From jkeating at redhat.com  Thu Dec 11 23:43:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 15:43:00 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghs80v$pdk$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<ghq732$5to$1@ger.gmane.org>
	<1229014969.3863.85.camel@localhost.localdomain>
	<ghs6mt$ll3$1@ger.gmane.org>
	<1229037944.3863.108.camel@localhost.localdomain>
	<ghs80v$pdk$1@ger.gmane.org>
Message-ID: <1229038980.3863.110.camel@localhost.localdomain>

On Fri, 2008-12-12 at 10:33 +1100, Bradley Baetz wrote:
> No, I mean just restore the tree to the previously run compose 
> (basically, restore from backup/snapshot/etc) Although updates that 
> break like this don't happen very frequently, I wonder how many F10 
> users just use PK and don't follow fedora lists, so aren't going to get 
> any more updates unless they notice that there haven't been updates for 
> a while and look into it. Was there a post to fedora-announce about this?
> 
> (Plus it took 2 days for me - I got PackageKit pushed but couldn't 
> update because gnome-packagekit wasn't pushed, plus the mirror update lag)

Given that each update push has been 150~ changes, that would be
throwing out 149 of them for one bad one.  And that's been on a 24 hour
cycle.  We're a tad over 24 hours from the last push start and we're
nearing 200 pending changes.  That's a lot to suddenly throw away and
re-churn on mirrors.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/a0d3fb84/attachment.sig>

From robert at fedoraproject.org  Fri Dec 12 00:10:05 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Fri, 12 Dec 2008 01:10:05 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229017523.30987.138.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
Message-ID: <20081212001005.GA15306@hurricane.linuxnetz.de>

Hello James,

On Thu, 11 Dec 2008, James Antill wrote:
>  The main reason? it was a daemon initially is that pirut/pupplet spoke
> to it over dbus.
>  Changing yum-cron to use yum-updatesd --oneshot was on my TODO list a
> long time ago, but it turned out to be non-trivial and keep backwards
> compat. with both pieces ... so nothing happened to either piece.

well, we all know nowadays, that it isn't really perfect, if everything
depends on dbus. Yes I know, I'm rubbing salt into the wounds. But stuff is
also breaking very easily.

> ? One other feature is that we wanted "hourly" but with a random start,
> so if everyone turned their computer on at 9am it wouldn't slam the
> repo. ... this might be possible in newer cron's though.

This is already possible with every cron: "sleep $(expr $RANDOM % 7200)" is
something, spamassassin already uses inside of the cronjob. That could have
been lightly adapted for a yum cronjob to generate more randomness and to
enlarge the possible timeframe.

Of course I understand, that dbus is nice and so on, but I'm not seeing how
it is really useful. Again, the push happens about every 24 hours and the
cache of the downloaded files by yum expires after maybe one hour, if I am
not wrong here. Why do we generate such unnecessary load and traffic?


Greetings,
  Robert



From lesmikesell at gmail.com  Fri Dec 12 00:31:58 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 18:31:58 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812111326oddf020eh6c17b26ad531b313@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org>	<49416103.6050900@gmail.com>	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>	<49416C55.6010900@gmail.com>	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>	<494178C1.3040002@gmail.com>	<604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>	<49418222.307@gmail.com>
	<604aa7910812111326oddf020eh6c17b26ad531b313@mail.gmail.com>
Message-ID: <4941B0FE.5070104@gmail.com>

Jeff Spaleta wrote:
> On Thu, Dec 11, 2008 at 12:12 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> That wasn't a question.  I'll figure out how to test for brokenness after
>> you tell me how to reproduce exact tested, non-broken states. Or maybe I'll
>> watch the mail list for subjects like 'sucking' or "dbus disaster" before
>> doing any updates.
> 
> You are the one that introduced the "known broken" terminology and
> have used in for like 3.2 million posts in this thread. Its your
> concept. Not mine.

For my example of the late FC6 update, the machine didn't boot.  I'd say 
  that's clearly a 'known broken' state at that point.  But not much 
more than that is clear.  Why does that have to happen to more than one 
machine?  Why does everyone it does happen to have to diagnose it 
further than not wanting that package set on any other machine?

>>> 2) Once you know its broken how prevent it from going on to a client
>>> system
>>> .... yum's configuration options work just fine for that.
>> No, I have to know a lot more than "it's broken" to do anything with a yum
>> configurations.  What I'd rather do is find an "it works", tested set and
>> duplicate that and only that.
> 
> If I tell you that "it works" is that enough for you?

If you have identical hardware, an identical set of other packages, and 
a similar workload, yes.

> Are you willing
> to trust me on that? Are you willing to trust any individual
> maintainer on that?

It's not a matter of trust for at least couple of reasons.  One is that 
your hardware and installed package set is probably nothing like mine. 
Another is that a maintainer might not be running the same version he 
pushed to everyone else, either by design or mistake.

> I'll just write an auto-fire script to send you
> email every time I install an update telling you it works.  How do you
> define what qualifies as working well enough for you before YOU
> install it?

That depends entirely on which machine(s) you are talking about.  It 
doesn't relate so much to me personally.

> What specifically do YOU need to see happen for you to
> feel an update is vetted enough for you to install?

Again, it isn't personal - it has to do with the need to keep certain 
machines running.  And what needs to happen is to know that somewhere, 
someone has installed the same package set on the same kind of hardware 
and has it still working.  Either a dedicated similar test machine would 
work, or waiting until some large number of others had run the new 
package set with no problems.

> And once you tell
> us what those things are... are YOU going to help implement them?

I'd be relatively happy to keep a test machine up to date and make sure 
it runs and that the programs I care about still work.  But, it doesn't 
make any sense to do that, knowing that no one else will be able to take 
advantage of that and that there is no way to duplicate the tested set 
of packages elsewhere.  I'd have no privacy concerns about the test 
machines - if there were a way to export it's package set, hardware 
list, and the fact that it is still working to something that could 
accumulate these statistics, that would be fine.

>>> 3) If you found out its broken after you installed it on a client
>>> system how do you revert to a previous update?
>>> ... you keep a local cache of previously installed updates. yum lets
>>> you keep a local cache..per client. The caching is off by default but
>>> it can be turned on.
>> Is that really the plan you expect users to follow?  Has anyone even tried
>> that to see if it works in the general case?
> 
> I've used it.

That hardly sounds like a recommendation.

> On my systems running Fedora which I maintain to be used
> and updated primarily by other people (like my wife's desktop).. I do
> in fact keep a local cache of previously installed updates which I
> purge based on my local administration policy judgement.  When there
> is an update that breaks functionality for her I am able to manually
> install the cached older version and then set an exclude. I don't have
> to use it often.

That sounds like at least an admission that the stock tools and 
mechanisms aren't good enough.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From opensource at till.name  Fri Dec 12 00:31:13 2008
From: opensource at till.name (Till Maas)
Date: Fri, 12 Dec 2008 01:31:13 +0100
Subject: Packaging dtds
In-Reply-To: <200812120035.18974.opensource@till.name>
References: <200812120035.18974.opensource@till.name>
Message-ID: <200812120131.20427.opensource@till.name>

On Fri December 12 2008, Till Maas wrote:

> %postun
> if [ $1 = 0 ]; then
> /usr/bin/xmlcatalog --noout --add "rewriteSystem" pam_mount.conf.xml.dtd
> file:///usr/share/xml/pam_mount/dtds/pam_mount.conf.xml.dtd
> /etc/xml/catalog fi

This should be the following:

/usr/bin/xmlcatalog --noout --del 
file://%{_datadir}/xml/pam_mount/dtds/pam_mount.conf.xml.dtd 
%{_sysconfdir}/catalog

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/63041050/attachment.sig>

From jspaleta at gmail.com  Fri Dec 12 01:00:23 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 16:00:23 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4941B0FE.5070104@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<49416103.6050900@gmail.com>
	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>
	<49416C55.6010900@gmail.com>
	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>
	<494178C1.3040002@gmail.com>
	<604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>
	<49418222.307@gmail.com>
	<604aa7910812111326oddf020eh6c17b26ad531b313@mail.gmail.com>
	<4941B0FE.5070104@gmail.com>
Message-ID: <604aa7910812111700k3063ca6r6b860eb38c7c6529@mail.gmail.com>

On Thu, Dec 11, 2008 at 3:31 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> If I tell you that "it works" is that enough for you?
>
> If you have identical hardware, an identical set of other packages, and a
> similar workload, yes.

How do you know if I do or do not?  Are you saying that the only
information that would help you make a determination as to 'known
broken' or 'is working' as YOU define those concepts is if you have
feedback from people who are doing what you are doing with the
hardware you are using? How much detail do you need about other
people's machines and workloads? How in the hell do you expect to
capture that level of detail from other people?

You keep missing the point. I'm going to have to ratchet up the
bluntness factor for you.

You are trying to rely on other people's experiences with updates to
justify whether you should be installing the update on your systems.
You haven't described how you would expect to capture that distributed
information from other people in such a way that you can make use of
it before you need to make the decision as to whether or not to
install that update on your very very precious machines.

You are talking in generalities and what this discussion needs at this
point is implementation specifics.

> It's not a matter of trust for at least couple of reasons.  One is that your
> hardware and installed package set is probably nothing like mine.

How do you know? How do you know that anyone out there is doing
something close enough to what you are doing to be comparable?  If you
are looking to compare systems and workloads you have to trust people
they are reporting the right information.

> Again, it isn't personal - it has to do with the need to keep certain
> machines running.

Stop with the generalities. Talk about YOUR needs and YOUR workloads.

> And what needs to happen is to know that somewhere,
> someone has installed the same package set on the same kind of hardware and
> has it still working.

How do you expect that information to be collected? How do you expect
that information to be served up?

>> I've used it.
>
> That hardly sounds like a recommendation.

I official recommend that you do whatever it is I've already
suggested.  Does that help?
Does that make the idea sound better to you? Need that in writing?


> That sounds like at least an admission that the stock tools and mechanisms
> aren't good enough.

Good enough for what? I do not expect the provided tools to meet all
of my needs all the time. As an adminstrator I am accountable for the
integrity of my systems... not Fedora... not the mirrors which are
serving fedora packages..and not my ISP who is providing me the
network access to reach those mirrors.  I expect there to be a need
for local administration policy that I control...which mitigates the
dependence on any external entity which puts the integrity of my
systems at risk.  For updates, that means doing several things, one of
which is caching backups locally in case I need to back out
something..even in situations where my ISP has a problem and my
network access goes down.

-jef



From tgl at redhat.com  Fri Dec 12 01:37:21 2008
From: tgl at redhat.com (Tom Lane)
Date: Thu, 11 Dec 2008 20:37:21 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora 
In-Reply-To: <604aa7910812111700k3063ca6r6b860eb38c7c6529@mail.gmail.com> 
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<49416103.6050900@gmail.com>
	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>
	<49416C55.6010900@gmail.com>
	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>
	<494178C1.3040002@gmail.com>
	<604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>
	<49418222.307@gmail.com>
	<604aa7910812111326oddf020eh6c17b26ad531b313@mail.gmail.com>
	<4941B0FE.5070104@gmail.com>
	<604aa7910812111700k3063ca6r6b860eb38c7c6529@mail.gmail.com>
Message-ID: <14986.1229045841@sss.pgh.pa.us>

"Jeff Spaleta" <jspaleta at gmail.com> writes:
> You are trying to rely on other people's experiences with updates to
> justify whether you should be installing the update on your systems.
> You haven't described how you would expect to capture that distributed
> information from other people in such a way that you can make use of
> it before you need to make the decision as to whether or not to
> install that update on your very very precious machines.

It's worse than that.  Presumably, nobody is shipping deliberately-broken
packages, and so if there is a regression that is going to bite you then
it is contingent on factors not known to the package maintainer.  This
means that in reality, you won't even know what questions to ask ---
what combination of hardware, other software, and usage pattern is
really critical?  There is no way to know in advance.  And by the time
that a bug is well enough characterized that you could use such a
database to decide if it might bite you, the package is probably either
fixed or withdrawn.

There's certainly value in a karma-style scoring mechanism to help
identify badly broken releases, but I think it's a pipe dream to imagine
that that can be refined into any sort of reliable predictor of
individual results.

			regards, tom lane



From john.ellson at comcast.net  Fri Dec 12 01:40:08 2008
From: john.ellson at comcast.net (John Ellson)
Date: Thu, 11 Dec 2008 20:40:08 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
Message-ID: <4941C0F8.6010203@comcast.net>

Seth Vidal wrote:
>
>
> On Thu, 11 Dec 2008, Steven Moix wrote:
>
>> Hello,
>>
>> Last night I had an idea, why not alias "yum update" to "yum
>> --skip-broken update" by default? This simple hack could prevent a lot
>> of recurring support questions on the forums:
>>
>> 1) People who have dependency problem won't see them anymore.
>
> b/c we need to get the dep problems reported, too.

I'm just wondering why you need 1000s of busy developers to all hit the 
same dependency issues to find this out?

Can't you do this on one "dependency checker' machine somewhere?   Or 
have it automatically reported from a limited number of testers?


-- 
John Ellson



From a.badger at gmail.com  Fri Dec 12 01:39:08 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 11 Dec 2008 17:39:08 -0800
Subject: Packaging dtds
In-Reply-To: <200812120035.18974.opensource@till.name>
References: <200812120035.18974.opensource@till.name>
Message-ID: <4941C0BC.2060706@gmail.com>

I wrote some a catalog handling %post(un) in the Red Hat Linux 9/Fedora
Core 1 time frame.  Not sure if it's still up to date, though.

> I would like to package a dtd for a package of mine: pam_mount. It has an xml 
> config file that has this dtd line:
> 
> <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
> 
The DOCTYPE that I was dealing with was:

  <!DOCTYPE checklist
    PUBLIC "-//BadgerWare//DTD QA Assistant Checklist File 0.3//EN"
    "http://qa-assistant.sf.net/dtds/checklist/0.3/checklist.dtd">

I think some of the differences we see below are due to PUBLIC instead
of SYSTEM.  Some other differences are due to upstream's use of a
subcatalog.

> Where do I now have to install the dtd? Is it 
> /usr/share/xml/dtds/pam_mount/pam_mount.conf.xml.dtd? I guess I will also have 
> to create some XML catalog file, probably with xmlcatalog to make xmllint find 
> the dtd automatically. This seems to work:
> 
> # for /etc/catalog and xmlcatalog
> Requires:         xml-common
> Requires(post):   xml-common libxml2
> Requires(postun): xml-common libxml2
> 
This looks correct.

> %post
> /usr/bin/xmlcatalog --noout --add "rewriteSystem" pam_mount.conf.xml.dtd 
> file:///usr/share/xml/pam_mount/dtds/pam_mount.conf.xml.dtd /etc/xml/catalog 
> &> /dev/null || :
> 

I did:

  ROOTCATALOG=%{_sysconfdir}/xml/catalog
  /usr/bin/xmlcatalog --noout --add "delegatePublic" \
      "-//BadgerWare//DTD QA Assistant" \
      "file://$CATALOG" $ROOTCATALOG &> /dev/null || :
  /usr/bin/xmlcatalog --noout --add "delegateSystem" \
      "http://qa-assistant.sf.net/dtds" \
      "file://$CATALOG" $ROOTCATALOG &> /dev/null || :
  /usr/bin/xmlcatalog --noout --add "delegateURI" \
      "http://qa-assistant.sf.net/dtds" \
      "file://$CATALOG" $ROOTCATALOG &> /dev/null || :

[Corrected from next post]
> %postun
> if [ $1 = 0 ]; then
> /usr/bin/xmlcatalog --noout --del
> file://%{_datadir}/xml/pam_mount/dtds/pam_mount.conf.xml.dtd
> %{_sysconfdir}/catalog
> fi
> 
  ROOTCATALOG=%{_sysconfdir}/xml/catalog
  CATALOG=%{_datadir}/xml/qa-assistant/xmlcatalog

  /usr/bin/xmlcatalog --noout --del \
      "-//BadgerWare//DTD QA Assistant" &> /dev/null || :
  /usr/bin/xmlcatalog --noout --del \
      "http://qa-assistant.sf.net/dtds"

The $CATALOG file referenced in the above snippets was created by the
upstream Makefile.  It added rewriteSystem as you do and also rewriteURI
and public:

 $(XMLCATALOG) --noout --add "public" \
  "-//BadgerWare//DTD QA Assistant Checklist File 0.3//EN" \
  "checklist/0.3/checklist.dtd" $(DESTDIR)$(CATALOG);
 $(XMLCATALOG) --noout --add "rewriteSystem" \
  "http://qa-assistant.sf.net/dtds/checklist/0.3" \
  "checklist/0.3/" $(DESTDIR)$(CATALOG);
 $(XMLCATALOG) --noout --add "rewriteURI" \
  "http://qa-assistant.sf.net/dtds/checklist/0.3" \
  "checklist/0.3/" $(DESTDIR)$(CATALOG);

The dtd ended up in %{_datadir}/xml/qa-assistant/checklist/0.3/checklist.dtd

The catalog referencing it was in %{_datadir}/xml/qa-assistant/xmlcatalog

> If this is good, I will suggest to include this in the Guidelines or add it 
> somewhere else in the wiki. Or is there already some guidance that I did not 
> find?
> 
This should go on Packaging/ScriptletSnippets when done.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/4c2f5836/attachment.sig>

From jspaleta at gmail.com  Fri Dec 12 01:47:20 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 16:47:20 -0900
Subject: yum --skip-broken update by default?
In-Reply-To: <4941C0F8.6010203@comcast.net>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
Message-ID: <604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>

On Thu, Dec 11, 2008 at 4:40 PM, John Ellson <john.ellson at comcast.net> wrote:
> Can't you do this on one "dependency checker' machine somewhere?   Or have
> it automatically reported from a limited number of testers?

A limited number of testers who attempt to install and update
EVERYTHING from every possible starting state between release and
current update collection.. including 3rd party interactions?

-jef



From kevin.kofler at chello.at  Fri Dec 12 01:55:00 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 02:55:00 +0100
Subject: use fcron as default scheduler in Fedora?
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<a2e85ed0812090100o347e9e2j293310f7f85d82ca@mail.gmail.com>
	<gtk416xo18.ln2@ppp1053.in.ipex.cz>
Message-ID: <ghsg9k$de8$1@ger.gmane.org>

Matej Cepl wrote:
> But you know it isn't, right? You surely know what is The
> Standard Text Editor, don't you?

Sure, KWrite. :-)

/me runs away from the hordes of vi and Emacs users suddenly uniting to
lynch me. ;-)

        Kevin Kofler



From jspaleta at gmail.com  Fri Dec 12 02:19:44 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 17:19:44 -0900
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081209151206.GA13238@nostromo.devel.redhat.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
Message-ID: <604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>

On Tue, Dec 9, 2008 at 6:12 AM, Bill Nottingham <notting at redhat.com> wrote:
> I'm not sure why a dependency on vim-minimal is truly that bad.

Is this a requirement on vim-minimal or just a requirement for a posix
compliant editor to be available?

Or let me ask it this way. Right now in the entire repository is
vim-minimal the only editor which is being explicitly required to
filling this fallback role? If it is, enshrine that as policy before I
get a chance to submit a package which falls back to nano. If its not
the only editor being used as a fallback in the repository, then some
compromise needs to be worked out so don't have people dragging in
multiple editors to fill the fallback capacity.

-jef



From kevin.kofler at chello.at  Fri Dec 12 02:22:30 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:22:30 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
Message-ID: <ghsht6$gpk$1@ger.gmane.org>

Robert Scheck wrote:
> Of course I understand, that dbus is nice and so on, but I'm not seeing
> how it is really useful. Again, the push happens about every 24 hours and
> the cache of the downloaded files by yum expires after maybe one hour, if
> I am not wrong here. Why do we generate such unnecessary load and traffic?

Because you do not know *when* the update push happens. And there are
third-party repos which sometimes push several updates a day.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 02:28:05 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:28:05 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
Message-ID: <ghsi7l$gpk$2@ger.gmane.org>

Jesse Keating wrote:
> With the 6 month cycle of Fedora, and our willingness to break things
> like crazy in the rawhide world, we're still a very very fast distro and
> unique in the distro space for early adoption of software.

But it is not enough. The updates are an important part of that. When
Kubuntu released Intrepid, Fedora 9 already had the same version of KDE
(4.1.2) despite having been released 6 months earlier. How was this
possible? Thanks to the updates of course! It's similar for the kernel and
other packages whose maintainers push new versions regularly.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 02:33:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:33:02 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
Message-ID: <ghsigu$gpk$3@ger.gmane.org>

Arthur Pemberton wrote:
> 6 months is a pretty long time to wait for a major release. I
> understand the rationale, but if this is going to be the new Fedora,
> best announce this and let  everyone know so that they can reevaluate
> if Fedora is for them. As things are, I feel that we are being _too_
> conservative. Any further move to more conservatism seriously affects
> Fedora's usefulness to me.

+1

On the "too conservative" scale, I'll put e.g. GNOME which could be upgraded
just as KDE is and Python which could be upgraded to point releases (of
course not from 2.5 to 2.6 or even 3.0, but to newer 2.5.x releases - for
example, F10 has 2.5.2, but F8 and F9 are stuck with 2.5.1 at a whopping
patch level of -26) (but there's more such stuff, those are just 2
examples).

        Kevin Kofler



From cra at WPI.EDU  Fri Dec 12 02:35:01 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 11 Dec 2008 21:35:01 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsi7l$gpk$2@ger.gmane.org>
References: <16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
Message-ID: <20081212023501.GG9937@angus.ind.WPI.EDU>

On Fri, Dec 12, 2008 at 03:28:05AM +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> > With the 6 month cycle of Fedora, and our willingness to break things
> > like crazy in the rawhide world, we're still a very very fast distro and
> > unique in the distro space for early adoption of software.
> 
> But it is not enough. The updates are an important part of that. When
> Kubuntu released Intrepid, Fedora 9 already had the same version of KDE
> (4.1.2) despite having been released 6 months earlier. How was this
> possible? Thanks to the updates of course! It's similar for the kernel and
> other packages whose maintainers push new versions regularly.

On the other hand, having every other kernel update break either 
wireless or suspend/hibernate sucks too.



From kevin.kofler at chello.at  Fri Dec 12 02:37:08 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:37:08 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1229013831.3863.76.camel@localhost.localdomain>
Message-ID: <ghsiok$gpk$5@ger.gmane.org>

Jesse Keating wrote:
> To an extent, that's acceptable.  Superfluous and gratuitous major
> version changes aren't.  Also, there is a difference between doing 4.0
> to 4.1 and doing something like 3.5 to 4.1.  I'm pretty sure you
> understand the spirit of what I'm pushing for, and aren't just trying to
> find fault in the specific words I've used (since every upstream is
> different and use numbers in different ways to express different
> things).

Well, I'm not sure I understood it and I'm also not sure the other people in
the discussion understood it.

I won't argue against the fact that an upgrade of the KDE 3->4 kind has no
business being in the update stream for a stable release, this seems
blatantly obvious to me. :-)

        Kevin Kofler



From jspaleta at gmail.com  Fri Dec 12 02:40:50 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 17:40:50 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081212023501.GG9937@angus.ind.WPI.EDU>
References: <16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org> <20081212023501.GG9937@angus.ind.WPI.EDU>
Message-ID: <604aa7910812111840ve4c326fie36b0f85c3b8b750@mail.gmail.com>

On Thu, Dec 11, 2008 at 5:35 PM, Chuck Anderson <cra at wpi.edu> wrote:
> On the other hand, having every other kernel update break either
> wireless or suspend/hibernate sucks too.

kernels are a bad example here.  We treat them different and let them
be parallel installable specifically to give you a fallback.

-jef



From kevin.kofler at chello.at  Fri Dec 12 02:44:11 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:44:11 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<49414D5F.4010202@gmail.com> <1229021252.6236.15.camel@arekh.okg>
Message-ID: <ghsj5s$k8d$1@ger.gmane.org>

Nicolas Mailhot wrote:
> I'm packaging a project that does monthly releases too (or did, it
> slowed down a little). Each new release brings bug fixes and features
> part of our userbase cares about. Anyone not having the latest features
> may have problems communicating with someone who does. Some releases
> have made changes that made people complain in the past. This package is
> in the default install set and should be installed on 90%+ of our
> userbase.

dejavu-fonts?

> And you know what? I don't push updates to stable releases. I haven't
> for a long time. Users can wait a little. The world does not end.

IMHO this is a bad decision. I remember the times you pushed out all the
updates and they never caused any problems.

> 6 months is really nothing except for update junkies. And update junkies
> will be happier with rawhide anyway.

No they won't, because there's a lot of breakage in Rawhide.

And people use Fedora *because* of the updates. There are dozens of other
distros to use for those who don't want them.

> Anything but a major bug fix or initial import has no place in Fedora
> updates. Other stuff helps very advanced users who can manage update
> breakage and hurts pretty much everyone else.

Update breakage induced by a font package? Come on... :-)

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 02:47:01 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:47:01 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>	<1228938532.3863.46.camel@localhost.localdomain>	<20081210234811.GA11018@zod.rchland.ibm.com>	<ghpktm$vou$1@ger.gmane.org>	<ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org>	<ghqfsl$pnm$1@ger.gmane.org>
	<ghqiqd$1h2$1@ger.gmane.org>
	<1228993069.3394.841.camel@beck.corsepiu.local>
	<49414B7A.1060903@gmail.com>
Message-ID: <ghsjb5$k8d$2@ger.gmane.org>

Les Mikesell wrote:
> But, balance that against the advice given here to people who complained
> about KDE 4.0 not being ready for prime time, which was that "nobody
> forced you to upgrade to F9".

... which is a good argument for having pushed version upgrades which don't
introduce major changes to F8 too, even after F9's release!

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 02:54:07 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:54:07 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<ghq7vu$5to$5@ger.gmane.org>
	<ghqcjc$iea$1@ger.gmane.org>
	<200812111242.15428.opensource@till.name>
	<494151CB.3020605@gmail.com>
Message-ID: <ghsjof$k8d$3@ger.gmane.org>

Les Mikesell wrote:
> Anyone who _wants_ todays bugs from upstream can always grab their
> tarball and build it under /usr/local/ with the big advantage of having
> a way back when they find it doesn't quite work.

Uh, what way back? A non-RPM package is almost impossible to uninstall
cleanly, at least as soon as you have more than one package in /usr/local.
Moreover, they may also write stuff to /usr, for example for menu entries
or other system integration tasks. (Or if they don't do that, they often
lack the system integration they'd have when installed to /usr.) Programs
are not isolated pieces. Tracking what they install where is what packages
are for. Some programs support "make uninstall", but most either don't
support it at all or never test it and leave it in various stages of
brokenness. And in any case it only works if you still have the exact
configured build directory you used to install the package.

It's much easier to rpm -Uvh --oldpackage to an older version than to get
rid of some custom-installed version.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 02:35:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:35:02 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
Message-ID: <ghsikm$gpk$4@ger.gmane.org>

Michael Schwendt wrote:

> On Thu, 11 Dec 2008 12:32:12 -0600, Arthur wrote:
> 
>> 6 months is a pretty long time to wait for a major release. I
>> understand the rationale, but if this is going to be the new Fedora,
>> best announce this and let  everyone know so that they can reevaluate
>> if Fedora is for them. As things are, I feel that we are being _too_
>> conservative. Any further move to more conservatism seriously affects
>> Fedora's usefulness to me.
> 
> Why?

Because, like me, he chose Fedora *because* of the stream of updates, we
*want* those updates, including version upgrades. We would be using Ubuntu
or CentOS or any of the other bazillion conservative distros otherwise.

A distro with a 6-month release cycle, but conservative updates, already
exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
go use Ubuntu.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 02:59:25 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 03:59:25 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<ghq732$5to$1@ger.gmane.org>
	<1229014969.3863.85.camel@localhost.localdomain>
Message-ID: <ghsk2d$k8d$4@ger.gmane.org>

Jesse Keating wrote:
> I mean, I just recently saw a maintainer build a package from F9,10, and
> 11 just to update a summary.  Was that seriously worth a build?  I
> haven't yet seen if the maintainer has queued up bodhi updates for that,
> but come on, seriously?  That type of change can certainly wait until
> there is a more compelling reason to consume the resources of an update.

Well yeah, 100% +1 to this one. Some updates really make no sense.

Maintainers pushing updates of the "Remove dot at end of Summary" type (and
I'm not even sure I'm exaggerating there, this may well have already
happened at some point!) really don't "get" it...

        Kevin Kofler



From walters at verbum.org  Fri Dec 12 03:08:40 2008
From: walters at verbum.org (Colin Walters)
Date: Thu, 11 Dec 2008 22:08:40 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsikm$gpk$4@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
	<ghsikm$gpk$4@ger.gmane.org>
Message-ID: <faa16b610812111908t515db343l683baedf0bf942dd@mail.gmail.com>

On Thu, Dec 11, 2008 at 9:35 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Michael Schwendt wrote:
>
>> On Thu, 11 Dec 2008 12:32:12 -0600, Arthur wrote:
>>
>>> 6 months is a pretty long time to wait for a major release. I
>>> understand the rationale, but if this is going to be the new Fedora,
>>> best announce this and let  everyone know so that they can reevaluate
>>> if Fedora is for them. As things are, I feel that we are being _too_
>>> conservative. Any further move to more conservatism seriously affects
>>> Fedora's usefulness to me.
>>
>> Why?
>
> Because, like me, he chose Fedora *because* of the stream of updates, we
> *want* those updates, including version upgrades. We would be using Ubuntu
> or CentOS or any of the other bazillion conservative distros otherwise.
>
> A distro with a 6-month release cycle, but conservative updates, already
> exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
> go use Ubuntu.

I don't think that's a good argument - there are quite a lot of
nontrivial differences between the two aside from the updates, such as
commitment to Free Software, multilib, different strengths in package
set, etc.  We don't need to change the world, just add an idiot filter
in bodhi =)



From kevin.kofler at chello.at  Fri Dec 12 03:09:34 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 04:09:34 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<200812112200.46965.opensource@till.name>
	<494184CC.1020104@gmail.com>
	<200812112248.55542.opensource@till.name>
Message-ID: <ghskle$k8d$6@ger.gmane.org>

Till Maas wrote:
> You can start with updating only packages that update packages you are not
> satisfied with. To get as much bugs fixed as possible in the initial
> release, you have to do more testing and report bugs.

But keep in mind updates are not tested in isolation, only with the previous
updates already applied. I can only repeat the advice from the old RHL
errata advisories:
> Before applying this update, make sure all previously released errata
> relevant to your system have been applied.

>From my experience with bug reports, selective updates are often a source of
trouble.

        Kevin Kofler



From jamundso at gmail.com  Fri Dec 12 03:11:21 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Thu, 11 Dec 2008 21:11:21 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsi7l$gpk$2@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
Message-ID: <6d06ce20812111911w361e242rdf895ca0793b8d39@mail.gmail.com>

On 12/11/08, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Jesse Keating wrote:
>> With the 6 month cycle of Fedora, and our willingness to break things
>> like crazy in the rawhide world, we're still a very very fast distro and
>> unique in the distro space for early adoption of software.
>
> But it is not enough. The updates are an important part of that. When
> Kubuntu released Intrepid, Fedora 9 already had the same version of KDE
> (4.1.2) despite having been released 6 months earlier. How was this
> possible? Thanks to the updates of course! It's similar for the kernel and
> other packages whose maintainers push new versions regularly.

For discussions' sake though, Fedora 9's 4.1.2 was built only one month prior.
http://koji.fedoraproject.org:80/koji/buildinfo?buildID=64533
http://www.kubuntu.org/news/8.10-release

jerry

-- 
Store in cool, dry place. Rotate stock.



From lesmikesell at gmail.com  Fri Dec 12 03:13:30 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 21:13:30 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812111908t515db343l683baedf0bf942dd@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>	<ghqc4j$brb$11@ger.gmane.org>
	<4940B92A.1030403@gmail.com>	<ghqg1t$pnm$2@ger.gmane.org>	<1229014165.3863.79.camel@localhost.localdomain>	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>	<20081211220650.e89782d5.mschwendt@gmail.com>	<ghsikm$gpk$4@ger.gmane.org>
	<faa16b610812111908t515db343l683baedf0bf942dd@mail.gmail.com>
Message-ID: <4941D6DA.80400@gmail.com>

Colin Walters wrote:
> On Thu, Dec 11, 2008 at 9:35 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> Michael Schwendt wrote:
>>
>>> On Thu, 11 Dec 2008 12:32:12 -0600, Arthur wrote:
>>>
>>>> 6 months is a pretty long time to wait for a major release. I
>>>> understand the rationale, but if this is going to be the new Fedora,
>>>> best announce this and let  everyone know so that they can reevaluate
>>>> if Fedora is for them. As things are, I feel that we are being _too_
>>>> conservative. Any further move to more conservatism seriously affects
>>>> Fedora's usefulness to me.
>>> Why?
>> Because, like me, he chose Fedora *because* of the stream of updates, we
>> *want* those updates, including version upgrades. We would be using Ubuntu
>> or CentOS or any of the other bazillion conservative distros otherwise.
>>
>> A distro with a 6-month release cycle, but conservative updates, already
>> exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
>> go use Ubuntu.
> 
> I don't think that's a good argument - there are quite a lot of
> nontrivial differences between the two aside from the updates, such as
> commitment to Free Software, multilib, different strengths in package
> set, etc.  We don't need to change the world, just add an idiot filter
> in bodhi =)

And the big difference: if you also need to keep RHEL and Centos boxes 
working, debian/Ubuntu is quite a culture shock.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Fri Dec 12 03:14:09 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 04:14:09 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<493EB9DE.6000507@gmail.com>	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>	<1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<604aa7910812091443u61131bb7vaac33c84e3596c11@mail.gmail.com>	<493F6B8F.8010209@gmail.com>	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>	<493F7368.9010005@gmail.com>	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>	<ghqb66$brb$5@ger.gmane.org>
	<4940BCB9.9070408@gmail.com>
	<1229015958.30987.133.camel@code.and.org>
	<4941653B.1070509@gmail.com>
Message-ID: <ghsku1$k8d$7@ger.gmane.org>

Les Mikesell wrote:
> No one is asking for that.  The problems with fedora are that there is
> no reason to expect any better stability at the end of a fedora version
> than at the beginning

Uh, Fedora releases _do_ tend to get more stable as updates come in. Taking
aside the D-Bus fiasco, F9 is a lot better now than when it was released.

        Kevin Kofler



From rc040203 at freenet.de  Fri Dec 12 03:18:28 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 12 Dec 2008 04:18:28 +0100
Subject: Installing from Live CD is the new black?
In-Reply-To: <604aa7910812111026q45f15904h93a9ce09c4b105d5@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<604aa7910812111026q45f15904h93a9ce09c4b105d5@mail.gmail.com>
Message-ID: <1229051908.3081.160.camel@beck.corsepiu.local>

On Thu, 2008-12-11 at 09:26 -0900, Jeff Spaleta wrote:
> On Thu, Dec 11, 2008 at 9:18 AM, Chris Lumens <clumens at redhat.com> wrote:
> > I do kind of wish everyone used live CDs, but that's probably never
> > going to be the way it works.
> 
> Live CDs are sooooo 2002.  You need to start using the phrase Live SDs

Live SDHCs, if you really feel like it. And when, then be consequent and
compose them from Everything/ ;)

Ralf




From kevin.kofler at chello.at  Fri Dec 12 03:06:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 04:06:02 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<493F0BA8.1050300@gmail.com>
	<1228930226.30987.107.camel@code.and.org>	<49416103.6050900@gmail.com>	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>	<49416C55.6010900@gmail.com>	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>	<494178C1.3040002@gmail.com>	<604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>	<49418222.307@gmail.com>
	<604aa7910812111326oddf020eh6c17b26ad531b313@mail.gmail.com>
	<4941B0FE.5070104@gmail.com>
Message-ID: <ghskeq$k8d$5@ger.gmane.org>

Les Mikesell wrote:
> For my example of the late FC6 update, the machine didn't boot.  I'd say
>   that's clearly a 'known broken' state at that point.  But not much
> more than that is clear.  Why does that have to happen to more than one
> machine?

Because if we block/unpush/whatever updates based on a single report of
brokenness, all Joe Evil Cracker needs to do to break into your machine is
to wait for a security issue in OpenSSH or some other security-critical
software, report the security update as "broken" and then exploit the hole.
There would also be other kinds of vandals or jokesters who'd incorrectly
report updates as "broken" just for fun.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 03:18:08 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 04:18:08 +0100
Subject: Installing from Live CD is the new black?
References: <1228955078.3037.10.camel@fecusia> <4940B89E.8050400@nicubunu.ro>
	<1229015757.3863.89.camel@localhost.localdomain>
Message-ID: <ghsl5g$k8d$8@ger.gmane.org>

Jesse Keating wrote:
> The setup for harddrive or network iso has changed, such that you now
> need an images/ directory with the install.img file within it at the
> same level as the directory of your isos.  We no longer crack open the
> isos in loader to find a image to use to bring up anaconda.

May I ask why?

        Kevin Kofler



From lesmikesell at gmail.com  Fri Dec 12 03:25:26 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 21:25:26 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsjof$k8d$3@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<ghq7vu$5to$5@ger.gmane.org>	<ghqcjc$iea$1@ger.gmane.org>	<200812111242.15428.opensource@till.name>	<494151CB.3020605@gmail.com>
	<ghsjof$k8d$3@ger.gmane.org>
Message-ID: <4941D9A6.4000602@gmail.com>

Kevin Kofler wrote:
> 
>> Anyone who _wants_ todays bugs from upstream can always grab their
>> tarball and build it under /usr/local/ with the big advantage of having
>> a way back when they find it doesn't quite work.
> 
> Uh, what way back?

Just use the one you still have in /usr/bin.

> A non-RPM package is almost impossible to uninstall
> cleanly, at least as soon as you have more than one package in /usr/local.

That's true for some.  Many understand that you often want parallel 
installs and go where you tell them.

> Moreover, they may also write stuff to /usr, for example for menu entries
> or other system integration tasks. (Or if they don't do that, they often
> lack the system integration they'd have when installed to /usr.)

System integration is generally a mistaken concept when you want 
parallel installs.

> Programs
> are not isolated pieces.

Many are, until distributions break the concept of parallel installs.

> Tracking what they install where is what packages
> are for.

With big tradeoffs in terms of making concurrent versions mostly impossible.

> Some programs support "make uninstall", but most either don't
> support it at all or never test it and leave it in various stages of
> brokenness. And in any case it only works if you still have the exact
> configured build directory you used to install the package.

And some install under a self-contained directory

> It's much easier to rpm -Uvh --oldpackage to an older version than to get
> rid of some custom-installed version.

Maybe.  What if the new version had dependencies that pulled in 
non-backwards compatible components?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Fri Dec 12 03:26:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 04:26:37 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<6d06ce20812111911w361e242rdf895ca0793b8d39@mail.gmail.com>
Message-ID: <ghslld$k8d$9@ger.gmane.org>

Jerry Amundson wrote:
> For discussions' sake though, Fedora 9's 4.1.2 was built only one month
> prior. http://koji.fedoraproject.org:80/koji/buildinfo?buildID=64533
> http://www.kubuntu.org/news/8.10-release

Sure, but that would not have been possible if the upgrade could only have
happened with the F10 release, which was only after Intrepid.

And we had 4.1.1 before that, and 4.1.0 before that and... :-)

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 03:30:17 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 04:30:17 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>	<ghq7vu$5to$5@ger.gmane.org>	<ghqcjc$iea$1@ger.gmane.org>	<200812111242.15428.opensource@till.name>	<494151CB.3020605@gmail.com>
	<ghsjof$k8d$3@ger.gmane.org> <4941D9A6.4000602@gmail.com>
Message-ID: <ghslsa$k8d$10@ger.gmane.org>

Les Mikesell wrote:
> Maybe.  What if the new version had dependencies that pulled in
> non-backwards compatible components?

That's exactly why we need new versions built for stable updates rather than
just using the Rawhide versions. The whole point of building for the
current/previous release (rather than the next one, i.e. Rawhide) is to (in
the vast majority of cases) NOT need new incompatible dependencies.

        Kevin Kofler



From jamundso at gmail.com  Fri Dec 12 03:39:49 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Thu, 11 Dec 2008 21:39:49 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsku1$k8d$7@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com>
	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>
	<ghqb66$brb$5@ger.gmane.org> <4940BCB9.9070408@gmail.com>
	<1229015958.30987.133.camel@code.and.org> <4941653B.1070509@gmail.com>
	<ghsku1$k8d$7@ger.gmane.org>
Message-ID: <6d06ce20812111939i569a3772q2794834f46044f4e@mail.gmail.com>

On 12/11/08, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Les Mikesell wrote:
>> No one is asking for that.  The problems with fedora are that there is
>> no reason to expect any better stability at the end of a fedora version
>> than at the beginning
>
> Uh, Fedora releases _do_ tend to get more stable as updates come in. Taking
> aside the D-Bus fiasco, F9 is a lot better now than when it was released.

Which implies F10 should have been good at it's release, as it
benefited from the F9 updates. Right.

jerry

-- 
Store in cool, dry place. Rotate stock.



From pemboa at gmail.com  Fri Dec 12 03:52:03 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Dec 2008 21:52:03 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812111908t515db343l683baedf0bf942dd@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
	<ghsikm$gpk$4@ger.gmane.org>
	<faa16b610812111908t515db343l683baedf0bf942dd@mail.gmail.com>
Message-ID: <16de708d0812111952n57b6b900h52741d56142f6ab4@mail.gmail.com>

On Thu, Dec 11, 2008 at 9:08 PM, Colin Walters <walters at verbum.org> wrote:
> On Thu, Dec 11, 2008 at 9:35 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> Michael Schwendt wrote:
>>
>>> On Thu, 11 Dec 2008 12:32:12 -0600, Arthur wrote:
>>>
>>>> 6 months is a pretty long time to wait for a major release. I
>>>> understand the rationale, but if this is going to be the new Fedora,
>>>> best announce this and let  everyone know so that they can reevaluate
>>>> if Fedora is for them. As things are, I feel that we are being _too_
>>>> conservative. Any further move to more conservatism seriously affects
>>>> Fedora's usefulness to me.
>>>
>>> Why?
>>
>> Because, like me, he chose Fedora *because* of the stream of updates, we
>> *want* those updates, including version upgrades. We would be using Ubuntu
>> or CentOS or any of the other bazillion conservative distros otherwise.
>>
>> A distro with a 6-month release cycle, but conservative updates, already
>> exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
>> go use Ubuntu.
>
> I don't think that's a good argument - there are quite a lot of
> nontrivial differences between the two aside from the updates, such as
> commitment to Free Software,

Ubuntu is the one with an FSF blessed spin, so I don't think Fedora
has any monopoly on that.

> multilib, different strengths in package set

Not significant enough to choose Fedora over Ubuntu or vice versa. In
fact, I'd guess that Ubuntu has more packages and packagers than
Fedora (just guessing however)

So really, it comes down to making Fedora more Ubuntu like without the
Ubuntu groupies.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From rc040203 at freenet.de  Fri Dec 12 03:56:02 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 12 Dec 2008 04:56:02 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <6d06ce20812111939i569a3772q2794834f46044f4e@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<604aa7910812092317m478a37c4yc6d27e82dce8c835@mail.gmail.com>
	<493F7368.9010005@gmail.com>
	<200812110415.mBB4F8hl005376@laptop14.inf.utfsm.cl>
	<1228974529.17672.TMDA@tmda.severn.wwwdotorg.org>
	<ghqb66$brb$5@ger.gmane.org> <4940BCB9.9070408@gmail.com>
	<1229015958.30987.133.camel@code.and.org> <4941653B.1070509@gmail.com>
	<ghsku1$k8d$7@ger.gmane.org>
	<6d06ce20812111939i569a3772q2794834f46044f4e@mail.gmail.com>
Message-ID: <1229054162.3081.178.camel@beck.corsepiu.local>

On Thu, 2008-12-11 at 21:39 -0600, Jerry Amundson wrote:
> On 12/11/08, Kevin Kofler <kevin.kofler at chello.at> wrote:
> > Les Mikesell wrote:
> >> No one is asking for that.  The problems with fedora are that there is
> >> no reason to expect any better stability at the end of a fedora version
> >> than at the beginning
> >
> > Uh, Fedora releases _do_ tend to get more stable as updates come in. Taking
> > aside the D-Bus fiasco, F9 is a lot better now than when it was released.
> 
> Which implies F10 should have been good at it's release, as it
> benefited from the F9 updates. Right.
Correct, as far as packages are concerned, which happen to be identical
or at least very similar in FC9 and FC10, their is such a effect.

Unfortunately, this effect is outweighed by packages, F10 inherited from
rawhide.

Ralf




From loganjerry at gmail.com  Fri Dec 12 03:59:31 2008
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 11 Dec 2008 20:59:31 -0700
Subject: Debugging sound volume problem
Message-ID: <870180fe0812111959v6fe9c549p294a93a7a2f6a0bd@mail.gmail.com>

How do I debug a sound volume problem?  With F-9 I had no audio
issues, but with F-10, I have to turn my speakers all the way up and
the desktop volume control all the way up to hear anything.  It's
still too quiet even so.  I've got one of those motherboards with
everything but the kitchen sink built in, including the audio.  The
manual doesn't say what it is, but /proc/asound/card0/codec#0 claims
it is a Realtek ALC888.  Any ideas on how I should determine the
source of the problem?

Incidentally, I also checked with a pair of headphones to make sure it
isn't a problem with the speakers.  The headphones are also too quiet.
 I also had my wife check in case the problem is with my personal
audio equipment.  She also agrees that the sound is too quiet. :-)

Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From rakesh.pandit at gmail.com  Fri Dec 12 04:08:29 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Fri, 12 Dec 2008 09:38:29 +0530
Subject: Package Review Stats for the week ending December 7, 2008
In-Reply-To: <200812111844.22764.opensource@till.name>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<200812111844.22764.opensource@till.name>
Message-ID: <b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>

2008/12/11 Till Maas <opensource at till.name>:
> On Mon December 8 2008, Brian Pepple wrote:
>> Top four FAS account holders who have completed reviewing "Package
>> review" components on bugzilla for the week ending December 7th, 2008
>> were Parag AN(????), Jason Tibbitts, Michael Schwendt, and Patrice
>> Dumas.  Below is the number of completed package reviews done.
>
> If it is not too much work, can you maybe mention how many merge reviews were
> done?
>

Right now the report generated is for component: "Package Review" and
merge reviews also come under that component.
-- 
rakesh



From rc040203 at freenet.de  Fri Dec 12 04:20:59 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 12 Dec 2008 05:20:59 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <1229017310.3381.48.camel@wicktop.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
Message-ID: <1229055659.3081.194.camel@beck.corsepiu.local>

On Thu, 2008-12-11 at 18:41 +0100, Christoph Wickert wrote:
> Am Donnerstag, den 11.12.2008, 17:52 +0100 schrieb Ralf Corsepius:
> > On Thu, 2008-12-11 at 17:08 +0100, Sven Lankes wrote:
> > > On Wed, Dec 10, 2008 at 11:58:51AM +0100, Matej Cepl wrote:
> > > 
> > > >> We should try to get the bohdi-karma-mechanism more popular. 
> > >  
> > > > IMNSHO we should get rid of it -- there is already one very good 
> > > > mechanism for registering bugs in the software and it is 
> > > > bugzilla.
> > > 
> > > Which can cater for negative feedback. I don't think most people would
> > > be too happy with bz-entries created just containing 'works for me'.
> > But this is exactly what is happening.
> > 
> > Cf. https://bugzilla.redhat.com/show_bug.cgi?id=475943
> > for a real world case.
> 
> Huh? This does not look like positive feedback to me but like a normal
> bug report.

Note the "works for me"s: It's the normal way users who report bugs
through bugzilla provide feedback on proposed fixes.


Note how the package maintainer pointed reporters to "fix-candidate"
packages: He directed users to packages in koji and not to packages in
*-testing.


Both observations are symptomatic for situations in which "non-trivial"
package bugs are being addressed. Neither *testing nor the karma stuff
are being applied. 

BTW: IMO this raises the next questions: Why don't successful koji
builds not automatically land in testing?

Ralf





From lesmikesell at gmail.com  Fri Dec 12 04:32:04 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 22:32:04 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812111700k3063ca6r6b860eb38c7c6529@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<49416103.6050900@gmail.com>	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>	<49416C55.6010900@gmail.com>	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>	<494178C1.3040002@gmail.com>	<604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>	<49418222.307@gmail.com>	<604aa7910812111326oddf020eh6c17b26ad531b313@mail.gmail.com>	<4941B0FE.5070104@gmail.com>
	<604aa7910812111700k3063ca6r6b860eb38c7c6529@mail.gmail.com>
Message-ID: <4941E944.8030906@gmail.com>

Jeff Spaleta wrote:
> 
>>> If I tell you that "it works" is that enough for you?
>> If you have identical hardware, an identical set of other packages, and a
>> similar workload, yes.
> 
> How do you know if I do or do not?  Are you saying that the only
> information that would help you make a determination as to 'known
> broken' or 'is working' as YOU define those concepts is if you have
> feedback from people who are doing what you are doing with the
> hardware you are using? How much detail do you need about other
> people's machines and workloads? How in the hell do you expect to
> capture that level of detail from other people?

Those are all good questions.  I don't think fedora has a way to answer 
any of them.

> You keep missing the point. I'm going to have to ratchet up the
> bluntness factor for you.

I'm trying to make a point so I can hardly miss it.  The point is that I 
need to minimize risk on certain machines and I'm not going to run 
fedora on them until I see a way to do that.  I don't think this is a 
unique need or that it is impossible for fedora to meet.

> You are trying to rely on other people's experiences with updates to
> justify whether you should be installing the update on your systems.

Yes, there is safety in numbers - there will always be problems that 
aren't exposed until a large number of machines run something.  But as 
always, I'm talking about other machines, not necessarily other people. 
I'd provide my own experience on a test machine to others, given some 
mechanism to do that usefully.

> You haven't described how you would expect to capture that distributed
> information from other people in such a way that you can make use of
> it before you need to make the decision as to whether or not to
> install that update on your very very precious machines.

We are talking about an expectation of risk here.  The ideal scenario is 
to know that the exact package set has been installed on the exact 
hardware and is currently running the same load.  That's the sort of 
testing you'd do if you had real QA.  Lacking that, knowing that a 
sufficiently large number of other machines have installed the packages 
in question without reporting problems is a good indication.

> You are talking in generalities and what this discussion needs at this
> point is implementation specifics.

It all has to start with being able to reproduce package sets.  What 
good does it do to track stability/usability of a configuration you or 
anyone else can't duplicate, or that after the testing period, aren't 
even available?

>> It's not a matter of trust for at least couple of reasons.  One is that your
>> hardware and installed package set is probably nothing like mine.
> 
> How do you know? How do you know that anyone out there is doing
> something close enough to what you are doing to be comparable?  If you
> are looking to compare systems and workloads you have to trust people
> they are reporting the right information.

As long as there are large number of users and any easy reporting 
mechanism, the simple lack of problem reports would satisfy my 
expectation of little risk.  But by the time this is evident, the 
configurations they were running successfully can't be created again.

>> Again, it isn't personal - it has to do with the need to keep certain
>> machines running.
> 
> Stop with the generalities. Talk about YOUR needs and YOUR workloads.

That varies wildly per machine.  The largest set would be java based web 
servers, then an assortment of squid proxies, the usual infrastructure 
services like DNS, dhcp, snmp monitoring, file, web (e.g. twiki running 
under mod_perl), email, subversion, backuppc, etc., with a few things 
running under VMware and and assortment of freenx sessions strategically 
positioned to be able to manage all the locations.

>> And what needs to happen is to know that somewhere,
>> someone has installed the same package set on the same kind of hardware and
>> has it still working.
> 
> How do you expect that information to be collected? How do you expect
> that information to be served up?

I'd opt in if there were a mechanism to publish my package set, hardware 
list, and uptime to some collecting mechanism.

>>> I've used it.
>> That hardly sounds like a recommendation.
> 
> I official recommend that you do whatever it is I've already
> suggested.  Does that help?
> Does that make the idea sound better to you? Need that in writing?

No, since I think my needs aren't unique, what I am looking for is 
advice published for fedora users in general - like something on the 
fedora project page that says that regressions in updates are rare but 
still expected, and here is the procedure to recover from them.

>> That sounds like at least an admission that the stock tools and mechanisms
>> aren't good enough.
> 
> Good enough for what? I do not expect the provided tools to meet all
> of my needs all the time. As an adminstrator I am accountable for the
> integrity of my systems...

OK, but doesn't that imply that you should be able to control your 
installed package set - or share or match it up with someone else?

> not Fedora...

And you don't think it would be helpful if fedora provided a way to 
install a package set exactly as known to work elsewhere?

 > not the mirrors which are
> serving fedora packages..and not my ISP who is providing me the
> network access to reach those mirrors.  I expect there to be a need
> for local administration policy that I control...which mitigates the
> dependence on any external entity which puts the integrity of my
> systems at risk.  For updates, that means doing several things, one of
> which is caching backups locally in case I need to back out
> something..even in situations where my ISP has a problem and my
> network access goes down.

OK, if fedora users are expected to do all that, shouldn't there be 
better tools set up for it as part of the distro and step by step 
procedures published so people know what to expect?

-- 
    Les Mikesell
     lesmikesell at gmail.com



From mike at cchtml.com  Fri Dec 12 04:46:54 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 11 Dec 2008 22:46:54 -0600
Subject: Debugging sound volume problem
In-Reply-To: <870180fe0812111959v6fe9c549p294a93a7a2f6a0bd@mail.gmail.com>
References: <870180fe0812111959v6fe9c549p294a93a7a2f6a0bd@mail.gmail.com>
Message-ID: <4941ECBE.4010803@cchtml.com>

Jerry James wrote:
> Any ideas on how I should determine the
> source of the problem?
>   

Gnome volume manager reports PCM and Master audio levels at 100%? Still 
quiet?

Open alsamixer? 100%? alsamixer -c 0? 100%?



From lesmikesell at gmail.com  Fri Dec 12 04:47:55 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Dec 2008 22:47:55 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghskeq$k8d$5@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<493F0BA8.1050300@gmail.com>	<1228930226.30987.107.camel@code.and.org>	<49416103.6050900@gmail.com>	<604aa7910812111108i5a6822b8u649cf302bd633e6b@mail.gmail.com>	<49416C55.6010900@gmail.com>	<604aa7910812111156g34558261o835ea9e6b6d35352@mail.gmail.com>	<494178C1.3040002@gmail.com>	<604aa7910812111243v61370032idbdc241afccc78a9@mail.gmail.com>	<49418222.307@gmail.com>	<604aa7910812111326oddf020eh6c17b26ad531b313@mail.gmail.com>	<4941B0FE.5070104@gmail.com>
	<ghskeq$k8d$5@ger.gmane.org>
Message-ID: <4941ECFB.7090900@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> For my example of the late FC6 update, the machine didn't boot.  I'd say
>>   that's clearly a 'known broken' state at that point.  But not much
>> more than that is clear.  Why does that have to happen to more than one
>> machine?
> 
> Because if we block/unpush/whatever updates based on a single report of
> brokenness, all Joe Evil Cracker needs to do to break into your machine is
> to wait for a security issue in OpenSSH or some other security-critical
> software, report the security update as "broken" and then exploit the hole.
> There would also be other kinds of vandals or jokesters who'd incorrectly
> report updates as "broken" just for fun.

What does it take then, if you don't believe reports? It wasn't 
something you had to guess about.  Any machine with certain types of 
scsi controllers would have exhibited the problem.  Could you establish 
  a list of trusted reporters with an assortment of hardware where you 
could bounce requests to reproduce problems to make them believable?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Fri Dec 12 04:59:31 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 20:59:31 -0800
Subject: Installing from Live CD is the new black?
In-Reply-To: <ghsl5g$k8d$8@ger.gmane.org>
References: <1228955078.3037.10.camel@fecusia> <4940B89E.8050400@nicubunu.ro>
	<1229015757.3863.89.camel@localhost.localdomain>
	<ghsl5g$k8d$8@ger.gmane.org>
Message-ID: <1229057971.3863.117.camel@localhost.localdomain>

On Fri, 2008-12-12 at 04:18 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> > The setup for harddrive or network iso has changed, such that you now
> > need an images/ directory with the install.img file within it at the
> > same level as the directory of your isos.  We no longer crack open the
> > isos in loader to find a image to use to bring up anaconda.
> 
> May I ask why?

That's for the anaconda team, but mostly I think it was moving all the
code that handled these sorts of things out of the loader (c) and into
stage2 (python) so that they can be handled better.  Anaconda devs would
have to clarify.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/1d320668/attachment.sig>

From jkeating at redhat.com  Fri Dec 12 05:02:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 21:02:01 -0800
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>
References: <20081205195914.GB3227@free.fr>
	<1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>
Message-ID: <1229058121.3863.119.camel@localhost.localdomain>

On Thu, 2008-12-11 at 17:19 -0900, Jeff Spaleta wrote:
> Or let me ask it this way. Right now in the entire repository is
> vim-minimal the only editor which is being explicitly required to
> filling this fallback role? If it is, enshrine that as policy before I
> get a chance to submit a package which falls back to nano. If its not
> the only editor being used as a fallback in the repository, then some
> compromise needs to be worked out so don't have people dragging in
> multiple editors to fill the fallback capacity.

calm down a bit here.  The only reason it would have a hard requires on
'vi' would be if the software itself, without any options for $EDITOR,
falls back to calling the hard path of /bin/vi.

If your software does the same, but is hard coded to fall back
to /usr/bin/nano, then that's fine, you'll have a requirement on nano.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/a37dc53c/attachment.sig>

From jkeating at redhat.com  Fri Dec 12 05:04:43 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 21:04:43 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsj5s$k8d$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<49414D5F.4010202@gmail.com> <1229021252.6236.15.camel@arekh.okg>
	<ghsj5s$k8d$1@ger.gmane.org>
Message-ID: <1229058283.3863.120.camel@localhost.localdomain>

On Fri, 2008-12-12 at 03:44 +0100, Kevin Kofler wrote:
> Update breakage induced by a font package? Come on... :-)

Such things have broken the installer.  Less of a concern for
non-rawhide, but still indication that font changes /can/ adversely
effect things.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/9bc3c4d9/attachment.sig>

From jkeating at redhat.com  Fri Dec 12 05:06:57 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 21:06:57 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsk2d$k8d$4@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<ghq732$5to$1@ger.gmane.org>
	<1229014969.3863.85.camel@localhost.localdomain>
	<ghsk2d$k8d$4@ger.gmane.org>
Message-ID: <1229058417.3863.122.camel@localhost.localdomain>

On Fri, 2008-12-12 at 03:59 +0100, Kevin Kofler wrote:
> Maintainers pushing updates of the "Remove dot at end of Summary" type (and
> I'm not even sure I'm exaggerating there, this may well have already
> happened at some point!) really don't "get" it...

it's these types of updates, and the gratuitous "latest upstream
everywhere" (I recently got a request for something in F8 that would
cause multiple other packages to have to be rebuilt.  F8 is weeks away
from end of life!!!) updates that I would like to see some re-training
over.  First step is having proper policy/guideline about what is
"common sense" when pushing updates.  Next step is identifying the
people breaking these and having some re-training with them and their
sponsor. 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/8693c492/attachment.sig>

From jkeating at redhat.com  Fri Dec 12 05:12:26 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Dec 2008 21:12:26 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsi7l$gpk$2@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<ghq7as$5to$3@ger.gmane.org>
	<1228974587.17709.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
Message-ID: <1229058746.3863.123.camel@localhost.localdomain>

On Fri, 2008-12-12 at 03:28 +0100, Kevin Kofler wrote:
> 
> But it is not enough. The updates are an important part of that. When
> Kubuntu released Intrepid, Fedora 9 already had the same version of KDE
> (4.1.2) despite having been released 6 months earlier. How was this
> possible? Thanks to the updates of course! It's similar for the kernel and
> other packages whose maintainers push new versions regularly.

You keep waiving about the KDE flag as if I was trying to take your
shiny ball away from you.  I'm not.  IMHO the KDE updates are being
managed in a responsible way.  It's the irresponsible updates that I
wish to address.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081211/135e4844/attachment.sig>

From jspaleta at gmail.com  Fri Dec 12 05:50:12 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 20:50:12 -0900
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <1229058121.3863.119.camel@localhost.localdomain>
References: <20081205195914.GB3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>
	<1229058121.3863.119.camel@localhost.localdomain>
Message-ID: <604aa7910812112150l563808c2tee83d6579d697889@mail.gmail.com>

2008/12/11 Jesse Keating <jkeating at redhat.com>:
> If your software does the same, but is hard coded to fall back
> to /usr/bin/nano, then that's fine, you'll have a requirement on nano.


My point is...if its arbitrary and the call out is really just for any
editor...why not just have all the same default fallbacks so all the
proggies can share the same fallback.

If the upstreams really really cared about vi being there
specifically, there'd be a build time check.

-jef



From jspaleta at gmail.com  Fri Dec 12 05:52:12 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Dec 2008 20:52:12 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812111908t515db343l683baedf0bf942dd@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
	<ghsikm$gpk$4@ger.gmane.org>
	<faa16b610812111908t515db343l683baedf0bf942dd@mail.gmail.com>
Message-ID: <604aa7910812112152sc0eff31s28482e39301a94d4@mail.gmail.com>

On Thu, Dec 11, 2008 at 6:08 PM, Colin Walters <walters at verbum.org> wrote:
> We don't need to change the world, just add an idiot filter
> in bodhi =)


Why are you singling me out to be filtered in bodhi?

-jef



From jamundso at gmail.com  Fri Dec 12 06:00:27 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 12 Dec 2008 00:00:27 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812112152sc0eff31s28482e39301a94d4@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
	<ghsikm$gpk$4@ger.gmane.org>
	<faa16b610812111908t515db343l683baedf0bf942dd@mail.gmail.com>
	<604aa7910812112152sc0eff31s28482e39301a94d4@mail.gmail.com>
Message-ID: <6d06ce20812112200k145ff283m1dbd14fc37bee156@mail.gmail.com>

On Thu, Dec 11, 2008 at 11:52 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Thu, Dec 11, 2008 at 6:08 PM, Colin Walters <walters at verbum.org> wrote:
>> We don't need to change the world, just add an idiot filter
>> in bodhi =)
>
> Why are you singling me out to be filtered in bodhi?
>
> -jef

Maybe because you're always misspelling your own name!
Sorry, couldn't resist. :-)

jerry



From fedora at leemhuis.info  Fri Dec 12 06:06:59 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 12 Dec 2008 07:06:59 +0100
Subject: Making updates-testing more useful
In-Reply-To: <1229020080.26965.0.camel@hughsie-work.lan>
References: <1228930549.3648.14.camel@localhost.localdomain>	<1228933404.2682.7.camel@scrappy.miketc.net>	<1229017332.15913.3.camel@hughsie-work.lan>	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
Message-ID: <4941FF83.7090404@leemhuis.info>

On 11.12.2008 19:28, Richard Hughes wrote:
>
> Yes, we can easily enable the testing repos with a small button and a
> more info link. The real question is, will this clutter the UI and
> confuse new users?

Another good question (related to the "will this confuse new users" 
part): Will you enable the updates-testing repos from 3rd party repos in 
the same step automatically? Otherwise people that use those repos will 
now and then run into dependency troubles -- for example when a new 
xine-lib enters updates-testing from Fedora and xine-lib-extras-nonfree 
enters updates-testing from RPM Fusion at the same time.

But well, likely it doesn't matter to much anyway, as yum is still 
pretty broken in such situations anyway, as mirror lags will confuse it:
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html

CU
knurd



From opensource at till.name  Fri Dec 12 07:14:03 2008
From: opensource at till.name (Till Maas)
Date: Fri, 12 Dec 2008 08:14:03 +0100
Subject: Package Review Stats for the week ending December 7, 2008
In-Reply-To: <b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<200812111844.22764.opensource@till.name>
	<b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>
Message-ID: <200812120814.13832.opensource@till.name>

On Fri December 12 2008, Rakesh Pandit wrote:
> 2008/12/11 Till Maas <opensource at till.name>:
> > On Mon December 8 2008, Brian Pepple wrote:
> >> Top four FAS account holders who have completed reviewing "Package
> >> review" components on bugzilla for the week ending December 7th, 2008
> >> were Parag AN(????), Jason Tibbitts, Michael Schwendt, and Patrice
> >> Dumas.  Below is the number of completed package reviews done.
> >
> > If it is not too much work, can you maybe mention how many merge reviews
> > were done?
>
> Right now the report generated is for component: "Package Review" and
> merge reviews also come under that component.

It seems it was not clear, what I meant. I would like to now, how many of the 
reviews that are done affect Merge Reviews, e.g. add the end of the report 
instead of only  this line:

| Total reviews: 40

It would be nice to have this:

Total Package Reviews: 39
Total Merge Reviews: 1

I would also appreciate a pointer to the script that generates these reports.

Regards,
Till


-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/b8202bb0/attachment.sig>

From rakesh.pandit at gmail.com  Fri Dec 12 07:53:47 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Fri, 12 Dec 2008 13:23:47 +0530
Subject: Package Review Stats for the week ending December 7, 2008
In-Reply-To: <200812120814.13832.opensource@till.name>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<200812111844.22764.opensource@till.name>
	<b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>
	<200812120814.13832.opensource@till.name>
Message-ID: <b401d2530812112353h3906b40ap56d591ef0a28e547@mail.gmail.com>

2008/12/12 Till Maas <opensource at till.name>:
[..]
>> Right now the report generated is for component: "Package Review" and
>> merge reviews also come under that component.
>
> It seems it was not clear, what I meant. I would like to now, how many of the
> reviews that are done affect Merge Reviews, e.g. add the end of the report
> instead of only  this line:
>
> | Total reviews: 40
>
> It would be nice to have this:
>
> Total Package Reviews: 39
> Total Merge Reviews: 1
>
> I would also appreciate a pointer to the script that generates these reports.
>

I will try to adjust the script to categorize the merge reviews part
of "Package Review" component as separate, probably based on summary
or other attribute of bug. The script is here:
http://cvs.fedora.redhat.com/viewvc//status-report-scripts/?root=fedora

The one named bugzillaReport.py

Feel free to patch it up;)

-- 
rakesh



From nicu_fedora at nicubunu.ro  Fri Dec 12 08:15:24 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 12 Dec 2008 10:15:24 +0200
Subject: Installing from Live CD is the new black?
In-Reply-To: <20081211181856.GB27793@localhost.localdomain>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
Message-ID: <49421D9C.8080307@nicubunu.ro>

Chris Lumens wrote:
>> Is it just me or doesn't everybody make their installs off the Live CD
>> these days?
> 
> I do kind of wish everyone used live CDs, but that's probably never
> going to be the way it works.

That's just not gonna happen. Live CD are so small, they can't hold even 
OpenOffice.org (or hold it but sacrifice a lot of other much needed 
applications).

-- 
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 pemboa at gmail.com  Fri Dec 12 08:28:27 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 02:28:27 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <1228955078.3037.10.camel@fecusia>
References: <1228955078.3037.10.camel@fecusia>
Message-ID: <16de708d0812120028q36e55dfev90ff0bae09e091ec@mail.gmail.com>

On Wed, Dec 10, 2008 at 6:24 PM, Linus Walleij <triad at df.lth.se> wrote:
> Is it just me or doesn't everybody make their installs off the Live CD
> these days?

LiveCD installs are almost too easy.

the livecd iso to usb util which works on both Windows and Linux is
just so sweet that I could barely contain myself when I first tried
it. All I wanted from it was an option to format all the unused space
as ntfs/fat32/ext3 and/or a bigger overlay (bigger that ~2000MB)

The DVDs are a waste of space and bandwidth if you're going to
download it anyway. If you're going to mail or share it, that's
another thing. Otherwise, you save bandwidth in just dloading the Live
and installing the latest packages. Otherwise you dload the dvd, and
then still have to redownload most of the (big) packages due to
updates.

I also look forward to LiveDVD spins, sucks not to have vim, screen
and svn on the live image. But having KRDC on the image was brilliant
however.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pemboa at gmail.com  Fri Dec 12 08:30:10 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 02:30:10 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <49421D9C.8080307@nicubunu.ro>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro>
Message-ID: <16de708d0812120030n9fdfc7cj6c95b2a7c9a59a2b@mail.gmail.com>

On Fri, Dec 12, 2008 at 2:15 AM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> Chris Lumens wrote:
>>>
>>> Is it just me or doesn't everybody make their installs off the Live CD
>>> these days?
>>
>> I do kind of wish everyone used live CDs, but that's probably never
>> going to be the way it works.
>
> That's just not gonna happen. Live CD are so small, they can't hold even
> OpenOffice.org (or hold it but sacrifice a lot of other much needed
> applications).

time for live dvds then. The sweetness that is livecds cannot be over
exaggerated. How people use other OSes heavily without them is beyond
me.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From bmaly at redhat.com  Fri Dec 12 08:43:56 2008
From: bmaly at redhat.com (Brian Maly)
Date: Fri, 12 Dec 2008 03:43:56 -0500
Subject: Debugging sound volume problem
In-Reply-To: <870180fe0812111959v6fe9c549p294a93a7a2f6a0bd@mail.gmail.com>
References: <870180fe0812111959v6fe9c549p294a93a7a2f6a0bd@mail.gmail.com>
Message-ID: <4942244C.3060902@redhat.com>

Jerry James wrote:
> How do I debug a sound volume problem?  With F-9 I had no audio
> issues, but with F-10, I have to turn my speakers all the way up and
> the desktop volume control all the way up to hear anything.  It's
> still too quiet even so.  I've got one of those motherboards with
> everything but the kitchen sink built in, including the audio.  The
> manual doesn't say what it is, but /proc/asound/card0/codec#0 claims
> it is a Realtek ALC888.  Any ideas on how I should determine the
> source of the problem?
>
> Incidentally, I also checked with a pair of headphones to make sure it
> isn't a problem with the speakers.  The headphones are also too quiet.
>  I also had my wife check in case the problem is with my personal
> audio equipment.  She also agrees that the sound is too quiet. :-)
>
> Thanks,
>   
This script is handy for debugging. Its a good place to start anyway. 
You might run this with both the F9 kernel and an F10 kernel and see if 
there are any obvious differences in the output.

Brian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: alsa-info.sh
Type: application/x-shellscript
Size: 18806 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/6c22a878/attachment.bin>

From pingou at pingoured.fr  Fri Dec 12 08:53:23 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Fri, 12 Dec 2008 09:53:23 +0100
Subject: Package Review Stats for the week ending December 7, 2008
In-Reply-To: <200812120814.13832.opensource@till.name>
References: <1228770379.5346.3.camel@localhost.localdomain>	<200812111844.22764.opensource@till.name>	<b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>
	<200812120814.13832.opensource@till.name>
Message-ID: <49422683.2030107@pingoured.fr>

Till Maas wrote:
> On Fri December 12 2008, Rakesh Pandit wrote:
>> 2008/12/11 Till Maas <opensource at till.name>:
>>> On Mon December 8 2008, Brian Pepple wrote:
>>>> Top four FAS account holders who have completed reviewing "Package
>>>> review" components on bugzilla for the week ending December 7th, 2008
>>>> were Parag AN(????), Jason Tibbitts, Michael Schwendt, and Patrice
>>>> Dumas.  Below is the number of completed package reviews done.
>>> If it is not too much work, can you maybe mention how many merge reviews
>>> were done?
>> Right now the report generated is for component: "Package Review" and
>> merge reviews also come under that component.

It would also be nice (IMHO) to have the amount of new review request
> 
> It would be nice to have this:
> 
> Total Package Reviews: 39
> Total Merge Reviews: 1
Total of New Reviews request: 45 ?

Thanks for the work done :)

Best regards,

Pierre



From nicolas.mailhot at laposte.net  Fri Dec 12 09:17:22 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Dec 2008 10:17:22 +0100 (CET)
Subject: Packaging dtds
In-Reply-To: <4941C0BC.2060706@gmail.com>
References: <200812120035.18974.opensource@till.name>
	<4941C0BC.2060706@gmail.com>
Message-ID: <7778f877daa100bb2505e4a4706f7201.squirrel@arekh.dyndns.org>



Le Ven 12 d?cembre 2008 02:39, Toshio Kuratomi a ?crit :

> I think some of the differences we see below are due to PUBLIC instead
> of SYSTEM.  Some other differences are due to upstream's use of a
> subcatalog.

IIRC a catalog indexes PUBLIC objects, so you need to add a PUBLIC id
to your DTD to catalog it.

SYSTEM is "direct reference to local system path"

-- 
Nicolas Mailhot



From opensource at till.name  Fri Dec 12 09:23:22 2008
From: opensource at till.name (Till Maas)
Date: Fri, 12 Dec 2008 10:23:22 +0100
Subject: Packaging dtds
In-Reply-To: <7778f877daa100bb2505e4a4706f7201.squirrel@arekh.dyndns.org>
References: <200812120035.18974.opensource@till.name>
	<4941C0BC.2060706@gmail.com>
	<7778f877daa100bb2505e4a4706f7201.squirrel@arekh.dyndns.org>
Message-ID: <200812121023.33715.opensource@till.name>

On Fri December 12 2008, Nicolas Mailhot wrote:

> IIRC a catalog indexes PUBLIC objects, so you need to add a PUBLIC id
> to your DTD to catalog it.

/etc/xml/catalog also works for SYSTEM objects.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/767af540/attachment.sig>

From nicolas.mailhot at laposte.net  Fri Dec 12 09:29:10 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Dec 2008 10:29:10 +0100 (CET)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsj5s$k8d$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<49414D5F.4010202@gmail.com> <1229021252.6236.15.camel@arekh.okg>
	<ghsj5s$k8d$1@ger.gmane.org>
Message-ID: <a43f5f7d4dc760d8bbe4185d54f7a12b.squirrel@arekh.dyndns.org>



Le Ven 12 d?cembre 2008 03:44, Kevin Kofler a ?crit :

> dejavu-fonts?

Yes

>> And you know what? I don't push updates to stable releases. I
>> haven't
>> for a long time. Users can wait a little. The world does not end.
>
> IMHO this is a bad decision. I remember the times you pushed out all
> the updates and they never caused any problems.

IMHO this is better this way. People have an incentive to report
problems instead of waiting for next month's dump, I don't clog pipes
anymore, and everyone is happy.

In fact, IIRC the lxn editors complained in the past the monthly
pushes continued in rawhide (I won't change this, that's what rawhide
is for).

> Update breakage induced by a font package? Come on... :-)

There are very good reasons why DejaVu was introduced as LGC and not
full in Fedora, I don't agree 100% with them, but the breakage risk
does exist and since it affects the whole UI of most of our users,
it's not worth the risk IMHO.

-- 
Nicolas Mailhot



From pertusus at free.fr  Fri Dec 12 09:34:09 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 12 Dec 2008 10:34:09 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>
References: <1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>
Message-ID: <20081212093409.GA2627@free.fr>

On Thu, Dec 11, 2008 at 05:19:44PM -0900, Jeff Spaleta wrote:
> 
> Is this a requirement on vim-minimal or just a requirement for a posix
> compliant editor to be available?

On /bin/vi. More precisely fcron has a build time check, with a 
configure flag --with-editor, that defaults to 
AC_PATH_PROG(FOUND_FCRON_EDITOR, vi. And cronie uses _PATH_VI from
paths.h. I don't think there is a posix compliance needed as all.

The posix compliance argument, is here to justify vim-minimal as 'not 
a bad choice for a default editor'. But once again if you have an idea
for a better default editor choice, just do the infrastructure, then
provide patches for packages that need a default editor and be done.

> Or let me ask it this way. Right now in the entire repository is
> vim-minimal the only editor which is being explicitly required to
> filling this fallback role? If it is, enshrine that as policy before I

Why do we need a policy here?

> get a chance to submit a package which falls back to nano. If its not
> the only editor being used as a fallback in the repository, then some
> compromise needs to be worked out so don't have people dragging in
> multiple editors to fill the fallback capacity.

I am not sure a compromise is needed. Just let the packagers do what
they prefer, in the constraints of upstream choices. If somebody is 
interested in modularizing better the default editor handling, for example 
with something built around xdg-open, or around xdg-edit no problem, I
think that all the packagers will gladly accept the change.

When pointed to it, all the packagers of packages I reviewed accepted to
use htmlview, and everybody accepted to switch to xdg-open when Ville
filled bugs with patches.

There was a thread about how to choose a default editor on the packaging 
list some time ago, I don't remember exactly what was the conclusion, 
but I pointed out that using xdg-open was dangerous, because it is not 
clear what xdg-open applie to a text file means, because it may mean 
editing it, viewing it, and maybe other action.

Of course finding out packages that need a default editor will require
some research, but I think that a mail on devel list should be enough.

There is another package which needs a default editor, grace, and we
used nedit for the lack of anything better, given that grace (and nedit) 
use Motif.

--
Pat



From nicolas.mailhot at laposte.net  Fri Dec 12 09:36:37 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Dec 2008 10:36:37 +0100 (CET)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <a43f5f7d4dc760d8bbe4185d54f7a12b.squirrel@arekh.dyndns.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org> <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org> <493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<49400A28.9080508@gmail.com>
	<1228938482.3863.45.camel@localhost.localdomain>
	<49414D5F.4010202@gmail.com> <1229021252.6236.15.camel@arekh.okg>
	<ghsj5s$k8d$1@ger.gmane.org>
	<a43f5f7d4dc760d8bbe4185d54f7a12b.squirrel@arekh.dyndns.org>
Message-ID: <64c5468664e992fb541e720e2fb4fd2d.squirrel@arekh.dyndns.org>



Le Ven 12 d?cembre 2008 10:29, Nicolas Mailhot a ?crit :
>
> In fact, IIRC the lxn editors complained in the past the monthly

lwn.net

> pushes continued in rawhide (I won't change this, that's what rawhide
> is for).

-- 
Nicolas Mailhot



From mcepl at redhat.com  Fri Dec 12 09:36:48 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 12 Dec 2008 10:36:48 +0100
Subject: Server SIG - work areas
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<m3abb24qvo.fsf@ursa.amorsen.dk>
	<9497e9990812111002g1702037q6839bb384aed9e9@mail.gmail.com>
	<200812112212.34232.opensource@till.name>
Message-ID: <gun916x4dc.ln2@ppp1053.in.ipex.cz>

On 2008-12-11, 21:12 GMT, Till Maas wrote:
> Unless the bikeshed is blue. ;-)

Blue??? OF COURSE, IT IS NONSENSE -- THERE ARE RATIONAL 
UNBREAKABLE REASONS WHY THE BIKESHED MUST BE GREEN.

Mat?j



From hughsient at gmail.com  Fri Dec 12 09:50:22 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 12 Dec 2008 09:50:22 +0000
Subject: Making updates-testing more useful
In-Reply-To: <604aa7910812111051r1c2bce57q4aab9f7e5f16fb4e@mail.gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<604aa7910812111051r1c2bce57q4aab9f7e5f16fb4e@mail.gmail.com>
Message-ID: <1229075422.3450.3.camel@hughsie-work.lan>

On Thu, 2008-12-11 at 09:51 -0900, Jeff Spaleta wrote:
> I am still interesting in the nag notifications if I can get them once
> updates-testing is enabled. As an updates-testing user...being nagged
> as to what testing things I have installed which deserve some
> feedback..would really help me remember to provide feedback.

This part is much harder. We do log what package comes from what repo,
but we don't know how many times the user actually used it. There's no
point asking the user "You've not given feedback on kdebase in 10 says"
if you've been using gnome for 10 days exclusively, and kdebase is only
installed because k3b is used every now and then.

I do think we need to log what programs have been run, and for how long
for lots of other reasons as well, but that seems to make people very
worried, very quickly.

Richard.




From ralph+fedora at strg-alt-entf.org  Fri Dec 12 09:52:11 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Fri, 12 Dec 2008 10:52:11 +0100
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
	<1229007272.3537.23.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
Message-ID: <20081212095211.GM1499@br-online.de>

Seth Vidal wrote:
> Spam Harvester?
>
> it'd be a good way to pickup email addresses.

Seeing that valueclick.com really isn't a "low profile setup" I don't
think that this is the case. 

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/dcdbe80c/attachment.sig>

From hughsient at gmail.com  Fri Dec 12 09:55:01 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 12 Dec 2008 09:55:01 +0000
Subject: Making updates-testing more useful
In-Reply-To: <4941FF83.7090404@leemhuis.info>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
Message-ID: <1229075701.3450.8.camel@hughsie-work.lan>

On Fri, 2008-12-12 at 07:06 +0100, Thorsten Leemhuis wrote:
> On 11.12.2008 19:28, Richard Hughes wrote:
> >
> > Yes, we can easily enable the testing repos with a small button and a
> > more info link. The real question is, will this clutter the UI and
> > confuse new users?
> 
> Another good question (related to the "will this confuse new users" 
> part): Will you enable the updates-testing repos from 3rd party repos in 
> the same step automatically?

Yes. If the user has fedora and rpmfusion enabled, but livna disabled,
it'll do in the first pass:

updates from all configured and enabled sources

and on the second pass:

disable fedora and rpmfusion
enable fedora-testing and rpmfusion-testing
updates from all configured and enabled sources
enable fedora and rpmfusion
disable fedora-testing and rpmfusion-testing

If you've got livna installed then it shouldn't touch the repo. The
tricky bit is the heuristic that matches up rpmfusion-testing to
rpmfusion.

> Otherwise people that use those repos will 
> now and then run into dependency troubles -- for example when a new 
> xine-lib enters updates-testing from Fedora and xine-lib-extras-nonfree 
> enters updates-testing from RPM Fusion at the same time.

We should handle that.

> But well, likely it doesn't matter to much anyway, as yum is still 
> pretty broken in such situations anyway, as mirror lags will confuse it:
> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html

We can't do much about mirror lags, but we do switch on --skip-broken by
default which sort of mitigates things.

Richard.




From rjones at redhat.com  Fri Dec 12 10:03:41 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 12 Dec 2008 10:03:41 +0000
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <ghrosn$462$1@ger.gmane.org>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
	<a9d183c80812100225l3e66a53dpdbbe02193703923d@mail.gmail.com>
	<20081210143309.GB18314@nostromo.devel.redhat.com>
	<20081210213546.GD12080@auslistsprd01.us.dell.com>
	<1229007272.3537.23.camel@localhost.localdomain>
	<alpine.LFD.2.00.0812111001260.14070@localhost.localdomain>
	<ghrosn$462$1@ger.gmane.org>
Message-ID: <20081212100341.GA23420@amd.home.annexia.org>

On Thu, Dec 11, 2008 at 01:15:35PM -0600, Matthew Woehlke wrote:
> Seth Vidal wrote:
>> On Thu, 11 Dec 2008, Tom \"spot\" Callaway wrote:
>>> He seems to be tracking most/all of mine as well.
>>
>> Spam Harvester?
>
> Given the domain name, that was my first thought as well. I'm glad  
> someone else mentioned it.

ValueClick are a huge US online advertising company.  Although I'm no
big fan of their stuff (like their several affiliate marketing
subsidiaries including Commission Junction) I somehow doubt they'd
bother to spam harvest Fedora email addresses.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From mschwendt at gmail.com  Fri Dec 12 10:42:03 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 12 Dec 2008 11:42:03 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsikm$gpk$4@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102153l2ac6cd30ma639ddc7f743f10@mail.gmail.com>
	<1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
	<ghsikm$gpk$4@ger.gmane.org>
Message-ID: <20081212114203.b912da4c.mschwendt@gmail.com>

On Fri, 12 Dec 2008 03:35:02 +0100, Kevin wrote:

> > On Thu, 11 Dec 2008 12:32:12 -0600, Arthur wrote:
> > 
> >> 6 months is a pretty long time to wait for a major release. I
> >> understand the rationale, but if this is going to be the new Fedora,
> >> best announce this and let  everyone know so that they can reevaluate
> >> if Fedora is for them. As things are, I feel that we are being _too_
> >> conservative. Any further move to more conservatism seriously affects
> >> Fedora's usefulness to me.
> > 
> > Why?
> 
> Because, like me, he chose Fedora *because* of the stream of updates, we
> *want* those updates, including version upgrades. 

Judging on the community uproar everytime a grave bug in updates is
discovered, I don't see that Fedora's users want so many poorly tested
updates and upgrades that throw away the work of the previous development
(Rawhide) period. I hear and read that the six months release cycle
is fast-moving enough for them and that every new release suffers from
enough bugs which requires updates to bring it into usable shape.

What I see is that although we have updates-testing repos and a karma
system in bodhi, nothing is done to build up a Fedora QA team that
controls the flow of updates into the stable repo. Why do we force our
precious users to become guinea pigs instead of only giving them the
chance to become early adaptors [by enabling updates-testing]? It's
especially the version upgrades that break the most things. Broken
dependencies are harmless compared with changes in a user-interface and
changes and in a feature-set.

"Idiot filters in bodhi"? - Not a bad idea to add a check-box where
package maintainers must acknowledge the guidelines:

https://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users

> We would be using Ubuntu
> or CentOS or any of the other bazillion conservative distros otherwise.
> A distro with a 6-month release cycle, but conservative updates, already
> exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
> go use Ubuntu.

CentOS is not only "conservative", as a copy of RHEL and completely
different release cycle it doesn't offer any release that is close to
Fedora 8/9/10. Colin has mentioned (essential) differences between Ubuntu
and Fedora. There are more. Ubuntu won't become equal to Fedora if it
increased its updates frequency.



From yaneti at declera.com  Fri Dec 12 10:57:23 2008
From: yaneti at declera.com (Yanko Kaneti)
Date: Fri, 12 Dec 2008 12:57:23 +0200
Subject: Who is "mriddle (a t) valueclick.com" ?
In-Reply-To: <20081210031750.GB21432@nostromo.devel.redhat.com>
References: <20081209223300.GA32716@thinkpad>
	<20081210031750.GB21432@nostromo.devel.redhat.com>
Message-ID: <1229079443.5073.4.camel@d2>

On Tue, 2008-12-09 at 22:17 -0500, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
> > I've wondered this for a while.  mriddle (apparently "Marc Riddle",
> > according to a quick Google search) gets emailed every time I update
> > many types of Bugzillas, particularly Review Requests.
> 
> https://bugzilla.redhat.com/userprefs.cgi?tab=email
> 
> See 'user watching'.
> 
> People can set up bugstalking filters to get e-mailed any time someone
> else would be e-mailed.
> 
> Bill

user watching is one way to get non-security bugzilla mail for a package
of interest without going through yet another line of red tape.

Waiting for approval for bugzilla watching, brilliant...



From mschwendt at gmail.com  Fri Dec 12 11:14:13 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 12 Dec 2008 12:14:13 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <1229055659.3081.194.camel@beck.corsepiu.local>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
Message-ID: <20081212121413.033685ca.mschwendt@gmail.com>

On Fri, 12 Dec 2008 05:20:59 +0100, Ralf wrote:

> BTW: IMO this raises the next questions: Why don't successful koji
> builds not automatically land in testing?

A build being successful does not imply that it is ready for release.
It could still do something wrong [in the .spec, at run-time, ...].
Automatic pushes to updates-testing would only lead to cases where
somebody forgets to withdraw a build and also forgets to enter release
notes.



From rc040203 at freenet.de  Fri Dec 12 11:20:07 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 12 Dec 2008 12:20:07 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <20081212121413.033685ca.mschwendt@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
	<20081212121413.033685ca.mschwendt@gmail.com>
Message-ID: <1229080807.3081.232.camel@beck.corsepiu.local>

On Fri, 2008-12-12 at 12:14 +0100, Michael Schwendt wrote:
> On Fri, 12 Dec 2008 05:20:59 +0100, Ralf wrote:
> 
> > BTW: IMO this raises the next questions: Why don't successful koji
> > builds not automatically land in testing?
> 
> A build being successful does not imply that it is ready for release.
> It could still do something wrong [in the .spec, at run-time, ...].

Right, but ...
> Automatic pushes to updates-testing would only lead to cases where
> somebody forgets to withdraw a build and also forgets to enter release
> notes.

Pushing packages to "stable" still requires approval by a human
(normally the maintainer).

=> Without this karma crap, this, so far mere bureaucratic step can be
avoided.

Ralf





From nils at redhat.com  Fri Dec 12 11:23:28 2008
From: nils at redhat.com (Nils Philippsen)
Date: Fri, 12 Dec 2008 12:23:28 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<20081209130409.283584eb@brian.englab.brq.redhat.com>
	<faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>
Message-ID: <1229081008.17998.5.camel@gibraltar.str.redhat.com>

On Tue, 2008-12-09 at 11:27 -0500, Colin Walters wrote:
> On Tue, Dec 9, 2008 at 7:04 AM, Michal Schmidt <mschmidt at redhat.com> wrote:
> > On Tue, 9 Dec 2008 01:25:40 +0100
> > Robert Scheck <robert at fedoraproject.org> wrote:
> >
> >> [PackageKit] kills my Firefox nicely during package updating,
> >> well-well done.
> >
> > Running instances of Firefox always break when the Firefox package is
> > being updated. It does not matter what you use for the update (rpm,
> > yum, PK). This is not PackageKit's fault.
> 
> In general, any software can break when a running copy has its files
> swapped out from under it.  XULRunner-based apps exacerbate this flaw
> in the package system because they use versioned directories.
> 
> But it's not Firefox's fault either.  Think about icons, glade files,
> etc. that might be included in software.
> 
> It's something that really needs to be fixed in yum/rpm.  Windows has
> a notion of "update this file after reboot", which might be the way to
> go.

Somehow delaying file updates until after a reboot sounds yucky to me,
not only because merely quitting firefox and starting it again would
help in this instance. Perhaps we should find a way where yum/PK would
flag packages which are known to have these issues to the user in the
form of "updating these packages requires you to restart firefox/..."
akin to how we hint users to logout and back in (e.g. update of basic
GNOME packages) or reboot the machine (kernel).

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From mschwendt at gmail.com  Fri Dec 12 11:53:27 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 12 Dec 2008 12:53:27 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229058417.3863.122.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<493EB9DE.6000507@gmail.com>
	<604aa7910812091043y4905f3e8j90985b4abb6fb143@mail.gmail.com>
	<1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<ghq732$5to$1@ger.gmane.org>
	<1229014969.3863.85.camel@localhost.localdomain>
	<ghsk2d$k8d$4@ger.gmane.org>
	<1229058417.3863.122.camel@localhost.localdomain>
Message-ID: <20081212125327.733ebe9b.mschwendt@gmail.com>

On Thu, 11 Dec 2008 21:06:57 -0800, Jesse wrote:

> On Fri, 2008-12-12 at 03:59 +0100, Kevin Kofler wrote:
> > Maintainers pushing updates of the "Remove dot at end of Summary" type (and
> > I'm not even sure I'm exaggerating there, this may well have already
> > happened at some point!) really don't "get" it...

It has happened indeed. Can't give a specific example, but it has been
"spec fixes" with no different results in the built files (except maybe
%summary, %description). Such updates would be harmless though.
Superfluous, but harmless. I'm aware of multiple mass-updates which
only fixed unowned directories recently. ;)

> it's these types of updates, and the gratuitous "latest upstream
> everywhere"

It can't be generalized, however. Minor version upgrades can be harmless
or even beneficial. And the same applies to some major releases.

There is no movement that aims at disallowing packagers to release such
updates.

What should really stop is the mass-updates of fresh packages prepared in
devel, which are only copied to, built for, and released in older branches
without any testing. Major spec file changes (full rewrites even), which
rename/remove lots of sub-packages without adding proper Obsoletes, on top
of major version upgrades, which even invalidate any personal
notes/documentation a user may have built up, or which requires rebuilds
and/or upgrades of dependencies (sometimes even new build requirements)
to move forward.

> (I recently got a request for something in F8 that would
> cause multiple other packages to have to be rebuilt.  F8 is weeks away
> from end of life!!!) updates that I would like to see some re-training
> over.  First step is having proper policy/guideline about what is
> "common sense" when pushing updates.  Next step is identifying the
> people breaking these and having some re-training with them and their
> sponsor. 

That sounds worthwhile.



From mzerqung at 0pointer.de  Fri Dec 12 12:19:36 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Fri, 12 Dec 2008 13:19:36 +0100
Subject: Debugging sound volume problem
In-Reply-To: <870180fe0812111959v6fe9c549p294a93a7a2f6a0bd@mail.gmail.com>
References: <870180fe0812111959v6fe9c549p294a93a7a2f6a0bd@mail.gmail.com>
Message-ID: <20081212121936.GC22242@tango.0pointer.de>

On Thu, 11.12.08 20:59, Jerry James (loganjerry at gmail.com) wrote:

> How do I debug a sound volume problem?  With F-9 I had no audio
> issues, but with F-10, I have to turn my speakers all the way up and
> the desktop volume control all the way up to hear anything.  It's
> still too quiet even so.  I've got one of those motherboards with
> everything but the kitchen sink built in, including the audio.  The
> manual doesn't say what it is, but /proc/asound/card0/codec#0 claims
> it is a Realtek ALC888.  Any ideas on how I should determine the
> source of the problem?
> 
> Incidentally, I also checked with a pair of headphones to make sure it
> isn't a problem with the speakers.  The headphones are also too quiet.
>  I also had my wife check in case the problem is with my personal
> audio equipment.  She also agrees that the sound is too quiet. :-)

Unfortunately the ALSA mixers are not in all cases properly
initialized by default yet. For cases where this went wrong, you can
use "alsamixer -c0" to play around with the mixer at the lowest level.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From jwboyer at gmail.com  Fri Dec 12 12:29:53 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 12 Dec 2008 07:29:53 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229058746.3863.123.camel@localhost.localdomain>
References: <1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
Message-ID: <20081212122953.GB19974@zod.rchland.ibm.com>

On Thu, Dec 11, 2008 at 09:12:26PM -0800, Jesse Keating wrote:
>On Fri, 2008-12-12 at 03:28 +0100, Kevin Kofler wrote:
>> 
>> But it is not enough. The updates are an important part of that. When
>> Kubuntu released Intrepid, Fedora 9 already had the same version of KDE
>> (4.1.2) despite having been released 6 months earlier. How was this
>> possible? Thanks to the updates of course! It's similar for the kernel and
>> other packages whose maintainers push new versions regularly.
>
>You keep waiving about the KDE flag as if I was trying to take your
>shiny ball away from you.  I'm not.  IMHO the KDE updates are being
>managed in a responsible way.  It's the irresponsible updates that I
>wish to address.

Maybe an example of an update you consider irresponsible?

josh



From mschwendt at gmail.com  Fri Dec 12 12:38:53 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 12 Dec 2008 13:38:53 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <1229080807.3081.232.camel@beck.corsepiu.local>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
	<20081212121413.033685ca.mschwendt@gmail.com>
	<1229080807.3081.232.camel@beck.corsepiu.local>
Message-ID: <20081212133853.33a06a4f.mschwendt@gmail.com>

On Fri, 12 Dec 2008 12:20:07 +0100, Ralf wrote:

> > > BTW: IMO this raises the next questions: Why don't successful koji
> > > builds not automatically land in testing?
> > 
> > A build being successful does not imply that it is ready for release.
> > It could still do something wrong [in the .spec, at run-time, ...].
> 
> Right, but ...
> > Automatic pushes to updates-testing would only lead to cases where
> > somebody forgets to withdraw a build and also forgets to enter release
> > notes.
> 
> Pushing packages to "stable" still requires approval by a human
> (normally the maintainer).

The problem Fedora has is that updates-testing is not popular enough.
It is counter-productive to flood that repo with builds automatically,
without somebody raising a green flag and declaring a build as an update.

A compromise would be to make this optional via a pkg cvs make target with
bodhi-client (see "make update"), but without the need to fill in forms.
The update could still be edited inside bodhi web.

> => Without this karma crap, this, so far mere bureaucratic step can be
> avoided.

It's not "karma crap", but some +1 voters have shown more than once that
they haven't tested packages painstakingly.
The possibility to vote -1 and leave a comment is quite good actually,
because this feedback is tied directly to the actual update request. On
the contrary, as we know, bugzilla spam overwhelmes the package
maintainers.

Whenever someone says "Fedora is community-driven" I'd really like to see
that it means "update pkg foo passed the testing done by a group of
power-users" and not just "Fedora provides a system where a single package
maintainer is free to unleash a pkg and burden the community with breakage".
Not only do we need to give interested parts of the community the
opportunity to contribute testing, we need to request it actively. "You
want updates, then help with testing to make sure the stuff remains
usable." Let it stay in updates-testing for several weeks, if need be.
Six months pass so quickly, the next Fedora will be released soon
enough if the community shows no interest in updating the older dist
releases.



From christof at damian.net  Fri Dec 12 12:39:43 2008
From: christof at damian.net (Christof Damian)
Date: Fri, 12 Dec 2008 13:39:43 +0100
Subject: Installing from Live CD is the new black?
In-Reply-To: <200812112140.11914.opensource@till.name>
References: <1228955078.3037.10.camel@fecusia>
	<200812111828.00512.opensource@till.name>
	<20081211181630.GA27793@localhost.localdomain>
	<200812112140.11914.opensource@till.name>
Message-ID: <f7c6719a0812120439x34dea32avb3b94d0146300d73@mail.gmail.com>

2008/12/11 Till Maas <opensource at till.name>:
>
> The problems I had are probably not USB disk related, then. I as usually used
> the live-iso-to-disk script to get the bootloader from the DVD to my USB stick
> and then only needed to copy the iso on the USB stick. Then I could use the
> USB stick to either install from it or to distribute the iso image to others.
> Now I would need an even bigger USB stick if I want to have it bootable and
> containing the iso.

One of my wishes for a future Fedora is also an easy way to install
from USB stick. I prefer to use the normal install instead of the
livecd/stick and currently you have to burn a CD / DVD to make this
work.

Most of the PCs can boot from USB sticks now and you get the sticks as
gift everywhere now, they are the new AOL CD. Some of the new current
computers also don't come with CD/DVD drives any more - for example
netbooks.

USB sticks are also reusable and more environment friendly than disks.

Christof



From rc040203 at freenet.de  Fri Dec 12 13:10:38 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 12 Dec 2008 14:10:38 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <20081212133853.33a06a4f.mschwendt@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
	<20081212121413.033685ca.mschwendt@gmail.com>
	<1229080807.3081.232.camel@beck.corsepiu.local>
	<20081212133853.33a06a4f.mschwendt@gmail.com>
Message-ID: <1229087438.3081.270.camel@beck.corsepiu.local>

On Fri, 2008-12-12 at 13:38 +0100, Michael Schwendt wrote:
> On Fri, 12 Dec 2008 12:20:07 +0100, Ralf wrote:
> 
> > > > BTW: IMO this raises the next questions: Why don't successful koji
> > > > builds not automatically land in testing?
> > > 
> > > A build being successful does not imply that it is ready for release.
> > > It could still do something wrong [in the .spec, at run-time, ...].
> > 
> > Right, but ...
> > > Automatic pushes to updates-testing would only lead to cases where
> > > somebody forgets to withdraw a build and also forgets to enter release
> > > notes.
> > 
> > Pushing packages to "stable" still requires approval by a human
> > (normally the maintainer).
> 
> The problem Fedora has is that updates-testing is not popular enough.
> It is counter-productive to flood that repo with builds automatically,
Then make sure that only one version at of a package (with NEVR >
version in stable) is inside. Could likely be automated without much
effort.

> without somebody raising a green flag and declaring a build as an update.
> 
> A compromise would be to make this optional via a pkg cvs make target with
> bodhi-client (see "make update"), but without the need to fill in forms.
> The update could still be edited inside bodhi web.
> 
> > => Without this karma crap, this, so far mere bureaucratic step can be
> > avoided.
> 
> It's not "karma crap", but some +1 voters have shown more than once that
> they haven't tested packages painstakingly.
> The possibility to vote -1 and leave a comment is quite good actually,
> because this feedback is tied directly to the actual update request.

In almost all cases, updates

* address a specific problem, which typically is BZ'ed, with the
relevant tester audience listening to this BZ 
=> a vote in bodhi is redundant to feedback in bugzilla

or
* are "upstream updates" addressing unspecific issues ("Upstreams says
package fixes issue XYZ").
=> Nobody but the maintainer is waiting to test this update, hardly
anybody will have a test case.

or
* are package maintainers addressing so far unpublished issues
(maintainer often extensive use a package and are likely more familiar
with a package than many other users).
=> Nobody but the maintainer is waiting to test this update.

=> A vote in bodhi is mostly meaningless.


>  On
> the contrary, as we know, bugzilla spam overwhelmes the package
> maintainers.

True, but the bureaucracy introduced by bodhi and the testing repos is
much worse - As far as my packages are concerned, it's at least one
magitude (factor 10) higher - Truely nagging!


> Whenever someone says "Fedora is community-driven" I'd really like to see
> that it means "update pkg foo passed the testing done by a group of
> power-users" and not just "Fedora provides a system where a single package
> maintainer is free to unleash a pkg and burden the community with breakage".
> Not only do we need to give interested parts of the community the
> opportunity to contribute testing, we need to request it actively. "You
> want updates, then help with testing to make sure the stuff remains
> usable." Let it stay in updates-testing for several weeks, if need be.
> Six months pass so quickly, the next Fedora will be released soon
> enough if the community shows no interest in updating the older dist
> releases.
/me thinks you are mis-understanding what I am aiming at:

 I don't want to get rid of "testing", I want to get rid of the hidden
"package has been built but maintainer hasn't gotten around to push a
package to testing" package queue and the interactions with it.

It's the interactive step maintainers are required to perform in bodhi
to push a package to testing, which adding to this bureaucratic bloat
maintainers in Fedora are confronted with.


Ralf




From limb at jcomserv.net  Fri Dec 12 14:04:31 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 12 Dec 2008 08:04:31 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <13600.1229038307@sss.pgh.pa.us>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
	<f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
Message-ID: <b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>


> "Jon Ciesla" <limb at jcomserv.net> writes:
>>> (Yes, I know libjpeg upstream is kinda moribund, but if you want new
>>> features in it you should be trying to revive upstream development,
>>> not strongarm the Fedora package maintainer to take over development.)
>
>> I agree strongly with that principle.  Two questions:
>
>> A. What has been done thusfar WTR reviving upstream development?
>
> Well, at one point I had more or less formally blessed Guido Vollbeding
> as the new lead maintainer, but if he's actually put out a release I
> haven't heard about it :-(.  You could try bugging the people associated
> with the sourceforge libjpeg project.

CCing them.  libjpeg SourceForge team, what is the current status of
libjpeg development?

>> B. In the meantime, how should I support jpegtran?  Bundle a custom
>> binary
>> in the subpackage and patch the module, or let it sit with known partial
>> functionality?
>
> The right fix would be to pester upstream to not depend on nonstandard
> functionality, but with no active upstream on that side either, I'm not
> sure what you do about it :-(.  How critical is that particular
> functionality to gallery2, anyway?  If you could just dike it out that
> would seem to be an appropriate short-term fix.

Not critical at all, AFAICT.  I'll have a look-see.

>> On a tangential note IIRC this patch is in Debian's libjpeg, not that
>> that
>> should be any sort of guideline for us, I'm just putting it out there.
>
> Yeah, Debian seems to have no qualms about carrying big patches without
> any upstream connection ...

No comment. :)

> 			regards, tom lane
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From kevin.kofler at chello.at  Fri Dec 12 14:32:24 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 15:32:24 +0100
Subject: Installing from Live CD is the new black?
References: <1228955078.3037.10.camel@fecusia>
	<200812111828.00512.opensource@till.name>
	<20081211181630.GA27793@localhost.localdomain>
	<200812112140.11914.opensource@till.name>
	<f7c6719a0812120439x34dea32avb3b94d0146300d73@mail.gmail.com>
Message-ID: <ghtslo$9d$1@ger.gmane.org>

Christof Damian wrote:
> One of my wishes for a future Fedora is also an easy way to install
> from USB stick. I prefer to use the normal install instead of the
> livecd/stick and currently you have to burn a CD / DVD to make this
> work.

https://fedorahosted.org/liveusb-creator/

        Kevin Kofler



From rawhide at fedoraproject.org  Fri Dec 12 14:37:57 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 12 Dec 2008 14:37:57 +0000 (UTC)
Subject: rawhide report: 20081212 changes
Message-ID: <20081212143757.8D95D1F823F@releng2.fedora.phx.redhat.com>

Compose started at Fri Dec 12 06:01:13 UTC 2008

New package gbdfed
        Bitmap Font Editor
New package gobject-introspection
        Introspection system for GObject-based libraries
New package perl-MooseX-StrictConstructor
        Make your object constructors blow up on unknown attributes
New package perl-RPM2
        Perl bindings for the RPM Package Manager API
Updated Packages:

DeviceKit-002-4
---------------
* Thu Dec 11 17:00:00 2008 Colin Walters <walters at verbum.org> - 002-4
- Add dbus permissions patch


LinLog-0.4-1.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Sindre Pedersen Bjordal <sindrepb at fedoraproject.org> - 0.4-1
- New upstream release


Maelstrom-3.0.6-16
------------------
* Thu Dec 11 17:00:00 2008 Bill Nottingham <notting at redhat.com> 3.0.6-16
- fix requirements for scriptlets (#475922)


OpenIPMI-2.0.14-9.fc11
----------------------
* Thu Dec 11 17:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-9
- fix linking without rpath, prelink won't screw up the libraries
  anymore (#475265)


ax25-tools-0.0.8-3.fc11
-----------------------
* Thu Dec 11 17:00:00 2008 Sindre Pedersen Bj??rdal <foolish at guezz.net> 0.0.8-3
- Fix pseudo-terminal issue, #475045


bzrtools-1.10.0-2.fc11
----------------------
* Thu Dec 11 17:00:00 2008 Henrik Nordstrom <henrik at henriknordstrom.net> - 1.10.0-2
- Minor packaging bugfix


cairo-dock-2.0.0-0.1.svn1432_trunk.fc11
---------------------------------------
* Fri Dec 12 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1432


cmake-2.6.3-0.rc5.1.fc11
------------------------
* Wed Dec 10 17:00:00 2008 Orion Poplawski <orion at cora.nwra.com> - 2.6.3-0.rc5.1
- Update to 2.6.3-RC-5

* Tue Dec  2 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 2.6.2-3
- Add -DCMAKE_VERBOSE_MAKEFILE=ON to %cmake (#474053)
- preserve timestamp of macros.cmake
- cosmetics

* Tue Oct 21 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com> - 2.6.2-2
- Allow conditional build of gui


compiz-fusion-0.7.8-5.fc11
--------------------------
* Thu Dec 11 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-5
- Bump release

* Thu Dec 11 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-4
- Add winrules patch back, not upstream yet


ctrlproxy-3.0.8-1.fc11
----------------------
* Wed Dec 10 17:00:00 2008 Bernie Innocenti <bernie at codewiz.org> 3.0.8-1
- Update to latest upstream


dbus-1.2.8-4.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.8-4
- And drop it again, needs more work


dfu-programmer-0.5.1-1.fc11
---------------------------
* Wed Dec 10 17:00:00 2008 Weston Schmidt <weston_schmidt at alumni.purdue.edu> - 0.5.1-1
- add new flag to surpress bootloader memory checking

* Wed Dec  3 17:00:00 2008 Weston Schmidt <weston_schmidt at alumni.purdue.edu> - 0.5.0-1
- update the description
- fix the broken hal rules


dkim-milter-2.7.2-2.fc11
------------------------
* Wed Dec 10 17:00:00 2008 Jim Radford <radford at blackbean.org> - 2.7.2-2
- updated to 2.7.2


dot2tex-2.8.4-1.fc11
--------------------
* Wed Dec 10 17:00:00 2008 Jim Radford <radford at blackbean.org> - 2.8.4-1
- upgrade to 2.8.4


drupal-6.7-1.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 6.7-1
- Upgrade to 6.7, SA-2008-073.


eclipse-pydev-1.3.24-3.fc11
---------------------------
* Thu Dec 11 17:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 1:1.3.24-3
- Require python-psyco to speed up debuging.

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1:1.3.24-2
- Rebuild for Python 2.6


gawk-3.1.6-3.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 3.1.6-3
- grab the current stable tree from savannah


gdal-1.6.0-1.fc11
-----------------
* Fri Dec 12 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 1.6.0-1
- final stable release


gimp-help-2.4.2-2.fc11
----------------------
* Thu Dec 11 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 2.4.2-2
- Merge Review (#225798):
  - ship AUTHORS, ChangeLog, COPYING, NEWS, README, TERMINOLOGY
  - don't own directories included in the gimp package
  - use %defattr(-, root, root, -)

* Wed Nov 26 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- Group: Documentation


git-1.6.0.5-1.fc11
------------------
* Thu Dec 11 17:00:00 2008 Josh Boyer <jboyer at gmail.com> 1.6.0.5-1
- git-1.6.0.5

* Mon Nov 17 17:00:00 2008 Seth Vidal <skvidal at fedoraproject.org>
- switch from /srv/git to /var/lib/git-daemon for packaging rules compliance


gnome-commander-1.2.8-0.2.svn2351_trunk.fc11
--------------------------------------------
* Fri Dec 12 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2351


gnome-keyring-2.25.2-2.fc11
---------------------------
* Fri Dec 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-2
- Update to 2.25.2

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-2
- Tweak description


gnubg-0.9.0.1-3.fc11
--------------------
* Thu Dec 11 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1:0.9.0.1-3
- Added coreutils requires, BZ 475933.


gpodder-0.14.0-1.fc11
---------------------
* Thu Dec 11 17:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> - 0.14.0-1
- New upstream release


grsync-0.6.2-1.fc11
-------------------
* Thu Dec 11 17:00:00 2008 Sebastian Vahl <fedora at deadbabylon.de> - 0.6.2-1
- new upstream release
- drop grsync-0.6.1-fix-crash-when-adding-new-sessions.patch


gstreamer-plugins-farsight-0.12.10-1.fc11
-----------------------------------------
* Thu Dec 11 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.12.10-1
- Update to 0.12.10.


hplip-2.8.10-2.fc11
-------------------
* Thu Dec 11 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 2.8.7-5
- Prevent backend crash when D-Bus not running (bug #474362).

* Thu Dec 11 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 2.8.10-2
- Rediff libsane patch.

* Thu Dec 11 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 2.8.10-1
- 2.8.10.  No longer need gzip-n or quiet patches.


hyphen-it-0.20071127-3.fc11
---------------------------
* Sun Nov  2 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20071127-3
- add Latin alias


i2c-tools-3.0.2-1.fc11
----------------------
* Thu Dec 11 17:00:00 2008 Adam Jackson <ajax at redhat.com> 3.0.2-1
- i2c-tools 3.0.2


kdelibs-4.1.85-1.fc11
---------------------
* Thu Dec 11 17:00:00 2008 Than Ngo <than at redhat.com> -  4.1.85-1
- 4.2beta2


kernel-2.6.28-0.127.rc8.git1.fc11
---------------------------------
* Thu Dec 11 17:00:00 2008 Hans de Goede <hdegoede at redhat.com>
- Add a patch updating the gspca driver to the latest "git" (mercurial
  actually) adding support for ov534 based cams, fixing support for
  spca501, finepix and vc0321 cams + many more bugfixes

* Thu Dec 11 17:00:00 2008 Dave Jones <davej at redhat.com>
- Remove noisy message from can network protocol.

* Thu Dec 11 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc8-git1

* Wed Dec 10 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
- 2.6.28-rc7-git8
- re-enable drm-nouveau...

* Wed Dec 10 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc8

* Wed Dec 10 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc7-git8

* Tue Dec  9 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc7-git7


libexif-0.6.16-2.fc11
---------------------
* Thu Dec 11 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.6.16-2
- rebuild to get a pkgconfig(libexif) provides


liboil-0.3.14-2.fc11
--------------------
* Thu Dec 11 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.3.14-2
- rebuild to get provides pkgconfig(liboil-0.3)


libpng-1.2.33-2.fc11
--------------------
* Thu Dec 11 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> 2:1.2.33-2
- rebuild to get provides pkgconfig(libpng)


lpsk31-1.1-4.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 1.1-4
- Add wrapper script to ensure user configuration is present, #474835
- Install sample user configuration


mantis-1.1.6-1.fc11
-------------------
* Wed Dec 10 17:00:00 2008 Gianluca Sforna <giallu gmail com> - 1.1.6-1
- new upstream release

* Mon Nov 24 17:00:00 2008 Gianluca Sforna <giallu gmail com> - 1.1.5-1
- new upstream release


mod_auth_kerb-5.4-2
-------------------
* Thu Dec 11 17:00:00 2008 Joe Orton <jorton at redhat.com> 5.4-2
- update to 5.4


nec2c-0.8-1.fc11
----------------
* Thu Dec 11 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 0.8-1
- New upstream release
- Fix some permissions to silent rpmlint

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.7-3
- Fix Patch0:/%patch mismatch.


netpanzer-0.8.2-4.fc11
----------------------
* Thu Dec 11 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> 0.8.2-4
- Fixed coreutils deps, BZ 475920.


ntl-5.4.2-4.fc11
----------------
* Thu Dec 11 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 5.4.2-4
- build -fPIC (#475254)


openoffice.org-3.0.1-13.2.fc11
------------------------------
* Thu Dec 11 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-13.2
- Resolves: rhbz#466680 package OGLTrans 3D OpenGL slide transitions
  as an optional extension.
- Resolves: rhbz#474961 wrong impress accelerators
  openoffice.org-3.0.1.ooo97088.sd.accel-fallback.patch
- Resolves: rhbz#475154 UI Language override doesn't affect system dialogs
  openoffice.org-3.0.1.ooo97064.fpicker.honour-uilang-override.patch
- version the Obsoletes
- Resolves: rhbz#475795 same fallbacks for printing as screen
  workspace.vcl97.patch


openssh-5.1p1-4.fc11
--------------------
* Thu Dec 11 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 5.1p1-4
- set FD_CLOEXEC on channel sockets (#475866)
- adjust summary
- adjust nss-keys patch so it is applicable without selinux patches (#470859)


openvpn-2.1-0.30.rc15.fc11
--------------------------
* Thu Dec 11 17:00:00 2008 Steven Pritchard <steve at kspei.com> 2.1-0.30.rc15
- Attempt to fix BZ#476129.


perl-Parse-CPAN-Packages-2.29-1.fc11
------------------------------------
* Thu Dec 11 17:00:00 2008 Steven Pritchard <steve at kspei.com> 2.29-1
- Update to 2.29.


perl-SOAP-Lite-0.710.08-1.fc11
------------------------------
* Thu Dec 11 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.710.08-1
- New upstream release
- Enable tests
- Include examples in documentation
- Don't grab in dependencies of exotic transports (for the sake
  of consistency with existing practice of Jabber transport)


perl-Set-Infinite-0.63-1.fc11
-----------------------------
* Thu Dec 11 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.63-1
- Update to 0.63.


perl-Spreadsheet-ParseExcel-0.3300-1.fc11
-----------------------------------------
* Thu Dec 11 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.3300-1
- Update to 0.3300.
- Make Test::More dep versioned.
- BR Test::Pod.


perl-XML-LibXML-1.69-1.fc11
---------------------------
* Thu Dec 11 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 1:1.69-1
- update to 1.69


perl-XML-SAX-0.96-1.fc11
------------------------
* Thu Dec 11 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 0.96-1
- update to 0.96, big leap in versioning


phpMyAdmin-3.1.1-1.fc11
-----------------------
* Thu Dec 11 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 3.1.1-1
- Upstream released 3.1.1 (#475954)


ppp-2.4.4-9.fc11
----------------
* Thu Dec 11 17:00:00 2008 Jiri Skala <jskala at redhat.com> 2.4.4.-9
- fixed #467004 PPP sometimes gets incorrect DNS servers for mobile broadband connections


rmanage-0.1.6-1.fc11
--------------------
* Thu Dec 11 17:00:00 2008 Parag Nemade <panemade at gmail.com>- 0.1.6-1
- Update to next update version 0.1.6


seamonkey-1.1.13-1.fc11
-----------------------
* Thu Dec 11 17:00:00 2008 Kai Engert <kengert at redhat.com> - 1.1.13-1
- Update to 1.1.13
- own additional directories, bug 474039


selinux-policy-3.6.1-10.fc11
----------------------------
* Thu Dec 11 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-10
- Allow unconfined_r unconfined_java_t


sugar-analyze-8-3.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 8-3
- Rebuild for Python 2.6


sugar-browse-99-2.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 99-2
- Rebuild for Python 2.6


sugar-calculator-23-2.fc11
--------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 23-2
- Rebuild for Python 2.6


sugar-chat-47-2.fc11
--------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 47-2
- Rebuild for Python 2.6


sugar-journal-99-4.fc11
-----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 99-4
- Rebuild for Python 2.6


sugar-jukebox-5-4.fc11
----------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 5-4
- Rebuild for Python 2.6


sugar-log-16-2.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 16-2
- Rebuild for Python 2.6


sugar-memorize-29-2.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 29-2
- Rebuild for Python 2.6


sugar-moon-8-3.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 8-3
- Rebuild for Python 2.6


sugar-terminal-16-3.fc11
------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 16-3
- Rebuild for Python 2.6


sugar-turtleart-19-2.fc11
-------------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 19-2
- Rebuild for Python 2.6


sugar-write-59-2.fc11
---------------------
* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 59-2
- Rebuild for Python 2.6


tar-1.20-6.fc11
---------------
* Thu Dec 11 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2:1.20-6
- add BuildRequires for rsh (#475950)


vodovod-1.10r19-1.fc11
----------------------
* Thu Dec 11 17:00:00 2008 Karel Volny <kvolny at redhat.com> 1.10r19-1
- Added coreutils to post(un) (fixes bug #475921)
- New version requires SDL_ttf-devel

* Wed Mar  5 17:00:00 2008 Karel Volny <kvolny at redhat.com> 1.10r13-1
- development version
- Removed gcc43 patch (fixed upstream)
- Removed wrapper stuff and harcoded paths, upstream now uses variables
- Use hiscore file %{_localstatedir}/games/%{name}.sco
- Added language files handling
- Added Czech localisation


wxsvg-1.0-4.fc11.1
------------------
* Thu Dec 11 17:00:00 2008 Stewart Adam <s.adam at diffingo.com> - 1.0-4.1
- Thinko: libtool, not libtoolize

* Thu Dec 11 17:00:00 2008 Stewart Adam <s.adam at diffingo.com> - 1.0-4
- We do need the BR: libtoolize though...

* Thu Dec 11 17:00:00 2008 Stewart Adam <s.adam at diffingo.com> - 1.0-3
- Don't use 'libtoolize --force' anymore
- Update expat patch, rm -rf internal expat sources
- BR: expat should be BR: expat-devel


xfhell-1.9-1.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org>- 1.9-1
- New upstream release


xmlrpc-c-1.16.6-1.1582.fc11
---------------------------
* Thu Dec 11 17:00:00 2008 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 1.16.6-1.1582
- updated to 1.16.6; rediffed patches
- fixed client headers (bug #475887)


xnec2c-1.2-1.fc11
-----------------
* Thu Dec 11 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org>- 1.2-1
- New upstream release


Summary:
Added Packages: 4
Removed Packages: 0
Modified Packages: 72
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	compiz-fusion-devel-0.7.8-5.fc11.i386 requires pkgconfig(cairo-xlib-xrender)
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.i386 requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so
	perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so
	perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so
	perl-XML-LibXSLT-1.66-2.fc10.i386 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.i386 requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	compiz-fusion-devel-0.7.8-5.fc11.i386 requires pkgconfig(cairo-xlib-xrender)
	compiz-fusion-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(cairo-xlib-xrender)
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.x86_64 requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.i386 requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.x86_64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit)
	perl-XML-LibXSLT-1.66-2.fc10.x86_64 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.x86_64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.i386 requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.x86_64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	compiz-fusion-devel-0.7.8-5.fc11.ppc requires pkgconfig(cairo-xlib-xrender)
	compiz-fusion-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(cairo-xlib-xrender)
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	1:eclipse-pydev-1.3.24-3.fc11.noarch requires python-psyco
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.ppc requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc requires pkgconfig(libtasn1) >= 0:1.1
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so
	perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so
	perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so
	perl-XML-LibXSLT-1.66-2.fc10.ppc requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc requires libgeos-3.0.1.so
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc requires pkgconfig(OpenEXR)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	compiz-fusion-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(cairo-xlib-xrender)
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:eclipse-pydev-1.3.24-3.fc11.noarch requires python-psyco
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.3.2-1.fc8.noarch requires python(abi) = 0:2.5
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libiphone-devel-0.1.0-6.20081201git8c3a01e.fc11.ppc64 requires pkgconfig(libtasn1) >= 0:1.1
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit)
	perl-XML-LibXSLT-1.66-2.fc10.ppc64 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-basemap-0.99-6.fc11.ppc64 requires libgeos-3.0.1.so()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	vips-devel-7.14.5-2.fc11.ppc64 requires pkgconfig(OpenEXR)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From kevin.kofler at chello.at  Fri Dec 12 14:36:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 15:36:55 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
	<20081212121413.033685ca.mschwendt@gmail.com>
	<1229080807.3081.232.camel@beck.corsepiu.local>
	<20081212133853.33a06a4f.mschwendt@gmail.com>
	<1229087438.3081.270.camel@beck.corsepiu.local>
Message-ID: <ghtsu7$9d$2@ger.gmane.org>

Ralf Corsepius wrote:
>  I don't want to get rid of "testing", I want to get rid of the hidden
> "package has been built but maintainer hasn't gotten around to push a
> package to testing" package queue and the interactions with it.
> 
> It's the interactive step maintainers are required to perform in bodhi
> to push a package to testing, which adding to this bureaucratic bloat
> maintainers in Fedora are confronted with.

This "bureaucracy" is needed so you can tell *why* you're pushing the
update. At the very least "upstream bugfix release, changelog here: [URL]".
But often you want to give a more precise reason, also referencing Bugzilla
IDs.

Now some maintainers don't do this, but that's their fault, not Bodhi's.

        Kevin Kofler



From skvidal at fedoraproject.org  Fri Dec 12 15:00:40 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 10:00:40 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <4941FF83.7090404@leemhuis.info>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
Message-ID: <alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>



On Fri, 12 Dec 2008, Thorsten Leemhuis wrote:

> Another good question (related to the "will this confuse new users" part): 
> Will you enable the updates-testing repos from 3rd party repos in the same 
> step automatically? Otherwise people that use those repos will now and then 
> run into dependency troubles -- for example when a new xine-lib enters 
> updates-testing from Fedora and xine-lib-extras-nonfree enters 
> updates-testing from RPM Fusion at the same time.
>
> But well, likely it doesn't matter to much anyway, as yum is still pretty 
> broken in such situations anyway, as mirror lags will confuse it:
> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html

Yes, that's right yum is broken b/c the mirrors are out of sync.

Just like Apache is broken when a 404 is issued. It must be apache's fault 
that the data is missing or broken.

Cmon, Thorsten, your command of english is excellent, you can phrase that 
a bit better.

-sv



From skvidal at fedoraproject.org  Fri Dec 12 15:04:11 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 10:04:11 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229081008.17998.5.camel@gibraltar.str.redhat.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<20081209130409.283584eb@brian.englab.brq.redhat.com>
	<faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>
	<1229081008.17998.5.camel@gibraltar.str.redhat.com>
Message-ID: <alpine.LFD.2.00.0812121003320.19488@localhost.localdomain>



On Fri, 12 Dec 2008, Nils Philippsen wrote:

>
> Somehow delaying file updates until after a reboot sounds yucky to me,
> not only because merely quitting firefox and starting it again would
> help in this instance. Perhaps we should find a way where yum/PK would
> flag packages which are known to have these issues to the user in the
> form of "updating these packages requires you to restart firefox/..."
> akin to how we hint users to logout and back in (e.g. update of basic
> GNOME packages) or reboot the machine (kernel).
>

there are multiple ways to do this - the hard part is not the 
implementation. The hard part is making the list of pkgs for which a 
restart of the box/app is important.

-sv



From mschwendt at gmail.com  Fri Dec 12 15:04:57 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 12 Dec 2008 16:04:57 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <1229087438.3081.270.camel@beck.corsepiu.local>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
	<20081212121413.033685ca.mschwendt@gmail.com>
	<1229080807.3081.232.camel@beck.corsepiu.local>
	<20081212133853.33a06a4f.mschwendt@gmail.com>
	<1229087438.3081.270.camel@beck.corsepiu.local>
Message-ID: <20081212160457.5af28778.mschwendt@gmail.com>

On Fri, 12 Dec 2008 14:10:38 +0100, Ralf wrote:

> > The problem Fedora has is that updates-testing is not popular enough.
> > It is counter-productive to flood that repo with builds automatically,
>
> Then make sure that only one version at of a package (with NEVR >
> version in stable) is inside. Could likely be automated without much
> effort.

Sure, but it wouldn't matter. Yum only chooses the most recent one
available anyway (and fails in case of missing Obsoletes and broken deps).
Any test-update which would be published immediately after a successful
build could be installed by users before you build the next one. If you
did several builds before you got it right (perhaps that doesn't apply to
you, but one can observe how other packagers do that), some users with
quick mirrors would get several test updates and would need to deal with
.rpmsave/.rpmnew issues and temporarily missing features (e.g. not every
configure script fails if something isn't detected).

In other words:

I would not want the publishing of builds to be automatic.

Rather introduce a "make build-update" as an optional alternative to
"make build". Perhaps adda a guard, so it needs an explicit opt-in
(e.g. an environment variable) before it becomes available to experienced
packagers.

I'm a fan of automation, too, but it leads to problems where it does
things magically and requires even more documentation, so packagers are
aware of what happens "in the background". I talk to packagers regularly,
and often they are surprised already by what rpmbuild does automatically.
"Oh, I didn't know that" is the phrase seen most often. Pushing builds
automatically is something we ought to be very careful with, even if
pushing only to updates-testing. We cannot affort to annoy any testers,
who are willing to help.

> In almost all cases, updates
> 
> * address a specific problem, which typically is BZ'ed, with the
> relevant tester audience listening to this BZ 
> => a vote in bodhi is redundant to feedback in bugzilla
> 
> or
> * are "upstream updates" addressing unspecific issues ("Upstreams says
> package fixes issue XYZ").
> => Nobody but the maintainer is waiting to test this update, hardly
> anybody will have a test case.
>
> or
> * are package maintainers addressing so far unpublished issues
> (maintainer often extensive use a package and are likely more familiar
> with a package than many other users).
> => Nobody but the maintainer is waiting to test this update.

That's a quite short-sighted view, IMHO. It may match your personal
perspective, but doesn't seem to apply to many updates in Fedora.

There are lots of updates, which simply say "update to x.y.z", where even
the maintainer did not sum up what changes come with this minor [not
major] version bump. Is it a bug-fix release? Is it for feature additions?
Is it a mix thereof? No BZ references either. Is it safe to install it?
Many users want to know that. The release notes for that update are empty,
as it's a simple "sync with upstream" update. [Major upgrades are a
completely different beast.]  All (!) the burden is put onto the shoulders
of the potential testers. And that's bad.

How do you know that none of your users is affected by a change
which is supposed to fix an issue known upstream? A fix that may work
for upstream can break for other users. You need to give the users
time to evaluate the update. Not rush and mark it stable after 2-3
days already.

>  I don't want to get rid of "testing", I want to get rid of the hidden
> "package has been built but maintainer hasn't gotten around to push a
> package to testing" package queue and the interactions with it.

As I said, you consider "make build" and "make update" as not convenient
enough.

That is independent from bashing the karma system or the necessity to
give the community a chance to evaluate test updates.

> 
> => A vote in bodhi is mostly meaningless.

We won't agree here, at least not fully. In +1 votes I see too much potential
for abuse (and I know several cases of sloppy testing, too), but the feature
is nice to have and helpful. Currently there is no alternative that is connected
as close to update package sets.



From thomas.moschny at gmail.com  Fri Dec 12 15:13:13 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Fri, 12 Dec 2008 16:13:13 +0100
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
Message-ID: <a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>

2008/12/12 Seth Vidal <skvidal at fedoraproject.org>:
> On Fri, 12 Dec 2008, Thorsten Leemhuis wrote:
>
>> Another good question (related to the "will this confuse new users" part):
>> Will you enable the updates-testing repos from 3rd party repos in the same
>> step automatically? Otherwise people that use those repos will now and then
>> run into dependency troubles -- for example when a new xine-lib enters
>> updates-testing from Fedora and xine-lib-extras-nonfree enters
>> updates-testing from RPM Fusion at the same time.
>>
>> But well, likely it doesn't matter to much anyway, as yum is still pretty
>> broken in such situations anyway, as mirror lags will confuse it:
>>
>> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
>
> Yes, that's right yum is broken b/c the mirrors are out of sync.

No matter how hard you try, there will always be a small period in
time where mirrors are out of sync. And this especially holds for the
synchronization between the main Fedora repo and third party repos.

So there should be a mechanism developed to make yum aware of the fact
that one repo (or mirror) it uses is behind others - because that can
lead to (virtual) dependency problems which probably should be
reported to the end user in a different way than intra-repo dependency
problems.

- Thomas



From skvidal at fedoraproject.org  Fri Dec 12 15:15:34 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 10:15:34 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>



On Fri, 12 Dec 2008, Thomas Moschny wrote:

> 2008/12/12 Seth Vidal <skvidal at fedoraproject.org>:
>> On Fri, 12 Dec 2008, Thorsten Leemhuis wrote:
>>
>>> Another good question (related to the "will this confuse new users" part):
>>> Will you enable the updates-testing repos from 3rd party repos in the same
>>> step automatically? Otherwise people that use those repos will now and then
>>> run into dependency troubles -- for example when a new xine-lib enters
>>> updates-testing from Fedora and xine-lib-extras-nonfree enters
>>> updates-testing from RPM Fusion at the same time.
>>>
>>> But well, likely it doesn't matter to much anyway, as yum is still pretty
>>> broken in such situations anyway, as mirror lags will confuse it:
>>>
>>> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
>>
>> Yes, that's right yum is broken b/c the mirrors are out of sync.
>
> No matter how hard you try, there will always be a small period in
> time where mirrors are out of sync. And this especially holds for the
> synchronization between the main Fedora repo and third party repos.
>
> So there should be a mechanism developed to make yum aware of the fact
> that one repo (or mirror) it uses is behind others - because that can
> lead to (virtual) dependency problems which probably should be
> reported to the end user in a different way than intra-repo dependency
> problems.

what do you mean 'virtual' dependency problems? They are not virtual they 
are actual dependency issues.

-sv





From thomas.moschny at gmail.com  Fri Dec 12 15:26:26 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Fri, 12 Dec 2008 16:26:26 +0100
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
Message-ID: <a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>

2008/12/12 Seth Vidal <skvidal at fedoraproject.org>:

>>> Yes, that's right yum is broken b/c the mirrors are out of sync.
>>
>> No matter how hard you try, there will always be a small period in
>> time where mirrors are out of sync. And this especially holds for the
>> synchronization between the main Fedora repo and third party repos.
>>
>> So there should be a mechanism developed to make yum aware of the fact
>> that one repo (or mirror) it uses is behind others - because that can
>> lead to (virtual) dependency problems which probably should be
>> reported to the end user in a different way than intra-repo dependency
>> problems.
>
> what do you mean 'virtual' dependency problems? They are not virtual they
> are actual dependency issues.

Yeah, sure, from the dependency solver's technical pov.

But, especially in case of a lagging mirror, they are 'virtual' in
that they could vanish immediately by using another mirror.

And this can be detected, if you give each repo an epoch or timestamp
and something like that.

A dependency problem in the set of packages provided by
  (fedora base, updates from today, rpmfusion from today)
is somehow more 'severe' than a dependency problem from
  (fedora base, updates from today, rpmfusion from yesterday)

- Thomas



From skvidal at fedoraproject.org  Fri Dec 12 15:32:49 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 10:32:49 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>



On Fri, 12 Dec 2008, Thomas Moschny wrote:

>
> Yeah, sure, from the dependency solver's technical pov.
>
> But, especially in case of a lagging mirror, they are 'virtual' in
> that they could vanish immediately by using another mirror.
>
> And this can be detected, if you give each repo an epoch or timestamp
> and something like that.
>
> A dependency problem in the set of packages provided by
>  (fedora base, updates from today, rpmfusion from today)
> is somehow more 'severe' than a dependency problem from
>  (fedora base, updates from today, rpmfusion from yesterday)
>

How? It's the same to the user. They can't do what they wanted to do b/c 
they're out of sync.

-sv



From thomas.moschny at gmail.com  Fri Dec 12 15:47:22 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Fri, 12 Dec 2008 16:47:22 +0100
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
Message-ID: <a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>

2008/12/12 Seth Vidal <skvidal at fedoraproject.org>:
>> A dependency problem in the set of packages provided by
>>  (fedora base, updates from today, rpmfusion from today)
>> is somehow more 'severe' than a dependency problem from
>>  (fedora base, updates from today, rpmfusion from yesterday)
>
> How? It's the same to the user. They can't do what they wanted to do b/c
> they're out of sync.

That's not true. They could go and report the dependency problems
somewhere - which would be superfluous work in case their mirror is
simply behind. And btw, how do you know what they really wanted -
probably they simply run yum upgrade.

- Thomas



From skvidal at fedoraproject.org  Fri Dec 12 15:55:47 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 10:55:47 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>



On Fri, 12 Dec 2008, Thomas Moschny wrote:

> 2008/12/12 Seth Vidal <skvidal at fedoraproject.org>:
>>> A dependency problem in the set of packages provided by
>>>  (fedora base, updates from today, rpmfusion from today)
>>> is somehow more 'severe' than a dependency problem from
>>>  (fedora base, updates from today, rpmfusion from yesterday)
>>
>> How? It's the same to the user. They can't do what they wanted to do b/c
>> they're out of sync.
>
> That's not true. They could go and report the dependency problems
> somewhere - which would be superfluous work in case their mirror is
> simply behind. And btw, how do you know what they really wanted -
> probably they simply run yum upgrade.
>

Which is really what --skip-broken is for.

In general skip-broken is probably going to need to be the default for 
these multi-repo situations. I don't LOVE it but if we tie this info into 
the updateinfo.xml so we can properly notify the user if a security or 
important update cannot be applied b/c of a broken dependency, then I will 
feel better about it.

-sv



From loganjerry at gmail.com  Fri Dec 12 16:04:16 2008
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 12 Dec 2008 09:04:16 -0700
Subject: Debugging sound volume problem
In-Reply-To: <20081212121936.GC22242@tango.0pointer.de>
References: <870180fe0812111959v6fe9c549p294a93a7a2f6a0bd@mail.gmail.com>
	<20081212121936.GC22242@tango.0pointer.de>
Message-ID: <870180fe0812120804y43d6d5e2qd5b92eac874ffea9@mail.gmail.com>

On Fri, Dec 12, 2008 at 5:19 AM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> Unfortunately the ALSA mixers are not in all cases properly
> initialized by default yet. For cases where this went wrong, you can
> use "alsamixer -c0" to play around with the mixer at the lowest level.

Thanks for the helpful information, everyone.  This tip did the trick.
 Even though the "Master" volume was at 100%, "PCM" and "Front" were
at very low levels, and everything else was at zero.  I can hear my
music again!  Hurrah!
-- 
Jerry James, showing his age by listening to "Eye in the Sky"
http://loganjerry.googlepages.com/



From pemboa at gmail.com  Fri Dec 12 16:09:03 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 10:09:03 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <ghtslo$9d$1@ger.gmane.org>
References: <1228955078.3037.10.camel@fecusia>
	<200812111828.00512.opensource@till.name>
	<20081211181630.GA27793@localhost.localdomain>
	<200812112140.11914.opensource@till.name>
	<f7c6719a0812120439x34dea32avb3b94d0146300d73@mail.gmail.com>
	<ghtslo$9d$1@ger.gmane.org>
Message-ID: <16de708d0812120809j59b80695j9d2b2b80fe1d6def@mail.gmail.com>

On Fri, Dec 12, 2008 at 8:32 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Christof Damian wrote:
>> One of my wishes for a future Fedora is also an easy way to install
>> from USB stick. I prefer to use the normal install instead of the
>> livecd/stick and currently you have to burn a CD / DVD to make this
>> work.
>
> https://fedorahosted.org/liveusb-creator/


He did say _from_ USB stick. Is the install to hard drive feature
preserved after you liveinstall to USB? I can't remember seeing the
icon.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From orion at cora.nwra.com  Fri Dec 12 16:12:25 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 12 Dec 2008 09:12:25 -0700
Subject: How to get c++ abort to generate backtrace
Message-ID: <49428D69.10403@cora.nwra.com>

We're seeing cmake crash on the ppc64 builders with the following:

terminate called after throwing an instance of 'std::out_of_range'
   what():  basic_string::erase

Is there anyway to get this to automatically generate a stack trace? 
When I try running the process under gdb I don't get the crash so I've 
been unable to debug that way.

-- 
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 fedora at leemhuis.info  Fri Dec 12 16:14:41 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 12 Dec 2008 17:14:41 +0100
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>	<1228933404.2682.7.camel@scrappy.miketc.net>	<1229017332.15913.3.camel@hughsie-work.lan>	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>	<1229020080.26965.0.camel@hughsie-work.lan>	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
Message-ID: <49428DF1.4080908@leemhuis.info>

On 12.12.2008 16:00, Seth Vidal wrote:
> 
> On Fri, 12 Dec 2008, Thorsten Leemhuis wrote:
>> Another good question (related to the "will this confuse new users" part): 
>> Will you enable the updates-testing repos from 3rd party repos in the same 
>> step automatically? Otherwise people that use those repos will now and then 
>> run into dependency troubles -- for example when a new xine-lib enters 
>> updates-testing from Fedora and xine-lib-extras-nonfree enters 
>> updates-testing from RPM Fusion at the same time.
>>
>> But well, likely it doesn't matter to much anyway, as yum is still pretty 
>> broken in such situations anyway, as mirror lags will confuse it:
>> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
> 
> Yes, that's right yum is broken b/c the mirrors are out of sync.
 >
> Just like Apache is broken when a 404 is issued. It must be apache's fault 
> that the data is missing or broken.

I don't think the Apache example really flies, but whatever, not worth 
arguing. I just want the problem fixed :-)

> Cmon, Thorsten, your command of english is excellent, you can phrase that 
> a bit better.

Hehe, actually I had written the word "broken", then deleted it, and 
then (after a few seconds) wrote it again. Mainly for one reason(?): 
users often use it when they run into troubles outlined in
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html

It depends a bit for what they use it -- sometimes it's Fedora that is 
"broken", sometimes RPM Fusion/Livna, sometimes yum or sometimes 
PackageKit. We all don't want that afaics; it's really bad for Fedoras 
reputation.

So we should try to get it fixed; yum *afaics* is the best place, as the 
data is there in the repos (at least if RPM Fusion pushes all the bits 
at the same time; that works often, but now always), yum just has to 
look at the right places *or* ignore those problems for some time *or* 
<your suggestion here>.

What would you suggest to fix the problem at hand?

Cu
knurd

(?) maybe I also a tiny little bit hoped it would help to get your 
attention (sorry for that) so we can finally work out a solution (with 
or without yum) to solve the problem once and for all



From jakub at redhat.com  Fri Dec 12 16:16:21 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Fri, 12 Dec 2008 17:16:21 +0100
Subject: How to get c++ abort to generate backtrace
In-Reply-To: <49428D69.10403@cora.nwra.com>
References: <49428D69.10403@cora.nwra.com>
Message-ID: <20081212161621.GI17496@tyan-ft48-01.lab.bos.redhat.com>

On Fri, Dec 12, 2008 at 09:12:25AM -0700, Orion Poplawski wrote:
> We're seeing cmake crash on the ppc64 builders with the following:
>
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  basic_string::erase
>
> Is there anyway to get this to automatically generate a stack trace?  

LD_PRELOAD=libSegFault.so SEGFAULT_SIGNALS=abrt ./program arguments

	Jakub



From pemboa at gmail.com  Fri Dec 12 16:15:55 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 10:15:55 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081212114203.b912da4c.mschwendt@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
	<ghsikm$gpk$4@ger.gmane.org>
	<20081212114203.b912da4c.mschwendt@gmail.com>
Message-ID: <16de708d0812120815y30ba063ci5fee6cff9482fa10@mail.gmail.com>

On Fri, Dec 12, 2008 at 4:42 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Fri, 12 Dec 2008 03:35:02 +0100, Kevin wrote:
>
>> > On Thu, 11 Dec 2008 12:32:12 -0600, Arthur wrote:
>> >
>> >> 6 months is a pretty long time to wait for a major release. I
>> >> understand the rationale, but if this is going to be the new Fedora,
>> >> best announce this and let  everyone know so that they can reevaluate
>> >> if Fedora is for them. As things are, I feel that we are being _too_
>> >> conservative. Any further move to more conservatism seriously affects
>> >> Fedora's usefulness to me.
>> >
>> > Why?
>>
>> Because, like me, he chose Fedora *because* of the stream of updates, we
>> *want* those updates, including version upgrades.
>
> Judging on the community uproar everytime a grave bug in updates is
> discovered, I don't see that Fedora's users want so many poorly tested
> updates and upgrades that throw away the work of the previous development
> (Rawhide) period. I hear and read that the six months release cycle
> is fast-moving enough for them and that every new release suffers from
> enough bugs which requires updates to bring it into usable shape.
>
> What I see is that although we have updates-testing repos and a karma
> system in bodhi, nothing is done to build up a Fedora QA team that
> controls the flow of updates into the stable repo. Why do we force our
> precious users to become guinea pigs instead of only giving them the
> chance to become early adaptors [by enabling updates-testing]? It's
> especially the version upgrades that break the most things. Broken
> dependencies are harmless compared with changes in a user-interface and
> changes and in a feature-set.
>
> "Idiot filters in bodhi"? - Not a bad idea to add a check-box where
> package maintainers must acknowledge the guidelines:
>
> https://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users
>
>> We would be using Ubuntu
>> or CentOS or any of the other bazillion conservative distros otherwise.
>> A distro with a 6-month release cycle, but conservative updates, already
>> exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
>> go use Ubuntu.
>
> CentOS is not only "conservative", as a copy of RHEL and completely
> different release cycle it doesn't offer any release that is close to
> Fedora 8/9/10. Colin has mentioned (essential) differences between Ubuntu
> and Fedora. There are more. Ubuntu won't become equal to Fedora if it
> increased its updates frequency.


We will have to agree to disagree on this as I found none of the
reasons he gave substantive. I'll wait to see what looks like may be a
new pace of releases play out. I will say that I find the tone of the
proposed changes to be overly conservative and overall unfortunate.
But if that's what the majority wishes, so be it.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From orion at cora.nwra.com  Fri Dec 12 16:25:19 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 12 Dec 2008 09:25:19 -0700
Subject: Updates QA/karma question
Message-ID: <4942906F.6080603@cora.nwra.com>

Another update issue that raises some questions -

- Does anyone actually read the comments in bodhi before allowing the 
push request to proceed?

Case in point:

================================================================================
      rpcbind-0.1.7-1.fc9
================================================================================
   Update ID: FEDORA-2008-10000
     Release: Fedora 9
      Status: stable
        Type: enhancement
       Karma: 0
       Notes: Updated to latest upstream version: 0.1.7 which fixes a 
number of
            : problems.
   Submitter: steved
   Submitted: 2008-11-21 10:48:00
    Comments: steved - 2008-11-21 10:48:00 (karma 0)
              This update has been submitted for testing
              bodhi - 2008-11-22 16:52:27 (karma 0)
              This update has been pushed to testing
              thethirddoorontheleft at comcast.net (unauthenticated) - 
2008-11-25 05:35:58 (karma -1)
              Causes nfs statd to fail at bootup
              orion - 2008-11-25 16:24:51 (karma -1)
              Needs selinux changes.  Fails to start with selinux
              enforcing.
              https://bugzilla.redhat.com/show_bug.cgi?id=472917
              steved - 2008-12-09 18:59:31 (karma 1)
              selinux-policy-targeted-3.3.1-115.fc9 is now available
              which does take care of the Selinux problem. Please up
              update and try again...
              steved - 2008-12-10 00:04:27 (karma 0)
              This update has been submitted for stable
              orion - 2008-12-10 16:12:46 (karma -1)
              This should not be pushed to stable until selinux-
              policy-targeted-3.3.1-115.fc9 has been pushed to
              stable.
              bodhi - 2008-12-11 07:58:07 (karma 0)
              This update has been pushed to stable

   http://admin.fedoraproject.org/updates/F9/FEDORA-2008-10000

- Should update submitters be allowed to give positive karma to their 
updates?  Seems like that they are too biased.

- Is there any requirement that an update have positive karma before 
being pushed to stable?


As of now, rpcbind will fail to start on F-9 with selinux in enforcing 
mode (esp. important on servers!) until 
selinux-policy-targeted-3.3.1-115.fc9 is pushed to stable.  Seems like 
we could have waited for that.

Dec 12 09:16:11 xenf9 yum: Updated: rpcbind-0.1.7-1.fc9.i386
Dec 12 09:18:21 xenf9 rpcbind: rpcbind terminating on signal. Restart 
with "rpcbind -w"
Dec 12 09:18:21 xenf9 rpcbind: setgid to 'rpc' (32) failed: Operation 
not permitted
Dec 12 09:18:21 xenf9 kernel: type=1400 audit(1229098701.631:5): avc: 
denied  {setgid } for  pid=2412 comm="rpcbind" capability=6 
scontext=unconfined_u:system_r:rpcbind_t:s0 
tcontext=unconfined_u:system_r:rpcbind_t:s0 tclass=capability


We really need to work on this updates system.

-- 
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 opensource at till.name  Fri Dec 12 16:25:57 2008
From: opensource at till.name (Till Maas)
Date: Fri, 12 Dec 2008 17:25:57 +0100
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812120809j59b80695j9d2b2b80fe1d6def@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia> <ghtslo$9d$1@ger.gmane.org>
	<16de708d0812120809j59b80695j9d2b2b80fe1d6def@mail.gmail.com>
Message-ID: <200812121726.02875.opensource@till.name>

On Fri December 12 2008, Arthur Pemberton wrote:
> On Fri, Dec 12, 2008 at 8:32 AM, Kevin Kofler <kevin.kofler at chello.at> 
wrote:
> > Christof Damian wrote:
> >> One of my wishes for a future Fedora is also an easy way to install
> >> from USB stick. I prefer to use the normal install instead of the
> >> livecd/stick and currently you have to burn a CD / DVD to make this
> >> work.
> >
> > https://fedorahosted.org/liveusb-creator/
>
> He did say _from_ USB stick. Is the install to hard drive feature
> preserved after you liveinstall to USB?

Yes, but he also said that he wants to install the contents of the regular DVD 
from USB, which became a little more trickier with F10.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/cd68a7dc/attachment.sig>

From jkeating at redhat.com  Fri Dec 12 16:29:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 08:29:12 -0800
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <604aa7910812112150l563808c2tee83d6579d697889@mail.gmail.com>
References: <20081205195914.GB3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>
	<1229058121.3863.119.camel@localhost.localdomain>
	<604aa7910812112150l563808c2tee83d6579d697889@mail.gmail.com>
Message-ID: <1229099352.3863.124.camel@localhost.localdomain>

On Thu, 2008-12-11 at 20:50 -0900, Jeff Spaleta wrote:
> My point is...if its arbitrary and the call out is really just for any
> editor...why not just have all the same default fallbacks so all the
> proggies can share the same fallback.
> 
> If the upstreams really really cared about vi being there
> specifically, there'd be a build time check.

I really don't get your point.  Do you want our maintainers to patch out
the strict fallback to vi?  That's not something we should be doing in
dist-cvs, that's something that should be discussed with the relevant
upstreams.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/ad0dd4fe/attachment.sig>

From lesmikesell at gmail.com  Fri Dec 12 16:28:27 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Dec 2008 10:28:27 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <alpine.LFD.2.00.0812121003320.19488@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<20081209130409.283584eb@brian.englab.brq.redhat.com>	<faa16b610812090827i151d661ex7ff4d0f6de5b6d9b@mail.gmail.com>	<1229081008.17998.5.camel@gibraltar.str.redhat.com>
	<alpine.LFD.2.00.0812121003320.19488@localhost.localdomain>
Message-ID: <4942912B.1010702@gmail.com>

Seth Vidal wrote:
> 
> 
> On Fri, 12 Dec 2008, Nils Philippsen wrote:
> 
>>
>> Somehow delaying file updates until after a reboot sounds yucky to me,
>> not only because merely quitting firefox and starting it again would
>> help in this instance. Perhaps we should find a way where yum/PK would
>> flag packages which are known to have these issues to the user in the
>> form of "updating these packages requires you to restart firefox/..."
>> akin to how we hint users to logout and back in (e.g. update of basic
>> GNOME packages) or reboot the machine (kernel).
>>
> 
> there are multiple ways to do this - the hard part is not the 
> implementation. The hard part is making the list of pkgs for which a 
> restart of the box/app is important.

Doesn't firefox do this by itself in the versions that do their own 
updates - that is, it tells you that the updates won't take effect until 
you restart the app?  I don't think it gets it completely right even 
then, though.  I've seen the Mac and Windows versions get slow and 
unresponsive if you keep them running for some time after the update has 
happened.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From loganjerry at gmail.com  Fri Dec 12 16:29:19 2008
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 12 Dec 2008 09:29:19 -0700
Subject: Fwd: [Bug 467179] Review Request: pngcrush - Optimizer for PNG
	(Portable Network Graphics) files
In-Reply-To: <200812121204.mBCC42J3010047@bz-web2.app.phx.redhat.com>
References: <bug-467179-150697@bugzilla.redhat.com>
	<200812121204.mBCC42J3010047@bz-web2.app.phx.redhat.com>
Message-ID: <870180fe0812120829g45bb5bbcv9cb3235eb756d8f9@mail.gmail.com>

Why did the Fedora Update System post information about an irqbalance
update to a review bug for pngcrush?


---------- Forwarded message ----------
From:  <bugzilla at redhat.com>
Date: Fri, Dec 12, 2008 at 5:04 AM
Subject: [Bug 467179] Review Request: pngcrush - Optimizer for PNG
(Portable Network Graphics) files
To: loganjerry at gmail.com


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=467179





--- Comment #12 from Fedora Update System <updates at fedoraproject.org>
2008-12-12 07:04:01 EDT ---
irqbalance-0.55-12.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/irqbalance-0.55-12.fc10

--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.



-- 
Jerry James
http://loganjerry.googlepages.com/



From fedora at leemhuis.info  Fri Dec 12 16:30:49 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 12 Dec 2008 17:30:49 +0100
Subject: Making updates-testing more useful
In-Reply-To: <1229075701.3450.8.camel@hughsie-work.lan>
References: <1228930549.3648.14.camel@localhost.localdomain>	<1228933404.2682.7.camel@scrappy.miketc.net>	<1229017332.15913.3.camel@hughsie-work.lan>	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>	<1229020080.26965.0.camel@hughsie-work.lan>	<4941FF83.7090404@leemhuis.info>
	<1229075701.3450.8.camel@hughsie-work.lan>
Message-ID: <494291B9.9070907@leemhuis.info>

On 12.12.2008 10:55, Richard Hughes wrote:
> On Fri, 2008-12-12 at 07:06 +0100, Thorsten Leemhuis wrote:
>> On 11.12.2008 19:28, Richard Hughes wrote:
>>> Yes, we can easily enable the testing repos with a small button and a
>>> more info link. The real question is, will this clutter the UI and
>>> confuse new users?
>> Another good question (related to the "will this confuse new users" 
>> part): Will you enable the updates-testing repos from 3rd party repos in 
>> the same step automatically?
> 
> Yes.

Great!

> If the user has fedora and rpmfusion enabled, but livna disabled,

Just to me sure: I assume you meant both rpmfusion repos (free and 
nonfree) when you wrote "rpmfusion"?

> it'll do in the first pass:
> 
> updates from all configured and enabled sources
> 
> and on the second pass:
> 
> disable fedora and rpmfusion

Disable? Why disable any repos? What is a package from one of the 
testing repos introduces a new dep that is only solved by a package in 
fedora (stock repos) or fedora-updates?

> enable fedora-testing and rpmfusion-testing
> updates from all configured and enabled sources
> enable fedora and rpmfusion
> disable fedora-testing and rpmfusion-testing
> 
> If you've got livna installed then it shouldn't touch the repo.

The new livna repo (that users get that install the current release 
package from the rlo front page) afaics has no testing area anymore, so 
it afaics should not matter at all and not get touched (like you said)

> The
> tricky bit is the heuristic that matches up rpmfusion-testing to
> rpmfusion.

Maybe all that is needed it to enable all "*-testing" repos. Then it 
would work even for other repos as well. But maybe that's to dangerous.

>> But well, likely it doesn't matter to much anyway, as yum is still 
>> pretty broken in such situations anyway, as mirror lags will confuse it:
>> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
> We can't do much about mirror lags, but we do switch on --skip-broken by
> default which sort of mitigates things.

I'm not really sure of "skip-broken" in its current form really is the 
best way to solve it, but maybe it's "good enough". Another subthread in 
this discussion hopefully gets to a result.

Cu
knurd



From nicu_fedora at nicubunu.ro  Fri Dec 12 16:31:49 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 12 Dec 2008 18:31:49 +0200
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812120809j59b80695j9d2b2b80fe1d6def@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>	<200812111828.00512.opensource@till.name>	<20081211181630.GA27793@localhost.localdomain>	<200812112140.11914.opensource@till.name>	<f7c6719a0812120439x34dea32avb3b94d0146300d73@mail.gmail.com>	<ghtslo$9d$1@ger.gmane.org>
	<16de708d0812120809j59b80695j9d2b2b80fe1d6def@mail.gmail.com>
Message-ID: <494291F5.9000303@nicubunu.ro>

Arthur Pemberton wrote:
> On Fri, Dec 12, 2008 at 8:32 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> Christof Damian wrote:
>>> One of my wishes for a future Fedora is also an easy way to install
>>> from USB stick. I prefer to use the normal install instead of the
>>> livecd/stick and currently you have to burn a CD / DVD to make this
>>> work.
>> https://fedorahosted.org/liveusb-creator/
> 
> 
> He did say _from_ USB stick. Is the install to hard drive feature
> preserved after you liveinstall to USB? I can't remember seeing the
> icon.

Yes, it is (it was in F10 Alpha), but Christof said "normal install", 
you can't make that in a live DVD. The idea was to perform a normal DVD 
install but use an USB stick instead of wasting DVD.

-- 
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 tibbs at math.uh.edu  Fri Dec 12 16:34:29 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 12 Dec 2008 10:34:29 -0600
Subject: Fwd: [Bug 467179] Review Request: pngcrush - Optimizer for PNG
	(Portable Network Graphics) files
In-Reply-To: <870180fe0812120829g45bb5bbcv9cb3235eb756d8f9@mail.gmail.com>
References: <bug-467179-150697@bugzilla.redhat.com>
	<200812121204.mBCC42J3010047@bz-web2.app.phx.redhat.com>
	<870180fe0812120829g45bb5bbcv9cb3235eb756d8f9@mail.gmail.com>
Message-ID: <ufazlj19wtm.fsf@epithumia.math.uh.edu>

>>>>> "JJ" == Jerry James <loganjerry at gmail.com> writes:

JJ> Why did the Fedora Update System post information about an
JJ> irqbalance update to a review bug for pngcrush?

Because someone made an error when entering a bug number.

 - J<



From chris.stone at gmail.com  Fri Dec 12 16:38:02 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Fri, 12 Dec 2008 08:38:02 -0800
Subject: Updates QA/karma question
In-Reply-To: <4942906F.6080603@cora.nwra.com>
References: <4942906F.6080603@cora.nwra.com>
Message-ID: <d9c612bf0812120838u6e96ac92o568cca4b2506a026@mail.gmail.com>

On Fri, Dec 12, 2008 at 8:25 AM, Orion Poplawski <orion at cora.nwra.com> wrote:
> - Is there any requirement that an update have positive karma before being
> pushed to stable?

I hope not, nobody every karmas my updates :/



From orion at cora.nwra.com  Fri Dec 12 16:39:57 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 12 Dec 2008 09:39:57 -0700
Subject: Updates QA/karma question
In-Reply-To: <d9c612bf0812120838u6e96ac92o568cca4b2506a026@mail.gmail.com>
References: <4942906F.6080603@cora.nwra.com>
	<d9c612bf0812120838u6e96ac92o568cca4b2506a026@mail.gmail.com>
Message-ID: <494293DD.5090906@cora.nwra.com>

Christopher Stone wrote:
> On Fri, Dec 12, 2008 at 8:25 AM, Orion Poplawski <orion at cora.nwra.com> wrote:
>> - Is there any requirement that an update have positive karma before being
>> pushed to stable?
> 
> I hope not, nobody every karmas my updates :/
> 

I guess I meant non-negative...


-- 
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 hughsient at gmail.com  Fri Dec 12 16:39:42 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 12 Dec 2008 16:39:42 +0000
Subject: Making updates-testing more useful
In-Reply-To: <494291B9.9070907@leemhuis.info>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1228933404.2682.7.camel@scrappy.miketc.net>
	<1229017332.15913.3.camel@hughsie-work.lan>
	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
	<1229075701.3450.8.camel@hughsie-work.lan>
	<494291B9.9070907@leemhuis.info>
Message-ID: <1229099982.3450.46.camel@hughsie-work.lan>

On Fri, 2008-12-12 at 17:30 +0100, Thorsten Leemhuis wrote:
> On 12.12.2008 10:55, Richard Hughes wrote:
> > On Fri, 2008-12-12 at 07:06 +0100, Thorsten Leemhuis wrote:
> >> On 11.12.2008 19:28, Richard Hughes wrote:
> >>> Yes, we can easily enable the testing repos with a small button and a
> >>> more info link. The real question is, will this clutter the UI and
> >>> confuse new users?
> >> Another good question (related to the "will this confuse new users" 
> >> part): Will you enable the updates-testing repos from 3rd party repos in 
> >> the same step automatically?
> > 
> > Yes.
> 
> Great!
> 
> > If the user has fedora and rpmfusion enabled, but livna disabled,
> 
> Just to me sure: I assume you meant both rpmfusion repos (free and 
> nonfree) when you wrote "rpmfusion"?

Whichever you have enabled. It's just a repo ID to PK.

> > it'll do in the first pass:
> > 
> > updates from all configured and enabled sources
> > 
> > and on the second pass:
> > 
> > disable fedora and rpmfusion
> 
> Disable? Why disable any repos? What is a package from one of the 
> testing repos introduces a new dep that is only solved by a package in 
> fedora (stock repos) or fedora-updates?

Else you report some updates twice.

> > enable fedora-testing and rpmfusion-testing
> > updates from all configured and enabled sources
> > enable fedora and rpmfusion
> > disable fedora-testing and rpmfusion-testing
> > 
> > If you've got livna installed then it shouldn't touch the repo.
> 
> The new livna repo (that users get that install the current release 
> package from the rlo front page) afaics has no testing area anymore, so 
> it afaics should not matter at all and not get touched (like you said)

Right.

> > The
> > tricky bit is the heuristic that matches up rpmfusion-testing to
> > rpmfusion.
> 
> Maybe all that is needed it to enable all "*-testing" repos. Then it 
> would work even for other repos as well. But maybe that's to dangerous.

I think some people might get upset by that.

> >> But well, likely it doesn't matter to much anyway, as yum is still 
> >> pretty broken in such situations anyway, as mirror lags will confuse it:
> >> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
> > We can't do much about mirror lags, but we do switch on --skip-broken by
> > default which sort of mitigates things.
> 
> I'm not really sure of "skip-broken" in its current form really is the 
> best way to solve it, but maybe it's "good enough". Another subthread in 
> this discussion hopefully gets to a result.

Right.

Richard.




From orcanbahri at yahoo.com  Fri Dec 12 16:41:13 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Fri, 12 Dec 2008 08:41:13 -0800 (PST)
Subject: Fwd: [Bug 467179] Review Request: pngcrush - Optimizer for PNG
	(Portable Network Graphics) files
In-Reply-To: <870180fe0812120829g45bb5bbcv9cb3235eb756d8f9@mail.gmail.com>
Message-ID: <601699.59720.qm@web32801.mail.mud.yahoo.com>

--- On Fri, 12/12/08, Jerry James wrote:
> Why did the Fedora Update System post information about an
> irqbalance
> update to a review bug for pngcrush?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=467179
> 
Wrong number. I guess it had to be
https://bugzilla.redhat.com/show_bug.cgi?id=476179

see:
https://admin.fedoraproject.org/updates/irqbalance-0.55-12.fc10

-oget


      



From jspaleta at gmail.com  Fri Dec 12 16:43:02 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 12 Dec 2008 07:43:02 -0900
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<1229020080.26965.0.camel@hughsie-work.lan>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
	<alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>
Message-ID: <604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>

On Fri, Dec 12, 2008 at 6:55 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> In general skip-broken is probably going to need to be the default for these
> multi-repo situations. I don't LOVE it but if we tie this info into the
> updateinfo.xml so we can properly notify the user if a security or important
> update cannot be applied b/c of a broken dependency, then I will feel better
> about it.

Yes, having skip-broken notify users of the problems its going to skip
over, and not silently skip would make me feel better. There will be a
vocal minority who will still report some of that breakage.

And since I'm asking for ponies, if there was an mechanism to drive
broken dep information back to the affected repositories via an email
or bugzilla drop that would also help me feel better.

The absolute worst thing we can do is to just silently ignore by default.

-jef



From ville.skytta at iki.fi  Fri Dec 12 16:47:12 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Fri, 12 Dec 2008 18:47:12 +0200
Subject: Packaging dtds
In-Reply-To: <200812120035.18974.opensource@till.name>
References: <200812120035.18974.opensource@till.name>
Message-ID: <200812121847.12890.ville.skytta@iki.fi>

On Friday 12 December 2008, Till Maas wrote:

> If this is good, I will suggest to include this in the Guidelines or add it
> somewhere else in the wiki. Or is there already some guidance that I did
> not find?

Unless you already have, I suggest taking a look at the xhtml1-dtds package; 
quite a bit of work has went to it (as well as html401-dtds) to get things 
right.  See also discussion in bugs 181068 and 226559.



From jkeating at redhat.com  Fri Dec 12 16:52:03 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 08:52:03 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081212122953.GB19974@zod.rchland.ibm.com>
References: <1228975029.17968.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102204h7731e72ds8ed38965b62939b0@mail.gmail.com>
	<1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
Message-ID: <1229100723.3863.137.camel@localhost.localdomain>

On Fri, 2008-12-12 at 07:29 -0500, Josh Boyer wrote:
> Maybe an example of an update you consider irresponsible?

Lets pick up some mysteries:

https://admin.fedoraproject.org/updates/F8/FEDORA-2008-10242

homebank-3.8-1.fc8 -> homebank-4.0-1.fc8

Nothing listed in the bodhi update to give users any indication as to
what the update brings, no bugfix information, no new feature
information to verify functionality.  Not even rpm changelog.  (although
in this case, the rpm changelog is "- 4.0".  How are users supposed to
consume this and provide appropriate feedback?  Why was a major version
bump necessary at this very late stage of Fedora 8's lifespan?

https://admin.fedoraproject.org/updates/F8/FEDORA-2008-9959

texmaker-1.7.1-1.fc8 -> texmaker-1.8-1.fc8

Only details in bodhi is "New upstream release".  Only rpm changelog is
"- New Release"  This appears to have been spammed from F8+ all at the
same time.  Same story as above.  As with above, 0 feedback in bodhi and
a relatively short period in updates-testing before the maintainer
pushed it on over to -stable.


https://admin.fedoraproject.org/updates/F8/FEDORA-2008-10246

More of the same.  No bodhi information, no changelog information beyond
"version upgrade", a single day between the update hitting -testing and
the maintainer requesting it go -stable.  0 feedback in bodhi.  Again
spammed across the release board.  Why?


I could go on and on with these mysteries, which could be sane updates,
but who knows!?  Certainly not the consumer.

For more dangerous updates I'd have to start prowling forum histories
and the like to find updates that were pushed that caused real problems.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/fe5de99d/attachment.sig>

From chris.stone at gmail.com  Fri Dec 12 16:48:38 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Fri, 12 Dec 2008 08:48:38 -0800
Subject: Making updates-testing more useful
In-Reply-To: <604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
	<alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>
	<604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>
Message-ID: <d9c612bf0812120848v7c9868dan9db58fa43f0e3650@mail.gmail.com>

On Fri, Dec 12, 2008 at 8:43 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Fri, Dec 12, 2008 at 6:55 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>> In general skip-broken is probably going to need to be the default for these
> Yes, having skip-broken notify users of the problems its going to skip
> over, and not silently skip would make me feel better. There will be a

--skip-broken is borked, I used it the other day with the PackageKit
problems, and skip-broken tried to pull in a bunch of .i386 deps (I
don't have any .i386 rpms installed on my system).  It did manage to
skip the broken rpms, but it also tried to pull in a bunch of .i386
rpms as well which is obviously wrong.



From skvidal at fedoraproject.org  Fri Dec 12 16:56:50 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 11:56:50 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <d9c612bf0812120848v7c9868dan9db58fa43f0e3650@mail.gmail.com>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
	<alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>
	<604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>
	<d9c612bf0812120848v7c9868dan9db58fa43f0e3650@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812121156160.19488@localhost.localdomain>



On Fri, 12 Dec 2008, Christopher Stone wrote:

> On Fri, Dec 12, 2008 at 8:43 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:
>> On Fri, Dec 12, 2008 at 6:55 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>>> In general skip-broken is probably going to need to be the default for these
>> Yes, having skip-broken notify users of the problems its going to skip
>> over, and not silently skip would make me feel better. There will be a
>
> --skip-broken is borked, I used it the other day with the PackageKit
> problems, and skip-broken tried to pull in a bunch of .i386 deps (I
> don't have any .i386 rpms installed on my system).  It did manage to
> skip the broken rpms, but it also tried to pull in a bunch of .i386
> rpms as well which is obviously wrong.
>

I bet it is not wrong. the i386 packages probably provide what was 
required. They just provide it sub-optimally.

-sv



From lesmikesell at gmail.com  Fri Dec 12 16:59:42 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Dec 2008 10:59:42 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812120815y30ba063ci5fee6cff9482fa10@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>	<ghqc4j$brb$11@ger.gmane.org>
	<4940B92A.1030403@gmail.com>	<ghqg1t$pnm$2@ger.gmane.org>	<1229014165.3863.79.camel@localhost.localdomain>	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>	<20081211220650.e89782d5.mschwendt@gmail.com>	<ghsikm$gpk$4@ger.gmane.org>	<20081212114203.b912da4c.mschwendt@gmail.com>
	<16de708d0812120815y30ba063ci5fee6cff9482fa10@mail.gmail.com>
Message-ID: <4942987E.1050502@gmail.com>

Arthur Pemberton wrote:
>>> We would be using Ubuntu
>>> or CentOS or any of the other bazillion conservative distros otherwise.
>>> A distro with a 6-month release cycle, but conservative updates, already
>>> exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
>>> go use Ubuntu.
>> CentOS is not only "conservative", as a copy of RHEL and completely
>> different release cycle it doesn't offer any release that is close to
>> Fedora 8/9/10. Colin has mentioned (essential) differences between Ubuntu
>> and Fedora. There are more. Ubuntu won't become equal to Fedora if it
>> increased its updates frequency.
> 
> 
> We will have to agree to disagree on this as I found none of the
> reasons he gave substantive.

Does that mean 'your' reasons for not waiting a week longer are 
substantive, but other people's reasons for wanting something between 
that and the two year's delay you get with Centos are not?  I'd consider 
both not wanting your machine to break regularly and not wanting to wait 
two years for a new feature to be substantive.

 > I'll wait to see what looks like may be a
> new pace of releases play out. I will say that I find the tone of the
> proposed changes to be overly conservative and overall unfortunate.
> But if that's what the majority wishes, so be it.

I still believe that with some minor changes you could please everyone, 
including people who want a different pace on different machines.  You 
just need a fast-track, slow-track scheme for installing updates and 
some cutoff (say 3 months in) for feature-change updates to a release.

It doesn't matter if the fast/slow update tracking is done by 
manipulating different repos (perhaps some changes to updates-testing or 
adding another similar layer) or some clever tricks in yum, as long as 
there is a way to push emergency fixes ahead to bypass any breakage 
noticed at the fast-track level.  That way, testing/development machines 
and people who want to live on the edge still proceed as normal, and for 
machines when you need to control the risk you would upgrade 3 months 
after release and configure the slow-track updates (exact time to be 
determined by observing your test machine).  With such a scheme in 
place, the only extra human work would be deciding when and how to do 
the emergency fixes, but that only comes into play when something 
breaks.  Worst-case, you just stop updates on the conservative machines 
until the test machine shows the fix is done and time has elapsed to 
move it to the slow-track.

-- 
    Les Mikesell
     lesmikesell at gmail.com





From jkeating at redhat.com  Fri Dec 12 17:01:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 09:01:12 -0800
Subject: Updates QA/karma question
In-Reply-To: <4942906F.6080603@cora.nwra.com>
References: <4942906F.6080603@cora.nwra.com>
Message-ID: <1229101272.3863.139.camel@localhost.localdomain>

On Fri, 2008-12-12 at 09:25 -0700, Orion Poplawski wrote:
> 
> - Does anyone actually read the comments in bodhi before allowing the 
> push request to proceed?

When a 24 hour period generates over 150 changes in bodhi, I don't
really have the time to read through each and every one to ensure that
the maintainer is doing the right thing.

Besides, I thought all Fedora maintainers were geniuses and my
bureaucracy just gets in the way? 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/d944b4e8/attachment.sig>

From rdieter at math.unl.edu  Fri Dec 12 16:47:52 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 12 Dec 2008 10:47:52 -0600
Subject: Updates QA/karma question
References: <4942906F.6080603@cora.nwra.com>
Message-ID: <ghu4jo$sr0$1@ger.gmane.org>

Orion Poplawski wrote:

> Another update issue that raises some questions -
> 
> - Does anyone actually read the comments in bodhi before allowing the
> push request to proceed?

It's all up to the individual pkg maintainer to "do the right thing, in
their best judgment".  Same pretty much applies to all your questions
here. :)

-- Rex



From jkeating at redhat.com  Fri Dec 12 17:17:05 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 09:17:05 -0800
Subject: Updates QA/karma question
In-Reply-To: <ghu4jo$sr0$1@ger.gmane.org>
References: <4942906F.6080603@cora.nwra.com>  <ghu4jo$sr0$1@ger.gmane.org>
Message-ID: <1229102225.3863.144.camel@localhost.localdomain>

On Fri, 2008-12-12 at 10:47 -0600, Rex Dieter wrote:
> Orion Poplawski wrote:
> 
> > Another update issue that raises some questions -
> > 
> > - Does anyone actually read the comments in bodhi before allowing the
> > push request to proceed?
> 
> It's all up to the individual pkg maintainer to "do the right thing, in
> their best judgment".  Same pretty much applies to all your questions
> here. :)
> 
> -- Rex

It is also up to the pkg maintainer's sponsor to ensure that the people
one has sponsored are doing the right thing.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/90d2b608/attachment.sig>

From jarod at redhat.com  Fri Dec 12 17:23:07 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Fri, 12 Dec 2008 12:23:07 -0500
Subject: cpufreq module on x86_64
In-Reply-To: <870180fe0812091321h24f95edcwb55576a4bfb33462@mail.gmail.com>
References: <870180fe0812050947v435a7807y9dbb15d40eeb70f@mail.gmail.com>
	<20081205182915.GA28483@srcf.ucam.org>
	<870180fe0812091321h24f95edcwb55576a4bfb33462@mail.gmail.com>
Message-ID: <200812121223.07447.jarod@redhat.com>

On Tuesday 09 December 2008 16:21:19 Jerry James wrote:
> On Fri, Dec 5, 2008 at 11:29 AM, Matthew Garrett <mjg at redhat.com> wrote:
> > I suspect what's happening is that acpi-cpufreq is loading and failing
> > to bind, and then p4-clockmod gets loaded, fails to bind and the module
> > load is aborted.
> 
> Thanks to everyone who responded with reasons why I want a cpufreq
> module loaded.  Matthew, you are absolutely correct.  I rebooted with
> cpufreq.debug=7 on the boot line and got this in the logs:
> 
> acpi-cpufreq: acpi_cpufreq_init
> acpi-cpufreq: acpi_cpufreq_early_init
> cpufreq-core: trying to register driver acpi-cpufreq
> cpufreq-core: adding CPU 0
> acpi-cpufreq: acpi_cpufreq_cpu_init
> cpufreq-core: initialization failed
> cpufreq-core: adding CPU 1
> acpi-cpufreq: acpi_cpufreq_cpu_init
> cpufreq-core: initialization failed
> cpufreq-core: adding CPU 2
> acpi-cpufreq: acpi_cpufreq_cpu_init
> cpufreq-core: initialization failed
> cpufreq-core: adding CPU 3
> acpi-cpufreq: acpi_cpufreq_cpu_init
> cpufreq-core: initialization failed
> cpufreq-core: no CPU initialized for driver acpi-cpufreq
> cpufreq-core: unregistering CPU 0
> cpufreq-core: unregistering CPU 1
> cpufreq-core: unregistering CPU 2
> cpufreq-core: unregistering CPU 3
> cpufreq-core: trying to register driver p4-clockmod
> cpufreq-core: adding CPU 0
> [snip the rest; I posted it before]
> 
> So the "initialization failed" line tells me that this line:
> 
>   ret = cpufreq_driver->init(policy)
> 
> in cpufreq_add_dev() in drivers/cpufreq/cpufreq.c is where things are
> going wrong.  Is there any way to tell what is going wrong here?  Is
> this likely to be a BIOS bug?  (I just flashed my BIOS to fix 3D
> graphics; it wouldn't surprise me if my vendor managed to mess this up
> at the same time.)

Yeah, I'd wager its one of two things. Either the vendor screwed something
up w/the acpi tables in this update, or the update also flipped the bios
option for frequency scaling off for some reason. First order of business
would be to poke around in your bios, looking for something having to do
with power savings, EIST, processor scaling, etc. (its called many
different things by different bioses, of course)

-- 
Jarod Wilson
jarod at redhat.com



From jspaleta at gmail.com  Fri Dec 12 17:17:31 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 12 Dec 2008 08:17:31 -0900
Subject: Updates QA/karma question
In-Reply-To: <1229101272.3863.139.camel@localhost.localdomain>
References: <4942906F.6080603@cora.nwra.com>
	<1229101272.3863.139.camel@localhost.localdomain>
Message-ID: <604aa7910812120917w45555f17r4ed063e3d187ffdc@mail.gmail.com>

2008/12/12 Jesse Keating <jkeating at redhat.com>:
> Besides, I thought all Fedora maintainers were geniuses and my
> bureaucracy just gets in the way?

I just want to point out that during my life as a genius, I've seen
multiple geniuses have their lives literally saved by the bureaucracy
of lab and industrial safety procedures. I've also seen a few of them
almost die because bureaucracy wasn't in place and they were not
required to stop for a second and think ahead about consequences.

And we will bitch and moan about the absolute stupidity of those
policies, until our buddy in the lab next door decides to disable the
safety interlocks on his laser, and then we walk into the room and the
laser doesn't turn off on door entry..like it did the day before.
Those are the sort of moments were safety policies become cherished..
even if the bureaucrats never are.


-jef"Sure turning your eyeball into a snowglobe that you look through
because you forgot to wear your safety goggles when you were in the
room while the high power infrared laser was on sound like fun...
until it happens to you"spaleta



From jwboyer at gmail.com  Fri Dec 12 17:18:26 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 12 Dec 2008 12:18:26 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229100723.3863.137.camel@localhost.localdomain>
References: <1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
	<1229100723.3863.137.camel@localhost.localdomain>
Message-ID: <20081212171825.GA12450@zod.rchland.ibm.com>

On Fri, Dec 12, 2008 at 08:52:03AM -0800, Jesse Keating wrote:
>On Fri, 2008-12-12 at 07:29 -0500, Josh Boyer wrote:
>> Maybe an example of an update you consider irresponsible?
>
>Lets pick up some mysteries:
>
>https://admin.fedoraproject.org/updates/F8/FEDORA-2008-10242
>
>homebank-3.8-1.fc8 -> homebank-4.0-1.fc8
>
>Nothing listed in the bodhi update to give users any indication as to
>what the update brings, no bugfix information, no new feature
>information to verify functionality.  Not even rpm changelog.  (although
>in this case, the rpm changelog is "- 4.0".  How are users supposed to
>consume this and provide appropriate feedback?  Why was a major version
>bump necessary at this very late stage of Fedora 8's lifespan?
>
>https://admin.fedoraproject.org/updates/F8/FEDORA-2008-9959
>
>texmaker-1.7.1-1.fc8 -> texmaker-1.8-1.fc8
>
>Only details in bodhi is "New upstream release".  Only rpm changelog is
>"- New Release"  This appears to have been spammed from F8+ all at the
>same time.  Same story as above.  As with above, 0 feedback in bodhi and
>a relatively short period in updates-testing before the maintainer
>pushed it on over to -stable.
>
>
>https://admin.fedoraproject.org/updates/F8/FEDORA-2008-10246
>
>More of the same.  No bodhi information, no changelog information beyond
>"version upgrade", a single day between the update hitting -testing and
>the maintainer requesting it go -stable.  0 feedback in bodhi.  Again
>spammed across the release board.  Why?
>
>
>I could go on and on with these mysteries, which could be sane updates,
>but who knows!?  Certainly not the consumer.

OK, "we need to provide better information as to what updates are doing
and why users should be updating".  Check.

Now, it might be a bit unfair to be asking you specifically so this is
an open question in general, but are there examples of major version
updates that _were_ descriptive that anyone thinks are a major problem?

I'm trying to figure out if we have a rampant "just shove the latest
upstream into all branches" problem, or if we have a lack of information
problem, or a bit of both.  I think trying to quantify the actual problem,
if there is one, is the only way we're going to know how to address
anything going forward.

josh



From paul at city-fan.org  Fri Dec 12 17:20:04 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 12 Dec 2008 17:20:04 +0000
Subject: Making updates-testing more useful
In-Reply-To: <alpine.LFD.2.00.0812121156160.19488@localhost.localdomain>
References: <1228930549.3648.14.camel@localhost.localdomain>	<4941FF83.7090404@leemhuis.info>	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>	<alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>	<604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>	<d9c612bf0812120848v7c9868dan9db58fa43f0e3650@mail.gmail.com>
	<alpine.LFD.2.00.0812121156160.19488@localhost.localdomain>
Message-ID: <49429D44.8040507@city-fan.org>

Seth Vidal wrote:
> 
> 
> On Fri, 12 Dec 2008, Christopher Stone wrote:
> 
>> On Fri, Dec 12, 2008 at 8:43 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:
>>> On Fri, Dec 12, 2008 at 6:55 AM, Seth Vidal 
>>> <skvidal at fedoraproject.org> wrote:
>>>> In general skip-broken is probably going to need to be the default 
>>>> for these
>>> Yes, having skip-broken notify users of the problems its going to skip
>>> over, and not silently skip would make me feel better. There will be a
>>
>> --skip-broken is borked, I used it the other day with the PackageKit
>> problems, and skip-broken tried to pull in a bunch of .i386 deps (I
>> don't have any .i386 rpms installed on my system).  It did manage to
>> skip the broken rpms, but it also tried to pull in a bunch of .i386
>> rpms as well which is obviously wrong.
>>
> 
> I bet it is not wrong. the i386 packages probably provide what was 
> required. They just provide it sub-optimally.

I get this quite a bit (and I don't use skip-broken), as I keep a local 
mirror of updates for packages that are on the DVD (my quick heuristic 
for the most common ones) and let the rest get pulled from the Internet. 
I update my local mirror when I see the package announcements on 
fedora-package-announce, so it's usually updated before many of the 
other mirrors.

The problem happens when I have two packages installed that have a 
versioned dependency relationship and where one can be found on my local 
mirror and the other needs to be pulled from the Internet, and the 
package that is "required" is multilib.

Suppose B is a subpackage of A,
with B requiring A = %{version}-%{release}, A being on the release media 
and B not being. So when A is updated, I see the update of A first.
When I do a "yum update", and updated version of A is available but no 
update to B is visible. My installed version of B needs the installed 
version of A, but A is about to be upgraded. This would normally cause a 
dependency issue and fail, but if A is multilib, the dependency can be 
satisfied by installing the original version of A.i386 in parallel with 
the new version of A.x86_64. This then pulls in all of the i386 deps of 
A. I tend to work around this by adding B to the list of packages I 
mirror locally when I see this sort of problem.

Whilst my arrangement is unusual and makes me more prone to seeing this 
sort of problem, there are other scenarios in which it could happen, 
e.g. where there are versioned cross-repo dependencies.

Paul.



From katzj at redhat.com  Fri Dec 12 17:26:52 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 12 Dec 2008 12:26:52 -0500
Subject: Installing from Live CD is the new black?
In-Reply-To: <200812121726.02875.opensource@till.name>
References: <1228955078.3037.10.camel@fecusia> <ghtslo$9d$1@ger.gmane.org>
	<16de708d0812120809j59b80695j9d2b2b80fe1d6def@mail.gmail.com>
	<200812121726.02875.opensource@till.name>
Message-ID: <CCF9A6FF-5A3A-4670-8E4E-898BD267B350@redhat.com>

On Dec 12, 2008, at 11:25 AM, Till Maas wrote:
> On Fri December 12 2008, Arthur Pemberton wrote:
>> On Fri, Dec 12, 2008 at 8:32 AM, Kevin Kofler  
>> <kevin.kofler at chello.at>
> wrote:
>>> Christof Damian wrote:
>>>> One of my wishes for a future Fedora is also an easy way to install
>>>> from USB stick. I prefer to use the normal install instead of the
>>>> livecd/stick and currently you have to burn a CD / DVD to make this
>>>> work.
>>>
>>> https://fedorahosted.org/liveusb-creator/
>>
>> He did say _from_ USB stick. Is the install to hard drive feature
>> preserved after you liveinstall to USB?
>
> Yes, but he also said that he wants to install the contents of the  
> regular DVD
> from USB, which became a little more trickier with F10.

It's not that tricky.  You just have to copy a file from images/ in  
addition to the iso and the bootloader bits

Jeremy



From kevin.kofler at chello.at  Fri Dec 12 17:27:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 18:27:55 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>	<ghqc4j$brb$11@ger.gmane.org>
	<4940B92A.1030403@gmail.com>	<ghqg1t$pnm$2@ger.gmane.org>	<1229014165.3863.79.camel@localhost.localdomain>	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>	<20081211220650.e89782d5.mschwendt@gmail.com>	<ghsikm$gpk$4@ger.gmane.org>	<20081212114203.b912da4c.mschwendt@gmail.com>
	<16de708d0812120815y30ba063ci5fee6cff9482fa10@mail.gmail.com>
	<4942987E.1050502@gmail.com>
Message-ID: <ghu6us$6a7$1@ger.gmane.org>

Les Mikesell wrote:
> I still believe that with some minor changes you could please everyone,
> including people who want a different pace on different machines.  You
> just need a fast-track, slow-track scheme for installing updates

More update tracks = more maintainership work, more possible combinations of
packages (thus less testing), so not very likely to happen and may well be
counterproductive (untested combinations of updates can cause problems).

> and some cutoff (say 3 months in) for feature-change updates to a release.

That would definitely not "please everyone". I don't want such a cutoff, and
if it really has to be introduced at some point, I'd be really unhappy with
anything less than 7-9 months in (giving me a 1-3 month old next release to
upgrade to to get my new features). And I'm sure there are more people like
me (just read e.g. Arthur Pemberton's comments, and it can't just be us 2
either).

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 12 17:30:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 18:30:47 +0100
Subject: Making updates-testing more useful
References: <1228930549.3648.14.camel@localhost.localdomain>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
	<alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>
	<604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>
	<d9c612bf0812120848v7c9868dan9db58fa43f0e3650@mail.gmail.com>
	<alpine.LFD.2.00.0812121156160.19488@localhost.localdomain>
Message-ID: <ghu747$6a7$2@ger.gmane.org>

Seth Vidal wrote:
> I bet it is not wrong. the i386 packages probably provide what was
> required. They just provide it sub-optimally.

But that's really the problem: yum (*) thinks



From jspaleta at gmail.com  Fri Dec 12 17:23:23 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 12 Dec 2008 08:23:23 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081212171825.GA12450@zod.rchland.ibm.com>
References: <1228976362.18544.TMDA@tmda.severn.wwwdotorg.org>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
	<1229100723.3863.137.camel@localhost.localdomain>
	<20081212171825.GA12450@zod.rchland.ibm.com>
Message-ID: <604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>

On Fri, Dec 12, 2008 at 8:18 AM, Josh Boyer <jwboyer at gmail.com> wrote:
> I'm trying to figure out if we have a rampant "just shove the latest
> upstream into all branches" problem, or if we have a lack of information
> problem, or a bit of both.  I think trying to quantify the actual problem,
> if there is one, is the only way we're going to know how to address
> anything going forward.

This will require some sort of systematic review of bugs filed about
updates during a release cycle or two.

-jef



From kevin.kofler at chello.at  Fri Dec 12 17:35:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 18:35:02 +0100
Subject: Making updates-testing more useful
References: <1228930549.3648.14.camel@localhost.localdomain>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
	<alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>
	<604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>
	<d9c612bf0812120848v7c9868dan9db58fa43f0e3650@mail.gmail.com>
	<alpine.LFD.2.00.0812121156160.19488@localhost.localdomain>
Message-ID: <ghu7cm$6a7$3@ger.gmane.org>

Seth Vidal wrote:
> I bet it is not wrong. the i386 packages probably provide what was
> required. They just provide it sub-optimally.

But that's really the problem: yum (*) tries to resolve conflicting
requirements (of the A requires C = 1.2.3 and B requires C = 2.3.4 type) by
installing C.x86_64 = 2.3.4 and C.i386 = 1.2.3. This obviously can't work
(it will in almost all cases lead to file conflicts, and it is almost
certainly not what the user wants). I think there needs to be some
restriction that C.x86_64 and C.i386 need to be of the same EVR.

(*) (and other depsolvers too, I've seen apt-rpm do it too, but let's focus
on yum here)

(And sorry for the previous incomplete message, I accidentally hit
Ctrl+Enter and KNode sends the message immediately if I hit that.)

        Kevin Kofler



From jwboyer at gmail.com  Fri Dec 12 17:42:41 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 12 Dec 2008 12:42:41 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>
References: <ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
	<1229100723.3863.137.camel@localhost.localdomain>
	<20081212171825.GA12450@zod.rchland.ibm.com>
	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>
Message-ID: <20081212174241.GB12450@zod.rchland.ibm.com>

On Fri, Dec 12, 2008 at 08:23:23AM -0900, Jeff Spaleta wrote:
>On Fri, Dec 12, 2008 at 8:18 AM, Josh Boyer <jwboyer at gmail.com> wrote:
>> I'm trying to figure out if we have a rampant "just shove the latest
>> upstream into all branches" problem, or if we have a lack of information
>> problem, or a bit of both.  I think trying to quantify the actual problem,
>> if there is one, is the only way we're going to know how to address
>> anything going forward.
>
>This will require some sort of systematic review of bugs filed about
>updates during a release cycle or two.

>From a quality standpoint, yes.

>From a "oh my $deity, we are shoving more updates into stable branches
than we are in rawhide!" (hyperbole, maybe) standpoint, well not so much.
I was more looking at this angle.  If people are doing updates just
because they are there and they don't really provide the end-users anything
more than a shiny new package, then that would appear to be wasted
resources.  The problem with catching those cases is that there may be
no bugs filed at all because things are still working fine.  But they might
have been working just fine before the update too.

Tricky, methinks.

josh



From lesmikesell at gmail.com  Fri Dec 12 17:43:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Dec 2008 11:43:02 -0600
Subject: Making updates-testing more useful
In-Reply-To: <49428DF1.4080908@leemhuis.info>
References: <1228930549.3648.14.camel@localhost.localdomain>	<1228933404.2682.7.camel@scrappy.miketc.net>	<1229017332.15913.3.camel@hughsie-work.lan>	<604aa7910812110952w24141618o5471a42aa35ad423@mail.gmail.com>	<1229020080.26965.0.camel@hughsie-work.lan>	<4941FF83.7090404@leemhuis.info>	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<49428DF1.4080908@leemhuis.info>
Message-ID: <4942A2A6.4010608@gmail.com>

Thorsten Leemhuis wrote:
> >
>>> But well, likely it doesn't matter to much anyway, as yum is still 
>>> pretty broken in such situations anyway, as mirror lags will confuse it:
>>> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html 
>>>
>>
>> Yes, that's right yum is broken b/c the mirrors are out of sync.
>  >
>> Just like Apache is broken when a 404 is issued. It must be apache's 
>> fault that the data is missing or broken.
> 
> I don't think the Apache example really flies, but whatever, not worth 
> arguing. I just want the problem fixed :-)

You have to know what is broken before you can fix it.  One case is like 
a farm of apache servers where you pull a page during a site update and 
get a link to a target not updated yet.  The fix there is to wait a 
second.  Another is that you have cross-site references where one site 
changes a reference used by another.  If that is planned, it may again 
be a matter of waiting some indeterminate length of time for a natural 
resolution.  But, from the consuming end you really have no idea whether 
the breakage is temporary and will resolve on its own schedule or if it 
is accidental breakage that will continue until someone reports and 
fixes it.

> It depends a bit for what they use it -- sometimes it's Fedora that is 
> "broken", sometimes RPM Fusion/Livna, sometimes yum or sometimes 
> PackageKit. We all don't want that afaics; it's really bad for Fedoras 
> reputation.
> 
> So we should try to get it fixed; yum *afaics* is the best place, as the 
> data is there in the repos (at least if RPM Fusion pushes all the bits 
> at the same time; that works often, but now always), yum just has to 
> look at the right places *or* ignore those problems for some time *or* 
> <your suggestion here>.

Yum might ignore updates with very recent timestamps and failed 
dependencies (if it knows anything about timestamps...).  But I don't 
think it knows much about which repo is supposed to be supplying a 
dependency for the cross site stuff (a separate problem IMHO).   How is 
it it supposed to determine the cases that won't get fixed without 
notification and intervention?

-- 
    Les Mikesell
     lesmikesell at gmail.com



From kevin.kofler at chello.at  Fri Dec 12 17:48:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Dec 2008 18:48:46 +0100
Subject: Updates QA/karma question
References: <4942906F.6080603@cora.nwra.com>
Message-ID: <ghu85u$al0$1@ger.gmane.org>

Orion Poplawski wrote:
> - Does anyone actually read the comments in bodhi before allowing the
> push request to proceed?

The maintainer is supposed to read them, but if he already mistakenly
requested the push, he might not be able to cancel it in time. "Push to
stable" is a bit of a "big red button" you have to be careful with pushing.
There's no way rel-eng can notice all such comments, the manpower is simply
not there. (It would also need to be coordinated so the proofreaders screen
the updates right before Jesse Keating starts the push process. I don't
think this is going to happen any time soon.)

        Kevin Kofler



From jamundso at gmail.com  Fri Dec 12 17:53:40 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 12 Dec 2008 11:53:40 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081212174241.GB12450@zod.rchland.ibm.com>
References: <ghqc4j$brb$11@ger.gmane.org> <ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
	<1229100723.3863.137.camel@localhost.localdomain>
	<20081212171825.GA12450@zod.rchland.ibm.com>
	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>
	<20081212174241.GB12450@zod.rchland.ibm.com>
Message-ID: <6d06ce20812120953m4c69831bwa0d6a4f401d0f110@mail.gmail.com>

On Fri, Dec 12, 2008 at 11:42 AM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Fri, Dec 12, 2008 at 08:23:23AM -0900, Jeff Spaleta wrote:
>>On Fri, Dec 12, 2008 at 8:18 AM, Josh Boyer <jwboyer at gmail.com> wrote:
>>> I'm trying to figure out if we have a rampant "just shove the latest
>>> upstream into all branches" problem, or if we have a lack of information
>>> problem, or a bit of both.  I think trying to quantify the actual problem,
>>> if there is one, is the only way we're going to know how to address
>>> anything going forward.
>>
>>This will require some sort of systematic review of bugs filed about
>>updates during a release cycle or two.
>
> >From a quality standpoint, yes.
>
> >From a "oh my $deity, we are shoving more updates into stable branches
> than we are in rawhide!" (hyperbole, maybe) standpoint, well not so much.
> I was more looking at this angle.  If people are doing updates just
> because they are there and they don't really provide the end-users anything
> more than a shiny new package, then that would appear to be wasted
> resources.  The problem with catching those cases is that there may be
> no bugs filed at all because things are still working fine.  But they might
> have been working just fine before the update too.
>
> Tricky, methinks.

Me too.
What may appear to be superfluous update shiny-1.2.3 -> shiny-2.0.0,
might also be the only way to get to *security fix* shiny-2.0.1 later
on...

jerry

-- 
TBD.



From jspaleta at gmail.com  Fri Dec 12 17:54:45 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 12 Dec 2008 08:54:45 -0900
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081212174241.GB12450@zod.rchland.ibm.com>
References: <ghqc4j$brb$11@ger.gmane.org> <ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
	<1229100723.3863.137.camel@localhost.localdomain>
	<20081212171825.GA12450@zod.rchland.ibm.com>
	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>
	<20081212174241.GB12450@zod.rchland.ibm.com>
Message-ID: <604aa7910812120954i701f2139t81bd5e768e68891b@mail.gmail.com>

On Fri, Dec 12, 2008 at 8:42 AM, Josh Boyer <jwboyer at gmail.com> wrote:
> Tricky, methinks.

I'm also concerned that the conversation is wandering too far away
into the weeds from the problem at hand.  A security tagged update was
pushed directly to stable in error.  Very little of the discussion I'm
seeing here would have prevented the scenario that happened with dbus
this week.

It's nice to discuss the larger issues, but if the ideas being put
forward consistently have an escape hatch which lets security tagged
packages directly into stable.... we haven't reduced the risk of what
has happened this week from happening again.

-jef



From orion at cora.nwra.com  Fri Dec 12 18:15:04 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 12 Dec 2008 11:15:04 -0700
Subject: Updates QA/karma question
In-Reply-To: <1229102225.3863.144.camel@localhost.localdomain>
References: <4942906F.6080603@cora.nwra.com> <ghu4jo$sr0$1@ger.gmane.org>
	<1229102225.3863.144.camel@localhost.localdomain>
Message-ID: <4942AA28.9000101@cora.nwra.com>

Jesse Keating wrote:
> It is also up to the pkg maintainer's sponsor to ensure that the people
> one has sponsored are doing the right thing.
> 

Can you "watch updates" in bodhi for a particular user they way you can 
in bugzilla?

-- 
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 orion at cora.nwra.com  Fri Dec 12 18:18:35 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 12 Dec 2008 11:18:35 -0700
Subject: Updates QA/karma question
In-Reply-To: <1229101272.3863.139.camel@localhost.localdomain>
References: <4942906F.6080603@cora.nwra.com>
	<1229101272.3863.139.camel@localhost.localdomain>
Message-ID: <4942AAFB.1020601@cora.nwra.com>

Jesse Keating wrote:
> On Fri, 2008-12-12 at 09:25 -0700, Orion Poplawski wrote:
>> - Does anyone actually read the comments in bodhi before allowing the 
>> push request to proceed?
> 
> When a 24 hour period generates over 150 changes in bodhi, I don't
> really have the time to read through each and every one to ensure that
> the maintainer is doing the right thing.

True, but at least negative karma ones could be flagged.

> Besides, I thought all Fedora maintainers were geniuses and my
> bureaucracy just gets in the way? 

I'm with you and jef on this one.  There is no way (other than security 
updates and possibly critical bugfixes - do we need a flag for this?) 
that getting an update out the door immediately is more important that 
preserving the stability of the release.

-- 
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  Fri Dec 12 18:25:25 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Dec 2008 12:25:25 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghu6us$6a7$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>	<ghqc4j$brb$11@ger.gmane.org>	<4940B92A.1030403@gmail.com>	<ghqg1t$pnm$2@ger.gmane.org>	<1229014165.3863.79.camel@localhost.localdomain>	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>	<20081211220650.e89782d5.mschwendt@gmail.com>	<ghsikm$gpk$4@ger.gmane.org>	<20081212114203.b912da4c.mschwendt@gmail.com>	<16de708d0812120815y30ba063ci5fee6cff9482fa10@mail.gmail.com>	<4942987E.1050502@gmail.com>
	<ghu6us$6a7$1@ger.gmane.org>
Message-ID: <4942AC95.3060009@gmail.com>

Kevin Kofler wrote:
> 
>> I still believe that with some minor changes you could please everyone,
>> including people who want a different pace on different machines.  You
>> just need a fast-track, slow-track scheme for installing updates
> 
> More update tracks = more maintainership work, more possible combinations of
> packages (thus less testing), so not very likely to happen and may well be
> counterproductive (untested combinations of updates can cause problems).

I don't think you are following what I'm trying to say.  Slow-track and 
fast-track are exactly the same with a delay factor.  If you don't make 
any mistakes with packages entering fast-track, there are no changes and 
no extra work regarding what shows up in slow-track.  If you do make a 
mistake, slow-track gives you a chance to fix it before you destroy all 
your user's critical work and fedora's reputation along with it.  The 
fast-track _is_ the large-scale testing (like you have now, but it would 
be worth something instead of just representing some ephemeral mix of 
changing package never to be seen again...).

>> and some cutoff (say 3 months in) for feature-change updates to a release.
> 
> That would definitely not "please everyone". I don't want such a cutoff, and
> if it really has to be introduced at some point, I'd be really unhappy with
> anything less than 7-9 months in (giving me a 1-3 month old next release to
> upgrade to to get my new features). And I'm sure there are more people like
> me (just read e.g. Arthur Pemberton's comments, and it can't just be us 2
> either).

I picked that off the top of my head.  If you want to push it out to 5 
months or even 6 so the wild and crazy changes can continue without 
pause as the next release starts, fine.  That would still leave 6 months 
where a release is actually usable for work instead of never.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From jkeating at redhat.com  Fri Dec 12 18:26:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 10:26:17 -0800
Subject: Updates QA/karma question
In-Reply-To: <4942AA28.9000101@cora.nwra.com>
References: <4942906F.6080603@cora.nwra.com> <ghu4jo$sr0$1@ger.gmane.org>
	<1229102225.3863.144.camel@localhost.localdomain>
	<4942AA28.9000101@cora.nwra.com>
Message-ID: <1229106377.3863.146.camel@localhost.localdomain>

On Fri, 2008-12-12 at 11:15 -0700, Orion Poplawski wrote:
> Can you "watch updates" in bodhi for a particular user they way you
> can 
> in bugzilla?

I don't think so directly, but there are rss feeds that you could filter
on.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/1c8b18f2/attachment.sig>

From jkeating at redhat.com  Fri Dec 12 18:27:05 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 10:27:05 -0800
Subject: Updates QA/karma question
In-Reply-To: <ghu85u$al0$1@ger.gmane.org>
References: <4942906F.6080603@cora.nwra.com>  <ghu85u$al0$1@ger.gmane.org>
Message-ID: <1229106425.3863.147.camel@localhost.localdomain>

On Fri, 2008-12-12 at 18:48 +0100, Kevin Kofler wrote:
> The maintainer is supposed to read them, but if he already mistakenly
> requested the push, he might not be able to cancel it in time. "Push to
> stable" is a bit of a "big red button" you have to be careful with pushing.
> There's no way rel-eng can notice all such comments, the manpower is simply
> not there. (It would also need to be coordinated so the proofreaders screen
> the updates right before Jesse Keating starts the push process. I don't
> think this is going to happen any time soon.)

A push to stable request can be revoked at any time before I come along
and start the push process.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/a997929f/attachment.sig>

From jkeating at redhat.com  Fri Dec 12 18:28:26 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 10:28:26 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812120954i701f2139t81bd5e768e68891b@mail.gmail.com>
References: <ghqc4j$brb$11@ger.gmane.org> <ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
	<1229100723.3863.137.camel@localhost.localdomain>
	<20081212171825.GA12450@zod.rchland.ibm.com>
	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>
	<20081212174241.GB12450@zod.rchland.ibm.com>
	<604aa7910812120954i701f2139t81bd5e768e68891b@mail.gmail.com>
Message-ID: <1229106506.3863.148.camel@localhost.localdomain>

On Fri, 2008-12-12 at 08:54 -0900, Jeff Spaleta wrote:
> 
> I'm also concerned that the conversation is wandering too far away
> into the weeds from the problem at hand.  A security tagged update was
> pushed directly to stable in error.  Very little of the discussion I'm
> seeing here would have prevented the scenario that happened with dbus
> this week.
> 
> It's nice to discuss the larger issues, but if the ideas being put
> forward consistently have an escape hatch which lets security tagged
> packages directly into stable.... we haven't reduced the risk of what
> has happened this week from happening again.

It falls down to maintainer education.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/52c5841f/attachment.sig>

From ndbecker2 at gmail.com  Fri Dec 12 18:27:21 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 12 Dec 2008 13:27:21 -0500
Subject: How to get c++ abort to generate backtrace
References: <49428D69.10403@cora.nwra.com>
	<20081212161621.GI17496@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <ghuae9$hun$1@ger.gmane.org>

Jakub Jelinek wrote:

> On Fri, Dec 12, 2008 at 09:12:25AM -0700, Orion Poplawski wrote:
>> We're seeing cmake crash on the ppc64 builders with the following:
>>
>> terminate called after throwing an instance of 'std::out_of_range'
>>   what():  basic_string::erase
>>
>> Is there anyway to get this to automatically generate a stack trace?
> 
> LD_PRELOAD=libSegFault.so SEGFAULT_SIGNALS=abrt ./program arguments
> 
> Jakub
> 

Interesting.  Where is doc on this?



From lesmikesell at gmail.com  Fri Dec 12 18:43:36 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Dec 2008 12:43:36 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229106506.3863.148.camel@localhost.localdomain>
References: <ghqc4j$brb$11@ger.gmane.org>
	<ghqg1t$pnm$2@ger.gmane.org>	<1229014165.3863.79.camel@localhost.localdomain>	<ghsi7l$gpk$2@ger.gmane.org>	<1229058746.3863.123.camel@localhost.localdomain>	<20081212122953.GB19974@zod.rchland.ibm.com>	<1229100723.3863.137.camel@localhost.localdomain>	<20081212171825.GA12450@zod.rchland.ibm.com>	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>	<20081212174241.GB12450@zod.rchland.ibm.com>	<604aa7910812120954i701f2139t81bd5e768e68891b@mail.gmail.com>
	<1229106506.3863.148.camel@localhost.localdomain>
Message-ID: <4942B0D8.2040901@gmail.com>

Jesse Keating wrote:
> On Fri, 2008-12-12 at 08:54 -0900, Jeff Spaleta wrote:
>> I'm also concerned that the conversation is wandering too far away
>> into the weeds from the problem at hand.  A security tagged update was
>> pushed directly to stable in error.  Very little of the discussion I'm
>> seeing here would have prevented the scenario that happened with dbus
>> this week.
>>
>> It's nice to discuss the larger issues, but if the ideas being put
>> forward consistently have an escape hatch which lets security tagged
>> packages directly into stable.... we haven't reduced the risk of what
>> has happened this week from happening again.
> 
> It falls down to maintainer education.

No way to enforce a '4-eyes' rule for expedited pushes?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Fri Dec 12 18:44:28 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 12 Dec 2008 09:44:28 -0900
Subject: A way out of the update trap
Message-ID: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>

How about this. Instead of trying to craft a policy right now which
applies equally to all parts of the distribution.
Let's narrowly define a prioritized list of functionality which we
think is critical and deserves to be a priority when doing update QA.

Here's my short list
1) Packaging Updating at the console (rpm and yum)
2) Package Updating in the desktop (PK and friends)
3) python-matplotlib
4) xeyes

Your list with most likely be different than mine.  But can we get
project wide consensus as to the top 2 are really really important to
keep working for 'most' people? Everything else aside.. all the good
and bad ideas about how to do a top to bottom restructuring of updates
generation project wide off the table for a few seconds. Can we agree
that 1 and 2 are critical functionality which deserves extra
precautionary effort to reduce the risk of falling over and dying for
users compared to other functionality? Maybe more important than
security? If an update goes out which could impact rpm,yum,PK and
friends can we make it a policy that those updates require a specific
level of testing, even if it means holding up a security tagged update
until basic functionality of rpm,yum,PK is confirmed?

This is a risk management argument I am making.

-jef"is really thinking about adapting all the Integrated Safety
Management training that was beaten into him while at PPPL and
re-applying it to Fedora packaging"spaleta



From limb at jcomserv.net  Fri Dec 12 18:49:12 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 12 Dec 2008 12:49:12 -0600 (CST)
Subject: A way out of the update trap
In-Reply-To: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
Message-ID: <6bd684395ed59dbe6f312d4522161678.squirrel@mail.jcomserv.net>


> How about this. Instead of trying to craft a policy right now which
> applies equally to all parts of the distribution.
> Let's narrowly define a prioritized list of functionality which we
> think is critical and deserves to be a priority when doing update QA.
>
> Here's my short list
> 1) Packaging Updating at the console (rpm and yum)
> 2) Package Updating in the desktop (PK and friends)
> 3) python-matplotlib
> 4) xeyes
>
> Your list with most likely be different than mine.  But can we get
> project wide consensus as to the top 2 are really really important to
> keep working for 'most' people? Everything else aside.. all the good
> and bad ideas about how to do a top to bottom restructuring of updates
> generation project wide off the table for a few seconds. Can we agree
> that 1 and 2 are critical functionality which deserves extra
> precautionary effort to reduce the risk of falling over and dying for
> users compared to other functionality? Maybe more important than
> security? If an update goes out which could impact rpm,yum,PK and
> friends can we make it a policy that those updates require a specific
> level of testing, even if it means holding up a security tagged update
> until basic functionality of rpm,yum,PK is confirmed?
>
> This is a risk management argument I am making.

Well made.  +1.

But can we really afford to be so slipshod with xeyes?  Next thing you
know, someone with break KSpaceDuel, and then it's all over. . .;)

> -jef"is really thinking about adapting all the Integrated Safety
> Management training that was beaten into him while at PPPL and
> re-applying it to Fedora packaging"spaleta
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From robert at fedoraproject.org  Fri Dec 12 19:10:20 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Fri, 12 Dec 2008 20:10:20 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <ghraon$ch1$2@ger.gmane.org>
References: <200812091149.02184.opensource@till.name>
	<20081211130130.GB1488@hurricane.linuxnetz.de>
	<ghraon$ch1$2@ger.gmane.org>
Message-ID: <20081212191020.GA13968@hurricane.linuxnetz.de>

Hello Kevin,

On Thu, 11 Dec 2008, Kevin Kofler wrote:
> Proprietary drivers are not, have never been and will never be supported in
> Fedora.

known to me. But another example for things working on and with prerelease
of Fedora 10 and which are broken afterwards. So Rawhide was a more better
choice rather Fedora 10 as "stable" release - not very well.


Greetings,
  Robert



From enrico.scholz at informatik.tu-chemnitz.de  Fri Dec 12 19:17:36 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Fri, 12 Dec 2008 20:17:36 +0100
Subject: Updates QA/karma question
In-Reply-To: <4942906F.6080603@cora.nwra.com> (Orion Poplawski's message of
	"Fri, 12 Dec 2008 09:25:19 -0700")
References: <4942906F.6080603@cora.nwra.com>
Message-ID: <87tz99p5in.fsf@sheridan.bigo.ensc.de>

Orion Poplawski <orion at cora.nwra.com> writes:

>              Causes nfs statd to fail at bootup
>              orion - 2008-11-25 16:24:51 (karma -1)
>              Needs selinux changes.  Fails to start with selinux
>              enforcing.
>              https://bugzilla.redhat.com/show_bug.cgi?id=472917
>              steved - 2008-12-09 18:59:31 (karma 1)
>              selinux-policy-targeted-3.3.1-115.fc9 is now available
>              which does take care of the Selinux problem. Please up
>              update and try again...

That's a completely unreadable formatting which renders bodhi nagmails
useless for me. Hence, don't wonder when they get ignored...



Enrico



From james at fedoraproject.org  Fri Dec 12 19:19:13 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 12 Dec 2008 14:19:13 -0500
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <1229055659.3081.194.camel@beck.corsepiu.local>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz> <20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
Message-ID: <1229109553.6392.3.camel@code.and.org>

On Fri, 2008-12-12 at 05:20 +0100, Ralf Corsepius wrote:
> On Thu, 2008-12-11 at 18:41 +0100, Christoph Wickert wrote:
> > Am Donnerstag, den 11.12.2008, 17:52 +0100 schrieb Ralf Corsepius:
> > > On Thu, 2008-12-11 at 17:08 +0100, Sven Lankes wrote:
> > > > On Wed, Dec 10, 2008 at 11:58:51AM +0100, Matej Cepl wrote:
> > > > 
> > > > >> We should try to get the bohdi-karma-mechanism more popular. 
> > > >  
> > > > > IMNSHO we should get rid of it -- there is already one very good 
> > > > > mechanism for registering bugs in the software and it is 
> > > > > bugzilla.
> > > > 
> > > > Which can cater for negative feedback. I don't think most people would
> > > > be too happy with bz-entries created just containing 'works for me'.
> > > But this is exactly what is happening.
> > > 
> > > Cf. https://bugzilla.redhat.com/show_bug.cgi?id=475943
> > > for a real world case.
> > 
> > Huh? This does not look like positive feedback to me but like a normal
> > bug report.
> 
> Note the "works for me"s: It's the normal way users who report bugs
> through bugzilla provide feedback on proposed fixes.

 So you suggest that automated tools trawl all the BZ comments looking
for "works for me" comments? ... and what do people do who are just
testing the new package but had no problem with the old one, pick a BZ
at random? Open a new "the old one worked for me BZ" which we add to the
update just so people can say the new one works.
 And this is _better_ than the simple karma system?

-- 
James Antill <james at fedoraproject.org>
Fedora



From jkeating at redhat.com  Fri Dec 12 19:23:55 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 11:23:55 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4942B0D8.2040901@gmail.com>
References: <ghqc4j$brb$11@ger.gmane.org> <ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
	<1229100723.3863.137.camel@localhost.localdomain>
	<20081212171825.GA12450@zod.rchland.ibm.com>
	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>
	<20081212174241.GB12450@zod.rchland.ibm.com>
	<604aa7910812120954i701f2139t81bd5e768e68891b@mail.gmail.com>
	<1229106506.3863.148.camel@localhost.localdomain>
	<4942B0D8.2040901@gmail.com>
Message-ID: <1229109835.3863.149.camel@localhost.localdomain>

On Fri, 2008-12-12 at 12:43 -0600, Les Mikesell wrote:
> No way to enforce a '4-eyes' rule for expedited pushes?

Not without adding "needless" bureaucracy. 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/dc5c52a5/attachment.sig>

From pemboa at gmail.com  Fri Dec 12 19:37:02 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 13:37:02 -0600
Subject: Fedora Com System ? (was: Package updating problem and solutions)
Message-ID: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>

I think everyone is familiar with the topic, and this isn't an attempt
to branch into, just a side question.

Does the Fedora community see a need for a simple (yet robust)
communication system (possibly one way) from the Fedora elders to the
Fedora users? The idea being that if there was such a system now, and
alert could be sent out and people could be aware of the issue and the
work around, without relying on a mailing list, etc?

I ask as I would likely be trying for the GSoC next summer, and seems
like this may be a good, fairly self contained, project to work on if
community finds there is a significant need for it.

Arthur Pemberton



From johannbg at hi.is  Fri Dec 12 19:36:36 2008
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Fri, 12 Dec 2008 19:36:36 +0000
Subject: A way out of the update trap
In-Reply-To: <6bd684395ed59dbe6f312d4522161678.squirrel@mail.jcomserv.net>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
	<6bd684395ed59dbe6f312d4522161678.squirrel@mail.jcomserv.net>
Message-ID: <4942BD44.8060503@hi.is>

Jon Ciesla wrote:
>> How about this. Instead of trying to craft a policy right now which
>> applies equally to all parts of the distribution.
>> Let's narrowly define a prioritized list of functionality which we
>> think is critical and deserves to be a priority when doing update QA.
>>
>> Here's my short list
>> 1) Packaging Updating at the console (rpm and yum)
>> 2) Package Updating in the desktop (PK and friends)
>> 3) python-matplotlib
>> 4) xeyes
>>
>> Your list with most likely be different than mine.  But can we get
>> project wide consensus as to the top 2 are really really important to
>> keep working for 'most' people? Everything else aside.. all the good
>> and bad ideas about how to do a top to bottom restructuring of updates
>> generation project wide off the table for a few seconds. Can we agree
>> that 1 and 2 are critical functionality which deserves extra
>> precautionary effort to reduce the risk of falling over and dying for
>> users compared to other functionality? Maybe more important than
>> security? If an update goes out which could impact rpm,yum,PK and
>> friends can we make it a policy that those updates require a specific
>> level of testing, even if it means holding up a security tagged update
>> until basic functionality of rpm,yum,PK is confirmed?
>>
>> This is a risk management argument I am making.
>>     
>
> Well made.  +1.
>
> But can we really afford to be so slipshod with xeyes?  Next thing you
> know, someone with break KSpaceDuel, and then it's all over. . .;)
>
>   
>
I suggested an time based approach on this matter on #fedora-qa.

Have packages stay in updates-testing for an x amount of time before 
pushed to update
with the ability to be rushed through.

Packages that would cause system breakage would stay for example 5 days.
Non system-breakage packages for example 3 days
Security and urgent updates for a day them being flagged as urgent and mail
sent to the test-list asking testing asap.

That at least guarantee an x time for testing and to provide feedback 
but of course
does not guarantee feedback from testers any more than it is today.

JBG


-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/6c777d53/attachment.vcf>

From john.ellson at comcast.net  Fri Dec 12 19:42:52 2008
From: john.ellson at comcast.net (John Ellson)
Date: Fri, 12 Dec 2008 14:42:52 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
Message-ID: <4942BEBC.4080402@comcast.net>

Jeff Spaleta wrote:
> On Thu, Dec 11, 2008 at 4:40 PM, John Ellson <john.ellson at comcast.net> wrote:
>   
>> Can't you do this on one "dependency checker' machine somewhere?   Or have
>> it automatically reported from a limited number of testers?
>>     
>
> A limited number of testers who attempt to install and update
> EVERYTHING from every possible starting state between release and
> current update collection.. including 3rd party interactions?
>
> -jef
>
>   
How about just within the current Fedora collection?

e.g. 

   # yum install sysklogd
   Resolving Dependencies
    --> Running transaction check
    ---> Package sysklogd.x86_64 0:1.5-3.fc10 set to be updated
    --> Processing Conflict: sysklogd conflicts rsyslog
    --> Finished Dependency Resolution
    sysklogd-1.5-3.fc10.x86_64 from rawhide has depsolving problems
      --> sysklogd conflicts with rsyslog
    Error: sysklogd conflicts with rsyslog

or the problem that causes "yum install tetex-bytefield tetex-perltex" 
to just die without even trying to install them.
(rpm -Uvh ...  reports conflicts for these two with texlive)
    rpm -Uvh ./rawhide/packages/tetex-bytefield-1.2a-4.fc10.noarch.rpm 
./rawhide/packages/tetex-perltex-1.7-1.fc10.noarch.rpm
    Preparing...                
########################################### [100%]
        file /usr/share/texmf/doc/latex/perltex/perltex.pdf from install 
of tetex-perltex-1.7-1.fc10.noarch conflicts with file from package 
texlive-texmf-doc-2007-26.fc10.noarch
        file /usr/share/texmf/tex/latex/perltex/perltex.sty from install 
of tetex-perltex-1.7-1.fc10.noarch conflicts with file from package 
texlive-texmf-latex-2007-26.fc10.noarch
        file /usr/share/texmf/doc/latex/bytefield/bytefield.pdf from 
install of tetex-bytefield-1.2a-4.fc10.noarch conflicts with file from 
package texlive-texmf-doc-2007-26.fc10.noarch
        file /usr/share/texmf/tex/latex/bytefield/bytefield.sty from 
install of tetex-bytefield-1.2a-4.fc10.noarch conflicts with file from 
package texlive-texmf-latex-2007-26.fc10.noarch

or the similar problem with "sos" ?
    rpm -Uvh ./rawhide/packages/sos-1.8-3.fc11.noarch.rpm
    Preparing...                
########################################### [100%]
        file /usr/sbin/sysreport from install of sos-1.8-3.fc11.noarch 
conflicts with file from package sysreport-1.4.4-1.noarch
        file /usr/share/sysreport/functions from install of 
sos-1.8-3.fc11.noarch conflicts with file from package 
sysreport-1.4.4-1.noarch

      


-- 
John Ellson



From lesmikesell at gmail.com  Fri Dec 12 19:46:43 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Dec 2008 13:46:43 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229109835.3863.149.camel@localhost.localdomain>
References: <ghqc4j$brb$11@ger.gmane.org>
	<ghqg1t$pnm$2@ger.gmane.org>	<1229014165.3863.79.camel@localhost.localdomain>	<ghsi7l$gpk$2@ger.gmane.org>	<1229058746.3863.123.camel@localhost.localdomain>	<20081212122953.GB19974@zod.rchland.ibm.com>	<1229100723.3863.137.camel@localhost.localdomain>	<20081212171825.GA12450@zod.rchland.ibm.com>	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>	<20081212174241.GB12450@zod.rchland.ibm.com>	<604aa7910812120954i701f2139t81bd5e768e68891b@mail.gmail.com>	<1229106506.3863.148.camel@localhost.localdomain>	<4942B0D8.2040901@gmail.com>
	<1229109835.3863.149.camel@localhost.localdomain>
Message-ID: <4942BFA3.7010006@gmail.com>

Jesse Keating wrote:
> On Fri, 2008-12-12 at 12:43 -0600, Les Mikesell wrote:
>> No way to enforce a '4-eyes' rule for expedited pushes?
> 
> Not without adding "needless" bureaucracy. 

I think the need has been demonstrated...  And if it only applied to 
cases that had not soaked in updates-testing for some amount of time it 
should rarely apply.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From johannbg at hi.is  Fri Dec 12 19:50:51 2008
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Fri, 12 Dec 2008 19:50:51 +0000
Subject: A way out of the update trap
In-Reply-To: <4942BD44.8060503@hi.is>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>	<6bd684395ed59dbe6f312d4522161678.squirrel@mail.jcomserv.net>
	<4942BD44.8060503@hi.is>
Message-ID: <4942C09B.20701@hi.is>

J?hann B. Gu?mundsson wrote:
> Jon Ciesla wrote:
>>> How about this. Instead of trying to craft a policy right now which
>>> applies equally to all parts of the distribution.
>>> Let's narrowly define a prioritized list of functionality which we
>>> think is critical and deserves to be a priority when doing update QA.
>>>
>>> Here's my short list
>>> 1) Packaging Updating at the console (rpm and yum)
>>> 2) Package Updating in the desktop (PK and friends)
>>> 3) python-matplotlib
>>> 4) xeyes
>>>
>>> Your list with most likely be different than mine.  But can we get
>>> project wide consensus as to the top 2 are really really important to
>>> keep working for 'most' people? Everything else aside.. all the good
>>> and bad ideas about how to do a top to bottom restructuring of updates
>>> generation project wide off the table for a few seconds. Can we agree
>>> that 1 and 2 are critical functionality which deserves extra
>>> precautionary effort to reduce the risk of falling over and dying for
>>> users compared to other functionality? Maybe more important than
>>> security? If an update goes out which could impact rpm,yum,PK and
>>> friends can we make it a policy that those updates require a specific
>>> level of testing, even if it means holding up a security tagged update
>>> until basic functionality of rpm,yum,PK is confirmed?
>>>
>>> This is a risk management argument I am making.
>>>     
>>
>> Well made.  +1.
>>
>> But can we really afford to be so slipshod with xeyes?  Next thing you
>> know, someone with break KSpaceDuel, and then it's all over. . .;)
>>
>>  
> I suggested an time based approach on this matter on #fedora-qa.
>
> Have packages stay in updates-testing for an x amount of time before 
> pushed to update
> with the ability to be rushed through.
>
> Packages that would cause system breakage would stay for example 5 days.
> Non system-breakage packages for example 3 days
> Security and urgent updates for a day them being flagged as urgent and 
> mail
> sent to the test-list asking testing asap.
>
> That at least guarantee an x time for testing and to provide feedback 
> but of course
> does not guarantee feedback from testers any more than it is today.
>
Members of the QA group could provide that feedback

There is also an additional problem it's the lack of test cases.
( does not apply to bug fixes since you can inspect the bug report and 
check if it fixes what was discussed there )

For instance should a tester vote +1 in karma if the application starts?
Should he vote +1 if the application does x,y and z?

"Updated to upstream version" is a favor of mine and tells me nothing

Well I have to admit sometimes I bother to go upstream and read the 
changelog
sometimes..

Did that new upstream release bring several bug fixes?
( Dont those fixes need testing)

Did that new upstream release bring enhancements?
( Dont those enhancments need testing)

Hey I start the application it runs should I vote +1 in karma

JBG.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/4607c551/attachment.vcf>

From tibbs at math.uh.edu  Fri Dec 12 19:56:11 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 12 Dec 2008 13:56:11 -0600
Subject: yum --skip-broken update by default?
In-Reply-To: <4942BEBC.4080402@comcast.net>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net>
Message-ID: <ufabpvh9nhg.fsf@epithumia.math.uh.edu>

>>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:

JE> How about just within the current Fedora collection?

JE>     Error: sysklogd conflicts with rsyslog

I hope you realize that's intentional.  The two packages explicitly
conflict.

 - J<



From mschwendt at gmail.com  Fri Dec 12 19:55:06 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 12 Dec 2008 20:55:06 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <16de708d0812120815y30ba063ci5fee6cff9482fa10@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<16de708d0812102223t77bf1fecpd9b78bca513b3f16@mail.gmail.com>
	<ghqc4j$brb$11@ger.gmane.org> <4940B92A.1030403@gmail.com>
	<ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
	<ghsikm$gpk$4@ger.gmane.org>
	<20081212114203.b912da4c.mschwendt@gmail.com>
	<16de708d0812120815y30ba063ci5fee6cff9482fa10@mail.gmail.com>
Message-ID: <20081212205506.645cce15.mschwendt@gmail.com>

On Fri, 12 Dec 2008 10:15:55 -0600, Arthur wrote:

> We will have to agree to disagree on this as I found none of the
> reasons he gave substantive. I'll wait to see what looks like may be a
> new pace of releases play out. I will say that I find the tone of the
> proposed changes to be overly conservative and overall unfortunate.
> But if that's what the majority wishes, so be it.

You could still run with updates-testing enabled to get many more updates
and upgrades than with stock Fedora plus only the stable updates
repository. Updates-testing for the bleeding edge fan-boys. The gold
release plus stable updates for the masses.

At the current pace of development it's necessary to fix a Fedora gold
release with quite a lot of bug-fixes, often even zero-day updates.
However, (and although it can't be generalised) there is no necessity to
replace tested components of a gold release with major upgrades without
spending roughly the same amount of testing on them. That's what
updates-testing is for.

Under consideration of your earlier messages, are you trying to say that
with Fedora one cannot be productive without hundreds of updates and
upgrades?

Perhaps you don't know that Fedora already has a policy that protects the
buildroots from being broken with ABI/API incompatible updates. For such
updates it is necessary to either contact Release Engineering or push such
updates to stable first. Recent development is that packagers run into
that hurdle and instead of understanding it as a warning ("uh, oh, trouble
ahead - I better don't do that") they skip updates-testing only to learn
via the painful way that by doing it they've broken the stable distribution.

Every update that skips updates-testing (or uses it only for a very short
period) should require the maintainer to give a rationale.

With all the uproar because of dbus and packagekit update mistakes, please
don't forget that problems with Fedora are not limited to those two
packages. Every broken dependency bears the risk of blocking a user's
machine from seeing important updates until either the user works around
it or the update is fixed. Every broken update bears the risk of becoming
the annoyance that causes him to reconsider choosing Fedora. I don't think
we want that.

And if we are unable to put updates-testing to a better effect and at
the same time put security-fixes and major bug-fixes rather quickly
into the stable repo, that only proves that we no longer cannot handle
the high number of updates and their inter-package dependencies.



From jkeating at redhat.com  Fri Dec 12 19:59:28 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 11:59:28 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4942BFA3.7010006@gmail.com>
References: <ghqc4j$brb$11@ger.gmane.org> <ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<ghsi7l$gpk$2@ger.gmane.org>
	<1229058746.3863.123.camel@localhost.localdomain>
	<20081212122953.GB19974@zod.rchland.ibm.com>
	<1229100723.3863.137.camel@localhost.localdomain>
	<20081212171825.GA12450@zod.rchland.ibm.com>
	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>
	<20081212174241.GB12450@zod.rchland.ibm.com>
	<604aa7910812120954i701f2139t81bd5e768e68891b@mail.gmail.com>
	<1229106506.3863.148.camel@localhost.localdomain>
	<4942B0D8.2040901@gmail.com>
	<1229109835.3863.149.camel@localhost.localdomain>
	<4942BFA3.7010006@gmail.com>
Message-ID: <1229111968.3863.151.camel@localhost.localdomain>

On Fri, 2008-12-12 at 13:46 -0600, Les Mikesell wrote:
> 
> I think the need has been demonstrated...  And if it only applied to 
> cases that had not soaked in updates-testing for some amount of time it 
> should rarely apply.

But soaking does not equate to actual testing.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/99d76e01/attachment.sig>

From jkeating at redhat.com  Fri Dec 12 20:00:29 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 12:00:29 -0800
Subject: yum --skip-broken update by default?
In-Reply-To: <ufabpvh9nhg.fsf@epithumia.math.uh.edu>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net> <ufabpvh9nhg.fsf@epithumia.math.uh.edu>
Message-ID: <1229112029.3863.152.camel@localhost.localdomain>

On Fri, 2008-12-12 at 13:56 -0600, Jason L Tibbitts III wrote:
> >>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:
> 
> JE> How about just within the current Fedora collection?
> 
> JE>     Error: sysklogd conflicts with rsyslog
> 
> I hope you realize that's intentional.  The two packages explicitly
> conflict.
> 
>  - J<

Which I do believe is against the packaging guidelines.

We /cannot/ have any 2 current packages in Fedora that conflict with
eachother.  That is something I will fight tooth and nail for until the
end of time.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/28e051b6/attachment.sig>

From tibbs at math.uh.edu  Fri Dec 12 20:02:39 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 12 Dec 2008 14:02:39 -0600
Subject: yum --skip-broken update by default?
In-Reply-To: <1229112029.3863.152.camel@localhost.localdomain>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net> <ufabpvh9nhg.fsf@epithumia.math.uh.edu>
	<1229112029.3863.152.camel@localhost.localdomain>
Message-ID: <ufa7i659n6o.fsf@epithumia.math.uh.edu>

>>>>> "JK" == Jesse Keating <jkeating at redhat.com> writes:

JK> Which I do believe is against the packaging guidelines.

Not really.  Conflicts should be explicit if they exist.

http://fedoraproject.org/wiki/Packaging/Conflicts

"Whenever possible, Fedora packages should avoid conflicting with each
other. Unfortunately, this is not always possible. These guidelines
illustrate how conflicts should be handled in Fedora, specifically
concerning when and when not to use the Conflicts: field."

 - J<



From skvidal at fedoraproject.org  Fri Dec 12 20:03:44 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 15:03:44 -0500 (EST)
Subject: Fedora Com System ? (was: Package updating problem and
 solutions)
In-Reply-To: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>



On Fri, 12 Dec 2008, Arthur Pemberton wrote:

> I think everyone is familiar with the topic, and this isn't an attempt
> to branch into, just a side question.
>
> Does the Fedora community see a need for a simple (yet robust)
> communication system (possibly one way) from the Fedora elders to the
> Fedora users? The idea being that if there was such a system now, and
> alert could be sent out and people could be aware of the issue and the
> work around, without relying on a mailing list, etc?

How are fedora-announce, the blogs and the webpages NOT this?


-sv



From jamundso at gmail.com  Fri Dec 12 20:08:46 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 12 Dec 2008 14:08:46 -0600
Subject: yum --skip-broken update by default?
In-Reply-To: <ufa7i659n6o.fsf@epithumia.math.uh.edu>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net> <ufabpvh9nhg.fsf@epithumia.math.uh.edu>
	<1229112029.3863.152.camel@localhost.localdomain>
	<ufa7i659n6o.fsf@epithumia.math.uh.edu>
Message-ID: <6d06ce20812121208g153aee3el1318b56b48d184bf@mail.gmail.com>

On Fri, Dec 12, 2008 at 2:02 PM, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
>>>>>> "JK" == Jesse Keating <jkeating at redhat.com> writes:
>
> JK> Which I do believe is against the packaging guidelines.
>
> Not really.  Conflicts should be explicit if they exist.
>
> http://fedoraproject.org/wiki/Packaging/Conflicts
>
> "Whenever possible, Fedora packages should avoid conflicting with each
> other. Unfortunately, this is not always possible. These guidelines
> illustrate how conflicts should be handled in Fedora, specifically
> concerning when and when not to use the Conflicts: field."

More importantly, in the next paragraph:

"As a general rule, Fedora packages must NOT contain any usage of the
Conflicts: field."

jerry

-- 
Store in cool, dry place. Rotate stock.



From skvidal at fedoraproject.org  Fri Dec 12 20:08:40 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 15:08:40 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <ghu747$6a7$2@ger.gmane.org>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
	<alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>
	<604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>
	<d9c612bf0812120848v7c9868dan9db58fa43f0e3650@mail.gmail.com>
	<alpine.LFD.2.00.0812121156160.19488@localhost.localdomain>
	<ghu747$6a7$2@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0812121507530.22105@localhost.localdomain>



On Fri, 12 Dec 2008, Kevin Kofler wrote:

> Seth Vidal wrote:
>> I bet it is not wrong. the i386 packages probably provide what was
>> required. They just provide it sub-optimally.
>
> But that's really the problem: yum (*) thinks
>

as opposed to doing what? Everyone wants yum to magically solve problems 
or if it cannot it needs to be able to distinguish b/t the 'next best' 
solution and a 'bad solution'. Which is entirely variable.

What would you have it do?

-sv



From pemboa at gmail.com  Fri Dec 12 20:09:12 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 14:09:12 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081212205506.645cce15.mschwendt@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<4940B92A.1030403@gmail.com> <ghqg1t$pnm$2@ger.gmane.org>
	<1229014165.3863.79.camel@localhost.localdomain>
	<16de708d0812111032l522dbb47v3003c380c2db85c2@mail.gmail.com>
	<20081211220650.e89782d5.mschwendt@gmail.com>
	<ghsikm$gpk$4@ger.gmane.org>
	<20081212114203.b912da4c.mschwendt@gmail.com>
	<16de708d0812120815y30ba063ci5fee6cff9482fa10@mail.gmail.com>
	<20081212205506.645cce15.mschwendt@gmail.com>
Message-ID: <16de708d0812121209p2786180ahd4a0f9953e2a8fa5@mail.gmail.com>

On Fri, Dec 12, 2008 at 1:55 PM, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Fri, 12 Dec 2008 10:15:55 -0600, Arthur wrote:
>
>> We will have to agree to disagree on this as I found none of the
>> reasons he gave substantive. I'll wait to see what looks like may be a
>> new pace of releases play out. I will say that I find the tone of the
>> proposed changes to be overly conservative and overall unfortunate.
>> But if that's what the majority wishes, so be it.
>
> You could still run with updates-testing enabled to get many more updates
> and upgrades than with stock Fedora plus only the stable updates
> repository. Updates-testing for the bleeding edge fan-boys. The gold
> release plus stable updates for the masses.

If it comes to that, I will do so.

> At the current pace of development it's necessary to fix a Fedora gold
> release with quite a lot of bug-fixes, often even zero-day updates.
> However, (and although it can't be generalised) there is no necessity to
> replace tested components of a gold release with major upgrades without
> spending roughly the same amount of testing on them. That's what
> updates-testing is for.

Fair enough.

> Under consideration of your earlier messages, are you trying to say that
> with Fedora one cannot be productive without hundreds of updates and
> upgrades?

Not at all, that would be a bit of a backward thinking. The way I see
it is that Fedora does the most good by going this route.
Give us the new stuff early, let us cut our teeth on it, etc. Let
things come here and die or grow. I think that is one of the greater
contributions of Fedora to the community. I may be overly idealistic
however.

> Perhaps you don't know that Fedora already has a policy that protects the
> buildroots from being broken with ABI/API incompatible updates. For such
> updates it is necessary to either contact Release Engineering or push such
> updates to stable first. Recent development is that packagers run into
> that hurdle and instead of understanding it as a warning ("uh, oh, trouble
> ahead - I better don't do that") they skip updates-testing only to learn
> via the painful way that by doing it they've broken the stable distribution.
>
> Every update that skips updates-testing (or uses it only for a very short
> period) should require the maintainer to give a rationale.

That's fair.

> With all the uproar because of dbus and packagekit update mistakes, please
> don't forget that problems with Fedora are not limited to those two
> packages. Every broken dependency bears the risk of blocking a user's
> machine from seeing important updates until either the user works around
> it or the update is fixed. Every broken update bears the risk of becoming
> the annoyance that causes him to reconsider choosing Fedora. I don't think
> we want that.

Fair enough.

> And if we are unable to put updates-testing to a better effect and at
> the same time put security-fixes and major bug-fixes rather quickly
> into the stable repo, that only proves that we no longer cannot handle
> the high number of updates and their inter-package dependencies.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pemboa at gmail.com  Fri Dec 12 20:12:33 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 14:12:33 -0600
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
Message-ID: <16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>

On Fri, Dec 12, 2008 at 2:03 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>
>
> On Fri, 12 Dec 2008, Arthur Pemberton wrote:
>
>> I think everyone is familiar with the topic, and this isn't an attempt
>> to branch into, just a side question.
>>
>> Does the Fedora community see a need for a simple (yet robust)
>> communication system (possibly one way) from the Fedora elders to the
>> Fedora users? The idea being that if there was such a system now, and
>> alert could be sent out and people could be aware of the issue and the
>> work around, without relying on a mailing list, etc?
>
> How are fedora-announce, the blogs and the webpages NOT this?

You don't get any of them with Fedora, that's primary difference I
see. During the new-key issue, many people claimed not to be on the
announce list for various reasons. All of these require you to check
regularly, or be aware that there is an ongoing issue.

But you are right, what we have now may be adequate. This is what I am
trying to to determine.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From skvidal at fedoraproject.org  Fri Dec 12 20:12:56 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 15:12:56 -0500 (EST)
Subject: Making updates-testing more useful
In-Reply-To: <ghu7cm$6a7$3@ger.gmane.org>
References: <1228930549.3648.14.camel@localhost.localdomain>
	<4941FF83.7090404@leemhuis.info>
	<alpine.LFD.2.00.0812121000290.19488@localhost.localdomain>
	<a9d183c80812120713k749d81aayd0e7905a6627f1ef@mail.gmail.com>
	<alpine.LFD.2.00.0812121014090.19488@localhost.localdomain>
	<a9d183c80812120726r4b587b3ah44c8b1a0e18f6e6c@mail.gmail.com>
	<alpine.LFD.2.00.0812121027130.19488@localhost.localdomain>
	<a9d183c80812120747r4a0484cfxe7cfe5d109bae6fa@mail.gmail.com>
	<alpine.LFD.2.00.0812121053440.19488@localhost.localdomain>
	<604aa7910812120843l17db4d3id2618582cd5f7537@mail.gmail.com>
	<d9c612bf0812120848v7c9868dan9db58fa43f0e3650@mail.gmail.com>
	<alpine.LFD.2.00.0812121156160.19488@localhost.localdomain>
	<ghu7cm$6a7$3@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0812121510550.22105@localhost.localdomain>



On Fri, 12 Dec 2008, Kevin Kofler wrote:

> Seth Vidal wrote:
>> I bet it is not wrong. the i386 packages probably provide what was
>> required. They just provide it sub-optimally.
>
> But that's really the problem: yum (*) tries to resolve conflicting
> requirements (of the A requires C = 1.2.3 and B requires C = 2.3.4 type) by
> installing C.x86_64 = 2.3.4 and C.i386 = 1.2.3. This obviously can't work
> (it will in almost all cases lead to file conflicts, and it is almost
> certainly not what the user wants). I think there needs to be some
> restriction that C.x86_64 and C.i386 need to be of the same EVR.

1. There's no way to know in advance that the above will be in conflict at 
all. And for every case where it is most likely to be so I'm positive I 
can (or have) find a situation where it is the opposite.

2. the better solution is %{_isa} being added to all deps/provides for any 
pkg which COULD become a multilib pkg.

>
> (*) (and other depsolvers too, I've seen apt-rpm do it too, but let's focus
> on yum here)

all depsolvers have a problem when the dependency/provide information is 
ambiguous.



> (And sorry for the previous incomplete message, I accidentally hit
> Ctrl+Enter and KNode sends the message immediately if I hit that.)

then I'm sorry about the cranky response to that message. I thought that 
was all of the message and you were being flippant.

-sv



From skvidal at fedoraproject.org  Fri Dec 12 20:14:19 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 15:14:19 -0500 (EST)
Subject: Fedora Com System ? (was: Package updating problem and
 solutions)
In-Reply-To: <16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>



On Fri, 12 Dec 2008, Arthur Pemberton wrote:

> On Fri, Dec 12, 2008 at 2:03 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>>
>>
>> On Fri, 12 Dec 2008, Arthur Pemberton wrote:
>>
>>> I think everyone is familiar with the topic, and this isn't an attempt
>>> to branch into, just a side question.
>>>
>>> Does the Fedora community see a need for a simple (yet robust)
>>> communication system (possibly one way) from the Fedora elders to the
>>> Fedora users? The idea being that if there was such a system now, and
>>> alert could be sent out and people could be aware of the issue and the
>>> work around, without relying on a mailing list, etc?
>>
>> How are fedora-announce, the blogs and the webpages NOT this?
>
> You don't get any of them with Fedora, that's primary difference I
> see. During the new-key issue, many people claimed not to be on the
> announce list for various reasons. All of these require you to check
> regularly, or be aware that there is an ongoing issue.
>
> But you are right, what we have now may be adequate. This is what I am
> trying to to determine.

My problem is we could have a international klaxon alert system which 
secretly uses traffic lights to warn people of fedora changes and we would 
still get some folks who wouldn't notice.

:)

-sv



From jkeating at redhat.com  Fri Dec 12 20:18:05 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 12:18:05 -0800
Subject: Package Conflicts (was Re: yum --skip-broken update by default?)
In-Reply-To: <6d06ce20812121208g153aee3el1318b56b48d184bf@mail.gmail.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net> <ufabpvh9nhg.fsf@epithumia.math.uh.edu>
	<1229112029.3863.152.camel@localhost.localdomain>
	<ufa7i659n6o.fsf@epithumia.math.uh.edu>
	<6d06ce20812121208g153aee3el1318b56b48d184bf@mail.gmail.com>
Message-ID: <1229113085.3863.156.camel@localhost.localdomain>

On Fri, 2008-12-12 at 14:08 -0600, Jerry Amundson wrote:
> > http://fedoraproject.org/wiki/Packaging/Conflicts
> >
> > "Whenever possible, Fedora packages should avoid conflicting with each
> > other. Unfortunately, this is not always possible. These guidelines
> > illustrate how conflicts should be handled in Fedora, specifically
> > concerning when and when not to use the Conflicts: field."
> 
> More importantly, in the next paragraph:
> 
> "As a general rule, Fedora packages must NOT contain any usage of the
> Conflicts: field."


Yeah, I'll go to bat with the FPC on the wording of this rule.

Conflicts are allowed to express that a given package may conflict with
an older version of some other package, but may not directly require
that other package and vice-versa.  What I don't find acceptable is any
current Fedora package conflicting with any other current Fedora
package, either explicitly or through files.

The failure case of when this happens is just unacceptable.  yum, et al,
cannot tell if files conflict until the packages are all downloaded
first, and when this happens it's just an error, the user is left to
translate, figure out a different course of action, and start over.
Especially bad during initial installs.

We have an alternatives system for when you absolutely cannot find any
other way for two packages to co-exist.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/00014c6c/attachment.sig>

From pertusus at free.fr  Fri Dec 12 19:59:50 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 12 Dec 2008 20:59:50 +0100
Subject: A way out of the update trap
In-Reply-To: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
Message-ID: <20081212195950.GA2866@free.fr>

On Fri, Dec 12, 2008 at 09:44:28AM -0900, Jeff Spaleta wrote:
> How about this. Instead of trying to craft a policy right now which
> applies equally to all parts of the distribution.
> Let's narrowly define a prioritized list of functionality which we
> think is critical and deserves to be a priority when doing update QA.
> 
> Here's my short list
> 1) Packaging Updating at the console (rpm and yum)
> 2) Package Updating in the desktop (PK and friends)

I'd propose, more largely @code, @base and dependencies.

--
Pat



From jamundso at gmail.com  Fri Dec 12 20:24:31 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 12 Dec 2008 14:24:31 -0600
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
	<alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
Message-ID: <6d06ce20812121224o5e7df8ckfc7a2a77b462d001@mail.gmail.com>

On Fri, Dec 12, 2008 at 2:14 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> My problem is we could have a international klaxon alert system which
> secretly uses traffic lights to warn people of fedora changes and we would
> still get some folks who wouldn't notice.

"Klaxon", derived from the Greek klazo, to shriek. As in, "The
on-lookers shrieked, 'Goodness! Fedora has released updates, run for
your lives!'"
:)

Yep, it's Friday for me...

jerry

-- 
TBD.



From lesmikesell at gmail.com  Fri Dec 12 20:26:20 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Dec 2008 14:26:20 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229111968.3863.151.camel@localhost.localdomain>
References: <ghqc4j$brb$11@ger.gmane.org>
	<ghqg1t$pnm$2@ger.gmane.org>	<1229014165.3863.79.camel@localhost.localdomain>	<ghsi7l$gpk$2@ger.gmane.org>	<1229058746.3863.123.camel@localhost.localdomain>	<20081212122953.GB19974@zod.rchland.ibm.com>	<1229100723.3863.137.camel@localhost.localdomain>	<20081212171825.GA12450@zod.rchland.ibm.com>	<604aa7910812120923h63695a41s93694a6860d550fe@mail.gmail.com>	<20081212174241.GB12450@zod.rchland.ibm.com>	<604aa7910812120954i701f2139t81bd5e768e68891b@mail.gmail.com>	<1229106506.3863.148.camel@localhost.localdomain>	<4942B0D8.2040901@gmail.com>	<1229109835.3863.149.camel@localhost.localdomain>	<4942BFA3.7010006@gmail.com>
	<1229111968.3863.151.camel@localhost.localdomain>
Message-ID: <4942C8EC.9040507@gmail.com>

Jesse Keating wrote:
> On Fri, 2008-12-12 at 13:46 -0600, Les Mikesell wrote:
>> I think the need has been demonstrated...  And if it only applied to 
>> cases that had not soaked in updates-testing for some amount of time it 
>> should rarely apply.
> 
> But soaking does not equate to actual testing.

That's a separate problem that in my opinion can't be fixed without 
creating a repo containing package sets that are exactly as will be in 
production.  But, that would not change the need to expedite certain 
things for security reasons or to undo breakage and without the usual 
test cycle there will be more mistakes.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From john.ellson at comcast.net  Fri Dec 12 20:28:24 2008
From: john.ellson at comcast.net (John Ellson)
Date: Fri, 12 Dec 2008 15:28:24 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <ufabpvh9nhg.fsf@epithumia.math.uh.edu>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>	<4941C0F8.6010203@comcast.net>	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>	<4942BEBC.4080402@comcast.net>
	<ufabpvh9nhg.fsf@epithumia.math.uh.edu>
Message-ID: <4942C968.7090803@comcast.net>

Jason L Tibbitts III wrote:
>>>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:
>>>>>>             
>
> JE> How about just within the current Fedora collection?
>
> JE>     Error: sysklogd conflicts with rsyslog
>
> I hope you realize that's intentional.  The two packages explicitly
> conflict.
>
>  - J<
>
>   
Why?  Thats a dumb way to select features.   Make them not-conflict and 
provide some kind of configuration option.

Who is going to read the fine print when there 5000 rpms to play with?

Just IMHO



-- 
John Ellson



From jspaleta at gmail.com  Fri Dec 12 20:29:22 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 12 Dec 2008 11:29:22 -0900
Subject: yum --skip-broken update by default?
In-Reply-To: <4942BEBC.4080402@comcast.net>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net>
Message-ID: <604aa7910812121229r236ff20fs7e3fb5e66a3cd05a@mail.gmail.com>

On Fri, Dec 12, 2008 at 10:42 AM, John Ellson <john.ellson at comcast.net> wrote:
> How about just within the current Fedora collection?

You missed the point.

If we make skip-broken work silently by default and do not notify
users about the crap being skipped... then our users who have 3rd
party repos installs will be missing Fedora updates.   That means..
they will silently fail to receive Fedora signed security updates. Not
cool. We can't just turn a blind-eye to that because they have 3rd
party repos enabled if we deliberately choose a default setting which
does that sort of thing silently.

Then there is also crap like locally installed packages..which were
downloaded from outside a repository structure.  Poeple do it. We make
it easy for them to do via a url handler in Firefox. There's no bloody
way a team of testers can catch that.

You can not possibly hit all the in the wild cases where someone is
going be affected by a broken dep chain which prevents them from
getting a Fedora signed security update with a small team of testers
who dedicate their very existence to testing for depchain breakage.
We have to notify users as its happening on their systems. I've no
problem giving them a choice to skip once they are notified.. but they
absolutely must be notified that updates are being skipped and whether
those updates are considered security or critical.  To silently ignore
that those updates aren't being installed, is a failure to adequately
notify users so they can make informed choices.

-jef



From mschwendt at gmail.com  Fri Dec 12 20:31:10 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 12 Dec 2008 21:31:10 +0100
Subject: Fedora Com System ? (was: Package updating problem and
 solutions)
In-Reply-To: <alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
	<alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
Message-ID: <20081212213110.079d449e.mschwendt@gmail.com>

On Fri, 12 Dec 2008 15:14:19 -0500 (EST), Seth wrote:

> My problem is we could have a international klaxon alert system which 
> secretly uses traffic lights to warn people of fedora changes and we would 
> still get some folks who wouldn't notice.
> 
> :)

What does that cost? I'd rather prefer a Fedora cycling jersey in blue. ;)



From tibbs at math.uh.edu  Fri Dec 12 20:33:37 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 12 Dec 2008 14:33:37 -0600
Subject: yum --skip-broken update by default?
In-Reply-To: <4942C968.7090803@comcast.net>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net> <ufabpvh9nhg.fsf@epithumia.math.uh.edu>
	<4942C968.7090803@comcast.net>
Message-ID: <ufa3agt9lr2.fsf@epithumia.math.uh.edu>

>>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:

JE> Why?  Thats a dumb way to select features.  Make them not-conflict
JE> and provide some kind of configuration option.

Because there have been certain difficulties in getting these packages
to live with each other, requiring various finessing which as I
understand things has been progressing.

I mean, come on, two syslog daemons?  Each needing to own (and do
things like provide log rotation for) the same files?  Alternatives
isn't going to handle that, you know.  And as I understand it, there
are actually three syslog daemons people might want to use, all with
the same issues.  You make it sound as if these things have absolutely
trivial solutions, and the only reason for making them conflict is to
annoy you.  Do you even allow for the possibility that there's an
actual difficult issue here?

 - J<



From skvidal at fedoraproject.org  Fri Dec 12 20:34:09 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 15:34:09 -0500 (EST)
Subject: Fedora Com System ? (was: Package updating problem and
 solutions)
In-Reply-To: <20081212213110.079d449e.mschwendt@gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
	<alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
	<20081212213110.079d449e.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0812121531530.22105@localhost.localdomain>



On Fri, 12 Dec 2008, Michael Schwendt wrote:

> On Fri, 12 Dec 2008 15:14:19 -0500 (EST), Seth wrote:
>
>> My problem is we could have a international klaxon alert system which
>> secretly uses traffic lights to warn people of fedora changes and we would
>> still get some folks who wouldn't notice.
>>
>> :)
>
> What does that cost? I'd rather prefer a Fedora cycling jersey in blue. ;)
>

Michael,
  You've been here for a long time. You know where we keep the codes to the 
orbital laser? On top of the filing cabinet next to the lockbox with 
the codes there's a spreadsheet with the costs for the international alert system.

:)
-sv



From mike at cchtml.com  Fri Dec 12 20:39:44 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Fri, 12 Dec 2008 14:39:44 -0600
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
Message-ID: <4942CC10.4050908@cchtml.com>

-------- Original Message --------
Subject: Re: Fedora Com System ? (was: Package updating problem and 
solutions)
From: Seth Vidal <skvidal at fedoraproject.org>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 12/12/2008 02:03 PM

> 
> How are fedora-announce, the blogs and the webpages NOT this?
> 

We need an applet that notifies users of announce e-mails or some form 
of libnotify box that says "hey stupid, read this Fedora news." New 
users typically care less about mailing lists, blogs, and webpages 
unless they are looking to set up new software like Samba sharing or 
have a bug like the PackageKit dependency.

 From my own experience, I could care less about visiting Fedora web 
sites daily. Should all end users pour hours of their lives into reading 
web pages and blogs daily? No, the process should be done for them.



From jspaleta at gmail.com  Fri Dec 12 20:40:07 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 12 Dec 2008 11:40:07 -0900
Subject: A way out of the update trap
In-Reply-To: <20081212195950.GA2866@free.fr>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
	<20081212195950.GA2866@free.fr>
Message-ID: <604aa7910812121240q46058b61g98d329e250194797@mail.gmail.com>

On Fri, Dec 12, 2008 at 10:59 AM, Patrice Dumas <pertusus at free.fr> wrote:
> I'd propose, more largely @code, @base and dependencies.

I think that's too broad a target to start with and you don't have the
QA resourses in place to support a policy that broad.

If QA resources are scarce, how about we treat them as scarce and
build narrow policies which let the existing resources get used for
best benefit on targetted priorities. And as resources grow, we grow
the list of priorities downward into more areas.

Right now. I am asking us as a project to suck it up and identify a
top functionality priority and to live within our means as it comes to
existing QA expectations.

For me, lowering the risk of the potential breakage of update
functionality breakage is the number 1 priority in terms of critical
functionality.  I dare you to suggest an alternative specific
functionality. If we can't even settle on one specific functionality
as a priority we've no chance a targetting all of @core and @base.
None.

-jef



From john.ellson at comcast.net  Fri Dec 12 20:40:04 2008
From: john.ellson at comcast.net (John Ellson)
Date: Fri, 12 Dec 2008 15:40:04 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <ufa3agt9lr2.fsf@epithumia.math.uh.edu>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>	<4941C0F8.6010203@comcast.net>	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>	<4942BEBC.4080402@comcast.net>
	<ufabpvh9nhg.fsf@epithumia.math.uh.edu>	<4942C968.7090803@comcast.net>
	<ufa3agt9lr2.fsf@epithumia.math.uh.edu>
Message-ID: <4942CC24.3030401@comcast.net>

Jason L Tibbitts III wrote:
>>>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:
>>>>>>             
>
> JE> Why?  Thats a dumb way to select features.  Make them not-conflict
> JE> and provide some kind of configuration option.
>
> Because there have been certain difficulties in getting these packages
> to live with each other, requiring various finessing which as I
> understand things has been progressing.
>
> I mean, come on, two syslog daemons?  Each needing to own (and do
> things like provide log rotation for) the same files?  Alternatives
> isn't going to handle that, you know.  And as I understand it, there
> are actually three syslog daemons people might want to use, all with
> the same issues.  You make it sound as if these things have absolutely
> trivial solutions, and the only reason for making them conflict is to
> annoy you.  Do you even allow for the possibility that there's an
> actual difficult issue here?
>
>  - J<
>
>   
Sure I allow that. But we're off track.   My primary complaint is that 
this dependency conflict
isn't listed in the daily yum updates dependency list and that yum 
doesn't deal with it automatically.



-- 
John Ellson



From john.ellson at comcast.net  Fri Dec 12 20:42:50 2008
From: john.ellson at comcast.net (John Ellson)
Date: Fri, 12 Dec 2008 15:42:50 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <604aa7910812121229r236ff20fs7e3fb5e66a3cd05a@mail.gmail.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>	<4941C0F8.6010203@comcast.net>	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>	<4942BEBC.4080402@comcast.net>
	<604aa7910812121229r236ff20fs7e3fb5e66a3cd05a@mail.gmail.com>
Message-ID: <4942CCCA.90604@comcast.net>

Jeff Spaleta wrote:
> On Fri, Dec 12, 2008 at 10:42 AM, John Ellson <john.ellson at comcast.net> wrote:
>   
>> How about just within the current Fedora collection?
>>     
>
> You missed the point.
>
> If we make skip-broken work silently by default and do not notify
> users about the crap being skipped... 
That would be fine, and notify the developers too, but then just install 
the rest of the updates
without quitting on me.







> then our users who have 3rd
> party repos installs will be missing Fedora updates.   That means..
> they will silently fail to receive Fedora signed security updates. Not
> cool. We can't just turn a blind-eye to that because they have 3rd
> party repos enabled if we deliberately choose a default setting which
> does that sort of thing silently.
>
> Then there is also crap like locally installed packages..which were
> downloaded from outside a repository structure.  Poeple do it. We make
> it easy for them to do via a url handler in Firefox. There's no bloody
> way a team of testers can catch that.
>
> You can not possibly hit all the in the wild cases where someone is
> going be affected by a broken dep chain which prevents them from
> getting a Fedora signed security update with a small team of testers
> who dedicate their very existence to testing for depchain breakage.
> We have to notify users as its happening on their systems. I've no
> problem giving them a choice to skip once they are notified.. but they
> absolutely must be notified that updates are being skipped and whether
> those updates are considered security or critical.  To silently ignore
> that those updates aren't being installed, is a failure to adequately
> notify users so they can make informed choices.
>
> -jef
>
>   


-- 
John Ellson



From alsadi at gmail.com  Fri Dec 12 20:42:13 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 12 Dec 2008 22:42:13 +0200
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <alpine.LFD.2.00.0812121531530.22105@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
	<alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
	<20081212213110.079d449e.mschwendt@gmail.com>
	<alpine.LFD.2.00.0812121531530.22105@localhost.localdomain>
Message-ID: <385866f0812121242k3e954104ofdde13b2e19c203b@mail.gmail.com>

the announce mailing list should be visible in some web site that support rss

and let firefox or any rss reader configured by default for it



From skvidal at fedoraproject.org  Fri Dec 12 20:43:49 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 15:43:49 -0500 (EST)
Subject: yum --skip-broken update by default?
In-Reply-To: <4942CC24.3030401@comcast.net>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net>
	<ufabpvh9nhg.fsf@epithumia.math.uh.edu> <4942C968.7090803@comcast.net>
	<ufa3agt9lr2.fsf@epithumia.math.uh.edu>
	<4942CC24.3030401@comcast.net>
Message-ID: <alpine.LFD.2.00.0812121541280.22105@localhost.localdomain>



On Fri, 12 Dec 2008, John Ellson wrote:

> Jason L Tibbitts III wrote:
>>>>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:
>>>>>>> 
>> 
>> JE> Why?  Thats a dumb way to select features.  Make them not-conflict
>> JE> and provide some kind of configuration option.
>> 
>> Because there have been certain difficulties in getting these packages
>> to live with each other, requiring various finessing which as I
>> understand things has been progressing.
>> 
>> I mean, come on, two syslog daemons?  Each needing to own (and do
>> things like provide log rotation for) the same files?  Alternatives
>> isn't going to handle that, you know.  And as I understand it, there
>> are actually three syslog daemons people might want to use, all with
>> the same issues.  You make it sound as if these things have absolutely
>> trivial solutions, and the only reason for making them conflict is to
>> annoy you.  Do you even allow for the possibility that there's an
>> actual difficult issue here?
>>
>>  - J<
>>
>> 
> Sure I allow that. But we're off track.   My primary complaint is that this 
> dependency conflict
> isn't listed in the daily yum updates dependency list and that yum doesn't 
> deal with it automatically.

How would you recommend it be dealt with? And remember we have to have an 
acceptable behavior for 'yum -y update'.


When there is a conflict should we:
1. assume the existing pkgs are better
or
2. assume the installing pkgs are better


argument in favor of 1 is that the existing pkgs are on the system and 
should therefore be protected as a possible running service.

argument in favor of 2 is that the user is requesting an action and the 
user knows best, therefore the requested action must be the 'best' action.

I bet out of 1000 fedora users I'll get an almost even split between them.
-sv



From jonathan.robie at redhat.com  Fri Dec 12 20:53:11 2008
From: jonathan.robie at redhat.com (Jonathan Robie)
Date: Fri, 12 Dec 2008 15:53:11 -0500
Subject: Perseus Digital Library?
Message-ID: <4942CF37.9050804@redhat.com>

Does anyone have plans to create a Fedora RPM for the Perseus Digital 
Library?

http://www.perseus.tufts.edu/hopper/opensource

I'm not quite ready to commit to creating one, but I'm definitely 
playing with the idea. I'd have to figure out roughly how much of my 
free time would be needed first.

Jonathan



From pemboa at gmail.com  Fri Dec 12 20:53:46 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 14:53:46 -0600
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <385866f0812121242k3e954104ofdde13b2e19c203b@mail.gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
	<alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
	<20081212213110.079d449e.mschwendt@gmail.com>
	<alpine.LFD.2.00.0812121531530.22105@localhost.localdomain>
	<385866f0812121242k3e954104ofdde13b2e19c203b@mail.gmail.com>
Message-ID: <16de708d0812121253sdb26fai7e252f0cd9e1f2e2@mail.gmail.com>

On Fri, Dec 12, 2008 at 2:42 PM, Muayyad AlSadi <alsadi at gmail.com> wrote:
> the announce mailing list should be visible in some web site that support rss
>
> and let firefox or any rss reader configured by default for it

There is little difference between this and checking the
fedora-announce archives regularly though.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pertusus at free.fr  Fri Dec 12 20:22:55 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 12 Dec 2008 21:22:55 +0100
Subject: Package Conflicts (was Re: yum --skip-broken update by default?)
In-Reply-To: <1229113085.3863.156.camel@localhost.localdomain>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net>
	<ufabpvh9nhg.fsf@epithumia.math.uh.edu>
	<1229112029.3863.152.camel@localhost.localdomain>
	<ufa7i659n6o.fsf@epithumia.math.uh.edu>
	<6d06ce20812121208g153aee3el1318b56b48d184bf@mail.gmail.com>
	<1229113085.3863.156.camel@localhost.localdomain>
Message-ID: <20081212202255.GB2866@free.fr>

On Fri, Dec 12, 2008 at 12:18:05PM -0800, Jesse Keating wrote:
> 
> We have an alternatives system for when you absolutely cannot find any
> other way for two packages to co-exist.

I agree with what you said, but not with that part. alternatives are for 
packages with compatible command-line and compatible functionalities
(though not necessarily the same coverage), not to avoid conflicts.

--
Pat



From skvidal at fedoraproject.org  Fri Dec 12 21:08:22 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 16:08:22 -0500 (EST)
Subject: Fedora Com System ? (was: Package updating problem and
 solutions)
In-Reply-To: <4942CC10.4050908@cchtml.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<4942CC10.4050908@cchtml.com>
Message-ID: <alpine.LFD.2.00.0812121606010.22105@localhost.localdomain>



On Fri, 12 Dec 2008, Michael Cronenworth wrote:

> -------- Original Message --------
> Subject: Re: Fedora Com System ? (was: Package updating problem and 
> solutions)
> From: Seth Vidal <skvidal at fedoraproject.org>
> To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
> Date: 12/12/2008 02:03 PM
>
>> 
>> How are fedora-announce, the blogs and the webpages NOT this?
>> 
>
> We need an applet that notifies users of announce e-mails or some form of 
> libnotify box that says "hey stupid, read this Fedora news." New users 
> typically care less about mailing lists, blogs, and webpages unless they are 
> looking to set up new software like Samba sharing or have a bug like the 
> PackageKit dependency.
>
> From my own experience, I could care less about visiting Fedora web sites 
> daily. Should all end users pour hours of their lives into reading web pages 
> and blogs daily? No, the process should be done for them.
>


okay, so as much as this makes me cringe I'll suggest something probably 
crack filled:

- additional metadata file of notices in repodata
- each notice has an id on it
- a yum plugin or pk or what not - records the notices you've seen
- as it finds new ones it emits them for you.

that wouldn't really help us in the situation where an update broke the 
update system, of course.

-sv



From dominik at greysector.net  Fri Dec 12 21:22:47 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 12 Dec 2008 22:22:47 +0100
Subject: Perseus Digital Library?
In-Reply-To: <4942CF37.9050804@redhat.com>
References: <4942CF37.9050804@redhat.com>
Message-ID: <20081212212246.GA17597@mokona.greysector.net>

On Friday, 12 December 2008 at 21:53, Jonathan Robie wrote:
> Does anyone have plans to create a Fedora RPM for the Perseus Digital 
> Library?
> 
> http://www.perseus.tufts.edu/hopper/opensource

It doesn't seem to be on the packaging wishlist:
https://fedoraproject.org/wiki/PackageMaintainers/WishList

I'd say go for it. You'll learn as you go. It's not THAT difficult.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From pemboa at gmail.com  Fri Dec 12 22:12:39 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 16:12:39 -0600
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <alpine.LFD.2.00.0812121606010.22105@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<4942CC10.4050908@cchtml.com>
	<alpine.LFD.2.00.0812121606010.22105@localhost.localdomain>
Message-ID: <16de708d0812121412w72c13242se6a33b8c739e3fde@mail.gmail.com>

On Fri, Dec 12, 2008 at 3:08 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>
>
> On Fri, 12 Dec 2008, Michael Cronenworth wrote:
>
>> -------- Original Message --------
>> Subject: Re: Fedora Com System ? (was: Package updating problem and
>> solutions)
>> From: Seth Vidal <skvidal at fedoraproject.org>
>> To: Development discussions related to Fedora
>> <fedora-devel-list at redhat.com>
>> Date: 12/12/2008 02:03 PM
>>
>>>
>>> How are fedora-announce, the blogs and the webpages NOT this?
>>>
>>
>> We need an applet that notifies users of announce e-mails or some form of
>> libnotify box that says "hey stupid, read this Fedora news." New users
>> typically care less about mailing lists, blogs, and webpages unless they are
>> looking to set up new software like Samba sharing or have a bug like the
>> PackageKit dependency.
>>
>> From my own experience, I could care less about visiting Fedora web sites
>> daily. Should all end users pour hours of their lives into reading web pages
>> and blogs daily? No, the process should be done for them.
>>
>
>
> okay, so as much as this makes me cringe I'll suggest something probably
> crack filled:
>
> - additional metadata file of notices in repodata
> - each notice has an id on it
> - a yum plugin or pk or what not - records the notices you've seen
> - as it finds new ones it emits them for you.
>
> that wouldn't really help us in the situation where an update broke the
> update system, of course.


I was thinking more of a human driven system.

Example:

1) The recent email to the announce list would be "sent out" to all
F10 users as a "critical alerting" instructing them accordingly.

2) Something takes down the build system, a "infrastructure alert:
would go out letting everyone know that updates will be dead for x
hours"

3) ...  i think you get the drift

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From skvidal at fedoraproject.org  Fri Dec 12 22:15:33 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 12 Dec 2008 17:15:33 -0500 (EST)
Subject: Fedora Com System ? (was: Package updating problem and
 solutions)
In-Reply-To: <16de708d0812121412w72c13242se6a33b8c739e3fde@mail.gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<4942CC10.4050908@cchtml.com>
	<alpine.LFD.2.00.0812121606010.22105@localhost.localdomain>
	<16de708d0812121412w72c13242se6a33b8c739e3fde@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812121714420.24125@localhost.localdomain>



On Fri, 12 Dec 2008, Arthur Pemberton wrote:
>
>
> I was thinking more of a human driven system.
>
> Example:
>
> 1) The recent email to the announce list would be "sent out" to all
> F10 users as a "critical alerting" instructing them accordingly.

We don't have any way to notify all fedora users. We don't even remotely 
have anything like a users list and we won't be getting one.


> 2) Something takes down the build system, a "infrastructure alert:
> would go out letting everyone know that updates will be dead for x
> hours"

and that would be sent, where?



>
> 3) ...  i think you get the drift

not exactly.

-sv



From pertusus at free.fr  Fri Dec 12 22:18:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 12 Dec 2008 23:18:34 +0100
Subject: A way out of the update trap
In-Reply-To: <604aa7910812121240q46058b61g98d329e250194797@mail.gmail.com>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
	<20081212195950.GA2866@free.fr>
	<604aa7910812121240q46058b61g98d329e250194797@mail.gmail.com>
Message-ID: <20081212221834.GA5627@free.fr>

On Fri, Dec 12, 2008 at 11:40:07AM -0900, Jeff Spaleta wrote:
> On Fri, Dec 12, 2008 at 10:59 AM, Patrice Dumas <pertusus at free.fr> wrote:
> > I'd propose, more largely @code, @base and dependencies.
> 
> For me, lowering the risk of the potential breakage of update
> functionality breakage is the number 1 priority in terms of critical
> functionality.  I dare you to suggest an alternative specific
> functionality. If we can't even settle on one specific functionality
> as a priority we've no chance a targetting all of @core and @base.

I think that the boot to console sequence should also be preserved. And
networking too (not networking reconfiguration). Reading comps, indeed, 
@core + @base is too much. Even @core has some non critical packages, 
like authconfig and ed... 

I propose for the console part:
yum, rpm, initscripts, mkinitrd, the bootloaders, kbd, shadow-utils, 
(passwd?).

And basic network:
iproute, dhclient


And dependencies of those packages basesystem, bash, coreutils, 
util-linux-ng, ncurses, libgcc, filesystem, e2fsprogs, cpio, glibc, 
curl, python...

--
Pat



From stickster at gmail.com  Fri Dec 12 22:29:38 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 12 Dec 2008 17:29:38 -0500
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <385866f0812121242k3e954104ofdde13b2e19c203b@mail.gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
	<alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
	<20081212213110.079d449e.mschwendt@gmail.com>
	<alpine.LFD.2.00.0812121531530.22105@localhost.localdomain>
	<385866f0812121242k3e954104ofdde13b2e19c203b@mail.gmail.com>
Message-ID: <20081212222938.GG19799@localhost.localdomain>

On Fri, Dec 12, 2008 at 10:42:13PM +0200, Muayyad AlSadi wrote:
> the announce mailing list should be visible in some web site that support rss
> 
> and let firefox or any rss reader configured by default for it

Gmane provides this:
http://rss.gmane.org/messages/excerpts/gmane.linux.redhat.fedora.core.announce

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/0f9113d1/attachment.sig>

From notting at redhat.com  Fri Dec 12 22:39:39 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 12 Dec 2008 17:39:39 -0500
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>
References: <1228507530.3275.53.camel@localhost.localdomain>
	<20081205201621.GC3227@free.fr> <493CD84F.6010309@redhat.com>
	<20081208111231.GB2611@free.fr> <ghk08m$ru3$1@ger.gmane.org>
	<20081208213830.GA2885@free.fr>
	<604aa7910812081512h612b75a1sb84f73d7945f0799@mail.gmail.com>
	<6d06ce20812081813v58b7d6f8pd07e8a514615fac0@mail.gmail.com>
	<20081209151206.GA13238@nostromo.devel.redhat.com>
	<604aa7910812111819j2fc48ecdg94889ff4f15bd36d@mail.gmail.com>
Message-ID: <20081212223939.GA21093@nostromo.devel.redhat.com>

Jeff Spaleta (jspaleta at gmail.com) said: 
> On Tue, Dec 9, 2008 at 6:12 AM, Bill Nottingham <notting at redhat.com> wrote:
> > I'm not sure why a dependency on vim-minimal is truly that bad.
> 
> Is this a requirement on vim-minimal or just a requirement for a posix
> compliant editor to be available?

It's a requirement on whatever provides _PATH_VI, as defined by
glibc's /usr/include/paths.h.

Bill



From lesmikesell at gmail.com  Fri Dec 12 22:41:53 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Dec 2008 16:41:53 -0600
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <alpine.LFD.2.00.0812121714420.24125@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>	<4942CC10.4050908@cchtml.com>	<alpine.LFD.2.00.0812121606010.22105@localhost.localdomain>	<16de708d0812121412w72c13242se6a33b8c739e3fde@mail.gmail.com>
	<alpine.LFD.2.00.0812121714420.24125@localhost.localdomain>
Message-ID: <4942E8B1.9030906@gmail.com>

Seth Vidal wrote:
> 
> 
> On Fri, 12 Dec 2008, Arthur Pemberton wrote:
>>
>>
>> I was thinking more of a human driven system.
>>
>> Example:
>>
>> 1) The recent email to the announce list would be "sent out" to all
>> F10 users as a "critical alerting" instructing them accordingly.
> 
> We don't have any way to notify all fedora users. We don't even remotely 
> have anything like a users list and we won't be getting one.

Why not put info in a package that updates like binaries with some tool 
to display the latest version at various occasions (bootup, starting 
updates, updates that pull a new version, etc.?

> 
>> 2) Something takes down the build system, a "infrastructure alert:
>> would go out letting everyone know that updates will be dead for x
>> hours"
> 
> and that would be sent, where?

Of course it wouldn't work to notify that the update system was broken...

-- 
   Les Mikesell
     lesmikesell at gmail.com



From notting at redhat.com  Fri Dec 12 22:44:00 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 12 Dec 2008 17:44:00 -0500
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <1229109553.6392.3.camel@code.and.org>
References: <ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
	<1229109553.6392.3.camel@code.and.org>
Message-ID: <20081212224400.GB21093@nostromo.devel.redhat.com>

James Antill (james at fedoraproject.org) said: 
>  And this is _better_ than the simple karma system?

Moreover, it's good to have 'works for me' comments that imply the
build works in general, and has no regressions. Those aren't necessarily
going to be tied to a particular bugzilla that the update fixes, nor
are they necessarily useful to have in the comments field of such
a bugzilla.

Bill



From ian at gallowit.com  Fri Dec 12 22:47:49 2008
From: ian at gallowit.com (Ian Amess)
Date: Fri, 12 Dec 2008 22:47:49 +0000
Subject: Where do we go from here DBus problem?
Message-ID: <4942EA15.8090100@gallowit.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, so we are where we are, not a good place to be but! What is the
best way to fix it?

After a number of days some things have been fixed others are being
worked on, but not everything is fixed.

Can the DBus security fix be reverted until its impact is fully
understood?

Does anyone have an understanding of exactly what is broken an what isn't?

Can some sort out a matrix - to be released to the community - of what
is known i.e.

    affected but fixed
    affected being worked on
    unsure
    not affected

I think this would be useful for the obvious reasons not least good
(agh I hate saying it) PR!


 
   
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJQuoHzR2KhuAWJ/gRAkNjAKC7NmdjOxkpTJK4axg7qNQcHshTqQCdF06h
Qfm01bwF3Hw0QoSll+Pu/e0=
=j3ZX
-----END PGP SIGNATURE-----





From pemboa at gmail.com  Fri Dec 12 22:51:36 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 16:51:36 -0600
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <alpine.LFD.2.00.0812121714420.24125@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<4942CC10.4050908@cchtml.com>
	<alpine.LFD.2.00.0812121606010.22105@localhost.localdomain>
	<16de708d0812121412w72c13242se6a33b8c739e3fde@mail.gmail.com>
	<alpine.LFD.2.00.0812121714420.24125@localhost.localdomain>
Message-ID: <16de708d0812121451r2cf0d6ebyfa7201c805f28a1c@mail.gmail.com>

On Fri, Dec 12, 2008 at 4:15 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>
>
> On Fri, 12 Dec 2008, Arthur Pemberton wrote:
>>
>>
>> I was thinking more of a human driven system.
>>
>> Example:
>>
>> 1) The recent email to the announce list would be "sent out" to all
>> F10 users as a "critical alerting" instructing them accordingly.
>
> We don't have any way to notify all fedora users. We don't even remotely
> have anything like a users list and we won't be getting one.

Well, all I think would be necessary is a preloaded RSS applet that is
tuned into a Fedora feed.
- no maintaining of a user list
- no actual sending (I think that the majority of the people who would
benefit from this won't care that this information isn't actually
being spent to them specifically)

>> 2) Something takes down the build system, a "infrastructure alert:
>> would go out letting everyone know that updates will be dead for x
>> hours"
>
> and that would be sent, where?

Ok, I clearly shouldn't have used the word sent. I was just trying to
give the image of something more intelligent than an RSS reader, but
using the same basic technologies and principles.

>> 3) ...  i think you get the drift
>
> not exactly

I am thinking in terms of the a "Fedora Radio" which sits on the
desktop and lets people know when things are happening, with an
adjustable "debug level". So it would just pull stuff from a feed and
only display relevant alerts, kind of like those weather radios used
in the USA (http://www.weather.gov/nwr/) Something that the user
doesn't have to mess with to have it be useful, but can be be messed
with to make less annoying (if someone would find that annoying)

This is seemingly a lot clearer and logical in my head, will attempt
to draw a flow chart or so at some later point.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pemboa at gmail.com  Fri Dec 12 22:54:04 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 12 Dec 2008 16:54:04 -0600
Subject: Fedora Com System ? (was: Package updating problem and
	solutions)
In-Reply-To: <4942E8B1.9030906@gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<4942CC10.4050908@cchtml.com>
	<alpine.LFD.2.00.0812121606010.22105@localhost.localdomain>
	<16de708d0812121412w72c13242se6a33b8c739e3fde@mail.gmail.com>
	<alpine.LFD.2.00.0812121714420.24125@localhost.localdomain>
	<4942E8B1.9030906@gmail.com>
Message-ID: <16de708d0812121454p77bcce7ft1855947719f37a73@mail.gmail.com>

On Fri, Dec 12, 2008 at 4:41 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Seth Vidal wrote:
[ snip ]
>> We don't have any way to notify all fedora users. We don't even remotely
>> have anything like a users list and we won't be getting one.
>
> Why not put info in a package that updates like binaries with some tool to
> display the latest version at various occasions (bootup, starting updates,
> updates that pull a new version, etc.?

Well, again. For this to be useful when "shit hits the fan" it would
need to be fairly detached from other core services.

>>
>>> 2) Something takes down the build system, a "infrastructure alert:
>>> would go out letting everyone know that updates will be dead for x
>>> hours"
>>
>> and that would be sent, where?
>
> Of course it wouldn't work to notify that the update system was broken...

Exactly.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mike at cchtml.com  Fri Dec 12 22:53:38 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Fri, 12 Dec 2008 16:53:38 -0600
Subject: Fedora Com System ? (was: Package updating problem
	and	solutions)
In-Reply-To: <16de708d0812121451r2cf0d6ebyfa7201c805f28a1c@mail.gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>	<4942CC10.4050908@cchtml.com>	<alpine.LFD.2.00.0812121606010.22105@localhost.localdomain>	<16de708d0812121412w72c13242se6a33b8c739e3fde@mail.gmail.com>	<alpine.LFD.2.00.0812121714420.24125@localhost.localdomain>
	<16de708d0812121451r2cf0d6ebyfa7201c805f28a1c@mail.gmail.com>
Message-ID: <4942EB72.2030108@cchtml.com>

-------- Original Message --------
Subject: Re: Fedora Com System ? (was: Package updating problem and 
solutions)
From: Arthur Pemberton <pemboa at gmail.com>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 12/12/2008 04:51 PM

> 
> I am thinking in terms of the a "Fedora Radio" which sits on the
> desktop and lets people know when things are happening, with an
> adjustable "debug level". So it would just pull stuff from a feed and
> only display relevant alerts, kind of like those weather radios used
> in the USA (http://www.weather.gov/nwr/) Something that the user
> doesn't have to mess with to have it be useful, but can be be messed
> with to make less annoying (if someone would find that annoying)
> 
> This is seemingly a lot clearer and logical in my head, will attempt
> to draw a flow chart or so at some later point.
> 

Oh.... Fedora Radio. I like it. RSS feed that could be sent across 
mirrors just like packages.



From rjones at redhat.com  Fri Dec 12 22:57:05 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 12 Dec 2008 22:57:05 +0000
Subject: Perseus Digital Library?
In-Reply-To: <4942CF37.9050804@redhat.com>
References: <4942CF37.9050804@redhat.com>
Message-ID: <20081212225705.GA3023@amd.home.annexia.org>

On Fri, Dec 12, 2008 at 03:53:11PM -0500, Jonathan Robie wrote:
> Does anyone have plans to create a Fedora RPM for the Perseus Digital  
> Library?
>
> http://www.perseus.tufts.edu/hopper/opensource
>
> I'm not quite ready to commit to creating one, but I'm definitely  
> playing with the idea. I'd have to figure out roughly how much of my  
> free time would be needed first.

Incidentally, isn't the non-commercial license incompatible with
Fedora?  And more to the point, aren't these texts unquestionably
public domain (the ancient Greeks never had such a concept as
copyright, and the collections date from 300-2500 years old) ...

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From mrsam at courier-mta.com  Fri Dec 12 22:57:25 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Fri, 12 Dec 2008 17:57:25 -0500
Subject: Alternatives to serial console for capturing oopses
Message-ID: <cone.1229122645.115179.23287.500@commodore.email-scan.com>

I've got a quad-core dual x86_64 server that, so far, reproducably locks up 
under every 2.6.27 kernel released for F9 so far, when I run a build cycle. 
The last kernel that manages to survive under load is 2.6.26.6-79.fc9, so 
I'll continue to boot it until I get a 2.6.27 kernel that doesn't croak on 
me.

Given that the hardware does not have a serial port, how else can I capture 
an oops, if one is being generated? At least I hope that there'll be an oops 
for me to capture.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/3c6df5b7/attachment.sig>

From lsof at nodata.co.uk  Fri Dec 12 23:06:44 2008
From: lsof at nodata.co.uk (nodata)
Date: Sat, 13 Dec 2008 00:06:44 +0100
Subject: Alternatives to serial console for capturing oopses
In-Reply-To: <cone.1229122645.115179.23287.500@commodore.email-scan.com>
References: <cone.1229122645.115179.23287.500@commodore.email-scan.com>
Message-ID: <1229123204.2898.1.camel@sb-home>

Am Freitag, den 12.12.2008, 17:57 -0500 schrieb Sam Varshavchik:
> I've got a quad-core dual x86_64 server that, so far, reproducably locks up 
> under every 2.6.27 kernel released for F9 so far, when I run a build cycle. 
> The last kernel that manages to survive under load is 2.6.26.6-79.fc9, so 
> I'll continue to boot it until I get a 2.6.27 kernel that doesn't croak on 
> me.
> 
> Given that the hardware does not have a serial port, how else can I capture 
> an oops, if one is being generated? At least I hope that there'll be an oops 
> for me to capture.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Take a look at netdump.



From jonathan.robie at redhat.com  Fri Dec 12 23:12:32 2008
From: jonathan.robie at redhat.com (Jonathan Robie)
Date: Fri, 12 Dec 2008 18:12:32 -0500
Subject: Perseus Digital Library?
In-Reply-To: <20081212225705.GA3023@amd.home.annexia.org>
References: <4942CF37.9050804@redhat.com>
	<20081212225705.GA3023@amd.home.annexia.org>
Message-ID: <4942EFE0.1010105@redhat.com>

Richard W.M. Jones wrote:
> On Fri, Dec 12, 2008 at 03:53:11PM -0500, Jonathan Robie wrote:
>   
>> Does anyone have plans to create a Fedora RPM for the Perseus Digital  
>> Library?
>>
>> http://www.perseus.tufts.edu/hopper/opensource
>>
>> I'm not quite ready to commit to creating one, but I'm definitely  
>> playing with the idea. I'd have to figure out roughly how much of my  
>> free time would be needed first.
>>     
>
> Incidentally, isn't the non-commercial license incompatible with
> Fedora? 

If it is, that would answer the question ....

> And more to the point, aren't these texts unquestionably
> public domain (the ancient Greeks never had such a concept as
> copyright, and the collections date from 300-2500 years old) ...
>   

Probably not "unquestionably", people use textual criticism to assemble 
a text, one edition of a given Greek work looks a little different from 
another. People who create critical texts have typically copyrighted them.

But I'm not sure what issue you are pointing at here. Educate me!

Jonathan



From rjones at redhat.com  Fri Dec 12 23:18:31 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 12 Dec 2008 23:18:31 +0000
Subject: Perseus Digital Library?
In-Reply-To: <4942EFE0.1010105@redhat.com>
References: <4942CF37.9050804@redhat.com>
	<20081212225705.GA3023@amd.home.annexia.org>
	<4942EFE0.1010105@redhat.com>
Message-ID: <20081212231831.GA3105@amd.home.annexia.org>

On Fri, Dec 12, 2008 at 06:12:32PM -0500, Jonathan Robie wrote:
> Richard W.M. Jones wrote:
>> On Fri, Dec 12, 2008 at 03:53:11PM -0500, Jonathan Robie wrote:
>>   
>>> Does anyone have plans to create a Fedora RPM for the Perseus Digital 
>>>  Library?
>>>
>>> http://www.perseus.tufts.edu/hopper/opensource
>>>
>>> I'm not quite ready to commit to creating one, but I'm definitely   
>>> playing with the idea. I'd have to figure out roughly how much of my  
>>> free time would be needed first.
>>>     
>>
>> Incidentally, isn't the non-commercial license incompatible with
>> Fedora? 
>
> If it is, that would answer the question ....
>
>> And more to the point, aren't these texts unquestionably
>> public domain (the ancient Greeks never had such a concept as
>> copyright, and the collections date from 300-2500 years old) ...
>>   
>
> Probably not "unquestionably", people use textual criticism to assemble  
> a text, one edition of a given Greek work looks a little different from  
> another. People who create critical texts have typically copyrighted 
> them.
>
> But I'm not sure what issue you are pointing at here. Educate me!

Well, I'm just looking at the URL you posted before:

http://www.perseus.tufts.edu/hopper/opensource

<quote>
  Texts are licensed under the Creative Commons NonCommercial
  ShareAlike 3.0 license
</quote>

BTW, I can probably help here, coz I read classical Greek & Latin
moderately well, and it'd be great to have truly free texts in Fedora.

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 jkeating at redhat.com  Fri Dec 12 23:58:58 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 15:58:58 -0800
Subject: Where do we go from here DBus problem?
In-Reply-To: <4942EA15.8090100@gallowit.com>
References: <4942EA15.8090100@gallowit.com>
Message-ID: <1229126338.3863.158.camel@localhost.localdomain>

On Fri, 2008-12-12 at 22:47 +0000, Ian Amess wrote:
> After a number of days some things have been fixed others are being
> worked on, but not everything is fixed.

Do you have examples of things currently not fixed?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/2906c56c/attachment.sig>

From mike at cchtml.com  Sat Dec 13 00:02:37 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Fri, 12 Dec 2008 18:02:37 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <4942EA15.8090100@gallowit.com>
References: <4942EA15.8090100@gallowit.com>
Message-ID: <4942FB9D.2050008@cchtml.com>

Ian Amess wrote:
> After a number of days some things have been fixed others are being
> worked on, but not everything is fixed.
>   


Some additional updates for affected packages are in updates-testing. 
Check there for a package for your broken program, or file a bug about 
it if you cannot find one.

The discussion for future prevention is ongoing in several threads, IRC, 
and who knows elsewhere.




From ian at gallowit.com  Sat Dec 13 00:16:59 2008
From: ian at gallowit.com (Ian Amess)
Date: Sat, 13 Dec 2008 00:16:59 +0000
Subject: Where do we go from here DBus problem?
In-Reply-To: <1229126338.3863.158.camel@localhost.localdomain>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
Message-ID: <4942FEFB.3090001@gallowit.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shutdown and Reboot from KDE is broken, Kbluetooth4 just hangs these
are examples.

I have a question, why, when it was realised how much of a problem
this update was, it was not just regressed?


Jesse Keating wrote:
> On Fri, 2008-12-12 at 22:47 +0000, Ian Amess wrote:
>> After a number of days some things have been fixed others are being
>> worked on, but not everything is fixed.
>
> Do you have examples of things currently not fixed?
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJQv7xzR2KhuAWJ/gRAgtIAJ9L+TEo/sRlMFkD2DVVieYK3MMp6QCgp/Vm
dyuH08prBh6UpS2ToAi+1dw=
=HMO3
-----END PGP SIGNATURE-----



From jkeating at redhat.com  Sat Dec 13 00:19:51 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Dec 2008 16:19:51 -0800
Subject: Where do we go from here DBus problem?
In-Reply-To: <4942FEFB.3090001@gallowit.com>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<4942FEFB.3090001@gallowit.com>
Message-ID: <1229127591.3863.159.camel@localhost.localdomain>

On Sat, 2008-12-13 at 00:16 +0000, Ian Amess wrote:
> Shutdown and Reboot from KDE is broken, Kbluetooth4 just hangs these
> are examples.

Are you aware of a tracker bug tracking all these related issues so that
we can get the whole picture?

> I have a question, why, when it was realised how much of a problem
> this update was, it was not just regressed?

I think that's because the developers and maintainers in question did
not, and perhaps still don't, know the entire extent of the problem, and
whether or not it would be quicker to fix the broken apps vs putting the
old dbus back in place.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/2c723d1f/attachment.sig>

From alsadi at gmail.com  Sat Dec 13 00:22:08 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sat, 13 Dec 2008 02:22:08 +0200
Subject: Where do we go from here DBus problem?
In-Reply-To: <4942FEFB.3090001@gallowit.com>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<4942FEFB.3090001@gallowit.com>
Message-ID: <385866f0812121622l681d4012vdeaa6ee63d2c0c4c@mail.gmail.com>

check the output of
find /etc/dbus-1/ -name '*.conf' | xargs rpm -qf | sort | uniq

they should all be double checked

this one https://bugzilla.redhat.com/show_bug.cgi?id=476043
is in updates-testing



From kevin.kofler at chello.at  Sat Dec 13 00:24:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 13 Dec 2008 01:24:55 +0100
Subject: Perseus Digital Library?
References: <4942CF37.9050804@redhat.com>
	<20081212225705.GA3023@amd.home.annexia.org>
	<4942EFE0.1010105@redhat.com>
	<20081212231831.GA3105@amd.home.annexia.org>
Message-ID: <ghuvcn$fsd$1@ger.gmane.org>

Richard W.M. Jones wrote:
> http://www.perseus.tufts.edu/hopper/opensource
> 
> <quote>
>   Texts are licensed under the Creative Commons NonCommercial
>   ShareAlike 3.0 license
> </quote>

That is clearly not OK for Fedora (it's non-Free), nor is it Open Source (in
the sense defined by the OSI).

Complain to them about diluting the term "Open Source".

        Kevin Kofler



From ian at gallowit.com  Sat Dec 13 00:29:08 2008
From: ian at gallowit.com (Ian Amess)
Date: Sat, 13 Dec 2008 00:29:08 +0000
Subject: Where do we go from here DBus problem?
In-Reply-To: <1229127591.3863.159.camel@localhost.localdomain>
References: <4942EA15.8090100@gallowit.com>	<1229126338.3863.158.camel@localhost.localdomain>	<4942FEFB.3090001@gallowit.com>
	<1229127591.3863.159.camel@localhost.localdomain>
Message-ID: <494301D4.8080000@gallowit.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

No exactly, there are a number of bugs on bugzilla that concentrate on
individual packages but I haven't found a single bug specifically on
this issue, I have found these:

    475074
    475160
    475200

BTW any comments found in these, attributed to me, are merely born of
frustration.



Jesse Keating wrote:
> On Sat, 2008-12-13 at 00:16 +0000, Ian Amess wrote:
>> Shutdown and Reboot from KDE is broken, Kbluetooth4 just hangs these
>> are examples.
>
> Are you aware of a tracker bug tracking all these related issues so that
> we can get the whole picture?
>
>> I have a question, why, when it was realised how much of a problem
>> this update was, it was not just regressed?
>
> I think that's because the developers and maintainers in question did
> not, and perhaps still don't, know the entire extent of the problem, and
> whether or not it would be quicker to fix the broken apps vs putting the
> old dbus back in place.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJQwHMzR2KhuAWJ/gRApR7AJ9vFW1bB/+o0jHz7dAC5kMHFeiaPQCfbaM/
jWQ6QGQgDvmcGjcF0Frdu00=
=iw5r
-----END PGP SIGNATURE-----



From kevin.kofler at chello.at  Sat Dec 13 00:41:41 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 13 Dec 2008 01:41:41 +0100
Subject: Where do we go from here DBus problem?
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
Message-ID: <ghv0c5$k5q$1@ger.gmane.org>

Jesse Keating wrote:
> Do you have examples of things currently not fixed?

https://bugzilla.redhat.com/show_bug.cgi?id=475444 "Can't shutdown or
restart any more; only "logout" is available" (KDE with GDM)
I wrote the KDE side of the offending code, I looked at it and the
ConsoleKit D-Bus policy, but I have no idea why D-Bus is now blocking my
messages (the policy looks OK). I asked for help from the ConsoleKit
maintainer (William Jon McCann) and from the maintainer who did the D-Bus
security fix (Colin Walters), neither replied yet.

https://bugzilla.redhat.com/show_bug.cgi?id=475468 "knetworkmanager:
incorrect default DBUS configuration"
KNetworkManager is not the default in F10 (NetworkManager-gnome is the
default even in the KDE spin), but still everyone who switched to it now
has no working networking anymore (unless they revert and/or block the
D-Bus update).

And I know there's more of those, just search in Bugzilla.

The D-Bus policy really ought to be reverted and never touched again in F8,
F9 and F10. This should only be changed in F11 or even F12. The change is
just not ready for production use at all.

        Kevin Kofler



From mrsam at courier-mta.com  Sat Dec 13 01:10:54 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Fri, 12 Dec 2008 20:10:54 -0500
Subject: Alternatives to serial console for capturing oopses
References: <cone.1229122645.115179.23287.500@commodore.email-scan.com>
	<1229123204.2898.1.camel@sb-home>
Message-ID: <cone.1229130654.603222.26677.500@commodore.email-scan.com>

nodata writes:

> Am Freitag, den 12.12.2008, 17:57 -0500 schrieb Sam Varshavchik:
>> I've got a quad-core dual x86_64 server that, so far, reproducably locks up 
>> under every 2.6.27 kernel released for F9 so far, when I run a build cycle. 
>> The last kernel that manages to survive under load is 2.6.26.6-79.fc9, so 
>> I'll continue to boot it until I get a 2.6.27 kernel that doesn't croak on 
>> me.
>> 
>> Given that the hardware does not have a serial port, how else can I capture 
>> an oops, if one is being generated? At least I hope that there'll be an oops 
>> for me to capture.
>> 
> 
> Take a look at netdump.

Took a look.

1) Only the server component is present in Fedora. There is no client. And, 
of course, I need the client.

2) The client package requires additional kernel modules to be built. If you 
are actually using netdump in Fedora, please explain how.

3) netdump only supports a small set of NICs. netdump does not support my 
NIC.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/fe13adaf/attachment.sig>

From walters at verbum.org  Sat Dec 13 01:39:09 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 12 Dec 2008 20:39:09 -0500
Subject: Where do we go from here DBus problem?
In-Reply-To: <ghv0c5$k5q$1@ger.gmane.org>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<ghv0c5$k5q$1@ger.gmane.org>
Message-ID: <faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>

On Fri, Dec 12, 2008 at 7:41 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:

> The D-Bus policy really ought to be reverted and never touched again in F8,
> F9 and F10. This should only be changed in F11 or even F12. The change is
> just not ready for production use at all.

I've been working through things this week and had hoped a lot would
get fixed, but at this point it has turned into an enormous ball of
yarn.  So thinking about it I suppose you're right.

I'll do an upload which reverts by tomorrow.



From ian at gallowit.com  Sat Dec 13 01:56:32 2008
From: ian at gallowit.com (Ian Amess)
Date: Sat, 13 Dec 2008 01:56:32 +0000
Subject: Where do we go from here DBus problem?
In-Reply-To: <faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>	<1229126338.3863.158.camel@localhost.localdomain>	<ghv0c5$k5q$1@ger.gmane.org>
	<faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
Message-ID: <49431650.2000207@gallowit.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Can I suggest that some sort of an announcement is made, there are a
lot of people out there probably having problems and it might save a
lot of people a lot of time.

Colin Walters wrote:
> On Fri, Dec 12, 2008 at 7:41 PM, Kevin Kofler
> <kevin.kofler at chello.at> wrote:
>
>> The D-Bus policy really ought to be reverted and never touched
>> again in F8, F9 and F10. This should only be changed in F11 or
>> even F12. The change is just not ready for production use at all.
>>
>
> I've been working through things this week and had hoped a lot
> would get fixed, but at this point it has turned into an enormous
> ball of yarn.  So thinking about it I suppose you're right.
>
> I'll do an upload which reverts by tomorrow.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJQxZIzR2KhuAWJ/gRArrtAKCbDddGac3WdfRpHsMzioE1J/ymiwCfczlJ
ItZw4ZMkH8u7d01qd6kYx4k=
=240U
-----END PGP SIGNATURE-----



From dtimms at iinet.net.au  Sat Dec 13 02:20:49 2008
From: dtimms at iinet.net.au (David Timms)
Date: Sat, 13 Dec 2008 13:20:49 +1100
Subject: Fedora Com System http://fedoraproject.org/ , un-release updates
 ?
In-Reply-To: <20081212222938.GG19799@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>	<alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>	<20081212213110.079d449e.mschwendt@gmail.com>	<alpine.LFD.2.00.0812121531530.22105@localhost.localdomain>	<385866f0812121242k3e954104ofdde13b2e19c203b@mail.gmail.com>
	<20081212222938.GG19799@localhost.localdomain>
Message-ID: <49431C01.6020900@iinet.net.au>

Paul W. Frields wrote:
> On Fri, Dec 12, 2008 at 10:42:13PM +0200, Muayyad AlSadi wrote:
>> the announce mailing list should be visible in some web site that support rss
>>
>> and let firefox or any rss reader configured by default for it
> 
> Gmane provides this:
> http://rss.gmane.org/messages/excerpts/gmane.linux.redhat.fedora.core.announce
I like gmane for this sort of archive tracking.

Would fedoraproject be OK, to add that as a link in the default web 
browser bookmarks ?

As well as http://news.gmane.org/gmane.linux.redhat.fedora.core.announce
, which shows the most recent item expanded out by default.

{no not the ugly mailing list archive on .redhat}.

However, don't miss the importance of:
http://fedoraproject.org/
http://fedoraproject.org/wiki/

While I might be expecting better response than is possible, it would 
have been a far improved user experience if the moment that the problem 
become known, that a prominent message at the top of both sites to 
inform them of the fau paux:
-----
2008-12-09 Tuesday: Special announcement: please defer updating your 
Fedora installation for up to 5 days while our developer community works 
on an incompatibility issue with some recently released updates. 
Deferring your updates will avoid the symptoms described below, and 
allow normal updates to work without using the workaround below.

:details link:

   Nature of issue:
Users who update the software on their Fedora (10,9 or 8) system between 
the 8th of December and 13th of December will be confronted by an 
incompatibility between gnome-PackageKit (the graphical update manager), 
and the DBUS application communication system. This is seen as: a 
recurring dialog stating "Failed to reset client - Failed to resolve"

   Resolution of issue:
Maintainers of the software packages involved are working to completely 
resolve the issue. This is expected to be begin testing within 3 days, 
and once QA process are complete be made available for general consumption.

   Workaround:
Since the issue only causes the GUI package manager to be unable to 
operate normally, the underlying package management system [rpm] and 
update tools [yum] continue to work correctly. If you are seeing the 
symptoms noted in the nature of the issue, then you can still use yum to 
update your system from the command line:
{like Paul's email}...
# yum update

This note will be updated once the updates have been released.
-----
So that took me 20 minutes to write. How much time would it have taken 
for infrastructure to make it available as an include on fedoraproject 
web pages ?

We really don't want or users to hit issues, _after_ we know about them. 
  So given a user is likely to click on "update me" before reading any 
mail, web, or rss feeds, the second step should have been to make the 
dodgy update invisible/unavailable etc perhaps by:

- immediate issue an updated repo metadata that does not have the 
possible culprits visible (eg put current date on the most recent known 
good repodata

- immediately replace the .rpm files in the master repo with broken rpms
of 1 byte or something - so as not to waste download consumption. These 
would get mirrored widely, overwriting the dodgy rpm, and making them 
unavailable even though some mirror repodata says they are available.

- updating metadata to indicate a set of packages that will never exist
: eg PackageKit-1.2.3-4.does_not_exist.rpm

Are any of these things possible ? Issues ?
Could bodhi/release tools be extended to have a "Release Engineer" 
button saying revert repodata to date=xxx, so that it becomes easy to 
implement one of the above ?

DaveT.



From walters at verbum.org  Sat Dec 13 02:50:44 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 12 Dec 2008 21:50:44 -0500
Subject: Where do we go from here DBus problem?
In-Reply-To: <faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<ghv0c5$k5q$1@ger.gmane.org>
	<faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
Message-ID: <faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>

On Fri, Dec 12, 2008 at 8:39 PM, Colin Walters <walters at verbum.org> wrote:
> On Fri, Dec 12, 2008 at 7:41 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>
>> The D-Bus policy really ought to be reverted and never touched again in F8,
>> F9 and F10. This should only be changed in F11 or even F12. The change is
>> just not ready for production use at all.
>
> I've been working through things this week and had hoped a lot would
> get fixed, but at this point it has turned into an enormous ball of
> yarn.  So thinking about it I suppose you're right.
>
> I'll do an upload which reverts by tomorrow.

F10:
https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
F9:
https://koji.fedoraproject.org/koji/buildinfo?buildID=74524

Any testing before tomorrow is greatly appreciated, I've tested a
local F10 on my machine.  After that I'll make a Bodhi update.



From jamundso at gmail.com  Sat Dec 13 04:22:39 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 12 Dec 2008 22:22:39 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<ghv0c5$k5q$1@ger.gmane.org>
	<faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
Message-ID: <6d06ce20812122022v28782bb6q3d0e5127c120aece@mail.gmail.com>

On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org> wrote:
> F10:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
> F9:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=74524

koji returns:

Secure Connection Failed
An error occurred during a connection to koji.fedoraproject.org.
SSL peer was unable to negotiate an acceptable set of security parameters.
(Error code: ssl_error_handshake_failure_alert)

jerry

-- 
TBD.



From jamundso at gmail.com  Sat Dec 13 04:26:19 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 12 Dec 2008 22:26:19 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <6d06ce20812122022v28782bb6q3d0e5127c120aece@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<ghv0c5$k5q$1@ger.gmane.org>
	<faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
	<6d06ce20812122022v28782bb6q3d0e5127c120aece@mail.gmail.com>
Message-ID: <6d06ce20812122026u8357d6ao1640a0f0623de90a@mail.gmail.com>

On Fri, Dec 12, 2008 at 10:22 PM, Jerry Amundson <jamundso at gmail.com> wrote:
> On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org> wrote:
>> F10:
>> https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
>> F9:
>> https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
>
> koji returns:
>
> Secure Connection Failed
> An error occurred during a connection to koji.fedoraproject.org.
> SSL peer was unable to negotiate an acceptable set of security parameters.
> (Error code: ssl_error_handshake_failure_alert)

For grins, I tried the port 80 version,
http://koji.fedoraproject.org/koji/buildinfo?buildID=74525F9

Mod_python error: "PythonHandler mod_python.publisher"

Traceback (most recent call last):

  File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line
299, in HandlerDispatch
    result = object(req)

  File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py",
line 213, in handler
    published = publish_object(req, object)

  File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py",
line 412, in publish_object
    return publish_object(req,util.apply_fs_data(object, req.form, req=req))

  File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line
439, in apply_fs_data
    return object(**args)

  File "/usr/share/koji-web/scripts/index.py", line 834, in buildinfo
    buildID = int(buildID)

ValueError: invalid literal for int(): 74525F9

jerry

-- 
TBD.



From dennis at ausil.us  Sat Dec 13 04:27:32 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Fri, 12 Dec 2008 22:27:32 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <6d06ce20812122022v28782bb6q3d0e5127c120aece@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
	<6d06ce20812122022v28782bb6q3d0e5127c120aece@mail.gmail.com>
Message-ID: <200812122230.57662.dennis@ausil.us>

On Friday 12 December 2008 10:22:39 pm Jerry Amundson wrote:
> On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org> wrote:
> > F10:
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
> > F9:
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
>
> koji returns:
>
> Secure Connection Failed
> An error occurred during a connection to koji.fedoraproject.org.
> SSL peer was unable to negotiate an acceptable set of security parameters.
> (Error code: ssl_error_handshake_failure_alert)
https  only works if you have a user cert imported in your browser.  use http 
instead of https.

Dennis



From seandarcy2 at gmail.com  Sat Dec 13 04:41:32 2008
From: seandarcy2 at gmail.com (sean darcy)
Date: Fri, 12 Dec 2008 23:41:32 -0500
Subject: Where do we go from here DBus problem?
In-Reply-To: <1229127591.3863.159.camel@localhost.localdomain>
References: <4942EA15.8090100@gallowit.com>	<1229126338.3863.158.camel@localhost.localdomain>	<4942FEFB.3090001@gallowit.com>
	<1229127591.3863.159.camel@localhost.localdomain>
Message-ID: <ghveds$djl$1@ger.gmane.org>

Jesse Keating wrote:
> On Sat, 2008-12-13 at 00:16 +0000, Ian Amess wrote:
>> Shutdown and Reboot from KDE is broken, Kbluetooth4 just hangs these
>> are examples.
> 
> Are you aware of a tracker bug tracking all these related issues so that
> we can get the whole picture?
> 
>> I have a question, why, when it was realised how much of a problem
>> this update was, it was not just regressed?
> 
> I think that's because the developers and maintainers in question did
> not, and perhaps still don't, know the entire extent of the problem, and
> whether or not it would be quicker to fix the broken apps vs putting the
> old dbus back in place.
> 
> 
Hello. This is a mess. Does everyone have to file to have it regressed?

Does no one have a clue?

Hands in the air.

WTF are you guys thinking.

Are you?



From jamundso at gmail.com  Sat Dec 13 05:00:56 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 12 Dec 2008 23:00:56 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <200812122230.57662.dennis@ausil.us>
References: <4942EA15.8090100@gallowit.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
	<6d06ce20812122022v28782bb6q3d0e5127c120aece@mail.gmail.com>
	<200812122230.57662.dennis@ausil.us>
Message-ID: <6d06ce20812122100wc4ba762mea361809da1a9ac3@mail.gmail.com>

On Fri, Dec 12, 2008 at 10:27 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> On Friday 12 December 2008 10:22:39 pm Jerry Amundson wrote:
>> On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org> wrote:
>> > F10:
>> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
>> > F9:
>> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
>>
>> koji returns:
>>
>> Secure Connection Failed
>> An error occurred during a connection to koji.fedoraproject.org.
>> SSL peer was unable to negotiate an acceptable set of security parameters.
>> (Error code: ssl_error_handshake_failure_alert)
> https  only works if you have a user cert imported in your browser.  use http
> instead of https.

Hmm. So, both url's work fine for you?

jerry

-- 
TBD.



From arjan at infradead.org  Sat Dec 13 05:11:45 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Fri, 12 Dec 2008 21:11:45 -0800
Subject: Where do we go from here DBus problem?
In-Reply-To: <1229126338.3863.158.camel@localhost.localdomain>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
Message-ID: <20081212211145.43cfb964@infradead.org>

On Fri, 12 Dec 2008 15:58:58 -0800
Jesse Keating <jkeating at redhat.com> wrote:

> On Fri, 2008-12-12 at 22:47 +0000, Ian Amess wrote:
> > After a number of days some things have been fixed others are being
> > worked on, but not everything is fixed.
> 
> Do you have examples of things currently not fixed?

I have a strong suspicion that the kerneloops applet is broken
(based on a sharp drop of incoming reports since a few days)

> 


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From jamundso at gmail.com  Sat Dec 13 05:22:03 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 12 Dec 2008 23:22:03 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <6d06ce20812122100wc4ba762mea361809da1a9ac3@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
	<6d06ce20812122022v28782bb6q3d0e5127c120aece@mail.gmail.com>
	<200812122230.57662.dennis@ausil.us>
	<6d06ce20812122100wc4ba762mea361809da1a9ac3@mail.gmail.com>
Message-ID: <6d06ce20812122122y125b7b82qef26de0571d599fd@mail.gmail.com>

On Fri, Dec 12, 2008 at 11:00 PM, Jerry Amundson <jamundso at gmail.com> wrote:
> On Fri, Dec 12, 2008 at 10:27 PM, Dennis Gilmore <dennis at ausil.us> wrote:
>> On Friday 12 December 2008 10:22:39 pm Jerry Amundson wrote:
>>> On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org> wrote:
>>> > F10:
>>> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
>>> > F9:
>>> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
>>>
>>> koji returns:
>>>
>>> Secure Connection Failed
>>> An error occurred during a connection to koji.fedoraproject.org.
>>> SSL peer was unable to negotiate an acceptable set of security parameters.
>>> (Error code: ssl_error_handshake_failure_alert)
>> https  only works if you have a user cert imported in your browser.  use http
>> instead of https.
>
> Hmm. So, both url's work fine for you?

Or for anyone else? Feedback from anywhere is good at this point -
anyone around Sydney or Tokyo (or similiar) checking e-mail on (your)
Saturday afternoon?

jerry

-- 
TBD.



From wtogami at redhat.com  Sat Dec 13 05:33:58 2008
From: wtogami at redhat.com (Warren Togami)
Date: Sat, 13 Dec 2008 00:33:58 -0500
Subject: Where do we go from here DBus problem?
In-Reply-To: <faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>	<1229126338.3863.158.camel@localhost.localdomain>	<ghv0c5$k5q$1@ger.gmane.org>	<faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
Message-ID: <49434946.30207@redhat.com>

Colin Walters wrote:
> On Fri, Dec 12, 2008 at 8:39 PM, Colin Walters <walters at verbum.org> wrote:
>> On Fri, Dec 12, 2008 at 7:41 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>>
>>> The D-Bus policy really ought to be reverted and never touched again in F8,
>>> F9 and F10. This should only be changed in F11 or even F12. The change is
>>> just not ready for production use at all.
>> I've been working through things this week and had hoped a lot would
>> get fixed, but at this point it has turned into an enormous ball of
>> yarn.  So thinking about it I suppose you're right.
>>
>> I'll do an upload which reverts by tomorrow.
> 
> F10:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
> F9:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
> 
> Any testing before tomorrow is greatly appreciated, I've tested a
> local F10 on my machine.  After that I'll make a Bodhi update.
> 


Colin, I'm glad that you are reverting this because it was clearly a 
mistake to fundamentally change how it works in the middle of a release.

However might it be possible to improve on this reversion a bit.  Might 
it be possible for apps to output, perhaps to stderr, when it hit a case 
where it would have failed before this reversion?  Then it would be more 
obvious what needs to be fixed in regular updates later, and as we 
approach F11.

Warren Togami
wtogami at redhat.com



From rc040203 at freenet.de  Sat Dec 13 05:46:43 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 13 Dec 2008 06:46:43 +0100
Subject: Updates QA/karma question
In-Reply-To: <1229102225.3863.144.camel@localhost.localdomain>
References: <4942906F.6080603@cora.nwra.com>  <ghu4jo$sr0$1@ger.gmane.org>
	<1229102225.3863.144.camel@localhost.localdomain>
Message-ID: <1229147203.3081.1004.camel@beck.corsepiu.local>

On Fri, 2008-12-12 at 09:17 -0800, Jesse Keating wrote:
> On Fri, 2008-12-12 at 10:47 -0600, Rex Dieter wrote:
> > Orion Poplawski wrote:
> > 
> > > Another update issue that raises some questions -
> > > 
> > > - Does anyone actually read the comments in bodhi before allowing the
> > > push request to proceed?
> > 
> > It's all up to the individual pkg maintainer to "do the right thing, in
> > their best judgment".  Same pretty much applies to all your questions
> > here. :)
> > 
> > -- Rex
> 
> It is also up to the pkg maintainer's sponsor to ensure that the people
> one has sponsored are doing the right thing.

Stop cheating, Keating ... this sponsorship model has stopped working
long time ago.




From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Dec 13 05:53:00 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sat, 13 Dec 2008 14:53:00 +0900
Subject: Where do we go from here DBus problem?
In-Reply-To: <6d06ce20812122122y125b7b82qef26de0571d599fd@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>	<6d06ce20812122022v28782bb6q3d0e5127c120aece@mail.gmail.com>	<200812122230.57662.dennis@ausil.us>	<6d06ce20812122100wc4ba762mea361809da1a9ac3@mail.gmail.com>
	<6d06ce20812122122y125b7b82qef26de0571d599fd@mail.gmail.com>
Message-ID: <49434DBC.1090100@ioa.s.u-tokyo.ac.jp>

Jerry Amundson wrote, at 12/13/2008 02:22 PM +9:00:
> On Fri, Dec 12, 2008 at 11:00 PM, Jerry Amundson <jamundso at gmail.com> wrote:
>> On Fri, Dec 12, 2008 at 10:27 PM, Dennis Gilmore <dennis at ausil.us> wrote:
>>> On Friday 12 December 2008 10:22:39 pm Jerry Amundson wrote:
>>>> On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org> wrote:
>>>>> F10:
>>>>> https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
>>>>> F9:
>>>>> https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
>>>> koji returns:
>>>>
>>>> Secure Connection Failed
>>>> An error occurred during a connection to koji.fedoraproject.org.
>>>> SSL peer was unable to negotiate an acceptable set of security parameters.
>>>> (Error code: ssl_error_handshake_failure_alert)
>>> https  only works if you have a user cert imported in your browser.  use http
>>> instead of https.
>> Hmm. So, both url's work fine for you?
> 
> Or for anyone else? Feedback from anywhere is good at this point -
> anyone around Sydney or Tokyo (or similiar) checking e-mail on (your)
> Saturday afternoon?
> 
> jerry

After you login to koji web interface, https will work
(when I login to koji the URLs above work)
The setup procedure to login to koji can be shown when you
again try $ fedora-packager-setup
(I seldom login to koji so I usually use http to access koji)

Mamoru (from Tokyo)



From dennis at ausil.us  Sat Dec 13 06:08:25 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Sat, 13 Dec 2008 00:08:25 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <6d06ce20812122100wc4ba762mea361809da1a9ac3@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<200812122230.57662.dennis@ausil.us>
	<6d06ce20812122100wc4ba762mea361809da1a9ac3@mail.gmail.com>
Message-ID: <200812130008.28231.dennis@ausil.us>

On Friday 12 December 2008 11:00:56 pm Jerry Amundson wrote:
> On Fri, Dec 12, 2008 at 10:27 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> > On Friday 12 December 2008 10:22:39 pm Jerry Amundson wrote:
> >> On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org> 
wrote:
> >> > F10:
> >> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
> >> > F9:
> >> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
> >>
> >> koji returns:
> >>
> >> Secure Connection Failed
> >> An error occurred during a connection to koji.fedoraproject.org.
> >> SSL peer was unable to negotiate an acceptable set of security
> >> parameters. (Error code: ssl_error_handshake_failure_alert)
> >
> > https  only works if you have a user cert imported in your browser.  use
> > http instead of https.
>
> Hmm. So, both url's work fine for you?
http://koji.fedoraproject.org/koji/buildinfo?buildID=74525   and 
http://koji.fedoraproject.org/koji/buildinfo?buildID=74524  both work fine for 
me 

Dennis



From jamundso at gmail.com  Sat Dec 13 06:22:58 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sat, 13 Dec 2008 00:22:58 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <200812130008.28231.dennis@ausil.us>
References: <4942EA15.8090100@gallowit.com>
	<200812122230.57662.dennis@ausil.us>
	<6d06ce20812122100wc4ba762mea361809da1a9ac3@mail.gmail.com>
	<200812130008.28231.dennis@ausil.us>
Message-ID: <6d06ce20812122222k79463dci50df9161b6ce96ce@mail.gmail.com>

On Sat, Dec 13, 2008 at 12:08 AM, Dennis Gilmore <dennis at ausil.us> wrote:
> On Friday 12 December 2008 11:00:56 pm Jerry Amundson wrote:
>> On Fri, Dec 12, 2008 at 10:27 PM, Dennis Gilmore <dennis at ausil.us> wrote:
>> > On Friday 12 December 2008 10:22:39 pm Jerry Amundson wrote:
>> >> On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org>
> wrote:
>> >> > F10:
>> >> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
>> >> > F9:
>> >> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
>> >>
>> >> koji returns:
>> >>
>> >> Secure Connection Failed
>> >> An error occurred during a connection to koji.fedoraproject.org.
>> >> SSL peer was unable to negotiate an acceptable set of security
>> >> parameters. (Error code: ssl_error_handshake_failure_alert)
>> >
>> > https  only works if you have a user cert imported in your browser.  use
>> > http instead of https.
>>
>> Hmm. So, both url's work fine for you?
> http://koji.fedoraproject.org/koji/buildinfo?buildID=74525   and
> http://koji.fedoraproject.org/koji/buildinfo?buildID=74524  both work fine for
> me

And koji shows you as logged in?
How about with a different browser?

jerry

-- 
TBD.



From sandeen at redhat.com  Sat Dec 13 06:49:34 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 13 Dec 2008 00:49:34 -0600
Subject: Alternatives to serial console for capturing oopses
In-Reply-To: <cone.1229130654.603222.26677.500@commodore.email-scan.com>
References: <cone.1229122645.115179.23287.500@commodore.email-scan.com>	<1229123204.2898.1.camel@sb-home>
	<cone.1229130654.603222.26677.500@commodore.email-scan.com>
Message-ID: <49435AFE.4070400@redhat.com>

Sam Varshavchik wrote:
> nodata writes:
> 
>> Am Freitag, den 12.12.2008, 17:57 -0500 schrieb Sam Varshavchik:
>>> I've got a quad-core dual x86_64 server that, so far, reproducably locks up 
>>> under every 2.6.27 kernel released for F9 so far, when I run a build cycle. 
>>> The last kernel that manages to survive under load is 2.6.26.6-79.fc9, so 
>>> I'll continue to boot it until I get a 2.6.27 kernel that doesn't croak on 
>>> me.
>>>
>>> Given that the hardware does not have a serial port, how else can I capture 
>>> an oops, if one is being generated? At least I hope that there'll be an oops 
>>> for me to capture.
>>>
>> Take a look at netdump.
> 
> Took a look.
> 
> 1) Only the server component is present in Fedora. There is no client. And, 
> of course, I need the client.

I haven't used netdump for a while but:

http://kojipkgs.fedoraproject.org/packages/netdump/0.7.16/13/x86_64/

for example seems to have both.  *shrug*

> 2) The client package requires additional kernel modules to be built. If you 
> are actually using netdump in Fedora, please explain how.
> 
> 3) netdump only supports a small set of NICs. netdump does not support my 
> NIC.

anyway, how about kexec/kdump/crash?  Maybe with a little sysrq-C thrown
in if it's not actually panicing?

-Eric



From dennis at ausil.us  Sat Dec 13 06:58:49 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Sat, 13 Dec 2008 00:58:49 -0600
Subject: Where do we go from here DBus problem?
In-Reply-To: <6d06ce20812122222k79463dci50df9161b6ce96ce@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<200812130008.28231.dennis@ausil.us>
	<6d06ce20812122222k79463dci50df9161b6ce96ce@mail.gmail.com>
Message-ID: <200812130058.52879.dennis@ausil.us>

On Saturday 13 December 2008 12:22:58 am Jerry Amundson wrote:
> On Sat, Dec 13, 2008 at 12:08 AM, Dennis Gilmore <dennis at ausil.us> wrote:
> > On Friday 12 December 2008 11:00:56 pm Jerry Amundson wrote:
> >> On Fri, Dec 12, 2008 at 10:27 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> >> > On Friday 12 December 2008 10:22:39 pm Jerry Amundson wrote:
> >> >> On Fri, Dec 12, 2008 at 8:50 PM, Colin Walters <walters at verbum.org>
> >
> > wrote:
> >> >> > F10:
> >> >> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
> >> >> > F9:
> >> >> > https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
> >> >>
> >> >> koji returns:
> >> >>
> >> >> Secure Connection Failed
> >> >> An error occurred during a connection to koji.fedoraproject.org.
> >> >> SSL peer was unable to negotiate an acceptable set of security
> >> >> parameters. (Error code: ssl_error_handshake_failure_alert)
> >> >
> >> > https  only works if you have a user cert imported in your browser. 
> >> > use http instead of https.
> >>
> >> Hmm. So, both url's work fine for you?
> >
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=74525   and
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=74524  both work
> > fine for me
>
> And koji shows you as logged in?
> How about with a different browser?
no im not logged in, you cant be logged in unless using ssl, unfortunatly ssl 
auth is broken in all browsers except for firefox.  i very very rarely am 
logged in.  i only log in when i need to.  i was able to login from both of 
the http urls and log back out again successfully.

Dennis 



From mschwendt at gmail.com  Sat Dec 13 11:42:01 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 13 Dec 2008 12:42:01 +0100
Subject: Updates QA/karma question
In-Reply-To: <4942906F.6080603@cora.nwra.com>
References: <4942906F.6080603@cora.nwra.com>
Message-ID: <20081213124201.08e3be07.mschwendt@gmail.com>

On Fri, 12 Dec 2008 09:25:19 -0700, Orion wrote:

> Another update issue that raises some questions -
> 
> - Does anyone actually read the comments in bodhi before allowing the 
> push request to proceed?

Interesting issue, but it's not the first time this has happened.

So, to sum up:

* Some package maintainers insist on receiving problem reports for updates
in bugzilla. In general, there's no guarantee, however, the bz ticket will
be seen early enough to prevent a bad test-update from being pushed to
stable. So, additional negative karma in bodhi seems to be the way to go.

* Some people suggest that one has to enter bz ticket numbers in bodhi
before becoming able to give negative karma. (I think that would be a
waste of time for lots of cases)

* Some package maintainers do notice negative karma in bodhi, but they
choose to ignore it in cases where they think an issue is not worse
enough. Even if it causes regression for some users, they mark an update
as stable, because they expect it to fix other issues.

* Communication problems between maintainers with regard to inter-package
dependencies. Maintainer "A" asks maintainer "B" about a needed update of
another package. "B" tells "A" which newer version is supposed to be
sufficient. "A" then proceeds in bodhi without making sure that the needed
update from "B" is released or that both updates will be pushed _at
once_. Unclear here: The change in bodhi which requires that both
maintainers have pkg cvs devel commit access for the relevant pkgs in
order to submit update requests for them. Else bodhi's group updates
would be the way to fix this and push rpcbind together with 
selinux-policy-targeted in a single set.

> - Should update submitters be allowed to give positive karma to their 
> updates?  Seems like that they are too biased.

Agreed. Some spend positive karma on mass-updates without even having
installed their packages on all dists. For example, some broken deps
make it impossible to install a package with rpm/yum/... and require
the --nodeps option.

> - Is there any requirement that an update have positive karma before 
> being pushed to stable?

No, not at all.

That's a fault IMO. Many more updates ought to rely on the automatic
pushing based on the minimum positive karma threshold. If package
maintainers (and sufficiently privileged staff) retained the power to push
an update despite its karma level, but only with a good rationale, the
act of sabotage would become impossible and less attractive. (read:
hostile users could not block an update from being pushed)

> As of now, rpcbind will fail to start on F-9 with selinux in enforcing 
> mode (esp. important on servers!) until 
> selinux-policy-targeted-3.3.1-115.fc9 is pushed to stable.  Seems like 
> we could have waited for that.

I've thought "group updates" are supposed to fix that. Those are updates
for multiple package at once. If one of the set/group of pkgs is bad and
leads to too much negative karma while in updates-testing, the entire set
of pkgs will be pulled.

> We really need to work on this updates system.

See Luke Macken's recent blog entry about some bodhi metrics. Several
available features would be helpful *if* they were used more, instead
of listening to fan-boys and early +1 voters (who even vote on pkgs
downloaded from koji).



From chitlesh.goorah at gmail.com  Sat Dec 13 11:43:49 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Sat, 13 Dec 2008 12:43:49 +0100
Subject: comps.xml and a new category "Electronics"
Message-ID: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>

Hello there,

In search to make deployment of "electronic" EDA tools easier. Is it
possible for me to create a new category "Electronics" in comps.xml
(F-11)?

Currently, most of the FEL apps are scattered around in other
categories and making it hard for users to identify those tools.
"Astronomy" already has such a category.

Thereby, I wish that with a category "Electronics" in comps.xml, users
can easily identify the electronic specific rpms on kpackageki.

If there is a special procedure for me to follow in order to get it
done, please let me know.

Kind regards,
Chitlesh



From robert at fedoraproject.org  Sat Dec 13 13:24:18 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sat, 13 Dec 2008 14:24:18 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <b0k416xn77.ln2@ppp1053.in.ipex.cz>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081213132418.GA15176@hurricane.linuxnetz.de>

Hello Matej,

On Wed, 10 Dec 2008, Matej Cepl wrote:
> Yes, there should be some mechanism how Bodhi should stop package 
> from entering updates, but I guess bodhi developers will have to 
> work a little bit harder than putting yet another stupid form on 
> the website somewhere, which doesn't integrate with anything than 
> with itself.

Bodhi is nice, yes. But people are not using it that much. Even packages
with a broader usage width are getting less to no karma points. And there
is no reflection into Bugzilla if something not works. Because if something
not works, that is likely a bug - why are such things only kept in Bodhi
but not noted as bug report?

Anyway, bodhi only refers to updates-testing. Can't we unpull packages from
updates fast once the karma gets negative? I'm still not happy, that there
was such a slow reaction for the dbus/PackageKit breakage...the interaction
from bodhi to the results on the mirrors seems to be currently ~ 48 hours
when looking to my last phpMyAdmin security update (or is therefore just
our scheme of how to handle security updates responsible?). The package for
EPEL of phpMyAdmin made it into the mirrors much faster as on Fedora.


Greetings,
  Robert



From cra at WPI.EDU  Sat Dec 13 14:13:25 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 13 Dec 2008 09:13:25 -0500
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081213132418.GA15176@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081213132418.GA15176@hurricane.linuxnetz.de>
Message-ID: <20081213141325.GA12103@angus.ind.WPI.EDU>

On Sat, Dec 13, 2008 at 02:24:18PM +0100, Robert Scheck wrote:
> Hello Matej,
> 
> On Wed, 10 Dec 2008, Matej Cepl wrote:
> > Yes, there should be some mechanism how Bodhi should stop package 
> > from entering updates, but I guess bodhi developers will have to 
> > work a little bit harder than putting yet another stupid form on 
> > the website somewhere, which doesn't integrate with anything than 
> > with itself.
> 
> Bodhi is nice, yes. But people are not using it that much. Even packages
> with a broader usage width are getting less to no karma points. And there
> is no reflection into Bugzilla if something not works. Because if something
> not works, that is likely a bug - why are such things only kept in Bodhi
> but not noted as bug report?

Given that Bodhi updates bugzilla reports when updates are pushed, 
maybe it can be made to update them with karma and comments too?

> Anyway, bodhi only refers to updates-testing. Can't we unpull packages from
> updates fast once the karma gets negative? I'm still not happy, that there
> was such a slow reaction for the dbus/PackageKit breakage...the interaction
> from bodhi to the results on the mirrors seems to be currently ~ 48 hours
> when looking to my last phpMyAdmin security update (or is therefore just
> our scheme of how to handle security updates responsible?). The package for
> EPEL of phpMyAdmin made it into the mirrors much faster as on Fedora.

If there were PK integration, there could be lots of interesting ways 
to allow the user to interact with the update system, such as 
single-click karma reporting back to bodhi, displaying the karma on 
updates to the user so they can choose whether to update that package 
or not, setting a preference that says somthing like "wait until karma 
gets to +3 before defaulting the checkbox to enabled to update this 
package".



From robert at fedoraproject.org  Sat Dec 13 14:33:43 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sat, 13 Dec 2008 15:33:43 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081213141325.GA12103@angus.ind.WPI.EDU>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081213132418.GA15176@hurricane.linuxnetz.de>
	<20081213141325.GA12103@angus.ind.WPI.EDU>
Message-ID: <20081213143343.GB15176@hurricane.linuxnetz.de>

Hello Chuck,

On Sat, 13 Dec 2008, Chuck Anderson wrote:
> Given that Bodhi updates bugzilla reports when updates are pushed, 
> maybe it can be made to update them with karma and comments too?

could be an interesting beginning, yes.

> If there were PK integration, there could be lots of interesting ways 
> to allow the user to interact with the update system, such as 
> single-click karma reporting back to bodhi, displaying the karma on 
> updates to the user so they can choose whether to update that package 
> or not, setting a preference that says somthing like "wait until karma 
> gets to +3 before defaulting the checkbox to enabled to update this 
> package".

The reporting should be always possible, as it maybe turns later out if an
update was broken or not. And how a about yum? If it's PackageKit-only it
is not really an advantage, given that unexperienced users won't rate such
updates anyway usually (at least from my point of view).


Greetings,
  Robert



From cra at WPI.EDU  Sat Dec 13 14:37:18 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 13 Dec 2008 09:37:18 -0500
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081213143343.GB15176@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081213132418.GA15176@hurricane.linuxnetz.de>
	<20081213141325.GA12103@angus.ind.WPI.EDU>
	<20081213143343.GB15176@hurricane.linuxnetz.de>
Message-ID: <20081213143718.GB12103@angus.ind.WPI.EDU>

On Sat, Dec 13, 2008 at 03:33:43PM +0100, Robert Scheck wrote:
> On Sat, 13 Dec 2008, Chuck Anderson wrote:
> > Given that Bodhi updates bugzilla reports when updates are pushed, 
> > maybe it can be made to update them with karma and comments too?
> 
> could be an interesting beginning, yes.
> 
> > If there were PK integration, there could be lots of interesting ways 
> > to allow the user to interact with the update system, such as 
> > single-click karma reporting back to bodhi, displaying the karma on 
> > updates to the user so they can choose whether to update that package 
> > or not, setting a preference that says somthing like "wait until karma 
> > gets to +3 before defaulting the checkbox to enabled to update this 
> > package".
> 
> The reporting should be always possible, as it maybe turns later out if an
> update was broken or not. And how a about yum? If it's PackageKit-only it
> is not really an advantage, given that unexperienced users won't rate such
> updates anyway usually (at least from my point of view).

PK already has features that yum does not--it shows metadata about 
updates that yum doesn't, for example.

Experienced users can use the bodhi web interface or bodhi 
command-line client (not sure the latter can do karma).



From musuruan at gmail.com  Sat Dec 13 14:48:15 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Sat, 13 Dec 2008 15:48:15 +0100
Subject: purple-facebookchat EVR in F8 and F9 > F10, devel
Message-ID: <29fee02b0812130648j73632836oda113b1aa7f5cd7b@mail.gmail.com>

Hi,
    It seems to me that purple-facebookchat EVR is bigger in F8 and F9
(1.38-1) than in F10 and devel (1.37-1).

It also seems it hasn't been updated recently. Latest upstream version is 1.44.

BTW, what happened to the EVR report that was usually posted here?

Regards,

Andrea.



From fedora at leemhuis.info  Sat Dec 13 14:54:18 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 13 Dec 2008 15:54:18 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <20081213143343.GB15176@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<ghkq7m$46p$1@ger.gmane.org>	<20081209104955.55a363b2.mschwendt@gmail.com>	<20081209100229.GD3833@free.fr>
	<20081209120300.GJ14496@killefiz>	<b0k416xn77.ln2@ppp1053.in.ipex.cz>	<20081213132418.GA15176@hurricane.linuxnetz.de>	<20081213141325.GA12103@angus.ind.WPI.EDU>
	<20081213143343.GB15176@hurricane.linuxnetz.de>
Message-ID: <4943CC9A.4090606@leemhuis.info>

On 13.12.2008 15:33, Robert Scheck wrote:
 >
> The reporting should be always possible, as it maybe turns later out if an
> update was broken or not. And how a about yum? If it's PackageKit-only it
> is not really an advantage, given that unexperienced users won't rate such
> updates anyway usually (at least from my point of view).

BTW, was "automatic feedback from the clients to bodhi" discussed 
already somewhere in this thread? E.g. if the package maintainer could 
see in bodhi "2500 users installed and ran this testin-update for at 
least three days, no negative karma reported, no new bugs" then it 
should be quite save to move the package.

Cu
knurd



From jreiser at BitWagon.com  Sat Dec 13 15:15:26 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Sat, 13 Dec 2008 07:15:26 -0800
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>
Message-ID: <4943D18E.60107@BitWagon.com>

Chitlesh GOORAH wrote:
> ... With a category "Electronics" in comps.xml, users
> can easily identify the electronic specific rpms on kpackageki.

Please list the existing packages which should be included
in an Electronics category.

-- 



From mdehaan at redhat.com  Sat Dec 13 17:21:49 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Sat, 13 Dec 2008 12:21:49 -0500
Subject: Perseus Digital Library?
In-Reply-To: <ghuvcn$fsd$1@ger.gmane.org>
References: <4942CF37.9050804@redhat.com>	<20081212225705.GA3023@amd.home.annexia.org>	<4942EFE0.1010105@redhat.com>	<20081212231831.GA3105@amd.home.annexia.org>
	<ghuvcn$fsd$1@ger.gmane.org>
Message-ID: <4943EF2D.4080102@redhat.com>

Kevin Kofler wrote:
> Richard W.M. Jones wrote:
>   
>> http://www.perseus.tufts.edu/hopper/opensource
>>
>> <quote>
>>   Texts are licensed under the Creative Commons NonCommercial
>>   ShareAlike 3.0 license
>> </quote>
>>     
>
> That is clearly not OK for Fedora (it's non-Free), nor is it Open Source (in
> the sense defined by the OSI).
>
> Complain to them about diluting the term "Open Source".
>
>         Kevin Kofler
>
>   

Indeed it's not. The ability for Linux to be used commercially is one of 
it's primer drivers of awesomeness. I would suspect they /could/ be 
educated about changing this if shown the benefits. (Future custom live 
spin for academic use easily distributable to libraries? I don't know as 
I'm not familiar with the app).

Incidentally, the Creative Commons has a survey up here, incidentally, 
that folks ought to way in on if you do license CC works. It's a bit long:

http://creativecommons.org/weblog/entry/11045

The issues for writers and photographers and such can be slightly 
different from those of software developers, so I'd encourage those with 
an interest in the CC to way in.

--Michael



From jamundso at gmail.com  Sat Dec 13 17:30:36 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sat, 13 Dec 2008 11:30:36 -0600
Subject: koji status (was Re: Where do we go from here DBus problem?)
Message-ID: <6d06ce20812130930k2664224ek959d974a828c04bc@mail.gmail.com>

On Sat, Dec 13, 2008 at 12:58 AM, Dennis Gilmore <dennis at ausil.us> wrote:
> no im not logged in, you cant be logged in unless using ssl, unfortunatly ssl
> auth is broken in all browsers except for firefox.  i very very rarely am
> logged in.  i only log in when i need to.  i was able to login from both of
> the http urls and log back out again successfully.

I'm using FF 3.0.4, but also found the same with FF 2.x and Konq, and
can't believe I'm the only one getting this... maybe clearing cache
will replicate this for someone who has it working now?
Secure Connection Failed

An error occurred during a connection to koji.fedoraproject.org.
SSL peer was unable to negotiate an acceptable set of security parameters.
(Error code: ssl_error_handshake_failure_alert)

jerry

-- 
TBD.



From rgorosito at comarb.gov.ar  Sat Dec 13 18:08:19 2008
From: rgorosito at comarb.gov.ar (Ricardo Ariel Gorosito)
Date: Sat, 13 Dec 2008 16:08:19 -0200 (ARST)
Subject: add new webcam to gspca-pac207 driver
Message-ID: <48811.192.168.1.131.1229191699.squirrel@padawan.comarb>

I have a webcam HP, which I have obtained it work with the following patch
to the F's kernel:

--- linux-2.6.27.x86_64/drivers/media/video/gspca/pac207.c	2008-10-09
19:13:53.000000000 -0300
+++
/tmp/linux-2.6.27.x86_64.patched/drivers/media/video/gspca/pac207.c	2008-12-13
12:58:33.000000000 -0200
@@ -528,6 +528,7 @@
 static const __devinitdata struct usb_device_id device_table[] = {
 	{USB_DEVICE(0x041e, 0x4028)},
 	{USB_DEVICE(0x093a, 0x2460)},
+	{USB_DEVICE(0x093a, 0x2461)},
 	{USB_DEVICE(0x093a, 0x2463)},
 	{USB_DEVICE(0x093a, 0x2464)},
 	{USB_DEVICE(0x093a, 0x2468)},

As you can see, it is no too complex ;-)

I wanted to know which is the correct road so to get it incorporated in
Fedora:  Creating a RFE? it will be ignored if is not applied upstream?

Thanks in advance

Ricardo.-



From mrsam at courier-mta.com  Sat Dec 13 18:19:55 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sat, 13 Dec 2008 13:19:55 -0500
Subject: Alternatives to serial console for capturing oopses
References: <cone.1229122645.115179.23287.500@commodore.email-scan.com>
	<1229123204.2898.1.camel@sb-home>
	<cone.1229130654.603222.26677.500@commodore.email-scan.com>
	<49435AFE.4070400@redhat.com>
Message-ID: <cone.1229192395.316306.13677.500@commodore.email-scan.com>

Eric Sandeen writes:

> Sam Varshavchik wrote:
>> nodata writes:
>> 
>>> Am Freitag, den 12.12.2008, 17:57 -0500 schrieb Sam Varshavchik:
>>>> I've got a quad-core dual x86_64 server that, so far, reproducably locks up 
>>>> under every 2.6.27 kernel released for F9 so far, when I run a build cycle. 
>>>> The last kernel that manages to survive under load is 2.6.26.6-79.fc9, so 
>>>> I'll continue to boot it until I get a 2.6.27 kernel that doesn't croak on 
>>>> me.
>>>>
>>>> Given that the hardware does not have a serial port, how else can I capture 
>>>> an oops, if one is being generated? At least I hope that there'll be an oops 
>>>> for me to capture.
>>>>
>>> Take a look at netdump.
>> 
>> Took a look.
>> 
>> 1) Only the server component is present in Fedora. There is no client. And, 
>> of course, I need the client.
> 
> I haven't used netdump for a while but:
> 
> http://kojipkgs.fedoraproject.org/packages/netdump/0.7.16/13/x86_64/
> 
> for example seems to have both.  *shrug*
> 
>> 2) The client package requires additional kernel modules to be built. If you 
>> are actually using netdump in Fedora, please explain how.
>> 
>> 3) netdump only supports a small set of NICs. netdump does not support my 
>> NIC.
> 
> anyway, how about kexec/kdump/crash?  Maybe with a little sysrq-C thrown
> in if it's not actually panicing?

Well, I boned up on the kexec/kdump/crash tools.

Immediately found a whole bunch of bugs in mkdumprd that produces a totally 
useless crash initrd image for me. I was able to fix some of the problems, 
but still don't have a workable crash image. Working on it.

Is anybody using kexec-tools on a *freshly* installed F9 (not an upgrade 
from earlier Fedoras) that uses RAID volumes? Did it work for you out of the 
box? As far as I can tell, it can't, because Anaconda no longer creates 
modules.conf for new installs, but mkinitrd figures out that the regular 
kernel boot images needs scsi_mod, sd_mod, and your hardware IDE/SATA/SCSI 
module, yet mkdumprd still looks for "alias scsi_hostadapter" in 
modules.conf, and without it you get a dumprd image without the necessary 
modules need to load scsi support. Even after I fixed that, I still don't 
get RAID to come up in the crash initrd image, not quite sure why.

Bug 476368.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081213/9b8be865/attachment.sig>

From francois.cami at free.fr  Sat Dec 13 18:46:04 2008
From: francois.cami at free.fr (FD Cami)
Date: Sat, 13 Dec 2008 19:46:04 +0100
Subject: koji status (was Re: Where do we go from here DBus problem?)
In-Reply-To: <6d06ce20812130930k2664224ek959d974a828c04bc@mail.gmail.com>
References: <6d06ce20812130930k2664224ek959d974a828c04bc@mail.gmail.com>
Message-ID: <20081213194604.308ea779@olorin>

On Sat, 13 Dec 2008 11:30:36 -0600
"Jerry Amundson" <jamundso at gmail.com> wrote:

> On Sat, Dec 13, 2008 at 12:58 AM, Dennis Gilmore <dennis at ausil.us> wrote:
> > no im not logged in, you cant be logged in unless using ssl, unfortunatly ssl
> > auth is broken in all browsers except for firefox.  i very very rarely am
> > logged in.  i only log in when i need to.  i was able to login from both of
> > the http urls and log back out again successfully.
> 
> I'm using FF 3.0.4, but also found the same with FF 2.x and Konq, and
> can't believe I'm the only one getting this... maybe clearing cache
> will replicate this for someone who has it working now?
> Secure Connection Failed
> 
> An error occurred during a connection to koji.fedoraproject.org.
> SSL peer was unable to negotiate an acceptable set of security parameters.
> (Error code: ssl_error_handshake_failure_alert)

Same here, Fedora 10, Firefox 3.0.4 .

--
fdc



From jkeating at redhat.com  Sat Dec 13 19:03:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 13 Dec 2008 11:03:35 -0800
Subject: [Fedora Update] [testing] typespeed-0.6.5-1.fc8
In-Reply-To: <20081213073229.654392086F7@bastion.fedora.phx.redhat.com>
References: <20081213073229.654392086F7@bastion.fedora.phx.redhat.com>
Message-ID: <1229195015.3863.163.camel@localhost.localdomain>

On Sat, 2008-12-13 at 07:32 +0000, updates at fedoraproject.org wrote:
> salimma has requested the pushing of the following update to testing:
> 
> ================================================================================
>      typespeed-0.6.5-1.fc8
> ================================================================================
>     Release: Fedora 8
>      Status: pending
>        Type: enhancement
>       Karma: 0
>     Request: testing
>   Submitter: salimma
>   Submitted: 2008-12-13 07:32:29
>    Comments: salimma - 2008-12-13 07:32:29 (karma 0)
>              This update has been submitted for testing
> 
>   http://admin.fedoraproject.org/updates/typespeed-0.6.5-1.fc8
> 

What is the purpose of this version bump update to F8 at this time?
There are no notes, no comments, nothing in the rpm changelog that would
make this compelling for F8 users.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081213/d478ddb1/attachment.sig>

From rawhide at fedoraproject.org  Sat Dec 13 19:06:28 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 13 Dec 2008 19:06:28 +0000 (UTC)
Subject: rawhide report: 20081213 changes
Message-ID: <20081213190628.CA05C1F8244@releng2.fedora.phx.redhat.com>

Compose started at Sat Dec 13 06:01:10 UTC 2008

New package libmsn
        Library for connecting to the MSN(tm) Messenger service
Updated Packages:

DeviceKit-002-5
---------------
* Fri Dec 12 17:00:00 2008 Colin Walters <walters at verbum.org> - 002-5
- Fix permissions patch


OpenEXR-1.6.1-5.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> 1.6.1-5
- rebuild to get provides pkgconfig(OpenEXR)


arts-1.5.10-3.fc11
------------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 8:1.5.10-3
- rebuild for pkgconfig deps

* Mon Sep 29 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 8:1.5.10-2
- multilib (sparc) fixes

* Tue Sep  2 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 8:1.5.10-1.1
- fix qt-devel dependency on F8


avahi-0.6.24-1.fc11
-------------------
* Fri Dec 12 17:00:00 2008 Lennart Poettering <lpoetter at redhat.com> - 0.6.24-1
- New upstream release


bzrtools-1.10.0-3.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Henrik Nordstrom <henrik at henriknordstrom.net> 1.10.0-3
- correct changelog


comix-4.0.1-0.1.rc1.fc11
------------------------
* Sat Dec 13 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 4.0.1-0.1.rc1
- 4.0.1 rc1
- "flip with wheel" feature merged into upstream

* Fri Dec  5 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 4.0.0-2
- Add "flip with wheel" function


dbus-1.2.4-2.fc11
-----------------
* Fri Dec 12 17:00:00 2008 Colin Walters <walters at redhat.com> - 1:1.2.4-2
- Revert to upstream 1.2.4, add epoch


docbook-style-xsl-1.74.0-4.fc11
-------------------------------
* Fri Dec 12 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 1.74.0-4
- Author_Group "<orgname>" merged between "<surname>" 
  and "<surname>" (#473019)


elisa-0.5.20-1.fc11
-------------------
* Mon Dec  1 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.20-1
- Update to 0.5.20.

* Mon Nov 24 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.19-1
- Update to 0.5.19.

* Mon Nov 17 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.18-1
- Update to 0.5.18.

* Sun Nov  9 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.17-2
- Add (now) missing python-twisted-web requirement.

* Tue Nov  4 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.17-1
- Update to 0.5.17.

* Mon Oct 27 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.16-1
- Update to 0.5.16.

* Tue Oct 21 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.15-1
- Update to 0.5.15.

* Mon Oct 13 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.14-1
- Update to 0.5.14.

* Fri Oct 10 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.13-2
- Go back to using an elisa/elisa-base split, we'll just BR elisa-base in
  the plugins.

* Tue Oct  7 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.13-1
- Update to 0.5.13.


exiv2-0.17.1-2.fc11
-------------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.17.2-2
- rebuild for pkgconfig deps


gc-7.1-6.fc11
-------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 7.1-6
- rebuild for pkgconfig deps

* Wed Oct 15 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 7.1-5
- forward-port patches (gcinit, sparc)


gimp-help-2.4.2-3.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 2.4.2-3
- Merge Review (#225798):
  - quote percent signs written into files list
  - enable parallel make


glpk-4.34-1.fc11
----------------
* Fri Dec 12 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> 4.34-1
- Update to 4.34.


gnome-packagekit-0.4.0-2.fc11
-----------------------------
* Fri Dec 12 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.4.0-2
- Depend on PackageKit-gtk-module so the auto-font installation can be
  turned on in F11.
- Turn off the loading of libpk-gtk-module.so until we have a new
  fontconfig using a spec file patch that we can nuke soon.
- Fixes rh#476066


gpsman-6.4-1.fc11
-----------------
* Mon Dec  8 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 6.4-1
- New upstream release


gvfs-1.1.1-5.fc11
-----------------
* Fri Dec 12 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.1.1-5
- FTP: Fix PASV connections


ilmbase-1.0.1-3.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.0.1-3
- rebuild for pkgconfig deps


irqbalance-0.55-12.fc11
-----------------------
* Fri Dec 12 17:00:00 2008 Neil Norman <nhorman at redhat.com> - 2:0.55-12
- Remove odd Netorking dependence from irqbalance (bz 476179)


jna-posix-0.7-1.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 0.7-1
- Bump to upstream new version.


joda-time-1.6-1.tzdata2008i.fc11
--------------------------------
* Fri Dec 12 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 1.6-1.tzdata2008i
- New upstream version (1.6).


jvyamlb-0.2.5-1.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 0.2.5-1
- Newer version (0.2.5).


kdeaccessibility-4.1.85-1.fc11
------------------------------
* Thu Dec 11 17:00:00 2008 Than Ngo <than at redhat.com> -  4.1.85-1
- 4.2beta2


kdeadmin-4.1.85-1.fc11
----------------------
* Thu Dec 11 17:00:00 2008 Than Ngo <than at redhat.com> -  4.1.85-1
- 4.2beta2


kdebase-4.1.85-1.fc11
---------------------
* Thu Dec 11 17:00:00 2008 Than Ngo <than at redhat.com> -  4.1.85-1
- 4.2beta2


kdebase-runtime-4.1.85-1.fc11
-----------------------------
* Thu Dec 11 17:00:00 2008 Than Ngo <than at redhat.com> -  4.1.85-1
- 4.2beta2


kdebase-workspace-4.1.85-2.fc11
-------------------------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 4.1.85-2
- BR: PyKDE4-devel >= %version

* Thu Dec 11 17:00:00 2008 Than Ngo <than at redhat.com> -  4.1.85-1
- 4.2beta2

* Wed Dec 10 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.82-1
- 4.1.82
- rebase redhat-startkde patch


kdebindings-4.1.85-2.fc11
-------------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2

* Fri Dec 12 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.85-2
- reenable smoke, ruby
- disable NepomukSmoke for now: it wasn't actually used (the corresponding
  Ruby binding is disabled by default and we don't build the C# bindings) and it
  depends on nepomukquery libs from kdebase (which also means we need to sort
  out the -devel symlink mess there first)


kdeedu-4.1.85-1.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2


kdegames-4.1.85-1.fc11
----------------------
* Fri Dec 12 17:00:00 2008 <than at redhat.com> 4.1.85-1
- 4.2beta2


kdegraphics-4.1.85-1.fc11
-------------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2
- BR: soprano-devel


kdemultimedia-4.1.85-2.fc11
---------------------------
* Sat Dec 13 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.85-2
- restore BR libtunepimp-devel libmusicbrainz-devel for now, needed by Kscd

* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2


kdenetwork-4.1.85-1.fc11
------------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2
- BR: libmsn-devel

* Thu Dec 11 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 7:4.1.80-7
- Obsoletes/Provides: kopete-bonjour (#451302)


kdepimlibs-4.1.85-1.fc11
------------------------
* Thu Dec 11 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.85-1
- KDE 4.2beta2

* Wed Dec 10 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.82-2
- add --debug-output to our cmake call, that should fix a reproducible
  bug with cmake and ppc builds (this work-around should be
  removed anyway)

* Tue Dec  9 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.82-1
- 4.1.82


kdeplasma-addons-4.1.85-1.fc11
------------------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2


kdesdk-4.1.85-1.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2


kdetoys-4.1.85-1.fc11
---------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2


kdeutils-4.1.85-1.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2

* Mon Dec  8 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.80-5
- BR: PyKDE4-devel >= %version (vs previously unversioned BR)


lensfun-0.2.3-3.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.2.3-3
- rebuild for pkgconfig deps


libfplll-3.0.11-1.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 3.0.11-1
- Bump to new version (3.0.11).


libggz-0.99.4-2.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.99.4-2
- rebuild for pkgconfig deps


libmusicbrainz3-3.0.2-2.fc11
----------------------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 3.0.2-2
- rebuild for pkgconfig deps


libselinux-2.0.76-4.fc11
------------------------
* Fri Dec 12 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 2.0.76-4
- Add new function getseuser which will take username and service and return
- seuser and level.  ipa will populate file in future.
- Change selinuxdefcon to return just the context by default


libtasn1-1.7-2.fc11
-------------------
* Fri Dec 12 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1.7-2
- rebuild to get provides pkgconfig(libtasn1)


libzip-0.9-1.fc11
-----------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.9-1
- libzip-0.9


llvm-2.4-2.fc11
---------------
* Tue Dec  2 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 2.4-2
- Patched build process for the OCaml binding

* Tue Dec  2 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 2.4-1
- Update to 2.4
- Package Ocaml binding


lush-1.2.1-4.fc11
-----------------
* Fri Dec 12 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 1.2.1-4
- rebuild with proper buildrequires


ncl-5.0.0-16.fc11
-----------------
* Fri Dec 12 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 5.0.0-16
- Re-add profile.d startup scripts to set NCARG env variables


ochusha-0.5.99.69-0.4.cvs20081213T0230.fc11
-------------------------------------------
* Sat Dec 13 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


perl-5.10.0-52.fc11
-------------------
* Fri Dec 12 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 4:5.10.0-52
- 295021 CVE-2007-4829 perl-Archive-Tar directory traversal flaws
- add another source for binary files, which test untaring links


perl-Apache-LogRegex-1.5-1.fc11
-------------------------------
* Fri Dec 12 17:00:00 2008 Steven Pritchard <steve at kspei.com> 1.5-1
- Update to 1.5.


perl-Devel-StackTrace-1.20-1.fc11
---------------------------------
* Sat Dec 13 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1:1.20-1
- Upstream update.
- Bump epoch.


perl-ExtUtils-Depends-0.301-1.fc11
----------------------------------
* Fri Dec 12 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.301-1
- Update to 0.301.


perl-HTTP-DAV-0.35-1.fc11
-------------------------
* Fri Dec 12 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.35-1
- Update to 0.35.
- Update Source0 URL.


perl-Module-Starter-1.50-2.fc11
-------------------------------
* Wed Nov  5 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.50-2
- correct source

* Wed Nov  5 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.50-1
- update to 1.50


perl-RPM2-0.67-7.fc11
---------------------
* Fri Dec 12 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.67-7
- Port to RPM 4.6

* Thu Sep 11 18:00:00 2008 Jesse Keating <jkeating at redhat.com> - 0.67-6
- Rebuild for rpm deps


python-basemap-0.99.2-2.fc11
----------------------------
* Thu Dec 11 17:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> - 0.99.2-2
- Update data directory patch

* Thu Dec 11 17:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> - 0.99.2-1
- Update to latest release


python-basemap-data-0.99.2-1.fc11
---------------------------------
* Thu Dec 11 17:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> 0.99.2-1
- Update to latest release

* Thu Dec 11 17:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> 0.99.1-1
- Update to match matplotlib release


python-lxml-2.2-0.4.beta1.fc11
------------------------------
* Fri Dec 12 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.2-0.4.beta1
- 2.2beta1 (2008-12-12)
- Features added
- 
-    * Allow lxml.html.diff.htmldiff to accept Element objects,
-      not just HTML strings.
- 
- Bugs fixed
- 
-    * Crash when using an XPath evaluator in multiple threads.
-    * Fixed missing whitespace before Link:... in lxml.html.diff.
- 
- Other changes
- 
-    * Export lxml.html.parse.


python-psyco-1.6-1.fc11
-----------------------
* Fri Dec 12 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 1.6-1
- Bump to new version (1.6).


qt-4.4.3-7.fc11
---------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.4.3-7
- rebuild for pkgconfig deps


roundcubemail-0.2-4.beta.fc11
-----------------------------
* Fri Dec 12 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> = 0.2-4.beta
- Security fix, BZ 476223.


rpm-4.6.0-0.rc3.2.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 4.6.0-0.rc3.2
- add back defaultdocdir patch which hadn't been applied on 4.6.x branch yet

* Fri Dec 12 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 4.6.0-0.rc3.1
- add dist-tag, rebuild


seahorse-plugins-2.25.1-3.fc11
------------------------------
* Fri Dec 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.25.1-3
- Call update-desktop-database in %post (#473680)


slang-2.1.4-2.fc11
------------------
* Fri Dec 12 17:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> - 2.1.4-2
- convert changes.txt to UTF-8, comment patches (#226420)


system-config-printer-1.0.12-4.fc11
-----------------------------------
* Fri Dec 12 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.12-4
- Updated patch for 1.0.x changes:
  - Fix for advanced server settings dialog.
  - Fixes for troubleshooter to restore error_log fetching.

* Wed Dec 10 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.12-3
- Updated patch for 1.0.x changes:
  - Fixed problem that prevented authentication prompt being
    displayed.

* Fri Dec  5 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.12-2
- Added patch for 1.0.x changes since 1.0.12:
  - Smarter PPD cache in cupshelpers module.
  - Don't write back localized versions of globalized PPDs.


taglib-1.5-3.fc11
-----------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.5-3
- rebuild for pkgconfig deps


typespeed-0.6.5-1.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.6.5-1
- Update to 0.6.5
- Updated desktop icon and categories


varnish-2.0.2-2.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Ingvar Hagelund <ingvar at linpro.no> - 2.0.2-2
Added a fix for a timeout bug, backported from trunk


wings-0.99.05-2.fc11
--------------------
* Thu Oct 30 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 0.99.05-2
- new release 0.99.05


xhtml1-dtds-1.0-20020801.2
--------------------------
* Fri Dec 12 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.0-20020801.2
- Drop no longer needed upgrade quirks.


xine-lib-1.1.15-4.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.1.15-4
- rebuild for pkgconfig deps


xmlto-0.0.21-3.fc11
-------------------
* Fri Dec 12 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 0.0.21-3
- merge review(#226568):
  ship documentation files, fix license tag, use recommended
  parallel make, make install instead of macro, require libxslt
  instead of direct binary requirement


xorg-x11-drv-radeonhd-1.2.4-1.1.20081212git.fc11
------------------------------------------------
* Fri Dec 12 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.2.4-1.1.20081212git
- Upstream have released 1.2.4 today. This snapshot is 1.2.4.
- New snapshot (upstream commit 4e8972638db59d007bc61eb1bef8adb99cc67000):
  - 4e897263: Bump to 1.2.4
  - 2db9ee5e: Add release information for 1.2.4
  - 9cdbad32: Nuke description of option "ShadowFB" (not existing any longer).
  - 0679ce59: Small manpage updates.
  - 7aae5f7f: FB mapping: Restore original PCI MapSize if IGP memory mapping failed.
  - 6c91fed6: Workaround for drm header mismatches (DEPRECATED and __user on Fedora 10)
- Disable spec file workaround for undefined DEPRECATED and __user macros.


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 73
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	compiz-fusion-devel-0.7.8-5.fc11.i386 requires pkgconfig(cairo-xlib-xrender)
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.i386 requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libmusicbrainz3-devel-3.0.2-2.fc11.i386 requires pkgconfig(libdiscid)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.i386 requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.i386 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.i386 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	compiz-fusion-devel-0.7.8-5.fc11.i386 requires pkgconfig(cairo-xlib-xrender)
	compiz-fusion-devel-0.7.8-5.fc11.x86_64 requires pkgconfig(cairo-xlib-xrender)
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.x86_64 requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libmusicbrainz3-devel-3.0.2-2.fc11.i386 requires pkgconfig(libdiscid)
	libmusicbrainz3-devel-3.0.2-2.fc11.x86_64 requires pkgconfig(libdiscid)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.x86_64 requires python(abi) = 0:2.5
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.x86_64 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.i386 requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.x86_64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.x86_64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	compiz-fusion-devel-0.7.8-5.fc11.ppc requires pkgconfig(cairo-xlib-xrender)
	compiz-fusion-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(cairo-xlib-xrender)
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	1:eclipse-pydev-1.3.24-3.fc11.noarch requires python-psyco
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.ppc requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libmusicbrainz3-devel-3.0.2-2.fc11.ppc requires pkgconfig(libdiscid)
	libmusicbrainz3-devel-3.0.2-2.fc11.ppc64 requires pkgconfig(libdiscid)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.ppc requires python(abi) = 0:2.5
	linkchecker-4.7-11.fc9.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.ppc requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc requires libgeos-3.0.1.so
	qgis-python-0.11.0-3.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	system-config-audit-0.4.8-11.fc11.ppc requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	compiz-fusion-devel-0.7.8-5.fc11.ppc64 requires pkgconfig(cairo-xlib-xrender)
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:eclipse-pydev-1.3.24-3.fc11.noarch requires python-psyco
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libmusicbrainz3-devel-3.0.2-2.fc11.ppc64 requires pkgconfig(libdiscid)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	linkchecker-4.7-11.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkchecker-4.7-11.fc9.ppc64 requires python(abi) = 0:2.5
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.ppc64 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-grass-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires libgeos-3.0.1.so()(64bit)
	qgis-python-0.11.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	system-config-audit-0.4.8-11.fc11.ppc64 requires audit-libs = 0:1.7.9-1.fc11
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From konrad at tylerc.org  Sat Dec 13 20:26:36 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 13 Dec 2008 12:26:36 -0800
Subject: add new webcam to gspca-pac207 driver
In-Reply-To: <48811.192.168.1.131.1229191699.squirrel@padawan.comarb>
References: <48811.192.168.1.131.1229191699.squirrel@padawan.comarb>
Message-ID: <200812131226.36776.konrad@tylerc.org>

On Saturday 13 December 2008 10:08:19 am Ricardo Ariel Gorosito wrote:
> I have a webcam HP, which I have obtained it work with the following patch
> to the F's kernel:
>
> --- linux-2.6.27.x86_64/drivers/media/video/gspca/pac207.c	2008-10-09
> 19:13:53.000000000 -0300
> +++
> /tmp/linux-2.6.27.x86_64.patched/drivers/media/video/gspca/pac207.c	2008-12
>-13 12:58:33.000000000 -0200
> @@ -528,6 +528,7 @@
>  static const __devinitdata struct usb_device_id device_table[] = {
>  	{USB_DEVICE(0x041e, 0x4028)},
>  	{USB_DEVICE(0x093a, 0x2460)},
> +	{USB_DEVICE(0x093a, 0x2461)},
>  	{USB_DEVICE(0x093a, 0x2463)},
>  	{USB_DEVICE(0x093a, 0x2464)},
>  	{USB_DEVICE(0x093a, 0x2468)},
>
> As you can see, it is no too complex ;-)
>
> I wanted to know which is the correct road so to get it incorporated in
> Fedora:  Creating a RFE? it will be ignored if is not applied upstream?
>
> Thanks in advance
>
> Ricardo.-

Maybe talk to Hans de Goede (if I remember correctly he was doing some work in 
this part of the kernel?) about submitting it to upstream. It's a simple 
enough patch (and isn't in 2.6.27.8 [0]).

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>

[0]: http://lxr.linux.no/linux+v2.6.27.8/drivers/media/video/gspca/pac207.c




From walters at verbum.org  Sat Dec 13 21:52:38 2008
From: walters at verbum.org (Colin Walters)
Date: Sat, 13 Dec 2008 16:52:38 -0500
Subject: Where do we go from here DBus problem?
In-Reply-To: <49434946.30207@redhat.com>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<ghv0c5$k5q$1@ger.gmane.org>
	<faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
	<49434946.30207@redhat.com>
Message-ID: <faa16b610812131352oec38da6t99df0583310d0919@mail.gmail.com>

On Sat, Dec 13, 2008 at 12:33 AM, Warren Togami <wtogami at redhat.com> wrote:
>
> However might it be possible to improve on this reversion a bit.  Might it
> be possible for apps to output, perhaps to stderr, when it hit a case where
> it would have failed before this reversion?  Then it would be more obvious
> what needs to be fixed in regular updates later, and as we approach F11.

There's a logging patch I'm working on upstream coming soon.



From walters at verbum.org  Sat Dec 13 21:56:10 2008
From: walters at verbum.org (Colin Walters)
Date: Sat, 13 Dec 2008 16:56:10 -0500
Subject: Where do we go from here DBus problem?
In-Reply-To: <faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<ghv0c5$k5q$1@ger.gmane.org>
	<faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
Message-ID: <faa16b610812131356r6160c581g78eedfcbe10fc4e5@mail.gmail.com>

On Fri, Dec 12, 2008 at 9:50 PM, Colin Walters <walters at verbum.org> wrote:
> On Fri, Dec 12, 2008 at 8:39 PM, Colin Walters <walters at verbum.org> wrote:
>> On Fri, Dec 12, 2008 at 7:41 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>>
>>> The D-Bus policy really ought to be reverted and never touched again in F8,
>>> F9 and F10. This should only be changed in F11 or even F12. The change is
>>> just not ready for production use at all.
>>
>> I've been working through things this week and had hoped a lot would
>> get fixed, but at this point it has turned into an enormous ball of
>> yarn.  So thinking about it I suppose you're right.
>>
>> I'll do an upload which reverts by tomorrow.
>
> F10:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=74525

Bodhi update:

https://admin.fedoraproject.org/updates/dbus-1.2.4-2.fc10

> F9:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=74524

Bodhi update:

https://admin.fedoraproject.org/updates/dbus-1.2.4-2.fc9



From dennis at ausil.us  Sat Dec 13 23:51:58 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Sat, 13 Dec 2008 17:51:58 -0600
Subject: koji status (was Re: Where do we go from here DBus problem?)
In-Reply-To: <6d06ce20812130930k2664224ek959d974a828c04bc@mail.gmail.com>
References: <6d06ce20812130930k2664224ek959d974a828c04bc@mail.gmail.com>
Message-ID: <200812131752.02267.dennis@ausil.us>

On Saturday 13 December 2008 11:30:36 am Jerry Amundson wrote:
> On Sat, Dec 13, 2008 at 12:58 AM, Dennis Gilmore <dennis at ausil.us> wrote:
> > no im not logged in, you cant be logged in unless using ssl, unfortunatly
> > ssl auth is broken in all browsers except for firefox.  i very very
> > rarely am logged in.  i only log in when i need to.  i was able to login
> > from both of the http urls and log back out again successfully.
>
> I'm using FF 3.0.4, but also found the same with FF 2.x and Konq, and
> can't believe I'm the only one getting this... maybe clearing cache
> will replicate this for someone who has it working now?
> Secure Connection Failed
>
> An error occurred during a connection to koji.fedoraproject.org.
> SSL peer was unable to negotiate an acceptable set of security parameters.
> (Error code: ssl_error_handshake_failure_alert)
SSL only works if you have a user cert imported to the browser,  right now 
only Firefox supports user certificates.  konqueror in 3.x also supports them 
but that is Fedora 8 only.  the behaviour you are descirbing is expected if 
you do not have a client side certificate.  you will only be able to access 
koji using http:// 

Dennis 



From skvidal at fedoraproject.org  Sun Dec 14 02:47:57 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sat, 13 Dec 2008 21:47:57 -0500 (EST)
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <20081213143718.GB12103@angus.ind.WPI.EDU>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081213132418.GA15176@hurricane.linuxnetz.de>
	<20081213141325.GA12103@angus.ind.WPI.EDU>
	<20081213143343.GB15176@hurricane.linuxnetz.de>
	<20081213143718.GB12103@angus.ind.WPI.EDU>
Message-ID: <alpine.LFD.2.00.0812132147230.27011@localhost.localdomain>



On Sat, 13 Dec 2008, Chuck Anderson wrote:

>
> PK already has features that yum does not--it shows metadata about
> updates that yum doesn't, for example.
>

It does? what metadata would that be? Considering all the info PK has 
about packages it gets FROM yum I don't see how that's possible.

-sv



From sundaram at fedoraproject.org  Sun Dec 14 06:29:03 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 14 Dec 2008 11:59:03 +0530
Subject: Installing from Live CD is the new black?
In-Reply-To: <49421D9C.8080307@nicubunu.ro>
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro>
Message-ID: <4944A7AF.5060904@fedoraproject.org>

Nicu Buculei wrote:
> Chris Lumens wrote:
>>> Is it just me or doesn't everybody make their installs off the Live CD
>>> these days?
>>
>> I do kind of wish everyone used live CDs, but that's probably never
>> going to be the way it works.
> 
> That's just not gonna happen. Live CD are so small, they can't hold even 
> OpenOffice.org (or hold it but sacrifice a lot of other much needed 
> applications).

OpenOffice.org in a live cd is certainly possible. We do more locales 
instead but if you want a custom live cd to include all the packages YOU 
need, it takes about 20 minutes with a local mirror. Really easy.

Rahul



From pemboa at gmail.com  Sun Dec 14 06:43:56 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sun, 14 Dec 2008 00:43:56 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <4944A7AF.5060904@fedoraproject.org>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
Message-ID: <16de708d0812132243g759e4858p70cce755b32d6249@mail.gmail.com>

On Sun, Dec 14, 2008 at 12:29 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Nicu Buculei wrote:
>>
>> Chris Lumens wrote:
>>>>
>>>> Is it just me or doesn't everybody make their installs off the Live CD
>>>> these days?
>>>
>>> I do kind of wish everyone used live CDs, but that's probably never
>>> going to be the way it works.
>>
>> That's just not gonna happen. Live CD are so small, they can't hold even
>> OpenOffice.org (or hold it but sacrifice a lot of other much needed
>> applications).
>
> OpenOffice.org in a live cd is certainly possible. We do more locales
> instead but if you want a custom live cd to include all the packages YOU
> need, it takes about 20 minutes with a local mirror. Really easy.
>
> Rahul

Are there any up to date instructions on this? Wouldn't mind spinning
my own KDE Live USB

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jamundso at gmail.com  Sun Dec 14 06:58:57 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 14 Dec 2008 00:58:57 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812132243g759e4858p70cce755b32d6249@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<16de708d0812132243g759e4858p70cce755b32d6249@mail.gmail.com>
Message-ID: <6d06ce20812132258x1466a4eaqa3839fc9e20dc339@mail.gmail.com>

On Sun, Dec 14, 2008 at 12:43 AM, Arthur Pemberton <pemboa at gmail.com> wrote:
> On Sun, Dec 14, 2008 at 12:29 AM, Rahul Sundaram
> <sundaram at fedoraproject.org> wrote:
>> OpenOffice.org in a live cd is certainly possible. We do more locales
>> instead but if you want a custom live cd to include all the packages YOU
>> need, it takes about 20 minutes with a local mirror. Really easy.
>>
>> Rahul
>
> Are there any up to date instructions on this? Wouldn't mind spinning
> my own KDE Live USB


https://fedoraproject.org/wiki/How_to_create_and_use_Fedora_LiveCD

-- 
TBD.



From sundaram at fedoraproject.org  Sun Dec 14 07:55:36 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 14 Dec 2008 13:25:36 +0530
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812132243g759e4858p70cce755b32d6249@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>	<49421D9C.8080307@nicubunu.ro>
	<4944A7AF.5060904@fedoraproject.org>
	<16de708d0812132243g759e4858p70cce755b32d6249@mail.gmail.com>
Message-ID: <4944BBF8.7010606@fedoraproject.org>

Arthur Pemberton wrote:

> Are there any up to date instructions on this? Wouldn't mind spinning
> my own KDE Live USB


# yum install livecd-tools spin-kickstarts

and follow

https://fedoraproject.org/wiki/How_to_create_and_use_Fedora_LiveCD

Rahul



From pemboa at gmail.com  Sun Dec 14 08:21:10 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sun, 14 Dec 2008 02:21:10 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <4944BBF8.7010606@fedoraproject.org>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<16de708d0812132243g759e4858p70cce755b32d6249@mail.gmail.com>
	<4944BBF8.7010606@fedoraproject.org>
Message-ID: <16de708d0812140021j2f4f42f4sb34a52aa2d77ae2b@mail.gmail.com>

On Sun, Dec 14, 2008 at 1:55 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Arthur Pemberton wrote:
>
>> Are there any up to date instructions on this? Wouldn't mind spinning
>> my own KDE Live USB
>
>
> # yum install livecd-tools spin-kickstarts
>
> and follow
>
> https://fedoraproject.org/wiki/How_to_create_and_use_Fedora_LiveCD
>
> Rahul


Thank you.



-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From dtimms at iinet.net.au  Sun Dec 14 08:22:16 2008
From: dtimms at iinet.net.au (David Timms)
Date: Sun, 14 Dec 2008 19:22:16 +1100
Subject: Perseus Digital Library?
In-Reply-To: <4943EF2D.4080102@redhat.com>
References: <4942CF37.9050804@redhat.com>	<20081212225705.GA3023@amd.home.annexia.org>	<4942EFE0.1010105@redhat.com>	<20081212231831.GA3105@amd.home.annexia.org>	<ghuvcn$fsd$1@ger.gmane.org>
	<4943EF2D.4080102@redhat.com>
Message-ID: <4944C238.9080103@iinet.net.au>

Michael DeHaan wrote:
> Kevin Kofler wrote:
>> Richard W.M. Jones wrote:
>>  
>>> http://www.perseus.tufts.edu/hopper/opensource
How would this fit into "code not content" ?
Would we be able to have a player, but no content ?

DaveT.



From francois.cami at free.fr  Sun Dec 14 10:26:05 2008
From: francois.cami at free.fr (FD Cami)
Date: Sun, 14 Dec 2008 11:26:05 +0100
Subject: Where do we go from here DBus problem?
In-Reply-To: <faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
References: <4942EA15.8090100@gallowit.com>
	<1229126338.3863.158.camel@localhost.localdomain>
	<ghv0c5$k5q$1@ger.gmane.org>
	<faa16b610812121739kd91d4b1jf3efc80f44ac71ac@mail.gmail.com>
	<faa16b610812121850r1c403bcah16d07518b7b28295@mail.gmail.com>
Message-ID: <20081214112605.7381e8c1@olorin>

On Fri, 12 Dec 2008 21:50:44 -0500
"Colin Walters" <walters at verbum.org> wrote:

> On Fri, Dec 12, 2008 at 8:39 PM, Colin Walters <walters at verbum.org> wrote:
> > On Fri, Dec 12, 2008 at 7:41 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> >
> >> The D-Bus policy really ought to be reverted and never touched again in F8,
> >> F9 and F10. This should only be changed in F11 or even F12. The change is
> >> just not ready for production use at all.
> >
> > I've been working through things this week and had hoped a lot would
> > get fixed, but at this point it has turned into an enormous ball of
> > yarn.  So thinking about it I suppose you're right.
> >
> > I'll do an upload which reverts by tomorrow.
> 
> F10:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=74525
> F9:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=74524
> 
> Any testing before tomorrow is greatly appreciated, I've tested a
> local F10 on my machine.  After that I'll make a Bodhi update.

Done for F10, no weird behaviour to report, that fixed smolt (the
gathering information stage was broken) here.

Thanks !

Francois



From nicolas.mailhot at laposte.net  Sun Dec 14 11:26:23 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 14 Dec 2008 12:26:23 +0100 (CET)
Subject: yum --skip-broken update by default?
In-Reply-To: <604aa7910812121229r236ff20fs7e3fb5e66a3cd05a@mail.gmail.com>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>
	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>
	<4941C0F8.6010203@comcast.net>
	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>
	<4942BEBC.4080402@comcast.net>
	<604aa7910812121229r236ff20fs7e3fb5e66a3cd05a@mail.gmail.com>
Message-ID: <3935ab85b541efa4e462c276e8a3e450.squirrel@arekh.dyndns.org>



> If we make skip-broken work silently by default and do not notify
> users about the crap being skipped...

In case no one noticed, skip-broken does notify users about the crap
being skipped now

Granted, this is a bit lost in yum's usual verbosity. But that's not
an argument to no make sckip-broken the default



From nicolas.mailhot at laposte.net  Sun Dec 14 11:31:11 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 14 Dec 2008 12:31:11 +0100 (CET)
Subject: Fedora Com System ? (was: Package updating problem and 
 solutions)
In-Reply-To: <16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
Message-ID: <3df5d55b4fedbbf28d230c79a1fd442f.squirrel@arekh.dyndns.org>



Le Ven 12 d?cembre 2008 21:12, Arthur Pemberton a ?crit :

>> How are fedora-announce, the blogs and the webpages NOT this?
>
> You don't get any of them with Fedora, that's primary difference I
> see.

Make an RSS or atom field for fedora announce+FWN and add it to the
fedora default homepage? (and get the l0n people to translate them?)

People talk about reinventing web desktops but we don't even take
advantage of existing proved techs.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Sun Dec 14 11:34:35 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 14 Dec 2008 12:34:35 +0100 (CET)
Subject: Fedora Com System ? (was: Package updating problem and 
 solutions)
In-Reply-To: <20081212222938.GG19799@localhost.localdomain>
References: <16de708d0812121137k13ac6e9dld06eec9000377dcd@mail.gmail.com>
	<alpine.LFD.2.00.0812121503240.22105@localhost.localdomain>
	<16de708d0812121212s39977448u8eff040ffb86e462@mail.gmail.com>
	<alpine.LFD.2.00.0812121513400.22105@localhost.localdomain>
	<20081212213110.079d449e.mschwendt@gmail.com>
	<alpine.LFD.2.00.0812121531530.22105@localhost.localdomain>
	<385866f0812121242k3e954104ofdde13b2e19c203b@mail.gmail.com>
	<20081212222938.GG19799@localhost.localdomain>
Message-ID: <b5cec3749070d11229e6e3d2f97c4ce3.squirrel@arekh.dyndns.org>



Le Ven 12 d?cembre 2008 23:29, Paul W. Frields a ?crit :
> On Fri, Dec 12, 2008 at 10:42:13PM +0200, Muayyad AlSadi wrote:
>> the announce mailing list should be visible in some web site that
>> support rss
>>
>> and let firefox or any rss reader configured by default for it
>
> Gmane provides this:
> http://rss.gmane.org/messages/excerpts/gmane.linux.redhat.fedora.core.announce

And fills fedora under "redhat" which is supposed to be a no-go.

-- 
Nicolas Mailhot



From tim.lauridsen at googlemail.com  Sun Dec 14 11:56:26 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sun, 14 Dec 2008 12:56:26 +0100
Subject: yum --skip-broken update by default?
In-Reply-To: <3935ab85b541efa4e462c276e8a3e450.squirrel@arekh.dyndns.org>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>	<4941C0F8.6010203@comcast.net>	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>	<4942BEBC.4080402@comcast.net>	<604aa7910812121229r236ff20fs7e3fb5e66a3cd05a@mail.gmail.com>
	<3935ab85b541efa4e462c276e8a3e450.squirrel@arekh.dyndns.org>
Message-ID: <4944F46A.5010108@googlemail.com>

Nicolas Mailhot wrote:
>   
>> If we make skip-broken work silently by default and do not notify
>> users about the crap being skipped...
>>     
>
> In case no one noticed, skip-broken does notify users about the crap
> being skipped now
>
> Granted, this is a bit lost in yum's usual verbosity. But that's not
> an argument to no make sckip-broken the default
>
>   
Skipped packages is shown in package confirmation, just like installed, 
updated etc. So running yum-cli is not then problem, but pk need to
be able to show skipped packages too.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081214/0801b060/attachment.htm>

From kanarip at kanarip.com  Sun Dec 14 12:12:01 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 14 Dec 2008 13:12:01 +0100
Subject: Server SIG - work areas
In-Reply-To: <1228140140.3664.72.camel@eagle.danny.cz>
References: <1228140140.3664.72.camel@eagle.danny.cz>
Message-ID: <4944F811.1040206@kanarip.com>

Dan Hor?k wrote:
> Hello,
> 

With regards to the areas of interest for this SIG, may I recommend the 
following (broad) topic:

Integration of Provisioning utilities such as Cobbler, Genome, 
Kickstart, Configuration Management utilities such as CFEngine, Puppet, 
Augeas, iClasssify, and Monitoring utilities such as Nagios, Zabbix, 
Zenos, Monit

Kind regards,

Jeroen van Meeuwen
-kanarip



From kanarip at kanarip.com  Sun Dec 14 12:28:37 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 14 Dec 2008 13:28:37 +0100
Subject: [Ambassadors] Live CD & Localization
In-Reply-To: <1228927277.3863.41.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<493E568E.3090404@kanarip.com>
	<1228927277.3863.41.camel@localhost.localdomain>
Message-ID: <4944FBF5.20809@kanarip.com>

Jesse Keating wrote:
> On Tue, 2008-12-09 at 12:29 +0100, Jeroen van Meeuwen wrote:
>> The Fedora Project however would still 
>> host the torrent tracker so they have control over revocation and/or 
>> modification of the spin/torrent.
> 
> The problem that this still leaves is currently to host the tracker, we
> have to host the bits,

I don't understand this primarily because I've been tracking torrents 
without the tracker needing to seed anything for ages.

Is this a limitation in the tracker FP uses? Which tracker would that be?

-Jeroen



From kanarip at kanarip.com  Sun Dec 14 12:41:28 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 14 Dec 2008 13:41:28 +0100
Subject: [Ambassadors] Live CD & Localization
In-Reply-To: <1228941473.3863.59.camel@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<493E568E.3090404@kanarip.com>	<1228927277.3863.41.camel@localhost.localdomain>	<1228939276.3572.51.camel@beta>
	<1228941473.3863.59.camel@localhost.localdomain>
Message-ID: <4944FEF8.9090404@kanarip.com>

Jesse Keating wrote:
> I have other concerns which mostly revolve around timing of the release
> of the spins, that the final moments before a compose becomes "gold" for
> a given release we're often creating scratch repos of last minute
> updates that need to be included in the spins.  Making these accessible
> to all the various different places that could be making spins, and
> keeping them coordinated is going to be a huge hurdle, unless we tell
> these spin folks that they have to wait until after GA to make their
> spins.
> 
> Then we run into the fun of "official" Fedora content being created on
> machines outside the control of the Fedora Infrastructure.  Doesn't sit
> very warm and fuzzy in my head.
> 

Well, thinking of it in terms of problems makes heads spin all around 
the world, not just yours.

Thinking in terms of potential solutions however; I'd be OK with a sleep 
86400-times-X after GA for things to settle down and then create the 
localized spins. It should be a batch process.

Whether we use livecd-creator's base_on capability or not for reasons of 
composing efficiency remains to be seen.

Whether we require to media to be composed on Fedora Infrastructure 
seems to be an obvious question, but so far no-one but Release 
Engineering has access to the composing hosts and I'm afraid 
time-constraints will hit it's ability to compose X*Y spins.

Another aspect of composing the spins on Fedora Infrastructure would be 
that the product would need to be seeded initially by the Fedora 
Project, re-introducing the disk space and bandwidth limitations.

If the products were to be composed outside of Fedora Infrastructure, as 
it happens now -while the resulting product is still named "Fedora" btw, 
that introduces a whole new aspect of security and reproducibility 
(and...) concerns. However, someone might be able to cough up a box or 
even a few boxes for Fedora Infrastructure to manage.

Kind regards,

Jeroen van Meeuwen
-kanarip



From john.ellson at comcast.net  Sun Dec 14 13:13:33 2008
From: john.ellson at comcast.net (John Ellson)
Date: Sun, 14 Dec 2008 08:13:33 -0500
Subject: yum --skip-broken update by default?
In-Reply-To: <alpine.LFD.2.00.0812121541280.22105@localhost.localdomain>
References: <1229024782.7518.7.camel@hp6710.axianet.ch>	<alpine.LFD.2.00.0812111508360.14070@localhost.localdomain>	<4941C0F8.6010203@comcast.net>	<604aa7910812111747rc2e064ftab7fe88c77141423@mail.gmail.com>	<4942BEBC.4080402@comcast.net>	<ufabpvh9nhg.fsf@epithumia.math.uh.edu>
	<4942C968.7090803@comcast.net>	<ufa3agt9lr2.fsf@epithumia.math.uh.edu>	<4942CC24.3030401@comcast.net>
	<alpine.LFD.2.00.0812121541280.22105@localhost.localdomain>
Message-ID: <4945067D.5040608@comcast.net>

Seth Vidal wrote:
>
>
> On Fri, 12 Dec 2008, John Ellson wrote:
>
>> My primary complaint is that this dependency conflict
>> isn't listed in the daily yum updates dependency list and that yum 
>> doesn't deal with it automatically.
>
> How would you recommend it be dealt with? And remember we have to have 
> an acceptable behavior for 'yum -y update'.
>
>
> When there is a conflict should we:
> 1. assume the existing pkgs are better
> or
> 2. assume the installing pkgs are better
>
>
> argument in favor of 1 is that the existing pkgs are on the system and 
> should therefore be protected as a possible running service.
>
> argument in favor of 2 is that the user is requesting an action and 
> the user knows best, therefore the requested action must be the 'best' 
> action.
>
> I bet out of 1000 fedora users I'll get an almost even split between 
> them.
> -sv
>

I don't think we ask for broken packages to be installed by doing "yum 
update".      If would be different for "rpm -Uvh --force...."

The currently installed version should never be affected until an 
upgrade can be performed without force, error or exceptions.
This is basic transaction semantics.  (Where the transaction is not the 
entire "yum update", but each independent package dependency subtree).

Anyway, if a package has a conflict, then its not going to install, so 
the installed version wins.

Updates are only allowed if all conditions are met, otherwise something 
is going on that the packager or the developer didn't foresee, and this 
needs
to be reported back to them and fixed.   However, unrelated updates 
should be allowed to proceed.   With ~500M of updates
every day in Rawhide, its not acceptable to block the entire firehose.

Updates should never be forced, because then you have broken dependency 
rules or transformations.


As a user, its mostly not very interesting if an update is broken.  
Don't bother me with it, just tell the packager to fix it and come back 
later.

Occasionally I might be willing to move a few things out of the way 
manually to get an update to install, but for me this is the exception.


-- 
John Ellson



From dtimms at iinet.net.au  Sun Dec 14 13:19:00 2008
From: dtimms at iinet.net.au (David Timms)
Date: Mon, 15 Dec 2008 00:19:00 +1100
Subject: rawhide report: 20081213 changes
In-Reply-To: <20081213190628.CA05C1F8244@releng2.fedora.phx.redhat.com>
References: <20081213190628.CA05C1F8244@releng2.fedora.phx.redhat.com>
Message-ID: <494507C4.9030404@iinet.net.au>

Rawhide Report wrote:
> Compose started at Sat Dec 13 06:01:10 UTC 2008
> 
> New package libmsn
...
> 	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
Just for the giggle: any chance we can get the compose completion time 
echoed to the end of the report.

Some statistical info would also be nice: (but not if it's significantly 
slows the process down ;)

-number of source rpms
-number of binary rpms
-total size of source
-total size of binaries
-average source rpm size
-average binary rpm size

perhaps that is already available on one of the fp.org web sites ? ( 
and/ or this report could have a link to such external info.)

DaveT.



From cra at WPI.EDU  Sun Dec 14 13:57:58 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 14 Dec 2008 08:57:58 -0500
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <alpine.LFD.2.00.0812132147230.27011@localhost.localdomain>
References: <ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081213132418.GA15176@hurricane.linuxnetz.de>
	<20081213141325.GA12103@angus.ind.WPI.EDU>
	<20081213143343.GB15176@hurricane.linuxnetz.de>
	<20081213143718.GB12103@angus.ind.WPI.EDU>
	<alpine.LFD.2.00.0812132147230.27011@localhost.localdomain>
Message-ID: <20081214135758.GA31582@angus.ind.WPI.EDU>

On Sat, Dec 13, 2008 at 09:47:57PM -0500, Seth Vidal wrote:
> On Sat, 13 Dec 2008, Chuck Anderson wrote:
>> PK already has features that yum does not--it shows metadata about
>> updates that yum doesn't, for example.
>
> It does? what metadata would that be? Considering all the info PK has  
> about packages it gets FROM yum I don't see how that's possible.

Yum doesn't show the user the type of the update: security vs. bugfix 
vs. enhancement. It also doesn't show the user the update comments, 
nor any suggested logout/login or reboot actions after the updates are 
applied.  I believe the data comes from updateinfo.xml.gz in the repo.



From jwboyer at gmail.com  Sun Dec 14 14:08:25 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 14 Dec 2008 09:08:25 -0500
Subject: rawhide report: 20081213 changes
In-Reply-To: <494507C4.9030404@iinet.net.au>
References: <20081213190628.CA05C1F8244@releng2.fedora.phx.redhat.com>
	<494507C4.9030404@iinet.net.au>
Message-ID: <20081214140825.GA25488@zod.rchland.ibm.com>

On Mon, Dec 15, 2008 at 12:19:00AM +1100, David Timms wrote:
> Rawhide Report wrote:
>> Compose started at Sat Dec 13 06:01:10 UTC 2008
>>
>> New package libmsn
> ...
>> 	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
> Just for the giggle: any chance we can get the compose completion time  
> echoed to the end of the report.
>
> Some statistical info would also be nice: (but not if it's significantly  
> slows the process down ;)
>
> -number of source rpms
> -number of binary rpms
> -total size of source
> -total size of binaries
> -average source rpm size
> -average binary rpm size
>
> perhaps that is already available on one of the fp.org web sites ? (  
> and/ or this report could have a link to such external info.)

The compose scripts can be found here:

git clone git://git.fedorahosted.org/git/releng

(or https://fedorahosted.org/rel-eng/browser for web browsing).

Patches welcome.

josh



From robert at fedoraproject.org  Sun Dec 14 14:51:30 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 15:51:30 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <4943CC9A.4090606@leemhuis.info>
References: <da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081213132418.GA15176@hurricane.linuxnetz.de>
	<20081213141325.GA12103@angus.ind.WPI.EDU>
	<20081213143343.GB15176@hurricane.linuxnetz.de>
	<4943CC9A.4090606@leemhuis.info>
Message-ID: <20081214145130.GA7579@hurricane.linuxnetz.de>

On Sat, 13 Dec 2008, Thorsten Leemhuis wrote:
> BTW, was "automatic feedback from the clients to bodhi" discussed  
> already somewhere in this thread? E.g. if the package maintainer could  
> see in bodhi "2500 users installed and ran this testin-update for at  
> least three days, no negative karma reported, no new bugs" then it  
> should be quite save to move the package.

That idea seems *very* interesting to me. Especially the result, that there
maybe have been no issues with the update. And if we could extend that even
to non-testing packages, but to regular updates, we even should get, if our
testing results are representative...

AFAIK we anyway don't have something reporting the packager how many people
are using his package. I might be wrong, but Debian has such a tool now for
years - IIRC not with the same goal as in our case, but I got told, it is
useful to the packagers and maintainers there.

Are there possible load issues for such an idea on or around the Fedora
Infrastructure?


Greetings,
  Robert



From robert at fedoraproject.org  Sun Dec 14 14:55:08 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 15:55:08 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
Message-ID: <20081214145508.GA8311@hurricane.linuxnetz.de>

On Tue, 09 Dec 2008, Colin Walters wrote:
> On Tue, Dec 9, 2008 at 12:34 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> > Thoughts on prevention or mediation ideas that would help when people
> > make this sort of mistake?
> 
> I think the simplest would have requiring pushes direct to stable for
> core packages (defining "core" as "anything installed by default on
> the Desktop or Service livecd images") need some sort of signoff,
> possibly from multiple people.

Maybe everything has to go through testing, the number of installation on
clients enabled with testing there compared with the results/karma and the
possible bug reports would give feedback whether its save to move the
package to stable or not - that would move us out of "core" or "base", as
this is anyway impossible to define.


Greetings,
  Robert



From robert at fedoraproject.org  Sun Dec 14 14:58:07 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 15:58:07 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1228834384.6701.15.camel@hughsie-work.lan>
	<faa16b610812090830o44a39e83k460bf7a18da66294@mail.gmail.com>
	<604aa7910812090934w2dca988bj4961766b3932ad1e@mail.gmail.com>
	<faa16b610812090943q15fd6ee3g4333714ee606fddc@mail.gmail.com>
	<604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
Message-ID: <20081214145807.GB8311@hurricane.linuxnetz.de>

Hello Jeff,

On Tue, 09 Dec 2008, Jeff Spaleta wrote:
> Did you really have to use the word "core"?  I think everything on the
> Desktop live image is probably way too broad.  Does all Desktop Live
> functionality need to be protected? Or do we need to safeguard package
> updating functionality specifically?

"core" could be anything, which is needed to run a minimum linux system. No
X, no multimedia etc. But that AFAIK includes dbus already, or am I wrong
so far?


Greetings,
  Robert



From robert at fedoraproject.org  Sun Dec 14 15:28:58 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 16:28:58 +0100
Subject: Stalled "Merge Reviews" (Re: What Fedora makes sucking for me
	- or why I am NOT Fedora
In-Reply-To: <493EBAB5.3010209@behdad.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EBAB5.3010209@behdad.org>
Message-ID: <20081214152858.GC8311@hurricane.linuxnetz.de>

Hello Behdad,

On Tue, 09 Dec 2008, Behdad Esfahbod wrote:
> First, it's not like you wake up in the morning and boot your Fedora and it
> pops up a message saying "Merge reviews are not fixied, shutting system
> down."??  What's the problem really, other than some cruft left in Bugzilla?

nobody forces to you maintain a package in Fedora: Simply orphan it. Any
Fedora packager has to go through a Package Review, before the package can
ever reach Fedora. But just there was Red Hat Linux and Fedora Core before
which was maintained exclusively by Red Hat, there's no exception for the
Red Hat people. On the other hand, the exception already exists since the
Fedora 7 release - which is now 1.5 years or 3 Fedora releases.

> If you were implying that the unreviewed packages should have been removed
> from Fedora, go ahead, remove cairo, fontconfig, freetype, pango, and vte.

That would maybe wake-up the packagers to either take care of their package
or to orphan them, that somebody else, who is maybe more active can take
care of it.

> If you are implying that as their maintainer, I must incorporate the merge
> reviews and close them, no thank you, I don't mind not maintaining anything in
> Fedora, and I certainly didn't block anyone from making progress in the merge
> reviews.  When you say "The Red Hat people have to follow the Fedora packaging
> guidelines and rules same as the Fedora folks", does it mean that Fedora
> should feel free to decide what *I* work on, when it doesn't decide what
> "other Fedora folks" work on?  That doesn't feel right.

You're seeing this IMHO from the wrong point of view. Read my view above on
the beginning of this e-mail. Either Red Hat people are following the rules
1.5 years after the deadline or just orphan your package if you don't want
to maintain it. Especially blocking and stopping a Merge Review caused by
Red Hat people is worse; and answers with the context of "I'm not following
the Fedora Packaging Guidelines, because I am the maintainer and I don't
care about the Packaging Guidelines" are not valid and worse for Fedora. So
why try some Red Hat people to be an exception?

Surely, Red Hat is the biggest sponsor of Fedora etc. But why was there the
merge then of Fedora Core (hard spoken: Red Hat) and Extras (hard spoken:
all non-Red Hat) if several Red Hat people refuse to walk with Fedora as it
was planned?

> Not sure what your point was, other than making your long email even longer

Getting the Merge Reviews now - 1.5 years after they should have been done
- really done and ensuring the same packaging quality for the former Red
Hat Linux and Fedora Core packages as the other former Fedora Extras and
afterwards just Fedora packages.

I think, that's a point I'm now hereby putting on the todo list of Fedora
Project Leader - as he's a Red Hat employee and as he can maybe delegate
this via the corresponding managers to the employees. I already mentioned
that during LinuxTag 2008 in Berlin, but likes the point got lost somewhere
until now, so see this please as remembering, Paul.


Greetings,
  Robert



From robert at fedoraproject.org  Sun Dec 14 15:53:06 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 16:53:06 +0100
Subject: Stalled "Merge Reviews" (Re: What Fedora makes sucking for me
	- or why I am NOT Fedora
In-Reply-To: <604aa7910812091123r2a763004k9bdc7bff70604cfa@mail.gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<493EBAB5.3010209@behdad.org>
	<604aa7910812091123r2a763004k9bdc7bff70604cfa@mail.gmail.com>
Message-ID: <20081214155306.GE8311@hurricane.linuxnetz.de>

Hello Jeff,

On Tue, 09 Dec 2008, Jeff Spaleta wrote:
> I think the point is to..politely..remind us the merge reviews should
> be completed.  Taking away more than that is probably not worthwhile.
> I think we can all agree that we'd like the merges done.  The question
> before us is, and has been, how do we motivate people to do that work?
>  I'm just as culpable as anyone... I haven't even completed all the
> reviews I started.

we've several awards now, wouldn't be a "Reviewer of the Month" or similar
some kind of motivation. But then, maybe quantity rather quality could come
up, which would be worse as well.


Greetings,
  Robert



From bruno at wolff.to  Sun Dec 14 16:13:46 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Sun, 14 Dec 2008 10:13:46 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812132243g759e4858p70cce755b32d6249@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<16de708d0812132243g759e4858p70cce755b32d6249@mail.gmail.com>
Message-ID: <20081214161346.GA5501@wolff.to>

On Sun, Dec 14, 2008 at 00:43:56 -0600,
  Arthur Pemberton <pemboa at gmail.com> wrote:
> 
> Are there any up to date instructions on this? Wouldn't mind spinning
> my own KDE Live USB

Be aware that you may tweak the provided kickstart files with some
unexpected things. With updates and updates-testing enabled I found
that using fedora-live-base.ks didn't bring in a display manager.
For the time being I added gdm to kickstart file I am working with.
I have also been finding this is a good way to find packages that don't
have the prerequisites for scripts properly defined. If you see install
errors during the yum install part of the build, you might want to file
bugs.



From pavel.lisy at gmail.com  Sun Dec 14 16:24:34 2008
From: pavel.lisy at gmail.com (Pavel =?ISO-8859-1?Q?Lis=FD?=)
Date: Sun, 14 Dec 2008 17:24:34 +0100
Subject: Fedora GIS SIG
Message-ID: <1229271874.5977.9.camel@pali-desktop.lisilan.cz>

Hello,

this is not fun :-)

I'm interesting in Geographic Information System (GIS) and I want to
join to packaging these rpms especially to EPEL. Is here place to
discuss about it or better mail list exists?

If this is right place I'll be back soon :-)

Pavel



From carl at five-ten-sg.com  Sun Dec 14 16:39:22 2008
From: carl at five-ten-sg.com (Carl Byington)
Date: Sun, 14 Dec 2008 08:39:22 -0800
Subject: how to add fc10-update branch?
In-Reply-To: <200811281621.00146.konrad@tylerc.org>
References: <1227917728.26993.32.camel@ns.five-ten-sg.com>
	<200811281621.00146.konrad@tylerc.org>
Message-ID: <1229272762.5224.3.camel@ns.five-ten-sg.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 2008-11-28 at 16:21 -0800, Conrad Meyer wrote:

> > That worked to build dist-f10 packages, and of course it now builds
> a
> > dist-f11 package. What steps do I need to build an updated f10
> package,
> > presumably going into something like dist-f10-updates-candidate
> that
> > can then be (eventually) fetched via yum update?

> cd fedora/$NAME
> cvs up -d

> Then your workflow is:

> cd fedora/$NAME/F-10
> cvs up
> make new-sources FILES=$BALL
> cvs ci -m "update to $VER"
> make tag build

That is working, but the new package does not show up with 'yum list
libpst' on a Fedora 10 system. 0.6.23-1.fc10 was built over a week ago.
Is there just a long delay before packages show up in the repositories,
or do I need to get some f-10-updates branch created?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFJRTaQL6j7milTFsERAu/MAJwLEWyAm/keP3iylX8bHIEb1K/nmgCfQnHE
0gH65Ms/MaZgemuT+Du4Aoc=
=GsMb
-----END PGP SIGNATURE-----




From lemenkov at gmail.com  Sun Dec 14 16:42:03 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 14 Dec 2008 19:42:03 +0300
Subject: Fedora GIS SIG
In-Reply-To: <1229271874.5977.9.camel@pali-desktop.lisilan.cz>
References: <1229271874.5977.9.camel@pali-desktop.lisilan.cz>
Message-ID: <adf480660812140842t1b1d596cvede2bc2b7bce0bb7@mail.gmail.com>

Hello!

2008/12/14, Pavel Lis? <pavel.lisy at gmail.com>:
> Hello,
>
>  this is not fun :-)

Definitely not. :)

>  I'm interesting in Geographic Information System (GIS) and I want to
>  join to packaging these rpms especially to EPEL. Is here place to
>  discuss about it or better mail list exists?

You may ask questions here.
Also, Fedora GIS SiG dedicated page is a good point to start from:

https://fedoraproject.org/wiki/GIS

-- 
With best regards!



From skvidal at fedoraproject.org  Sun Dec 14 16:53:15 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sun, 14 Dec 2008 11:53:15 -0500 (EST)
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
 am NOT Fedora
In-Reply-To: <20081214135758.GA31582@angus.ind.WPI.EDU>
References: <ghkq7m$46p$1@ger.gmane.org>
	<20081209104955.55a363b2.mschwendt@gmail.com>
	<20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081213132418.GA15176@hurricane.linuxnetz.de>
	<20081213141325.GA12103@angus.ind.WPI.EDU>
	<20081213143343.GB15176@hurricane.linuxnetz.de>
	<20081213143718.GB12103@angus.ind.WPI.EDU>
	<alpine.LFD.2.00.0812132147230.27011@localhost.localdomain>
	<20081214135758.GA31582@angus.ind.WPI.EDU>
Message-ID: <alpine.LFD.2.00.0812141152001.30438@localhost.localdomain>



On Sun, 14 Dec 2008, Chuck Anderson wrote:

> On Sat, Dec 13, 2008 at 09:47:57PM -0500, Seth Vidal wrote:
>> On Sat, 13 Dec 2008, Chuck Anderson wrote:
>>> PK already has features that yum does not--it shows metadata about
>>> updates that yum doesn't, for example.
>>
>> It does? what metadata would that be? Considering all the info PK has
>> about packages it gets FROM yum I don't see how that's possible.
>
> Yum doesn't show the user the type of the update: security vs. bugfix
> vs. enhancement. It also doesn't show the user the update comments,
> nor any suggested logout/login or reboot actions after the updates are
> applied.  I believe the data comes from updateinfo.xml.gz in the repo.


yum install yum-security

Description:
This plugin adds the options --security, --cve, --bz and --advisory
flags to yum and the list-security and info-security 
commands. The options make it possible to limit list/upgrade of packages to
specific security relevant ones. The commands give you the security information.


-sv





From triad at df.lth.se  Sun Dec 14 17:17:00 2008
From: triad at df.lth.se (Linus Walleij)
Date: Sun, 14 Dec 2008 18:17:00 +0100
Subject: Installing from Live CD is the new black?
In-Reply-To: <20081211181856.GB27793@localhost.localdomain>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
Message-ID: <1229275020.3091.2.camel@fecusia>

tor 2008-12-11 klockan 13:18 -0500 skrev Chris Lumens:

> > And I cannot switch to say harddisk or netinstall either, none of that
> > works as it should.
> 
> This is likely due to the changes I made in how we find the install.img.

Yeah that was it, hm, I should've looked harder for that info.

In the past I had to use say 6 .iso files to get this to work, does it
work to simply use the DVD image and extract the install.img from that
these days? That used to be impossible, to me atleast.

Linus



From mschwendt at gmail.com  Sun Dec 14 17:21:29 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 14 Dec 2008 17:21:29 -0000
Subject: Broken dependencies in Fedora 10 - 2008-12-14
Message-ID: <20081214172129.17830.82330@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by owner):

    aconway AT redhat.com
        qpidc

    cooly AT gnome.eu.org
        fuse-emulator-utils

    dhuff AT redhat.com
        appliance-tools

    mnowak AT redhat.com
        eclipse-pydev

    mr.ecik AT gmail.com
        kadu

    sundaram AT redhat.com
        gyachi
        olpc-utils


======================================================================
Broken packages in fedora-10-i386:

    fuse-emulator-utils-0.9.0-3.fc10.i386  requires  libspectrum.so.5
    gyachi-plugin-photo_album-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    qpidd-cluster-0.3.705289-1.fc10.i386  requires  qpidd = 0:0.3.705289-1.fc10


======================================================================
Broken packages in fedora-10-ppc:

    fuse-emulator-utils-0.9.0-3.fc10.ppc  requires  libspectrum.so.5
    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10


======================================================================
Broken packages in fedora-10-ppc64:

    fuse-emulator-utils-0.9.0-3.fc10.ppc64  requires  libspectrum.so.5()(64bit)
    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10


======================================================================
Broken packages in fedora-10-x86_64:

    fuse-emulator-utils-0.9.0-3.fc10.x86_64  requires  libspectrum.so.5()(64bit)
    gyachi-plugin-photo_album-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    qpidd-cluster-0.3.705289-1.fc10.x86_64  requires  qpidd = 0:0.3.705289-1.fc10


======================================================================
Broken packages in fedora-updates-10-i386:

    olpc-utils-0.89-6.fc10.i386  requires  olpcupdate >= 0:2.10


======================================================================
Broken packages in fedora-updates-10-ppc:

    olpc-utils-0.89-6.fc10.ppc  requires  olpcupdate >= 0:2.10


======================================================================
Broken packages in fedora-updates-10-ppc64:

    appliance-tools-003.9-1.fc10.noarch  requires  qemu-img
    olpc-utils-0.89-6.fc10.ppc64  requires  olpcupdate >= 0:2.10


======================================================================
Broken packages in fedora-updates-10-x86_64:

    olpc-utils-0.89-6.fc10.x86_64  requires  olpcupdate >= 0:2.10


======================================================================
Broken packages in fedora-updates-testing-10-ppc:

    1:eclipse-pydev-1.3.24-2.fc10.noarch  requires  python-psyco


======================================================================
Broken packages in fedora-updates-testing-10-ppc64:

    1:eclipse-pydev-1.3.24-2.fc10.noarch  requires  python-psyco


======================================================================
Broken packages in fedora-updates-testing-10-x86_64:

    1:eclipse-pydev-1.3.24-2.fc10.noarch  requires  python-psyco



From mschwendt at gmail.com  Sun Dec 14 17:32:46 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 14 Dec 2008 18:32:46 +0100
Subject: how to add fc10-update branch?
In-Reply-To: <1229272762.5224.3.camel@ns.five-ten-sg.com>
References: <1227917728.26993.32.camel@ns.five-ten-sg.com>
	<200811281621.00146.konrad@tylerc.org>
	<1229272762.5224.3.camel@ns.five-ten-sg.com>
Message-ID: <20081214183246.f28ee5cd.mschwendt@gmail.com>

On Sun, 14 Dec 2008 08:39:22 -0800, Carl wrote:

> > cd fedora/$NAME/F-10
> > cvs up
> > make new-sources FILES=$BALL
> > cvs ci -m "update to $VER"
> > make tag build
> 
> That is working, but the new package does not show up with 'yum list
> libpst' on a Fedora 10 system. 0.6.23-1.fc10 was built over a week ago.
> Is there just a long delay before packages show up in the repositories,
> or do I need to get some f-10-updates branch created?

You need to submit an update request via bodhi ("make update")
or via the web page: https://admin.fedoraproject.org/updates/



From rawhide at fedoraproject.org  Sun Dec 14 17:37:08 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 14 Dec 2008 17:37:08 +0000 (UTC)
Subject: rawhide report: 20081214 changes
Message-ID: <20081214173709.325FF1F81C9@releng2.fedora.phx.redhat.com>

Compose started at Sun Dec 14 06:01:12 UTC 2008

Updated Packages:

GtkAda-2.10.2-1.fc11
--------------------
* Sat Dec 13 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 2.10.2-1
- new release 2.10.2


adminutil-1.1.7-2.fc10
----------------------
* Mon Dec  8 17:00:00 2008 Rich Megginson <rmeggins at redhat.com> - 1.1.7-2
- force rebuild for f10 official release

* Wed Aug 27 18:00:00 2008 Rich Megginson <rmeggins at redhat.com> - 1.1.7-1
- Resolves bug 454060   -  ViewLog CGI crash with new adminutil
- Resolves bug 413531   -  Web browser accepted languages configuration causes dsgw CGI binaries to segfault


audio-convert-mod-3.45.4-3.fc11
-------------------------------
* Sat Dec 13 17:00:00 2008 Stewart Adam <s.adam at diffingo.com> - 3.45.4-3
- Add patch for fixing lame decode


audit-1.7.10-1.fc11
-------------------
* Sat Dec 13 17:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.10-1
- New upstream release


boinc-client-6.2.15-2.20080818svn.fc11
--------------------------------------
* Sat Dec 13 17:00:00 2008 Milos Jakubicek <xjakub at fi.muni.cz> - 6.2.15-2.20080818svn
- Fix usage of $BOINCDIR in the init script


cairo-1.8.0-3.fc11
------------------
* Sun Dec 14 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 1.8.0-3
- Rebuild for pkgconfig provides

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 1.8.0-2
- Tweak %summary and %documentation


cairo-dock-2.0.0-0.1.svn1434_trunk.fc11
---------------------------------------
* Sun Dec 14 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1434


deco-archive-1.3.1-1.fc11
-------------------------
* Fri Dec 12 17:00:00 2008 Orcan Ogetbil <orcanbahri [AT] yahoo [DOT] com> 1.3.1-1
- Version update
- Use ffmpeg instead of wine+Monkey's Audio for converting ape to wav


fldigi-3.03-1.fc11
------------------
* Sun Dec 14 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> 3.03-1
- New upstream release
- Remove explicit libsamplerate dependency


fuse-emulator-0.10.0.1-1.fc11
-----------------------------
* Sat Dec 13 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.10.0.1-1
- new upstream critial fix release


fuse-emulator-utils-0.10.0.1-1.fc11
-----------------------------------
* Sat Dec 13 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.10.0.1-1
- new upstream package (package was missing files)


gai-0.5.10-16.fc11
------------------
* Sat Dec 13 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.5.10-16
- Rebuild to get automatic pkgconfig(..) Requires.


gtk2-engines-2.17.2-1.fc11
--------------------------
* Sat Dec 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.17.2-1
- Update to 2.17.2


jd-2.1.0-0.1.svn2559_trunk.fc11
-------------------------------
* Sun Dec 14 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2559


kde-plasma-quickaccess-0.7.1-5.fc11
-----------------------------------
* Sun Dec 14 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.7.1-5
- drop libkonq hack, linker search path fixed in kdelibs now


kdeartwork-4.1.85-1.fc11
------------------------
* Thu Dec 11 17:00:00 2008 Than Ngo <than at redhat.com> -  4.1.85-1
- 4.2beta2


kdelibs-4.1.85-2.fc11
---------------------
* Sun Dec 14 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 4.1.85-2
- tweak parallel_devel patch to get a -L flag for the symlink directory


kdepim-4.1.85-1.fc11
--------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.85-1
- 4.2beta2


libgee-0.1.4-1.fc11
-------------------
* Sat Dec 13 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.1.4-1
- Update to 0.1.4


linkchecker-4.7-14.fc11
-----------------------
* Fri Dec 12 17:00:00 2008 W. Michael Petullo <mike[at]flyn.org> - 4.7-14
- Dynamically discover version (for .egg-info), do not hard code.

* Fri Dec 12 17:00:00 2008 W. Michael Petullo <mike[at]flyn.org> - 4.7-13
- linkchecker-4.7-py2.5.egg-info -> 2.6.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.7-12
- Rebuild for Python 2.6


perl-Business-Hours-0.09-1.fc11
-------------------------------
* Sat Dec 13 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.09-1
- Upstream update.
- Reflect Source0-URL having changed.


perl-Exception-Class-1.26-1.fc11
--------------------------------
* Fri Dec 12 17:00:00 2008 Steven Pritchard <steve at kspei.com> 1.26-1
- Update to 1.26.
- Bump Devel::StackTrace dependency to 1.20.


perl-File-Copy-Recursive-0.38-1.fc11
------------------------------------
* Sat Dec 13 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.38-1
- Upstream update.


php-5.2.8-2.fc11
----------------
* Sat Dec 13 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 5.2.8-2
- libtool 2 workaround for phpize (#476004)
- add missing php_embed.h (#457777)


pixman-0.12.0-3.fc11
--------------------
* Sun Dec 14 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.12.0-3
- Rebuild for pkgconfig provides


python-html2text-2.35-1.1
-------------------------
* Sat Dec 13 17:00:00 2008 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 2.35-1
- update to 2.35


qgis-0.11.0-4.fc10
------------------
* Tue Dec  9 17:00:00 2008 Douglas E. Warner <silfreed at silfreed.net> - 0.11.0-4
- Rebuild for geos to fix broken deps


rkhunter-1.3.2-6.fc11
---------------------
* Sat Dec 13 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 1.3.2-6
- Fix cron job sending as attachment - bug #472679
- Fix cron job trying to send with colors - bug #475916


rubygems-1.3.1-1.fc11
---------------------
* Sun Nov  9 17:00:00 2008 Jeroen van Meeuwen <kanarip at kanarip.com> - 1.3.1-1
- New upstream version


switchdesk-4.0.9-4.fc11
-----------------------
* Sat Dec 13 17:00:00 2008 Than Ngo <than at redhat.com> - 4.0.9-4
- fix bz447749, broken desktop file


sysklogd-1.5-5.fc11
-------------------
* Sat Dec 13 17:00:00 2008 Jeroen van Meeuwen <kanarip at fedoraproject.org> 1.5-5
- Put binaries in the correct path (#471701)


vala-0.5.2-1.fc11
-----------------
* Sat Dec 13 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.5.2-1
- Update to 0.5.2


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 32
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.i386 requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libmusicbrainz3-devel-3.0.2-2.fc11.i386 requires pkgconfig(libdiscid)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.i386 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.x86_64 requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libmusicbrainz3-devel-3.0.2-2.fc11.i386 requires pkgconfig(libdiscid)
	libmusicbrainz3-devel-3.0.2-2.fc11.x86_64 requires pkgconfig(libdiscid)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.x86_64 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	1:eclipse-pydev-1.3.24-3.fc11.noarch requires python-psyco
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	ghc-haddock-2.0.0.0-3.fc10.ppc requires ghc = 0:6.8.3
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libmusicbrainz3-devel-3.0.2-2.fc11.ppc requires pkgconfig(libdiscid)
	libmusicbrainz3-devel-3.0.2-2.fc11.ppc64 requires pkgconfig(libdiscid)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.ppc requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:eclipse-pydev-1.3.24-3.fc11.noarch requires python-psyco
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libmusicbrainz3-devel-3.0.2-2.fc11.ppc64 requires pkgconfig(libdiscid)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.ppc64 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From pavel.lisy at gmail.com  Sun Dec 14 17:59:41 2008
From: pavel.lisy at gmail.com (Pavel =?ISO-8859-1?Q?Lis=FD?=)
Date: Sun, 14 Dec 2008 18:59:41 +0100
Subject: Fedora GIS SIG
In-Reply-To: <adf480660812140842t1b1d596cvede2bc2b7bce0bb7@mail.gmail.com>
References: <1229271874.5977.9.camel@pali-desktop.lisilan.cz>
	<adf480660812140842t1b1d596cvede2bc2b7bce0bb7@mail.gmail.com>
Message-ID: <1229277582.5977.23.camel@pali-desktop.lisilan.cz>

Peter Lemenkov p??e v Ne 14. 12. 2008 v 19:42 +0300:
> Hello!
> 
> 2008/12/14, Pavel Lis? <pavel.lisy at gmail.com>:
> > Hello,
> >
> >  this is not fun :-)
> 
> Definitely not. :)
> 
> >  I'm interesting in Geographic Information System (GIS) and I want to
> >  join to packaging these rpms especially to EPEL. Is here place to
> >  discuss about it or better mail list exists?
> 
> You may ask questions here.
> Also, Fedora GIS SiG dedicated page is a good point to start from:
> 
> https://fedoraproject.org/wiki/GIS

I know this place but there is no information about members or how to
make first contact. Can anybody add it there? 

i.e. Juha.Tuomala at iki.fi wrote me about #fedora-gis IRC, which is better
then nothing but with time zones is mailing list often better.

Pavel

> -- 
> With best regards!
> 



From jamundso at gmail.com  Sun Dec 14 18:00:31 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 14 Dec 2008 12:00:31 -0600
Subject: A way out of the update trap
In-Reply-To: <604aa7910812121240q46058b61g98d329e250194797@mail.gmail.com>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
	<20081212195950.GA2866@free.fr>
	<604aa7910812121240q46058b61g98d329e250194797@mail.gmail.com>
Message-ID: <6d06ce20812141000q60b74d1ehc1379aeedbd9b2ca@mail.gmail.com>

On Fri, Dec 12, 2008 at 2:40 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Fri, Dec 12, 2008 at 10:59 AM, Patrice Dumas <pertusus at free.fr> wrote:
>> I'd propose, more largely @code, @base and dependencies.
>
> I think that's too broad a target to start with and you don't have the
> QA resourses in place to support a policy that broad.
>
> If QA resources are scarce, how about we treat them as scarce and
> build narrow policies which let the existing resources get used for
> best benefit on targetted priorities. And as resources grow, we grow
> the list of priorities downward into more areas.

Yes!

> Right now. I am asking us as a project to suck it up and identify a
> top functionality priority and to live within our means as it comes to
> existing QA expectations.

Based on an informal weighted system, using scores for Technicality,
Severity, and Emotional impact, these add up fairly evenly:

*) grub (e.g. Bug 450143) - not so severe, and short to fix (for those
adept with repair disk), but it's soooo disheartening to see a system
turned to paperweight in an instant.

*) wireless - it just *has* to work, period. Oft-times, even currently
wired areas (campus, business, etc.) go wireless. Extra bonus :
connect in runlevel 3. I can *remote desktop* to my laptop upstairs
when it's running the windowing os from M$, yet I can't even ssh to it
when I boot up Fedora. Come on, it's nearly 2009 folks....

*) the stuff between grub and networking (forgive the generalization
:-) - wired networking included here as a fallback option and is,
generally, easier to implement/fix.

*) wired network - it's still important.

[unless we have the above, we don't have a simple update ability, right?]

*) [pony alert] some sort of 'update from media' feature - like an
"Install from" dvd/cd/sd which contains updates instead of base
packages... repair-disk-on-drugs... Something to help get the machine
back that's easier than going into the office, burning to cd all the
packages to fix my breakage (assuming I've figured that out beforehand
- of course I'd get it right the first time!), booting it (assuming I
can), mount the cd (assuming I can), edit yum.conf for the disk-based
updates, and apply them...??

*) Package Updating at the console (rpm and yum)

*) The desktop that, 1. Works, and 2. Looks the same as my previous
login [related example is KDE in rawhide - no desktop, but the right
click konsole terminal is there at least - even better with a wireless
net, see above :-)]

jerry

-- 
TBD.



From jkeating at redhat.com  Sun Dec 14 18:16:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 14 Dec 2008 10:16:53 -0800
Subject: [Fedora Update] [testing] vala-0.5.2-2.fc8
In-Reply-To: <20081214050009.E3BE5208742@bastion.fedora.phx.redhat.com>
References: <20081214050009.E3BE5208742@bastion.fedora.phx.redhat.com>
Message-ID: <1229278613.3863.168.camel@localhost.localdomain>

On Sun, 2008-12-14 at 05:00 +0000, updates at fedoraproject.org wrote:
> salimma has requested the pushing of the following update to testing:
> 
> ================================================================================
>      vala-0.5.2-2.fc8
> ================================================================================
>     Release: Fedora 8
>      Status: pending
>        Type: enhancement
>       Karma: 0
>     Request: testing
>   Submitter: salimma
>   Submitted: 2008-12-14 05:00:08
>    Comments: salimma - 2008-12-14 05:00:09 (karma 0)
>              This update has been submitted for testing
> 
>   http://admin.fedoraproject.org/updates/vala-0.5.2-2.fc8


What is the purpose of this version bump (0.3.5 -> 0.5.2) in F8, which
only has a few weeks of lifespan yet.  There is no information in the
update request that would help users understand why they should consume
this update.  Please fill in some details, and consider whether the
update is suitable for Fedora 8.
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users

> 
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081214/e5c33343/attachment.sig>

From robert at fedoraproject.org  Sun Dec 14 18:22:04 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 19:22:04 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <200812112248.55542.opensource@till.name>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<200812112200.46965.opensource@till.name>
	<494184CC.1020104@gmail.com>
	<200812112248.55542.opensource@till.name>
Message-ID: <20081214182204.GA31351@hurricane.linuxnetz.de>

Hello Till,

On Thu, 11 Dec 2008, Till Maas wrote:
> I agree here. I already mentioned some methods in another e-mail. Another 
> possibility I just thought of would be to create reverse delta rpms, i.e. 
> before an rpm is installed, a delta to the current state is created and stored 
> somewhere. This can then used to restore the previous state. Of course someone 
> needs to write this. :-)

Shrug. Who will be the lucky guy doing this? IMHO delta rpms are making the
handling of packages just more complicated, even they e.g. save traffic.
Oh, did already implement somebody the downgrading once the last update
using a delta rpm was broken? That's a thing, e.g. openSUSE is AFAIK now
lacking for years and nobody took care there, even they're using delta rpms
also for years now there. In fact, I wasn't seeing a working downgrade at a
bigger Linux distribution until now once delta rpms have been in use there.


Greetings,
  Robert



From robert at fedoraproject.org  Sun Dec 14 18:33:54 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 19:33:54 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsht6$gpk$1@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
Message-ID: <20081214183354.GB31351@hurricane.linuxnetz.de>

Hello Kevin,

On Fri, 12 Dec 2008, Kevin Kofler wrote:
> Robert Scheck wrote:
> > Of course I understand, that dbus is nice and so on, but I'm not seeing
> > how it is really useful. Again, the push happens about every 24 hours and
> > the cache of the downloaded files by yum expires after maybe one hour, if
> > I am not wrong here. Why do we generate such unnecessary load and traffic?
> 
> Because you do not know *when* the update push happens. And there are
> third-party repos which sometimes push several updates a day.

maybe true, but do users really need to be so up-to-date? Mirrors also need
time to synchronize, as we learned in this thread, right? I'm still lacking
a good reason why we're checking each yum interaction for updated metadata
as far as I can see.

And since when support we third-party repositories? I had to hear here in
my thread as well, that e.g. proprietary drivers are not supported by
Fedora. So why should third-party repositories get any love and so on by
Fedora now?

If a third-party repository needs something else, make an option into yum
to configure that per repository.

If one time per 24 hours is too less, which seems understandable, let us
switch to two or three times a day, that's even three times more than for
Fedora a push to stable happens. And waiting 4 to 6 hours for an update is
more then acceptable - again, mirrors need also time to get synchronous.


Greetings,
  Robert



From robert at fedoraproject.org  Sun Dec 14 18:36:53 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 19:36:53 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghsjof$k8d$3@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<ghq7vu$5to$5@ger.gmane.org> <ghqcjc$iea$1@ger.gmane.org>
	<200812111242.15428.opensource@till.name>
	<494151CB.3020605@gmail.com> <ghsjof$k8d$3@ger.gmane.org>
Message-ID: <20081214183653.GC31351@hurricane.linuxnetz.de>

Hello Kevin,

On Fri, 12 Dec 2008, Kevin Kofler wrote:
> It's much easier to rpm -Uvh --oldpackage to an older version than to get
> rid of some custom-installed version.

IMHO only as long as no delta rpms are in use or did somebody already
implement fine working downgrades to an application?


Greetings,
  Robert



From lesmikesell at gmail.com  Sun Dec 14 18:48:46 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 14 Dec 2008 12:48:46 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081214183354.GB31351@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<20081211124523.GA31161@hurricane.linuxnetz.de>	<1229017523.30987.138.camel@code.and.org>	<20081212001005.GA15306@hurricane.linuxnetz.de>	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
Message-ID: <4945550E.4040000@gmail.com>

Robert Scheck wrote:
> 
>>> Of course I understand, that dbus is nice and so on, but I'm not seeing
>>> how it is really useful. Again, the push happens about every 24 hours and
>>> the cache of the downloaded files by yum expires after maybe one hour, if
>>> I am not wrong here. Why do we generate such unnecessary load and traffic?
>> Because you do not know *when* the update push happens. And there are
>> third-party repos which sometimes push several updates a day.
> 
> maybe true, but do users really need to be so up-to-date? Mirrors also need
> time to synchronize, as we learned in this thread, right? I'm still lacking
> a good reason why we're checking each yum interaction for updated metadata
> as far as I can see.

Being far out-of-date doesn't help avoid doing your update in the middle 
of a push with mirrors out of sync, or are you proposing some sort of 
fixed schedule with update blackouts while the mirrors catch up?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From robert at fedoraproject.org  Sun Dec 14 18:50:02 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 19:50:02 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <ghslsa$k8d$10@ger.gmane.org>
References: <604aa7910812090958h1d11ac43i4a079fcfd993cbe7@mail.gmail.com>
	<ghq7vu$5to$5@ger.gmane.org> <ghqcjc$iea$1@ger.gmane.org>
	<200812111242.15428.opensource@till.name>
	<494151CB.3020605@gmail.com> <ghsjof$k8d$3@ger.gmane.org>
	<4941D9A6.4000602@gmail.com> <ghslsa$k8d$10@ger.gmane.org>
Message-ID: <20081214185002.GA2976@hurricane.linuxnetz.de>

Hello Kevin,

On Fri, 12 Dec 2008, Kevin Kofler wrote:
> That's exactly why we need new versions built for stable updates rather than
> just using the Rawhide versions. The whole point of building for the
> current/previous release (rather than the next one, i.e. Rawhide) is to (in
> the vast majority of cases) NOT need new incompatible dependencies.

this isn't always true. There are cases, where backporting causes more work
to the packager than simply updating. And what if, when a security update
is fixed by rewriting parts of the (already further developed) code, thus
the fix behind is only very hard to backport? That's IMHO an point, where
an incompatible update can make it into a stable release. If such a release
is now buggy, flipping down is maybe hard to the end user as well.


Greetings,
  Robert



From robert at fedoraproject.org  Sun Dec 14 20:28:39 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 21:28:39 +0100
Subject: Fedora QA ? - Re: What Fedora makes sucking for me - or why I
	am NOT Fedora
In-Reply-To: <20081212133853.33a06a4f.mschwendt@gmail.com>
References: <20081209100229.GD3833@free.fr> <20081209120300.GJ14496@killefiz>
	<b0k416xn77.ln2@ppp1053.in.ipex.cz>
	<20081211160811.GG21424@killefiz>
	<1229014354.3394.1226.camel@beck.corsepiu.local>
	<1229017310.3381.48.camel@wicktop.localdomain>
	<1229055659.3081.194.camel@beck.corsepiu.local>
	<20081212121413.033685ca.mschwendt@gmail.com>
	<1229080807.3081.232.camel@beck.corsepiu.local>
	<20081212133853.33a06a4f.mschwendt@gmail.com>
Message-ID: <20081214202839.GD31351@hurricane.linuxnetz.de>

Hello Michael,

On Fri, 12 Dec 2008, Michael Schwendt wrote:
> The problem Fedora has is that updates-testing is not popular enough.

well, this is not the only problem. There's also a thinking of, that the
repository contains buggy packages, broken dependencies and other stuff,
which will eat your baby. And of course that's partitially right. Maybe it
doesn't eat the Fedora system, but who can be sure when it's testing?

I think, that's an unresolvable issue, but there are enough users out
there, which will never enable updates-testing because of this thinking.
But less testing makes updates-testing and even updates not better (if some
testing happens at all).

> Whenever someone says "Fedora is community-driven" I'd really like to see
> that it means "update pkg foo passed the testing done by a group of
> power-users" and not just "Fedora provides a system where a single package
> maintainer is free to unleash a pkg and burden the community with breakage".

I like also to see the idea, where the installations of a package are
counted and reported to the maintainer who can compare the number with
issues and problems reported for. E.g. 100 installations of an updated
package where no new issues where reported for.


Greetings,
  Robert



From robert at fedoraproject.org  Sun Dec 14 20:42:15 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 14 Dec 2008 21:42:15 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4945550E.4040000@gmail.com>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
	<4945550E.4040000@gmail.com>
Message-ID: <20081214204215.GE31351@hurricane.linuxnetz.de>

Hello Les,

On Sun, 14 Dec 2008, Les Mikesell wrote:
> Being far out-of-date doesn't help avoid doing your update in the middle  
> of a push with mirrors out of sync, or are you proposing some sort of  
> fixed schedule with update blackouts while the mirrors catch up?

indirectly im thinking about the second, yes. The question is whether it's
realistic or even possible or not. And it lowers the need on client side to
check very often for updates as we're currently doing.


Greetings,
  Robert



From skvidal at fedoraproject.org  Sun Dec 14 21:07:10 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sun, 14 Dec 2008 16:07:10 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081214183354.GB31351@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
Message-ID: <alpine.LFD.2.00.0812141606360.30438@localhost.localdomain>



On Sun, 14 Dec 2008, Robert Scheck wrote:

> Hello Kevin,
>
> On Fri, 12 Dec 2008, Kevin Kofler wrote:
>> Robert Scheck wrote:
>>> Of course I understand, that dbus is nice and so on, but I'm not seeing
>>> how it is really useful. Again, the push happens about every 24 hours and
>>> the cache of the downloaded files by yum expires after maybe one hour, if
>>> I am not wrong here. Why do we generate such unnecessary load and traffic?
>>
>> Because you do not know *when* the update push happens. And there are
>> third-party repos which sometimes push several updates a day.
>
> maybe true, but do users really need to be so up-to-date? Mirrors also need
> time to synchronize, as we learned in this thread, right? I'm still lacking
> a good reason why we're checking each yum interaction for updated metadata
> as far as I can see.

It's checking for new metadata when the cache timeout occurs. It's an 
option per-repo or globally.


-sv



From skvidal at fedoraproject.org  Sun Dec 14 21:12:13 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sun, 14 Dec 2008 16:12:13 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081214182204.GA31351@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<200812112200.46965.opensource@till.name>
	<494184CC.1020104@gmail.com>
	<200812112248.55542.opensource@till.name>
	<20081214182204.GA31351@hurricane.linuxnetz.de>
Message-ID: <alpine.LFD.2.00.0812141609320.30438@localhost.localdomain>



On Sun, 14 Dec 2008, Robert Scheck wrote:

> Hello Till,
>
> On Thu, 11 Dec 2008, Till Maas wrote:
>> I agree here. I already mentioned some methods in another e-mail. Another
>> possibility I just thought of would be to create reverse delta rpms, i.e.
>> before an rpm is installed, a delta to the current state is created and stored
>> somewhere. This can then used to restore the previous state. Of course someone
>> needs to write this. :-)
>
> Shrug. Who will be the lucky guy doing this? IMHO delta rpms are making the
> handling of packages just more complicated, even they e.g. save traffic.
> Oh, did already implement somebody the downgrading once the last update
> using a delta rpm was broken? That's a thing, e.g. openSUSE is AFAIK now
> lacking for years and nobody took care there, even they're using delta rpms
> also for years now there. In fact, I wasn't seeing a working downgrade at a
> bigger Linux distribution until now once delta rpms have been in use there.
>

the downgrade problems are as follows:

1. scriptlets are not reversible
2. downgrading works provided the user data/user config is not modified by 
an update in a one-way process. (ex: mysql upgrade from  4->5 will convert 
a db, but going back the other way won't fly)
3. There are certain processes which no one is ever going to do the work 
to make them reversible: lvm1->lvm2, db transitions, udev migration, 
ext3->ext4.


The problem is not putting the pkg bits back on the disk. The problem is 
all the stuff that goes along with making the bits WORK.

-sv



From henriquecsj at gmail.com  Sun Dec 14 22:00:12 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Sun, 14 Dec 2008 20:00:12 -0200
Subject: XOOPS in Fedora?
Message-ID: <4f629b520812141400p3e9a2338hc5210cfb204f22de@mail.gmail.com>

Hello, folks,
Is anybody, actually, packaging the XOOPS CMS? [1]
The license described in the "terms of use" is acceptable by Fedora? [2]
If, finally, no one is packaging the CMS and it is within the required
criteria, I would like to try.

[1] - http://www.xoops.org
[2] - http://www.xoops.org/modules/wfchannel/index.php?pagenum=3

Regards

-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081214/90d4a2df/attachment.htm>

From itamar at ispbrasil.com.br  Sun Dec 14 22:07:20 2008
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Sun, 14 Dec 2008 20:07:20 -0200
Subject: XOOPS in Fedora?
In-Reply-To: <4f629b520812141400p3e9a2338hc5210cfb204f22de@mail.gmail.com>
References: <4f629b520812141400p3e9a2338hc5210cfb204f22de@mail.gmail.com>
Message-ID: <d3ceea380812141407w2593205cj1941b9d31c143499@mail.gmail.com>

este ? seu primeiro pacote ?

https://fedoraproject.org/wiki/PackageMaintainers/Join

assim que tiver com o bugilla aberto envia o endereco para que
possamos fazer o review


2008/12/14 Henrique Junior <henriquecsj at gmail.com>:
> Hello, folks,
> Is anybody, actually, packaging the XOOPS CMS? [1]
> The license described in the "terms of use" is acceptable by Fedora? [2]
> If, finally, no one is packaging the CMS and it is within the required
> criteria, I would like to try.
>
> [1] - http://www.xoops.org
> [2] - http://www.xoops.org/modules/wfchannel/index.php?pagenum=3
>
> Regards
>
> --
> Henrique "LonelySpooky" Junior
> http://www.lonelyspooky.com
> -------------------------------------------------------------
> "In a world without walls and fences, who needs windows and gates?!"
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From henriquecsj at gmail.com  Sun Dec 14 22:14:01 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Sun, 14 Dec 2008 20:14:01 -0200
Subject: XOOPS in Fedora?
In-Reply-To: <d3ceea380812141407w2593205cj1941b9d31c143499@mail.gmail.com>
References: <4f629b520812141400p3e9a2338hc5210cfb204f22de@mail.gmail.com>
	<d3ceea380812141407w2593205cj1941b9d31c143499@mail.gmail.com>
Message-ID: <4f629b520812141414w76108679t1e61a498e0f7d11@mail.gmail.com>

No, this is not my first package. Before we begin I would like to know if
the license is acceptable and if there is someone already involved.

2008/12/14 Itamar Reis Peixoto <itamar at ispbrasil.com.br>

> este ? seu primeiro pacote ?
>
> https://fedoraproject.org/wiki/PackageMaintainers/Join
>
> assim que tiver com o bugilla aberto envia o endereco para que
> possamos fazer o review
>
>
> 2008/12/14 Henrique Junior <henriquecsj at gmail.com>:
> > Hello, folks,
> > Is anybody, actually, packaging the XOOPS CMS? [1]
> > The license described in the "terms of use" is acceptable by Fedora? [2]
> > If, finally, no one is packaging the CMS and it is within the required
> > criteria, I would like to try.
> >
> > [1] - http://www.xoops.org
> > [2] - http://www.xoops.org/modules/wfchannel/index.php?pagenum=3
> >
> > Regards
> >
> > --
> > Henrique "LonelySpooky" Junior
> > http://www.lonelyspooky.com
> > -------------------------------------------------------------
> > "In a world without walls and fences, who needs windows and gates?!"
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>
>
>
> --
> ------------
>
> Itamar Reis Peixoto
>
> e-mail/msn: itamar at ispbrasil.com.br
> sip: itamar at ispbrasil.com.br
> skype: itamarjp
> icq: 81053601
> +55 11 4063 5033
> +55 34 3221 8599
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081214/04c8a354/attachment.htm>

From itamar at ispbrasil.com.br  Sun Dec 14 22:31:44 2008
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Sun, 14 Dec 2008 20:31:44 -0200
Subject: XOOPS in Fedora?
In-Reply-To: <4f629b520812141414w76108679t1e61a498e0f7d11@mail.gmail.com>
References: <4f629b520812141400p3e9a2338hc5210cfb204f22de@mail.gmail.com>
	<d3ceea380812141407w2593205cj1941b9d31c143499@mail.gmail.com>
	<4f629b520812141414w76108679t1e61a498e0f7d11@mail.gmail.com>
Message-ID: <d3ceea380812141431w1ac1615v401bdb9bd2c12393@mail.gmail.com>

about license look at

https://fedoraproject.org/wiki/Licensing


2008/12/14 Henrique Junior <henriquecsj at gmail.com>:
> No, this is not my first package. Before we begin I would like to know if
> the license is acceptable and if there is someone already involved.
>
> 2008/12/14 Itamar Reis Peixoto <itamar at ispbrasil.com.br>
>>
>> este ? seu primeiro pacote ?
>>
>> https://fedoraproject.org/wiki/PackageMaintainers/Join
>>
>> assim que tiver com o bugilla aberto envia o endereco para que
>> possamos fazer o review
>>
>>
>> 2008/12/14 Henrique Junior <henriquecsj at gmail.com>:
>> > Hello, folks,
>> > Is anybody, actually, packaging the XOOPS CMS? [1]
>> > The license described in the "terms of use" is acceptable by Fedora? [2]
>> > If, finally, no one is packaging the CMS and it is within the required
>> > criteria, I would like to try.
>> >
>> > [1] - http://www.xoops.org
>> > [2] - http://www.xoops.org/modules/wfchannel/index.php?pagenum=3
>> >
>> > Regards
>> >
>> > --
>> > Henrique "LonelySpooky" Junior
>> > http://www.lonelyspooky.com
>> > -------------------------------------------------------------
>> > "In a world without walls and fences, who needs windows and gates?!"
>> >
>> > --
>> > fedora-devel-list mailing list
>> > fedora-devel-list at redhat.com
>> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>> >
>>
>>
>>
>> --
>> ------------
>>
>> Itamar Reis Peixoto
>>
>> e-mail/msn: itamar at ispbrasil.com.br
>> sip: itamar at ispbrasil.com.br
>> skype: itamarjp
>> icq: 81053601
>> +55 11 4063 5033
>> +55 34 3221 8599
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>
> --
> Henrique "LonelySpooky" Junior
> http://www.lonelyspooky.com
> -------------------------------------------------------------
> "In a world without walls and fences, who needs windows and gates?!"
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From jos at xos.nl  Sun Dec 14 22:45:18 2008
From: jos at xos.nl (Jos Vos)
Date: Sun, 14 Dec 2008 23:45:18 +0100
Subject: OTRS and Fedora
In-Reply-To: <4899FDB3.8080901@gmx.de>
References: <200808061914.m76JEHt1011463@jasmine.xos.nl>
	<80d7e4090808061218s4e7a2697obee15f53f2192fb7@mail.gmail.com>
	<20080806193418.GA11496@jasmine.xos.nl> <4899FDB3.8080901@gmx.de>
Message-ID: <20081214224518.GA25550@jasmine.xos.nl>

On Wed, Aug 06, 2008 at 09:38:27PM +0200, Robert M. Albrecht wrote:

> I picked it up two weeks ago, but didn`t had any time the last days.
> 
> Any cooperation is welcome :-)

What is the status of this?
Did you start looking at the 2.3.3 release yet?

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From kevin.kofler at chello.at  Sun Dec 14 22:45:13 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 14 Dec 2008 23:45:13 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<200812112200.46965.opensource@till.name>
	<494184CC.1020104@gmail.com>
	<200812112248.55542.opensource@till.name>
	<20081214182204.GA31351@hurricane.linuxnetz.de>
	<alpine.LFD.2.00.0812141609320.30438@localhost.localdomain>
Message-ID: <gi429p$ntm$4@ger.gmane.org>

Seth Vidal wrote:
> the downgrade problems are as follows:
> 
> 1. scriptlets are not reversible
> 2. downgrading works provided the user data/user config is not modified by
> an update in a one-way process. (ex: mysql upgrade from  4->5 will convert
> a db, but going back the other way won't fly)
> 3. There are certain processes which no one is ever going to do the work
> to make them reversible: lvm1->lvm2, db transitions, udev migration,
> ext3->ext4.

4. Some KDE applications use kconf_update to upgrade configuration files to
a new syntax. This works per user, the first time the KDE libraries are
used by that user after the upgrade. Other applications may have similar
per-user config file upgrade mechanisms. This is also not easily
reversible.

        Kevin Kofler



From henriquecsj at gmail.com  Sun Dec 14 22:52:22 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Sun, 14 Dec 2008 20:52:22 -0200
Subject: XOOPS in Fedora?
In-Reply-To: <d3ceea380812141431w1ac1615v401bdb9bd2c12393@mail.gmail.com>
References: <4f629b520812141400p3e9a2338hc5210cfb204f22de@mail.gmail.com>
	<d3ceea380812141407w2593205cj1941b9d31c143499@mail.gmail.com>
	<4f629b520812141414w76108679t1e61a498e0f7d11@mail.gmail.com>
	<d3ceea380812141431w1ac1615v401bdb9bd2c12393@mail.gmail.com>
Message-ID: <4f629b520812141452v395ed9afvfde1d06a18855b1a@mail.gmail.com>

Hi, Itamar, good to see you here.
The case with the license used by XOOPS is that they seem to have a license
tailored to the project.
The upstream website uses a FSF button, but the license does not come with a
specific name. Any tips?

2008/12/14 Itamar Reis Peixoto <itamar at ispbrasil.com.br>

> about license look at
>
> https://fedoraproject.org/wiki/Licensing
>
>
> 2008/12/14 Henrique Junior <henriquecsj at gmail.com>:
> > No, this is not my first package. Before we begin I would like to know if
> > the license is acceptable and if there is someone already involved.
> >
> > 2008/12/14 Itamar Reis Peixoto <itamar at ispbrasil.com.br>
> >>
> >> este ? seu primeiro pacote ?
> >>
> >> https://fedoraproject.org/wiki/PackageMaintainers/Join
> >>
> >> assim que tiver com o bugilla aberto envia o endereco para que
> >> possamos fazer o review
> >>
> >>
> >> 2008/12/14 Henrique Junior <henriquecsj at gmail.com>:
> >> > Hello, folks,
> >> > Is anybody, actually, packaging the XOOPS CMS? [1]
> >> > The license described in the "terms of use" is acceptable by Fedora?
> [2]
> >> > If, finally, no one is packaging the CMS and it is within the required
> >> > criteria, I would like to try.
> >> >
> >> > [1] - http://www.xoops.org
> >> > [2] - http://www.xoops.org/modules/wfchannel/index.php?pagenum=3
> >> >
> >> > Regards
> >> >
> >> > --
> >> > Henrique "LonelySpooky" Junior
> >> > http://www.lonelyspooky.com
> >> > -------------------------------------------------------------
> >> > "In a world without walls and fences, who needs windows and gates?!"
> >> >
> >> > --
> >> > fedora-devel-list mailing list
> >> > fedora-devel-list at redhat.com
> >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >> >
> >>
> >>
> >>
> >> --
> >> ------------
> >>
> >> Itamar Reis Peixoto
> >>
> >> e-mail/msn: itamar at ispbrasil.com.br
> >> sip: itamar at ispbrasil.com.br
> >> skype: itamarjp
> >> icq: 81053601
> >> +55 11 4063 5033
> >> +55 34 3221 8599
> >>
> >> --
> >> fedora-devel-list mailing list
> >> fedora-devel-list at redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> >
> >
> > --
> > Henrique "LonelySpooky" Junior
> > http://www.lonelyspooky.com
> > -------------------------------------------------------------
> > "In a world without walls and fences, who needs windows and gates?!"
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>
>
>
> --
> ------------
>
> Itamar Reis Peixoto
>
> e-mail/msn: itamar at ispbrasil.com.br
> sip: itamar at ispbrasil.com.br
> skype: itamarjp
> icq: 81053601
> +55 11 4063 5033
> +55 34 3221 8599
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081214/ac6c26df/attachment.htm>

From kevin.kofler at chello.at  Sun Dec 14 22:55:16 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 14 Dec 2008 23:55:16 +0100
Subject: XOOPS in Fedora?
References: <4f629b520812141400p3e9a2338hc5210cfb204f22de@mail.gmail.com>
	<d3ceea380812141407w2593205cj1941b9d31c143499@mail.gmail.com>
	<4f629b520812141414w76108679t1e61a498e0f7d11@mail.gmail.com>
	<d3ceea380812141431w1ac1615v401bdb9bd2c12393@mail.gmail.com>
	<4f629b520812141452v395ed9afvfde1d06a18855b1a@mail.gmail.com>
Message-ID: <gi42sk$ntm$6@ger.gmane.org>

Henrique Junior wrote:
> The case with the license used by XOOPS is that they seem to have a
> license tailored to the project.
> The upstream website uses a FSF button, but the license does not come with
> a specific name. Any tips?

If you click on "License" instead of "Terms of use", you get the GPL. As far
as I can tell, the terms of use are just for the XOOPS site itself, not for
the software.

        Kevin Kofler



From henriquecsj at gmail.com  Sun Dec 14 23:13:54 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Sun, 14 Dec 2008 21:13:54 -0200
Subject: XOOPS in Fedora?
In-Reply-To: <gi42sk$ntm$6@ger.gmane.org>
References: <4f629b520812141400p3e9a2338hc5210cfb204f22de@mail.gmail.com>
	<d3ceea380812141407w2593205cj1941b9d31c143499@mail.gmail.com>
	<4f629b520812141414w76108679t1e61a498e0f7d11@mail.gmail.com>
	<d3ceea380812141431w1ac1615v401bdb9bd2c12393@mail.gmail.com>
	<4f629b520812141452v395ed9afvfde1d06a18855b1a@mail.gmail.com>
	<gi42sk$ntm$6@ger.gmane.org>
Message-ID: <4f629b520812141513k51cf9893ld81b5541f8ca8a4f@mail.gmail.com>

Yes, there it is! I didn't see the link. : $
Thanks

2008/12/14 Kevin Kofler <kevin.kofler at chello.at>

> Henrique Junior wrote:
> > The case with the license used by XOOPS is that they seem to have a
> > license tailored to the project.
> > The upstream website uses a FSF button, but the license does not come
> with
> > a specific name. Any tips?
>
> If you click on "License" instead of "Terms of use", you get the GPL. As
> far
> as I can tell, the terms of use are just for the XOOPS site itself, not for
> the software.
>
>        Kevin Kofler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081214/7ab37a14/attachment.htm>

From jamundso at gmail.com  Mon Dec 15 02:01:38 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 14 Dec 2008 21:01:38 -0500
Subject: OTRS and Fedora
In-Reply-To: <20081214224518.GA25550@jasmine.xos.nl>
References: <200808061914.m76JEHt1011463@jasmine.xos.nl>
	<80d7e4090808061218s4e7a2697obee15f53f2192fb7@mail.gmail.com>
	<20080806193418.GA11496@jasmine.xos.nl> <4899FDB3.8080901@gmx.de>
	<20081214224518.GA25550@jasmine.xos.nl>
Message-ID: <6d06ce20812141801l4ef91123pe9bee791d92d3eaf@mail.gmail.com>

On Sun, Dec 14, 2008 at 5:45 PM, Jos Vos <jos at xos.nl> wrote:
> On Wed, Aug 06, 2008 at 09:38:27PM +0200, Robert M. Albrecht wrote:
>
>> I picked it up two weeks ago, but didn`t had any time the last days.
>>
>> Any cooperation is welcome :-)
>
> What is the status of this?
> Did you start looking at the 2.3.3 release yet?

https://bugzilla.redhat.com/show_bug.cgi?id=473833
is also out there.
I've downloaded the new sources, but also have not gotten very far...

jerry

-- 
TBD.



From skvidal at fedoraproject.org  Mon Dec 15 05:03:55 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 15 Dec 2008 00:03:55 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <gi429p$ntm$4@ger.gmane.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<200812112200.46965.opensource@till.name>
	<494184CC.1020104@gmail.com>
	<200812112248.55542.opensource@till.name>
	<20081214182204.GA31351@hurricane.linuxnetz.de>
	<alpine.LFD.2.00.0812141609320.30438@localhost.localdomain>
	<gi429p$ntm$4@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0812150003230.28634@localhost.localdomain>



On Sun, 14 Dec 2008, Kevin Kofler wrote:

> Seth Vidal wrote:
>> the downgrade problems are as follows:
>>
>> 1. scriptlets are not reversible
>> 2. downgrading works provided the user data/user config is not modified by
>> an update in a one-way process. (ex: mysql upgrade from  4->5 will convert
>> a db, but going back the other way won't fly)
>> 3. There are certain processes which no one is ever going to do the work
>> to make them reversible: lvm1->lvm2, db transitions, udev migration,
>> ext3->ext4.
>
> 4. Some KDE applications use kconf_update to upgrade configuration files to
> a new syntax. This works per user, the first time the KDE libraries are
> used by that user after the upgrade. Other applications may have similar
> per-user config file upgrade mechanisms. This is also not easily
> reversible.


I've documented the problems with downgrading packages here:

http://yum.baseurl.org/wiki/DownGradeProblems

so we can refer to that in the future.

-sv



From nicu_fedora at nicubunu.ro  Mon Dec 15 06:57:55 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Mon, 15 Dec 2008 08:57:55 +0200
Subject: Installing from Live CD is the new black?
In-Reply-To: <4944A7AF.5060904@fedoraproject.org>
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>	<49421D9C.8080307@nicubunu.ro>
	<4944A7AF.5060904@fedoraproject.org>
Message-ID: <4945FFF3.8050009@nicubunu.ro>

Rahul Sundaram wrote:
> Nicu Buculei wrote:
>> Chris Lumens wrote:
>>> I do kind of wish everyone used live CDs, but that's probably never
>>> going to be the way it works.
>>
>> That's just not gonna happen. Live CD are so small, they can't hold 
>> even OpenOffice.org (or hold it but sacrifice a lot of other much 
>> needed applications).
> 
> OpenOffice.org in a live cd is certainly possible. We do more locales 
> instead but if you want a custom live cd to include all the packages YOU 
> need, it takes about 20 minutes with a local mirror. Really easy.

But to make room for it you have to leave out something else, perhaps 
something just as important. This is why the DVD is a better option for 
install.

-- 
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 jamundso at gmail.com  Mon Dec 15 07:19:54 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Mon, 15 Dec 2008 01:19:54 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <4945FFF3.8050009@nicubunu.ro>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<4945FFF3.8050009@nicubunu.ro>
Message-ID: <6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>

On Mon, Dec 15, 2008 at 12:57 AM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> Rahul Sundaram wrote:
>>
>> Nicu Buculei wrote:
>>>
>>> Chris Lumens wrote:
>>>>
>>>> I do kind of wish everyone used live CDs, but that's probably never
>>>> going to be the way it works.
>>>
>>> That's just not gonna happen. Live CD are so small, they can't hold even
>>> OpenOffice.org (or hold it but sacrifice a lot of other much needed
>>> applications).
>>
>> OpenOffice.org in a live cd is certainly possible. We do more locales
>> instead but if you want a custom live cd to include all the packages YOU
>> need, it takes about 20 minutes with a local mirror. Really easy.
>
> But to make room for it you have to leave out something else, perhaps
> something just as important. This is why the DVD is a better option for
> install.

But the DVD writer is not an easy commodity, globally speaking.
Other install options are best.

jerry

-- 
TBD.



From bashton at brennanashton.com  Mon Dec 15 07:43:46 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sun, 14 Dec 2008 23:43:46 -0800
Subject: Package Review Stats for the week ending December 7, 2008
In-Reply-To: <b401d2530812112353h3906b40ap56d591ef0a28e547@mail.gmail.com>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<200812111844.22764.opensource@till.name>
	<b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>
	<200812120814.13832.opensource@till.name>
	<b401d2530812112353h3906b40ap56d591ef0a28e547@mail.gmail.com>
Message-ID: <981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>

On Thu, Dec 11, 2008 at 11:53 PM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
> 2008/12/12 Till Maas <opensource at till.name>:
> [..]
>>> Right now the report generated is for component: "Package Review" and
>>> merge reviews also come under that component.
>>
>> It seems it was not clear, what I meant. I would like to now, how many of the
>> reviews that are done affect Merge Reviews, e.g. add the end of the report
>> instead of only  this line:
>>
>> | Total reviews: 40
>>
>> It would be nice to have this:
>>
>> Total Package Reviews: 39
>> Total Merge Reviews: 1
>>
>> I would also appreciate a pointer to the script that generates these reports.
>>
>
> I will try to adjust the script to categorize the merge reviews part
> of "Package Review" component as separate, probably based on summary
> or other attribute of bug. The script is here:
> http://cvs.fedora.redhat.com/viewvc//status-report-scripts/?root=fedora
>
> The one named bugzillaReport.py
>
> Feel free to patch it up;)
>
> --
> rakesh

I just did a massive rewrite of a large part of the script, I was not
sure what new-com and new-incom really did so I omitted them from this
version, but I did add in two new reports cvs-com cvs-incom. You will
also now get the totals for Merge Review and Review Request.  The
script also now runs much much faster as it only has to parse around
100 bugs rather then the 8000+ it was doing before.  I am linking the
script rather then posting a patch as it is so different.
If you are interested I would like to add this to our triage scripts
fedorahosted project, so we can keep track of features requests
easier.  If not that is fine too.

New script:
http://bashton.fedorapeople.org/bugzillaReport2.py

--Brennan Ashton



From nicu_fedora at nicubunu.ro  Mon Dec 15 07:54:29 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Mon, 15 Dec 2008 09:54:29 +0200
Subject: Installing from Live CD is the new black?
In-Reply-To: <6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>	<49421D9C.8080307@nicubunu.ro>
	<4944A7AF.5060904@fedoraproject.org>	<4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
Message-ID: <49460D35.9000604@nicubunu.ro>

Jerry Amundson wrote:
> On Mon, Dec 15, 2008 at 12:57 AM, Nicu Buculei wrote:
>> But to make room for it you have to leave out something else, perhaps
>> something just as important. This is why the DVD is a better option for
>> install.
> 
> But the DVD writer is not an easy commodity, globally speaking.
> Other install options are best.

If you don't have access to a DVD writer, I assume you don't have an 
internet connection good enough to transform a Live CD install into 
something usable, so what is your best choice? the 6 install CDs?

-- 
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 rakesh.pandit at gmail.com  Mon Dec 15 08:00:42 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Mon, 15 Dec 2008 13:30:42 +0530
Subject: Package Review Stats for the week ending December 7, 2008
In-Reply-To: <981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<200812111844.22764.opensource@till.name>
	<b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>
	<200812120814.13832.opensource@till.name>
	<b401d2530812112353h3906b40ap56d591ef0a28e547@mail.gmail.com>
	<981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>
Message-ID: <b401d2530812150000p3e0d4f13k616e14d3d036cbfb@mail.gmail.com>

2008/12/15 Brennan Ashton <bashton at brennanashton.com>:
[..]
>
> I just did a massive rewrite of a large part of the script, I was not
> sure what new-com and new-incom really did so I omitted them from this
> version, but I did add in two new reports cvs-com cvs-incom. You will
> also now get the totals for Merge Review and Review Request.  The
> script also now runs much much faster as it only has to parse around
> 100 bugs rather then the 8000+ it was doing before.  I am linking the
> script rather then posting a patch as it is so different.
> If you are interested I would like to add this to our triage scripts
> fedorahosted project, so we can keep track of features requests
> easier.  If not that is fine too.
>

Nice, add it ;-) I would also like to have a look shortly.
-- 
rakesh



From jamundso at gmail.com  Mon Dec 15 08:04:02 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Mon, 15 Dec 2008 02:04:02 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <49460D35.9000604@nicubunu.ro>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<49460D35.9000604@nicubunu.ro>
Message-ID: <6d06ce20812150004k5d3fe69m30f0ae53b88f0cdb@mail.gmail.com>

On Mon, Dec 15, 2008 at 1:54 AM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> Jerry Amundson wrote:
>>
>> On Mon, Dec 15, 2008 at 12:57 AM, Nicu Buculei wrote:
>>>
>>> But to make room for it you have to leave out something else, perhaps
>>> something just as important. This is why the DVD is a better option for
>>> install.
>>
>> But the DVD writer is not an easy commodity, globally speaking.
>> Other install options are best.
>
> If you don't have access to a DVD writer, I assume you don't have an
> internet connection good enough to transform a Live CD install into
> something usable, so what is your best choice? the 6 install CDs?

Your assumption is Non sequitur, your facts are uncoordinated. My
office, where my only DVD writer happens to be, has a 10gb Internet
connection.

jerry

-- 
TBD.



From sundaram at fedoraproject.org  Mon Dec 15 08:16:19 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 15 Dec 2008 13:46:19 +0530
Subject: Installing from Live CD is the new black?
In-Reply-To: <49460D35.9000604@nicubunu.ro>
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>	<49421D9C.8080307@nicubunu.ro>	<4944A7AF.5060904@fedoraproject.org>	<4945FFF3.8050009@nicubunu.ro>	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<49460D35.9000604@nicubunu.ro>
Message-ID: <49461253.40405@fedoraproject.org>

Nicu Buculei wrote:
> Jerry Amundson wrote:
>> On Mon, Dec 15, 2008 at 12:57 AM, Nicu Buculei wrote:
>>> But to make room for it you have to leave out something else, perhaps
>>> something just as important. This is why the DVD is a better option for
>>> install.
>>
>> But the DVD writer is not an easy commodity, globally speaking.
>> Other install options are best.
> 
> If you don't have access to a DVD writer, I assume you don't have an 
> internet connection good enough to transform a Live CD install into 
> something usable, so what is your best choice? the 6 install CDs?

Live USB keys are what I prefer. Cross platform tools available. Does 
not waste media. Installation is very fast - usually around 3 minutes. 
Performance is good. Support for persistence where I can install more 
packages as I prefer and carry them around easily and so on.

Rahul



From adamwill at shaw.ca  Mon Dec 15 08:43:25 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Mon, 15 Dec 2008 00:43:25 -0800
Subject: Installing from Live CD is the new black?
In-Reply-To: <6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
Message-ID: <1229330605.24419.265.camel@lenovo.local.net>

On Mon, 2008-12-15 at 01:19 -0600, Jerry Amundson wrote:

> > But to make room for it you have to leave out something else, perhaps
> > something just as important. This is why the DVD is a better option for
> > install.
> 
> But the DVD writer is not an easy commodity, globally speaking.
> Other install options are best.

There are many places where high-speed internet connections are not
widely available. However, there are groups in these countries at large
companies and universities who will download distributions and
re-distribute them to others via user groups and so on. These groups
prefer very 'full' images, like DVD ISOs, because they can contain most
of the packages a user will need. By the nature of their small capacity,
live CDs cannot, and tend to assume the user has a high-speed internet
connection to download additional packages. Where such a connection is
not available, a live CD is not very much use.

This is an important use case for DVD images.

There may be places where DVD writers are not easily available, but high
speed internet connections are - I've never heard of one, though. Either
way, it doesn't invalidate the above case.
-- 
adamw



From pemboa at gmail.com  Mon Dec 15 08:46:50 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 15 Dec 2008 02:46:50 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <1229330605.24419.265.camel@lenovo.local.net>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<1229330605.24419.265.camel@lenovo.local.net>
Message-ID: <16de708d0812150046j4073b8b3i8cd602ec111bea3f@mail.gmail.com>

On Mon, Dec 15, 2008 at 2:43 AM, Adam Williamson <adamwill at shaw.ca> wrote:
> On Mon, 2008-12-15 at 01:19 -0600, Jerry Amundson wrote:
>
>> > But to make room for it you have to leave out something else, perhaps
>> > something just as important. This is why the DVD is a better option for
>> > install.
>>
>> But the DVD writer is not an easy commodity, globally speaking.
>> Other install options are best.
>
> There are many places where high-speed internet connections are not
> widely available. However, there are groups in these countries at large
> companies and universities who will download distributions and
> re-distribute them to others via user groups and so on. These groups
> prefer very 'full' images, like DVD ISOs, because they can contain most
> of the packages a user will need. By the nature of their small capacity,
> live CDs cannot, and tend to assume the user has a high-speed internet
> connection to download additional packages. Where such a connection is
> not available, a live CD is not very much use.
>
> This is an important use case for DVD images.
>
> There may be places where DVD writers are not easily available, but high
> speed internet connections are - I've never heard of one, though. Either
> way, it doesn't invalidate the above case.
> --
> adamw


Of course it is an important use case. No one is saying DVD installs
are useless. However if you have the bandwith to dload the DVD image
yourself, it is a lot more efficient to dload a live CD and install
from that.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mcepl at redhat.com  Mon Dec 15 08:55:09 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 15 Dec 2008 09:55:09 +0100
Subject: purple-facebookchat EVR in F8 and F9 > F10, devel
References: <29fee02b0812130648j73632836oda113b1aa7f5cd7b@mail.gmail.com>
Message-ID: <dkih16xqh6.ln2@ppp1053.in.ipex.cz>

On 2008-12-13, 14:48 GMT, Andrea Musuruane wrote:
> It seems to me that purple-facebookchat EVR is bigger in F8 and 
> F9 (1.38-1) than in F10 and devel (1.37-1).
>
> It also seems it hasn't been updated recently. Latest upstream 
> version is 1.44.

All packages in Fedora >= 9 upgraded to 1.44.

> BTW, what happened to the EVR report that was usually posted 
> here?

Yeah, that is an interesting question.

Mat?j



From nicu_fedora at nicubunu.ro  Mon Dec 15 09:35:02 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Mon, 15 Dec 2008 11:35:02 +0200
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812150046j4073b8b3i8cd602ec111bea3f@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>	<49421D9C.8080307@nicubunu.ro>
	<4944A7AF.5060904@fedoraproject.org>	<4945FFF3.8050009@nicubunu.ro>	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>	<1229330605.24419.265.camel@lenovo.local.net>
	<16de708d0812150046j4073b8b3i8cd602ec111bea3f@mail.gmail.com>
Message-ID: <494624C6.9070409@nicubunu.ro>

Arthur Pemberton wrote:
> 
> Of course it is an important use case. No one is saying DVD installs
> are useless. However if you have the bandwith to dload the DVD image
> yourself, it is a lot more efficient to dload a live CD and install
> from that.

No if:
- you perform the install on more than one machine;
- you download in one location and install on another;
- you want control over the way the download is performed (bittorrent, 
download rate control with gwget etc.)
- you want a downtime as small as possible.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com



From kevin.kofler at chello.at  Mon Dec 15 09:42:16 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 15 Dec 2008 10:42:16 +0100
Subject: Installing from Live CD is the new black?
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>	<49421D9C.8080307@nicubunu.ro>
	<4944A7AF.5060904@fedoraproject.org>	<4945FFF3.8050009@nicubunu.ro>	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>	<1229330605.24419.265.camel@lenovo.local.net>
	<16de708d0812150046j4073b8b3i8cd602ec111bea3f@mail.gmail.com>
	<494624C6.9070409@nicubunu.ro>
Message-ID: <gi58pp$f6l$1@ger.gmane.org>

Nicu Buculei wrote:

> Arthur Pemberton wrote:
>> 
>> Of course it is an important use case. No one is saying DVD installs
>> are useless. However if you have the bandwith to dload the DVD image
>> yourself, it is a lot more efficient to dload a live CD and install
>> from that.
> 
> No if:
[snip]
> - you want a downtime as small as possible.

Uh no, if you want a downtime as small as possible, you run "yum upgrade" on
the running system with X11 and all and hope for the best. :-) If
everything works, the downtime will be only a reboot.

But at least KDE won't like it very much if you upgrade it while it is
running, especially not if that's an F8 to F9/F10 (KDE 3 to 4) upgrade. ;-)
So the system might not be fully usable until the upgrade is complete. A
safer way is to yum --download-only upgrade in runlevel 5, then swich to
runlevel 3 and yum -C upgrade from there, but that does imply some downtime
as far as graphical applications are concerned (of course if all you ever
do is browse the web using Lynx you won't notice ;-) ).

        Kevin Kofler



From alan at redhat.com  Mon Dec 15 10:28:08 2008
From: alan at redhat.com (Alan Cox)
Date: Mon, 15 Dec 2008 05:28:08 -0500
Subject: add new webcam to gspca-pac207 driver
In-Reply-To: <48811.192.168.1.131.1229191699.squirrel@padawan.comarb>
References: <48811.192.168.1.131.1229191699.squirrel@padawan.comarb>
Message-ID: <20081215102808.GB10230@shell.devel.redhat.com>

> 12:58:33.000000000 -0200
> @@ -528,6 +528,7 @@
>  static const __devinitdata struct usb_device_id device_table[] = {
>  	{USB_DEVICE(0x041e, 0x4028)},
>  	{USB_DEVICE(0x093a, 0x2460)},
> +	{USB_DEVICE(0x093a, 0x2461)},
>  	{USB_DEVICE(0x093a, 0x2463)},
>  	{USB_DEVICE(0x093a, 0x2464)},
>  	{USB_DEVICE(0x093a, 0x2468)},
> 
> As you can see, it is no too complex ;-)
> 
> I wanted to know which is the correct road so to get it incorporated in
> Fedora:  Creating a RFE? it will be ignored if is not applied upstream?

If you created the patch then send it upstream and it'll end up back in
Fedora.



From dan at danny.cz  Mon Dec 15 10:54:24 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Mon, 15 Dec 2008 11:54:24 +0100
Subject: Server SIG - work areas
In-Reply-To: <4944F811.1040206@kanarip.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<4944F811.1040206@kanarip.com>
Message-ID: <1229338464.4693.6.camel@eagle.danny.cz>

Jeroen van Meeuwen p??e v Ne 14. 12. 2008 v 13:12 +0100:
> Dan Hor?k wrote:
> > Hello,
> > 
> 
> With regards to the areas of interest for this SIG, may I recommend the 
> following (broad) topic:
> 
> Integration of Provisioning utilities such as Cobbler, Genome, 
> Kickstart, Configuration Management utilities such as CFEngine, Puppet, 
> Augeas, iClasssify, and Monitoring utilities such as Nagios, Zabbix, 
> Zenos, Monit

As I see you have already updated the Admins Corner section in the Wiki,
perfect.


		Dan




From belegdol at gmail.com  Mon Dec 15 11:39:53 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 15 Dec 2008 12:39:53 +0100
Subject: [Fwd: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11
	on	fedora-development-rpmfusion_nonfree]
Message-ID: <49464209.7010005@gmail.com>

This is some fallout from the new RPM pkgconfig automatic deps, right?

Regards,
Julian

-------- Wiadomo?? oryginalna --------
Temat: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11 on
fedora-development-rpmfusion_nonfree
Data: Mon, 15 Dec 2008 11:23:10 +0100 (CET)
Nadawca: rpmfusion-buildsys at lists.rpmfusion.org
Adresat: belegdol at gmail.com

Job failed on arch ppc64


         Build logs may be found at
http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_nonfree/2059-sdlmame-0129-0.6.0128u6.fc11/


-------------------------------------------------

Package 'dbus-1', required by 'gconf', not found
Compiling src/osd/sdl/debug-intf.c...
Package dbus-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `dbus-1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'dbus-1', required by 'gconf', not found
src/osd/sdl/dview.c:3:32: error: gconf/gconf-client.h: No such file or
directory
src/osd/sdl/dview.c: In function 'dview_class_init':
src/osd/sdl/dview.c:357: error: 'GConfClient' undeclared (first use in
this function)
src/osd/sdl/dview.c:357: error: (Each undeclared identifier is reported
only once
src/osd/sdl/dview.c:357: error: for each function it appears in.)
src/osd/sdl/dview.c:357: error: 'conf' undeclared (first use in this
function)
src/osd/sdl/dview.c:357: warning: implicit declaration of function
'gconf_client_get_default'
src/osd/sdl/dview.c:358: warning: ISO C90 forbids mixed declarations and
code
src/osd/sdl/dview.c:362: warning: implicit declaration of function
'gconf_client_get_string'
src/osd/sdl/dview.c:362: warning: assignment makes pointer from integer
without a cast
Compiling src/build/file2str.c...
make: *** [obj/sdl/mamed/osd/sdl/dview.o] Error 1
make: *** Waiting for unfinished jobs....
Package dbus-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `dbus-1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'dbus-1', required by 'gconf', not found
src/build/file2str.c: In function 'main':
src/build/file2str.c:70: warning: ignoring return value of 'fread',
declared with attribute warn_unused_result
error: Bad exit status from /var/tmp/rpm-tmp.nnfOtp (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.nnfOtp (%build)



From opensource at till.name  Mon Dec 15 11:54:29 2008
From: opensource at till.name (Till Maas)
Date: Mon, 15 Dec 2008 12:54:29 +0100
Subject: Package Review Stats for the week ending December 7, 2008
In-Reply-To: <981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<b401d2530812112353h3906b40ap56d591ef0a28e547@mail.gmail.com>
	<981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>
Message-ID: <200812151254.41961.opensource@till.name>

On Monday 15 December 2008 08:43:46 Brennan Ashton wrote:

> If you are interested I would like to add this to our triage scripts
> fedorahosted project, so we can keep track of features requests
> easier.  If not that is fine too.

Can you please also make the script add a note at the end of the record that 
explains where this script can be found and where bugs or patches can be 
sent? Maybe you can use the attached patch. :-)

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugzillaReport2.py-upstream.patch
Type: text/x-diff
Size: 885 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/2bd9f66a/attachment.bin>
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/2bd9f66a/attachment.sig>

From mschwendt at gmail.com  Mon Dec 15 12:24:21 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 15 Dec 2008 13:24:21 +0100
Subject: [Fwd: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11 on
 fedora-development-rpmfusion_nonfree]
In-Reply-To: <49464209.7010005@gmail.com>
References: <49464209.7010005@gmail.com>
Message-ID: <20081215132421.0f2de2c6.mschwendt@gmail.com>

On Mon, 15 Dec 2008 12:39:53 +0100, Julian wrote:

> This is some fallout from the new RPM pkgconfig automatic deps, right?

No.

There is some misunderstanding with regard to those automatic deps.

1.) Automatic Provides  pkgconfig(foo)  are in the packages for a longer
time already. Just examine old builds to see. If any Provides is missing
nevertheless, a rebuild may fix it, though.

2.) Only builds with a sufficiently recent RPM add the automatic
RPM _Requires_ (!) for any pkgconfig Requires found in a .pc file in
a package. For most packages, the maintainers has added Requires for
all needed -devel packages before, however.

3.) Rebuilding existing packages in Rawhide only breaks something,
if a Requires pkgconfig(foo) is added automatically without any
package being the provider.

Case 3) does not apply to your package. Its dependencies resolve fine
in mock/yum. The build fails at compile-time, because dbus-devel
is missing. gconf2-devel should have added "Requires: dbus-devel"
much earlier or now be rebuilt to add the automatic Requires for
an automatic pkgconfig(dbus-1) dependency.

> Package 'dbus-1', required by 'gconf', not found

> Package dbus-1 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `dbus-1.pc'
> to the PKG_CONFIG_PATH environment variable



From mschwendt at gmail.com  Mon Dec 15 12:28:26 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 15 Dec 2008 13:28:26 +0100
Subject: [Fwd: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11 on
 fedora-development-rpmfusion_nonfree]
In-Reply-To: <20081215132421.0f2de2c6.mschwendt@gmail.com>
References: <49464209.7010005@gmail.com>
	<20081215132421.0f2de2c6.mschwendt@gmail.com>
Message-ID: <20081215132826.3e8e91b2.mschwendt@gmail.com>

On Mon, 15 Dec 2008 13:24:21 +0100, me wrote:

> > Package 'dbus-1', required by 'gconf', not found
> 
> > Package dbus-1 was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `dbus-1.pc'
> > to the PKG_CONFIG_PATH environment variable

Additionally, there's related activity in pkg-config with regard
to Requires.private:

  http://koji.fedoraproject.org/koji/buildinfo?buildID=73901

gconf-2.0.pc has dbus-1 as a Requires.private



From sundaram at fedoraproject.org  Mon Dec 15 12:29:42 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 15 Dec 2008 17:59:42 +0530
Subject: Broken dependencies in Fedora 10 - 2008-12-14
In-Reply-To: <20081214172129.17830.82330@faldor.intranet>
References: <20081214172129.17830.82330@faldor.intranet>
Message-ID: <49464DB6.4040602@fedoraproject.org>

Michael Schwendt wrote:
> 
>     sundaram 
>         gyachi
>         olpc-utils

Can you modify the script to drop mails to the co-maintainers as well? I 
am not active on the packages and more importantly, the changes that 
broke deps have been made by others.

Rahul



From belegdol at gmail.com  Mon Dec 15 12:33:46 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 15 Dec 2008 13:33:46 +0100
Subject: [Fwd: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11 on
 fedora-development-rpmfusion_nonfree]
In-Reply-To: <20081215132421.0f2de2c6.mschwendt@gmail.com>
References: <49464209.7010005@gmail.com>
	<20081215132421.0f2de2c6.mschwendt@gmail.com>
Message-ID: <49464EAA.7090604@gmail.com>

Michael Schwendt pisze:
> On Mon, 15 Dec 2008 12:39:53 +0100, Julian wrote:
> 
>> This is some fallout from the new RPM pkgconfig automatic deps, right?
> 
> No.
> 
> There is some misunderstanding with regard to those automatic deps.
> 
> 1.) Automatic Provides  pkgconfig(foo)  are in the packages for a longer
> time already. Just examine old builds to see. If any Provides is missing
> nevertheless, a rebuild may fix it, though.
> 
> 2.) Only builds with a sufficiently recent RPM add the automatic
> RPM _Requires_ (!) for any pkgconfig Requires found in a .pc file in
> a package. For most packages, the maintainers has added Requires for
> all needed -devel packages before, however.
> 
> 3.) Rebuilding existing packages in Rawhide only breaks something,
> if a Requires pkgconfig(foo) is added automatically without any
> package being the provider.
> 
> Case 3) does not apply to your package. Its dependencies resolve fine
> in mock/yum. The build fails at compile-time, because dbus-devel
> is missing. gconf2-devel should have added "Requires: dbus-devel"
> much earlier or now be rebuilt to add the automatic Requires for
> an automatic pkgconfig(dbus-1) dependency.
> 
>> Package 'dbus-1', required by 'gconf', not found
> 
>> Package dbus-1 was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `dbus-1.pc'
>> to the PKG_CONFIG_PATH environment variable
> 

OK, GConf2-devel indeed does not have dbus-devel Requires defined, but
then how come the build did work on F-10? Also, previous version built
fine on F-11.

Regards,
Julian



From mschwendt at gmail.com  Mon Dec 15 12:39:00 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 15 Dec 2008 13:39:00 +0100
Subject: [Fwd: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11 on
 fedora-development-rpmfusion_nonfree]
In-Reply-To: <49464EAA.7090604@gmail.com>
References: <49464209.7010005@gmail.com>
	<20081215132421.0f2de2c6.mschwendt@gmail.com>
	<49464EAA.7090604@gmail.com>
Message-ID: <20081215133900.2c529310.mschwendt@gmail.com>

On Mon, 15 Dec 2008 13:33:46 +0100, Julian wrote:

> >> Package 'dbus-1', required by 'gconf', not found
> > 
> >> Package dbus-1 was not found in the pkg-config search path.
> >> Perhaps you should add the directory containing `dbus-1.pc'
> >> to the PKG_CONFIG_PATH environment variable
> > 
> 
> OK, GConf2-devel indeed does not have dbus-devel Requires defined, but
> then how come the build did work on F-10? Also, previous version built
> fine on F-11.

See my other reply. pkg-config behaviour has been modified, too

What exactly has been changed with regard to processing the
Requires.private dependencies in .pc files is not clear to me, and
I don't have the time to examine it further. It can be debugged with
several checks like running pkg-config with common use-cases like
--exists/--cflags/--libs and see whether/how it processes the private
deps. It could be that it pulls in Requires.private when it shouldn't.



From belegdol at gmail.com  Mon Dec 15 12:45:58 2008
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 15 Dec 2008 13:45:58 +0100
Subject: [Fwd: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11  
 on fedora-development-rpmfusion_nonfree]
In-Reply-To: <49464209.7010005@gmail.com>
References: <49464209.7010005@gmail.com>
Message-ID: <49465186.502@gmail.com>

Julian Sikorski pisze:
> This is some fallout from the new RPM pkgconfig automatic deps, right?
> 
> Regards,
> Julian
> 
> -------- Wiadomo?? oryginalna --------
> Temat: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11 on
> fedora-development-rpmfusion_nonfree
> Data: Mon, 15 Dec 2008 11:23:10 +0100 (CET)
> Nadawca: rpmfusion-buildsys at lists.rpmfusion.org
> Adresat: belegdol at gmail.com
> 
> Job failed on arch ppc64
> 
> 
>          Build logs may be found at
> http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_nonfree/2059-sdlmame-0129-0.6.0128u6.fc11/
> 
> 
> -------------------------------------------------
> 
> Package 'dbus-1', required by 'gconf', not found
> Compiling src/osd/sdl/debug-intf.c...
> Package dbus-1 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `dbus-1.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'dbus-1', required by 'gconf', not found
> src/osd/sdl/dview.c:3:32: error: gconf/gconf-client.h: No such file or
> directory
Actually I think this is the culprit, the weird thing is that
GConf2-devel was installed according to build.log and this file is
present in that package. Missing dbus-devel never seemed to cause
problems, In current rawhide it just got announced more loudly.

Julian



From mtasaka at ioa.s.u-tokyo.ac.jp  Mon Dec 15 12:46:06 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Mon, 15 Dec 2008 21:46:06 +0900
Subject: [Fwd: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11 on
 fedora-development-rpmfusion_nonfree]
In-Reply-To: <20081215132826.3e8e91b2.mschwendt@gmail.com>
References: <49464209.7010005@gmail.com>	<20081215132421.0f2de2c6.mschwendt@gmail.com>
	<20081215132826.3e8e91b2.mschwendt@gmail.com>
Message-ID: <4946518E.2040305@ioa.s.u-tokyo.ac.jp>

Michael Schwendt wrote, at 12/15/2008 09:28 PM +9:00:
> On Mon, 15 Dec 2008 13:24:21 +0100, me wrote:
> 
>>> Package 'dbus-1', required by 'gconf', not found
>>> Package dbus-1 was not found in the pkg-config search path.
>>> Perhaps you should add the directory containing `dbus-1.pc'
>>> to the PKG_CONFIG_PATH environment variable
> 
> Additionally, there's related activity in pkg-config with regard
> to Requires.private:
> 
>   http://koji.fedoraproject.org/koji/buildinfo?buildID=73901
> 
> gconf-2.0.pc has dbus-1 as a Requires.private

Umm.. It seems with recent rawhide pkgconfig
$ pkg-config --print-requires gconf-2.0 

will always pull in Requires.private dependency. And so with 
recent rpm behavior if GConf2 is rebuilt Requires.private
dependency will always pulled in. Is this expected behavior?
I guess this is superfluous and this behavior should be
reverted.

Mamoru




From mschwendt at gmail.com  Mon Dec 15 12:49:48 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 15 Dec 2008 13:49:48 +0100
Subject: Broken dependencies in Fedora 10 - 2008-12-14
In-Reply-To: <49464DB6.4040602@fedoraproject.org>
References: <20081214172129.17830.82330@faldor.intranet>
	<49464DB6.4040602@fedoraproject.org>
Message-ID: <20081215134948.44dc2305.mschwendt@gmail.com>

On Mon, 15 Dec 2008 17:59:42 +0530, Rahul wrote:

> > 
> >     sundaram 
> >         gyachi
> >         olpc-utils
> 
> Can you modify the script to drop mails to the co-maintainers as well? I 
> am not active on the packages and more importantly, the changes that 
> broke deps have been made by others.

It mails all co-maintainers for a very long time already.

In the summary, only the primary owner (the first one in the old
owner.list files) is listed. Recently I wanted to modify it to make that
more clear (and e.g. print the number of co-maintainers that have been
mailed -- I've been distracted with other things). Or the summary could be
changed to list only the src.rpm package names.


Btw, the wrong Obsoletes in gyachi have been discussed in private mail.
I'm unsure whether the packager has understood the problem and the fix.

olpc-utils is one of the packages that have gone directly to stable:
https://admin.fedoraproject.org/updates/F10/FEDORA-2008-10123
It's broken in rawhide, too.



From mschwendt at gmail.com  Mon Dec 15 12:55:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 15 Dec 2008 13:55:33 +0100
Subject: [Fwd: Build Error (Job 2059): sdlmame-0129-0_6_0128u6_fc11 on
 fedora-development-rpmfusion_nonfree]
In-Reply-To: <4946518E.2040305@ioa.s.u-tokyo.ac.jp>
References: <49464209.7010005@gmail.com>
	<20081215132421.0f2de2c6.mschwendt@gmail.com>
	<20081215132826.3e8e91b2.mschwendt@gmail.com>
	<4946518E.2040305@ioa.s.u-tokyo.ac.jp>
Message-ID: <20081215135533.3a7e57bb.mschwendt@gmail.com>

On Mon, 15 Dec 2008 21:46:06 +0900, Mamoru wrote:

> Michael Schwendt wrote, at 12/15/2008 09:28 PM +9:00:
> > On Mon, 15 Dec 2008 13:24:21 +0100, me wrote:
> > 
> >>> Package 'dbus-1', required by 'gconf', not found
> >>> Package dbus-1 was not found in the pkg-config search path.
> >>> Perhaps you should add the directory containing `dbus-1.pc'
> >>> to the PKG_CONFIG_PATH environment variable
> > 
> > Additionally, there's related activity in pkg-config with regard
> > to Requires.private:
> > 
> >   http://koji.fedoraproject.org/koji/buildinfo?buildID=73901
> > 
> > gconf-2.0.pc has dbus-1 as a Requires.private
> 
> Umm.. It seems with recent rawhide pkgconfig
> $ pkg-config --print-requires gconf-2.0 
> 
> will always pull in Requires.private dependency. And so with 
> recent rpm behavior if GConf2 is rebuilt Requires.private
> dependency will always pulled in. Is this expected behavior?
> I guess this is superfluous and this behavior should be
> reverted.

I don't see that. Check out pkgconfig %changelog in koji linked
above. There's the bz ticket where this is being discussed.

dbus-1 is not pulled in yet (or else it would be in the package RPM
Requires already), but the ticket looks as if they want that to be the new
behaviour for a future rpmbuild. The sdlmame configure script apparently
pulls in the Requires.private dbus-1 in its --exists or compilation check
of GConf2 and fails to retrieve proper search paths for the headers, too.



From sundaram at fedoraproject.org  Mon Dec 15 13:03:06 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 15 Dec 2008 18:33:06 +0530
Subject: Broken dependencies in Fedora 10 - 2008-12-14
In-Reply-To: <20081215134948.44dc2305.mschwendt@gmail.com>
References: <20081214172129.17830.82330@faldor.intranet>	<49464DB6.4040602@fedoraproject.org>
	<20081215134948.44dc2305.mschwendt@gmail.com>
Message-ID: <4946558A.3060105@fedoraproject.org>

Michael Schwendt wrote:

> It mails all co-maintainers for a very long time already.
> 
> In the summary, only the primary owner (the first one in the old
> owner.list files) is listed. Recently I wanted to modify it to make that
> more clear (and e.g. print the number of co-maintainers that have been
> mailed -- I've been distracted with other things). 

That would be very useful.

Or the summary could be
> changed to list only the src.rpm package names.

Well, that would be very problematic for people who have say more than a 
  few dozen packages. I don't even recall offhand all the packages I own 
and I don't own that many.
> 
> Btw, the wrong Obsoletes in gyachi have been discussed in private mail.
> I'm unsure whether the packager has understood the problem and the fix.

It appears he does but he seems offline for a couple of weeks. He also 
told me, you had informed him that the issue isn't a urgent priority. Is 
that because the updates are in testing repository?

> olpc-utils is one of the packages that have gone directly to stable:
> https://admin.fedoraproject.org/updates/F10/FEDORA-2008-10123
> It's broken in rawhide, too.

I haven't done anything with it in a long time. I am going to orphan it 
and let the current co-maintainer take ownership if he is going to fix it.

Rahul



From paul at all-the-johnsons.co.uk  Sat Dec 13 22:48:16 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sat, 13 Dec 2008 22:48:16 +0000
Subject: X taking upto 99% processor time
Message-ID: <1229208496.5890.2.camel@PB3.Linux>

Hi,

Anyone any ideas why X should be taking 99% of my available processor
time? I'm using a dual core Intel x86 box with an nVidia graphics card
(I'm using the default X driver for it, not the nasty proprietory one
with it's nasty 3d acceleration and stuff ;-p)

I'm using rawhide, last updated at 9am UK time.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081213/5be67305/attachment.sig>

From vonbrand at inf.utfsm.cl  Mon Dec 15 13:25:40 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 15 Dec 2008 10:25:40 -0300
Subject: X taking upto 99% processor time
In-Reply-To: <1229208496.5890.2.camel@PB3.Linux>
References: <1229208496.5890.2.camel@PB3.Linux>
Message-ID: <200812151325.mBFDPe8p008178@laptop14.inf.utfsm.cl>

Paul <paul at all-the-johnsons.co.uk> wrote:
> Anyone any ideas why X should be taking 99% of my available processor
> time? I'm using a dual core Intel x86 box with an nVidia graphics card
> (I'm using the default X driver for it, not the nasty proprietory one
> with it's nasty 3d acceleration and stuff ;-p)

Bad interaction between gnome-screensaver and Xorg. Go back to
gnome-screensaver-2.24.1-2.fc11. 
-- 
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 mschwendt at gmail.com  Mon Dec 15 13:41:04 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 15 Dec 2008 14:41:04 +0100
Subject: Broken dependencies in Fedora 10 - 2008-12-14
In-Reply-To: <4946558A.3060105@fedoraproject.org>
References: <20081214172129.17830.82330@faldor.intranet>
	<49464DB6.4040602@fedoraproject.org>
	<20081215134948.44dc2305.mschwendt@gmail.com>
	<4946558A.3060105@fedoraproject.org>
Message-ID: <20081215144104.b4aec581.mschwendt@gmail.com>

On Mon, 15 Dec 2008 18:33:06 +0530, Rahul wrote:

> > Btw, the wrong Obsoletes in gyachi have been discussed in private mail.
> > I'm unsure whether the packager has understood the problem and the fix.
> 
> It appears he does but he seems offline for a couple of weeks. He also 
> told me, you had informed him that the issue isn't a urgent priority. Is 
> that because the updates are in testing repository?

No, they have been marked stable after just three hours in testing.

The first attempt at fixing it was half-hearted.
That's when I said:

| Take your time. Don't rush. The current commit in cvs is insufficient.

Without taking the time to fully understand RPM Obsoletes,
Obsoletes+Provides pairs and how they are entered into a spec file, the
problem will return sooner or late. Either that or -- almost guaranteed --
the %dist pitfall will be hit.



From kmaraas at broadpark.no  Mon Dec 15 13:25:08 2008
From: kmaraas at broadpark.no (Kjartan Maraas)
Date: Mon, 15 Dec 2008 14:25:08 +0100
Subject: X taking upto 99% processor time
In-Reply-To: <1229208496.5890.2.camel@PB3.Linux>
References: <1229208496.5890.2.camel@PB3.Linux>
Message-ID: <1229347508.11859.0.camel@localhost.localdomain>

l?., 13.12.2008 kl. 22.48 +0000, skrev Paul:
> Hi,
> 
> Anyone any ideas why X should be taking 99% of my available processor
> time? I'm using a dual core Intel x86 box with an nVidia graphics card
> (I'm using the default X driver for it, not the nasty proprietory one
> with it's nasty 3d acceleration and stuff ;-p)
> 

I asked the same thing on irc this weekend and was told it was
gnome-screensaver tickling some bug somewhere. Terminating
gnome-screensaver fixed it for me at least.

Cheers
Kjartan




From thomas.moschny at gmail.com  Mon Dec 15 14:01:36 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Mon, 15 Dec 2008 15:01:36 +0100
Subject: Broken dependencies in Fedora 10 - 2008-12-14
In-Reply-To: <20081214172129.17830.82330@faldor.intranet>
References: <20081214172129.17830.82330@faldor.intranet>
Message-ID: <a9d183c80812150601i6188849fpe070524d914ce7b@mail.gmail.com>

2008/12/14 Michael Schwendt <mschwendt at gmail.com>:
>    mr.ecik AT gmail.com
>        kadu

Would be nice if these could be fixed. Problems with this package also
seem to be due to wrong or missing Obsoletes.

- Thomas



From jonathan.robie at redhat.com  Mon Dec 15 14:01:58 2008
From: jonathan.robie at redhat.com (Jonathan Robie)
Date: Mon, 15 Dec 2008 09:01:58 -0500
Subject: Perseus Digital Library?
In-Reply-To: <4944C238.9080103@iinet.net.au>
References: <4942CF37.9050804@redhat.com>	<20081212225705.GA3023@amd.home.annexia.org>	<4942EFE0.1010105@redhat.com>	<20081212231831.GA3105@amd.home.annexia.org>	<ghuvcn$fsd$1@ger.gmane.org>	<4943EF2D.4080102@redhat.com>
	<4944C238.9080103@iinet.net.au>
Message-ID: <49466356.70100@redhat.com>

David Timms wrote:
> Michael DeHaan wrote:
>> Kevin Kofler wrote:
>>> Richard W.M. Jones wrote:
>>>  
>>>> http://www.perseus.tufts.edu/hopper/opensource
> How would this fit into "code not content" ?
> Would we be able to have a player, but no content ?

Yes, we'd have to tell people where to get the texts. And I think it is 
the texts that are licensed for non-commercial use.

If the system were compatibly licensed, would this be analogous to what 
we're doing with audio? A lot of movies or music are commercial, but the 
players are still kosher?

Jonathan



From jonathan.robie at redhat.com  Mon Dec 15 14:05:00 2008
From: jonathan.robie at redhat.com (Jonathan Robie)
Date: Mon, 15 Dec 2008 09:05:00 -0500
Subject: Perseus Digital Library?
In-Reply-To: <4943EF2D.4080102@redhat.com>
References: <4942CF37.9050804@redhat.com>	<20081212225705.GA3023@amd.home.annexia.org>	<4942EFE0.1010105@redhat.com>	<20081212231831.GA3105@amd.home.annexia.org>	<ghuvcn$fsd$1@ger.gmane.org>
	<4943EF2D.4080102@redhat.com>
Message-ID: <4946640C.6040308@redhat.com>

Michael DeHaan wrote:
> Kevin Kofler wrote:
>> Richard W.M. Jones wrote:
>>> http://www.perseus.tufts.edu/hopper/opensource
>>>
>>> <quote>
>>> Texts are licensed under the Creative Commons NonCommercial
>>> ShareAlike 3.0 license
>>> </quote>
>>
>> That is clearly not OK for Fedora (it's non-Free), nor is it Open 
>> Source (in
>> the sense defined by the OSI).
>>
>> Complain to them about diluting the term "Open Source".
>>
>> Kevin Kofler
>>
>
> Indeed it's not. The ability for Linux to be used commercially is one 
> of it's primer drivers of awesomeness. I would suspect they /could/ be 
> educated about changing this if shown the benefits. (Future custom 
> live spin for academic use easily distributable to libraries? I don't 
> know as I'm not familiar with the app).
>
> Incidentally, the Creative Commons has a survey up here, incidentally, 
> that folks ought to way in on if you do license CC works. It's a bit 
> long:
>
> http://creativecommons.org/weblog/entry/11045
>
> The issues for writers and photographers and such can be slightly 
> different from those of software developers, so I'd encourage those 
> with an interest in the CC to way in.

Suppose this were available as a Fedora RPM. Would we want to include 
the texts or not, if we could get truly open licensing agreements?

I'm not sure what issues they face with the texts themselves, but these 
are the same critical texts found in books that you can buy in the book 
store.

Jonathan



From jonathan.robie at redhat.com  Mon Dec 15 14:06:28 2008
From: jonathan.robie at redhat.com (Jonathan Robie)
Date: Mon, 15 Dec 2008 09:06:28 -0500
Subject: Perseus Digital Library?
In-Reply-To: <20081212231831.GA3105@amd.home.annexia.org>
References: <4942CF37.9050804@redhat.com>	<20081212225705.GA3023@amd.home.annexia.org>	<4942EFE0.1010105@redhat.com>
	<20081212231831.GA3105@amd.home.annexia.org>
Message-ID: <49466464.8090406@redhat.com>

Richard W.M. Jones wrote:
> BTW, I can probably help here, coz I read classical Greek & Latin
> moderately well, and it'd be great to have truly free texts in Fedora.
>   

That would be great - if the licensing is compatible. Thanks for the offer!

Jonathan

P.S., I don't know Latin at all ....



From kwizart at gmail.com  Mon Dec 15 14:28:00 2008
From: kwizart at gmail.com (Nicolas Chauvet)
Date: Mon, 15 Dec 2008 15:28:00 +0100
Subject: f11 boost-1.37.0 upgrade: notice of intent, and best way to
In-Reply-To: <20081124120549.5107aced@balbo.artheist.org>
References: <20081124120549.5107aced@balbo.artheist.org>
Message-ID: <e1760170812150628k5d37ec2apd57150960e1a87f@mail.gmail.com>

2008/11/24 Benjamin Kosnik <bkoz at redhat.com>:
>
> The boost maintainers are planning to update the boost versions
> to the current release (1.37.0) in rawhide for F11. There was an
> attempt to upgrade boost for F10, but the timing was off.
>
> Details on that attempt:
>
> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00464.html
>
> We have a tenative (local) srpm, and intend with this announcement to
> put the boost upgrade in the queue for F11. Consider yourself notified,
> devel-list reader.
>
> There is some general discussion of how changes with a lot of deps
> should be brought into rawhide:
>
> 1) making a koji tag, check in new boost, rebuild deps
> 2) mock chroot with the new boost, rebuild deps
>
> Suggestions? Actual instructions, written down somewhere? The other
> option is to:
>
> 3) check in the base boost package to devel, and immediately work on
> rebuilding the deps
>
> I don't want to jump the gun here, as I know F11 planning is ongoing,
> and that holiday scheduling is a concern. Thoughts, and suggestion on
> how to proceed are welcome.
Any ETA on this attempt ?
I think using a special tag would be the right thing, (like what was
done for python2.6)

But a wiki pages that would explain the common fix would also help.

Nicolas (kwizart)

ps: I have a LuxRender package under review that is known to fails on
the current boost.
aqsis on the other hand should work fine with newer boost.



From pbrobinson at gmail.com  Mon Dec 15 14:12:53 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Mon, 15 Dec 2008 15:12:53 +0100
Subject: Broken dependencies in Fedora 10 - 2008-12-14
In-Reply-To: <20081215134948.44dc2305.mschwendt@gmail.com>
References: <20081214172129.17830.82330@faldor.intranet>
	<49464DB6.4040602@fedoraproject.org>
	<20081215134948.44dc2305.mschwendt@gmail.com>
Message-ID: <5256d0b0812150612j4f7e6dfdy2fc1d08eaabd383b@mail.gmail.com>

>> Can you modify the script to drop mails to the co-maintainers as well? I
>> am not active on the packages and more importantly, the changes that
>> broke deps have been made by others.
>
> It mails all co-maintainers for a very long time already.
>
> In the summary, only the primary owner (the first one in the old
> owner.list files) is listed. Recently I wanted to modify it to make that
> more clear (and e.g. print the number of co-maintainers that have been
> mailed -- I've been distracted with other things). Or the summary could be
> changed to list only the src.rpm package names.
>
>
> Btw, the wrong Obsoletes in gyachi have been discussed in private mail.
> I'm unsure whether the packager has understood the problem and the fix.
>
> olpc-utils is one of the packages that have gone directly to stable:
> https://admin.fedoraproject.org/updates/F10/FEDORA-2008-10123
> It's broken in rawhide, too.

Its on my list to fix this week, or at least investigate. I haven't
had time up until now.

Peter



From harald at redhat.com  Mon Dec 15 14:47:32 2008
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 15 Dec 2008 15:47:32 +0100
Subject: Fedora 10 - Boot Analysis
Message-ID: <gi5qm4$bbq$1@ger.gmane.org>

http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis

A brief Fedora 10 boot analysis.

Hardware: Asus EeePC 901 with a flash disk.

Time taken from entering the encrypted root disk password until the password can 
be entered (after pressing return in gdm). The 10 second wait in nash is ignored 
here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).

Default Live CD Installation:  39s (bootchart 
http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)

After installing readahead and running one collection boot process: 36s 
(bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)

At this point, I recognized that all processes (NetworkManager and newaliases), 
which call a fsync(), let the boot process wait until all data is written to 
disk. This is the same effect as the firefox sqlite fsync bug 
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/.

Mounting the root filessystem with relatime and turning off ordered data writing 
for the journal with

# tune2fs -o journal_data_writeback /dev/root

improved the situation (even though data might be old on the disk after a crash, 
but ext3 does not force the disk to empty the write cache anyway).

Turning off setroubleshoot and fixing 
https://bugzilla.redhat.com/show_bug.cgi?id=476023 and 
https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart 
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble.png)

Turning off bootchart: 30s

So all in all we have nearly accomplished the 30 Second Startup Feature 
http://fedoraproject.org/wiki/Features/30SecondStartup.

To reach the 20 Second Startup Feature 
http://fedoraproject.org/wiki/Features/20SecondStartup, we really have to tackle 
setroubleshootd. Also we might start to move basic services to upstart and start 
them in parallel (bootchart with some services moved 
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble-upstart.png). 
Parallel booting will show now benefits with readahead and a small amount of 
active services, but the more services are turned on, the more you benefit with 
a parallel boot setup. Moving more basic modules to be compiled in the kernel 
also would gain some seconds. Speaking about modules, I ported Jakubs modprobe 
patch to the recent 3.6pre1 module-init-tools version. Though it nearly halves 
I/O, it would only safe us a fraction of a second here (not recognizable).

In the end, we also have to extend our view to things that happen after the user 
logs in (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-full.png) 
and do an extended analysis. Work is also in progress by Gnome developer Behdad 
Esfahbod http://mces.blogspot.com/2008/12/improving-login-time-part-3.html.



From triad at df.lth.se  Mon Dec 15 14:50:18 2008
From: triad at df.lth.se (Linus Walleij)
Date: Mon, 15 Dec 2008 15:50:18 +0100 (CET)
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812120028q36e55dfev90ff0bae09e091ec@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>
	<16de708d0812120028q36e55dfev90ff0bae09e091ec@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0812151549030.2104@mer.df.lth.se>

On Fri, 12 Dec 2008, Arthur Pemberton wrote:

> I also look forward to LiveDVD spins,

This just fell in from LWN:
http://www.montanalinux.org/fedora-remix-howto-screencast.html

LiveDVD, with install to HD option. Oh the joy!

Linus



From bruno at wolff.to  Mon Dec 15 14:50:47 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 15 Dec 2008 08:50:47 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <49461253.40405@fedoraproject.org>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<49460D35.9000604@nicubunu.ro> <49461253.40405@fedoraproject.org>
Message-ID: <20081215145047.GB27788@wolff.to>

On Mon, Dec 15, 2008 at 13:46:19 +0530,
  Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>
> Live USB keys are what I prefer. Cross platform tools available. Does  
> not waste media. Installation is very fast - usually around 3 minutes.  
> Performance is good. Support for persistence where I can install more  
> packages as I prefer and carry them around easily and so on.

They are also getting cheap enough, where I might be giving out a few
with the games spin on them as presents next (2009) Christmas.



From bruno at wolff.to  Mon Dec 15 14:54:23 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 15 Dec 2008 08:54:23 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <gi5qm4$bbq$1@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
Message-ID: <20081215145423.GC27788@wolff.to>

On Mon, Dec 15, 2008 at 15:47:32 +0100,
  Harald Hoyer <harald at redhat.com> wrote:
>
> Time taken from entering the encrypted root disk password until the 
> password can be entered (after pressing return in gdm). The 10 second 
> wait in nash is ignored here (which really annoys me and should be 
> configurable in /etc/sysconfig/mkinitrd).

If you are referring to bug 470628, that is fixed now with mkinitrd-6.0.71-3.



From bpepple at fedoraproject.org  Mon Dec 15 14:59:19 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 15 Dec 2008 09:59:19 -0500
Subject: Updated Package Review script
In-Reply-To: <981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<200812111844.22764.opensource@till.name>
	<b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>
	<200812120814.13832.opensource@till.name>
	<b401d2530812112353h3906b40ap56d591ef0a28e547@mail.gmail.com>
	<981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>
Message-ID: <1229353160.3146.1.camel@localhost.localdomain>

On Sun, 2008-12-14 at 23:43 -0800, Brennan Ashton wrote:
> 
> I just did a massive rewrite of a large part of the script, I was not
> sure what new-com and new-incom really did so I omitted them from this
> version, but I did add in two new reports cvs-com cvs-incom. You will
> also now get the totals for Merge Review and Review Request.  The
> script also now runs much much faster as it only has to parse around
> 100 bugs rather then the 8000+ it was doing before.  I am linking the
> script rather then posting a patch as it is so different.
> If you are interested I would like to add this to our triage scripts
> fedorahosted project, so we can keep track of features requests
> easier.  If not that is fine too.

Thanks! I'll start using you improved script for the weekly reports.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/4eea1d3a/attachment.sig>

From harald at redhat.com  Mon Dec 15 15:03:57 2008
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 15 Dec 2008 16:03:57 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081215145423.GC27788@wolff.to>
References: <gi5qm4$bbq$1@ger.gmane.org> <20081215145423.GC27788@wolff.to>
Message-ID: <gi5rkt$f9t$1@ger.gmane.org>

Bruno Wolff III wrote:
> On Mon, Dec 15, 2008 at 15:47:32 +0100,
>   Harald Hoyer <harald at redhat.com> wrote:
>> Time taken from entering the encrypted root disk password until the 
>> password can be entered (after pressing return in gdm). The 10 second 
>> wait in nash is ignored here (which really annoys me and should be 
>> configurable in /etc/sysconfig/mkinitrd).
> 
> If you are referring to bug 470628, that is fixed now with mkinitrd-6.0.71-3.
> 

ah :) very nice :)



From bashton at brennanashton.com  Mon Dec 15 15:07:14 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Mon, 15 Dec 2008 07:07:14 -0800
Subject: Package Review Stats for the week ending December 7, 2008
In-Reply-To: <200812151254.41961.opensource@till.name>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<b401d2530812112353h3906b40ap56d591ef0a28e547@mail.gmail.com>
	<981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>
	<200812151254.41961.opensource@till.name>
Message-ID: <981da310812150707p4b577a3bqe4b2c3d72f052eb2@mail.gmail.com>

2008/12/15 Till Maas <opensource at till.name>:
> On Monday 15 December 2008 08:43:46 Brennan Ashton wrote:
>
>> If you are interested I would like to add this to our triage scripts
>> fedorahosted project, so we can keep track of features requests
>> easier.  If not that is fine too.
>
> Can you please also make the script add a note at the end of the record that
> explains where this script can be found and where bugs or patches can be
> sent? Maybe you can use the attached patch. :-)
>
> Regards,
> Till

I will take a look at it, it will soon be located in the fedorahosted
project for triage, so tickets can be opened there.
https://fedorahosted.org/triage/ Feel free to put feature requests
there as well.

--Brennan Ashton



From dcbw at redhat.com  Mon Dec 15 15:06:48 2008
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 15 Dec 2008 10:06:48 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <gi5qm4$bbq$1@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
Message-ID: <1229353608.12163.13.camel@localhost.localdomain>

On Mon, 2008-12-15 at 15:47 +0100, Harald Hoyer wrote:
> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
> 
> A brief Fedora 10 boot analysis.
> 
> Hardware: Asus EeePC 901 with a flash disk.
> 
> Time taken from entering the encrypted root disk password until the password can 
> be entered (after pressing return in gdm). The 10 second wait in nash is ignored 
> here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).
> 
> Default Live CD Installation:  39s (bootchart 
> http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)
> 
> After installing readahead and running one collection boot process: 36s 
> (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)
> 
> At this point, I recognized that all processes (NetworkManager and newaliases), 

Odd, NM isn't intentionally calling fsync() (it's not anywhere in the
code), nor does glib do that anywhere that I can find.  I can't think of
anything that would require an fsync for NM, so I'm interested in
finding this and killing it.

dan

> which call a fsync(), let the boot process wait until all data is written to 
> disk. This is the same effect as the firefox sqlite fsync bug 
> http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/.
> 
> Mounting the root filessystem with relatime and turning off ordered data writing 
> for the journal with
> 
> # tune2fs -o journal_data_writeback /dev/root
> 
> improved the situation (even though data might be old on the disk after a crash, 
> but ext3 does not force the disk to empty the write cache anyway).
> 
> Turning off setroubleshoot and fixing 
> https://bugzilla.redhat.com/show_bug.cgi?id=476023 and 
> https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart 
> http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble.png)
> 
> Turning off bootchart: 30s
> 
> So all in all we have nearly accomplished the 30 Second Startup Feature 
> http://fedoraproject.org/wiki/Features/30SecondStartup.
> 
> To reach the 20 Second Startup Feature 
> http://fedoraproject.org/wiki/Features/20SecondStartup, we really have to tackle 
> setroubleshootd. Also we might start to move basic services to upstart and start 
> them in parallel (bootchart with some services moved 
> http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble-upstart.png). 
> Parallel booting will show now benefits with readahead and a small amount of 
> active services, but the more services are turned on, the more you benefit with 
> a parallel boot setup. Moving more basic modules to be compiled in the kernel 
> also would gain some seconds. Speaking about modules, I ported Jakubs modprobe 
> patch to the recent 3.6pre1 module-init-tools version. Though it nearly halves 
> I/O, it would only safe us a fraction of a second here (not recognizable).
> 
> In the end, we also have to extend our view to things that happen after the user 
> logs in (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-full.png) 
> and do an extended analysis. Work is also in progress by Gnome developer Behdad 
> Esfahbod http://mces.blogspot.com/2008/12/improving-login-time-part-3.html.
> 



From harald at redhat.com  Mon Dec 15 15:18:28 2008
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 15 Dec 2008 16:18:28 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229353608.12163.13.camel@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
Message-ID: <gi5sg4$ikd$1@ger.gmane.org>

Dan Williams wrote:
> On Mon, 2008-12-15 at 15:47 +0100, Harald Hoyer wrote:
>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>
>> A brief Fedora 10 boot analysis.
>>
>> Hardware: Asus EeePC 901 with a flash disk.
>>
>> Time taken from entering the encrypted root disk password until the password can 
>> be entered (after pressing return in gdm). The 10 second wait in nash is ignored 
>> here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).
>>
>> Default Live CD Installation:  39s (bootchart 
>> http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)
>>
>> After installing readahead and running one collection boot process: 36s 
>> (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)
>>
>> At this point, I recognized that all processes (NetworkManager and newaliases), 
> 
> Odd, NM isn't intentionally calling fsync() (it's not anywhere in the
> code), nor does glib do that anywhere that I can find.  I can't think of
> anything that would require an fsync for NM, so I'm interested in
> finding this and killing it.

http://www.harald-hoyer.de/files/bootchart-16.png

looks very much like it... but I could be wrong, though.

> 
> dan
> 



From mclasen at redhat.com  Mon Dec 15 15:21:37 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 15 Dec 2008 10:21:37 -0500
Subject: X taking upto 99% processor time
In-Reply-To: <1229347508.11859.0.camel@localhost.localdomain>
References: <1229208496.5890.2.camel@PB3.Linux>
	<1229347508.11859.0.camel@localhost.localdomain>
Message-ID: <1229354497.3343.7.camel@matthiasc>

On Mon, 2008-12-15 at 14:25 +0100, Kjartan Maraas wrote:
> l?., 13.12.2008 kl. 22.48 +0000, skrev Paul:
> > Hi,
> > 
> > Anyone any ideas why X should be taking 99% of my available processor
> > time? I'm using a dual core Intel x86 box with an nVidia graphics card
> > (I'm using the default X driver for it, not the nasty proprietory one
> > with it's nasty 3d acceleration and stuff ;-p)
> > 
> 
> I asked the same thing on irc this weekend and was told it was
> gnome-screensaver tickling some bug somewhere. Terminating
> gnome-screensaver fixed it for me at least.
> 

It was a bug in the SYNC extension. Ajax fixed it last week.



From harald at redhat.com  Mon Dec 15 15:26:55 2008
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 15 Dec 2008 16:26:55 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <gi5sg4$ikd$1@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org>
Message-ID: <gi5svv$jvc$1@ger.gmane.org>

Harald Hoyer wrote:
> http://www.harald-hoyer.de/files/bootchart-16.png
> 
> looks very much like it... but I could be wrong, though.

with newaliases this was 100% reproducable.

> 
>>
>> dan
>>
> 



From hughsient at gmail.com  Mon Dec 15 15:37:56 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 15 Dec 2008 15:37:56 +0000
Subject: RFC: Description text in packages
Message-ID: <1229355476.3432.89.camel@hughsie-work.lan>

It seems many packagers have committed new summary text for their
packages, and I thank you all for that.

Next on my list are insane descriptions. For instance, just take a look
at the description for enlightenment (many pages in length) and various
packages using ``quoting'' or ''quoting''. Many packages also try to do
a bullet list using '*' or '-', usually with a random amount of spacing.

Question 1: Should we use '', "", or the UTF-8 quote characters? If we
use LaTeX style ``double'' and `single' formatters then it's trivial for
the session programs to either use ?? or ?? depending on the locale.

Question 2: What's the maximum permitted length of a description? For
some stuff like enlightenment there's a short essay in the description.

Question 3: How should a description be bulletted? Using '*' or the
UTF-8 '?' marker?

One such example:

--------------------------------------------------------------
Mousepad is a text editor for Xfce based on Leafpad. The initial reason for
Mousepad was to provide printing support, which would have been difficult
for Leafpad for various reasons.

Although some features are under development, currently Mousepad has following
features:

    * Complete support for UTF-8 text
    * Cut/Copy/Paste and Select All text
    * Search and Replace
    * Font selecton
    * Word Wrap
    * Character coding selection
    * Auto character coding detection (UTF-8 and some codesets)
    * Manual codeset setting
    * Infinite Undo/Redo by word
    * Auto Indent
    * Multi-line Indent
    * Display line numbers
    * Drag and Drop
    * Printing
--------------------------------------------------------------

Now, this format makes it very difficult for PackageKit to display the
description test in a sane way. PackageKit already joins lines together
to fit properly on the word-wrapped length, but preserving paragraph
markers.

If the bullet format was:
--------------------------------------------------------------
Although some features are under development, currently Mousepad has following
features:

* Complete support for UTF-8 text
* Is has multiple features of note
 * Like this one
  * But this is not important
* And this one
--------------------------------------------------------------

The session tools could do multilevel indenting with the correct locale
UTF-8 character (?, ?, etc).

Comments please.

Richard.



From lmacken at redhat.com  Mon Dec 15 15:42:45 2008
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 15 Dec 2008 10:42:45 -0500
Subject: from fedora.client import Wiki
Message-ID: <20081215154245.GD3336@x300>

http://lewk.org/blog/wiki



From james at fedoraproject.org  Mon Dec 15 15:50:44 2008
From: james at fedoraproject.org (James Antill)
Date: Mon, 15 Dec 2008 10:50:44 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081214183354.GB31351@hurricane.linuxnetz.de>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
Message-ID: <1229356244.6392.13.camel@code.and.org>

On Sun, 2008-12-14 at 19:33 +0100, Robert Scheck wrote:
> Hello Kevin,
> 
> On Fri, 12 Dec 2008, Kevin Kofler wrote:
> > Robert Scheck wrote:
> > > Of course I understand, that dbus is nice and so on, but I'm not seeing
> > > how it is really useful. Again, the push happens about every 24 hours and
> > > the cache of the downloaded files by yum expires after maybe one hour, if
> > > I am not wrong here. Why do we generate such unnecessary load and traffic?
> > 
> > Because you do not know *when* the update push happens. And there are
> > third-party repos which sometimes push several updates a day.
> 
> maybe true, but do users really need to be so up-to-date? Mirrors also need
> time to synchronize, as we learned in this thread, right? I'm still lacking
> a good reason why we're checking each yum interaction for updated metadata
> as far as I can see.

 This is probably a mildly confusing math thing, much like the 6 month
update of Fedora results in an average wait of 3 months.

 By default yum sets the metadata cache timeout to 90 minutes, now if
you want to optimize for Fedora you might be tempted to change this to
"1d" so yum will only re-check it's metadata once a day. However if you
turn on your laptop at 22:00 Sunday, then you'll miss any updates from
Monday until 22:00 Monday night.
 Or more technically, from any given Fedora update you'll have to wait
_upto_ 1 day later to see them.
 This then only gets worse with mirrors.

 I've said for a long time, if you want a "zero network" yum the best
thing you can do is run yum-updatesd it metadata only mode.
 PK kind of takes over some of jobs yum-updatesd did, is not really
integrated to do this function atm.

-- 
James Antill <james at fedoraproject.org>
Fedora



From harald at redhat.com  Mon Dec 15 15:51:54 2008
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 15 Dec 2008 16:51:54 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <gi5sg4$ikd$1@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org>
Message-ID: <49467D1A.5060008@redhat.com>

Harald Hoyer wrote:
> Dan Williams wrote:
>> On Mon, 2008-12-15 at 15:47 +0100, Harald Hoyer wrote:
>>> At this point, I recognized that all processes (NetworkManager and 
>>> newaliases), 
>>
>> Odd, NM isn't intentionally calling fsync() (it's not anywhere in the
>> code), nor does glib do that anywhere that I can find.  I can't think of
>> anything that would require an fsync for NM, so I'm interested in
>> finding this and killing it.
> 
> http://www.harald-hoyer.de/files/bootchart-16.png
> 
> looks very much like it... but I could be wrong, though.

ok, could only very the newaliases fdatasync(). NetworkManager and hald do not 
seem to trigger this nor can I find any sync. Might be a normal journal commit 
going on there coincidentally.

sorry for the false alarm.

> 
>>
>> dan
>>
> 



From sandeen at redhat.com  Mon Dec 15 15:55:52 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Mon, 15 Dec 2008 09:55:52 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <gi5qm4$bbq$1@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
Message-ID: <49467E08.2080806@redhat.com>

Harald Hoyer wrote:
> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
> 
> A brief Fedora 10 boot analysis.
> 
> Hardware: Asus EeePC 901 with a flash disk.
> 
> Time taken from entering the encrypted root disk password until the password can 
> be entered (after pressing return in gdm). The 10 second wait in nash is ignored 
> here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).
> 
> Default Live CD Installation:  39s (bootchart 
> http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)
> 
> After installing readahead and running one collection boot process: 36s 
> (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)
> 
> At this point, I recognized that all processes (NetworkManager and newaliases), 
> which call a fsync(), let the boot process wait until all data is written to 
> disk. This is the same effect as the firefox sqlite fsync bug 
> http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/.
> 
> Mounting the root filessystem with relatime and turning off ordered data writing 
> for the journal with
> 
> # tune2fs -o journal_data_writeback /dev/root
> 
> improved the situation (even though data might be old on the disk after a crash, 
> but ext3 does not force the disk to empty the write cache anyway).
> 
> Turning off setroubleshoot and fixing 
> https://bugzilla.redhat.com/show_bug.cgi?id=476023 and 
> https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart 
> http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble.png)
> 
> Turning off bootchart: 30s
> 
> So all in all we have nearly accomplished the 30 Second Startup Feature 
> http://fedoraproject.org/wiki/Features/30SecondStartup.

Well, no; not if this requires data=writeback.  We can't ship that way,
it's a potential security hole.  You don't want someone's maildir
suddenly containing pieces of /etc/shadow or whatnot.  The old data that
may be exposed by data=writeback may not belong to that user.

-Eric



From nicolas.mailhot at laposte.net  Mon Dec 15 15:57:59 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Dec 2008 16:57:59 +0100 (CET)
Subject: RFC: Description text in packages
In-Reply-To: <1229355476.3432.89.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
Message-ID: <0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>



Le Lun 15 d?cembre 2008 16:37, Richard Hughes a ?crit :

> Next on my list are insane descriptions.

Specs files and most notably human-targeted text inside them are
UTF-8. Please do not invent any broken application-side transcoding
system. Writing correctly encoded text is the packager and translator
responsability.

If the fugly ASCII-zation some packagers use offends you,
1. write a best practices wiki page with recommended UTF-8 sequences
2. get it reviewed/approved by FPC and FESCO
3. open bugs for offending packages
4. get some broken-ASCII checks added to our package linting/review
tools.

This is how our guidelines process works, it's long and bureaucratic
but it ensures everyone has its say and no gratuituous bikesheding is
pushed on packagers.

> Question 2: What's the maximum permitted length of a description?

What matters is not the description length but its quality and
usefulness to users. Some domains use long descriptions, because the
target audience expects them.

Note that that because rpmlint insists on forcing 79 character
line-wraps to help dumb terminal users, it's effectively impossible
right now to get correct paragraph flow and breaks in descriptions
(aye for optimizing the minority case at the expense of everyone
else).

-- 
Nicolas Mailhot



From harald at redhat.com  Mon Dec 15 15:58:28 2008
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 15 Dec 2008 16:58:28 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49467E08.2080806@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <49467E08.2080806@redhat.com>
Message-ID: <49467EA4.2060909@redhat.com>

Eric Sandeen wrote:
>> Turning off bootchart: 30s
>>
>> So all in all we have nearly accomplished the 30 Second Startup Feature 
>> http://fedoraproject.org/wiki/Features/30SecondStartup.
> 
> Well, no; not if this requires data=writeback.  We can't ship that way,
> it's a potential security hole.  You don't want someone's maildir
> suddenly containing pieces of /etc/shadow or whatnot.  The old data that
> may be exposed by data=writeback may not belong to that user.
> 
> -Eric
> 

So, we switch to xfs as the default FS? :-)



From bashton at brennanashton.com  Mon Dec 15 16:22:06 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Mon, 15 Dec 2008 08:22:06 -0800
Subject: Updated Package Review script
In-Reply-To: <1229353160.3146.1.camel@localhost.localdomain>
References: <1228770379.5346.3.camel@localhost.localdomain>
	<200812111844.22764.opensource@till.name>
	<b401d2530812112008r3ebf97f8y2b608c3febfa4bf5@mail.gmail.com>
	<200812120814.13832.opensource@till.name>
	<b401d2530812112353h3906b40ap56d591ef0a28e547@mail.gmail.com>
	<981da310812142343k67658612g473d6ade4f9e7fd3@mail.gmail.com>
	<1229353160.3146.1.camel@localhost.localdomain>
Message-ID: <981da310812150822v4d61895bv454f493ad0f47131@mail.gmail.com>

2008/12/15 Brian Pepple <bpepple at fedoraproject.org>:
> On Sun, 2008-12-14 at 23:43 -0800, Brennan Ashton wrote:
>>
>> I just did a massive rewrite of a large part of the script, I was not
>> sure what new-com and new-incom really did so I omitted them from this
>> version, but I did add in two new reports cvs-com cvs-incom. You will
>> also now get the totals for Merge Review and Review Request.  The
>> script also now runs much much faster as it only has to parse around
>> 100 bugs rather then the 8000+ it was doing before.  I am linking the
>> script rather then posting a patch as it is so different.
>> If you are interested I would like to add this to our triage scripts
>> fedorahosted project, so we can keep track of features requests
>> easier.  If not that is fine too.
>
> Thanks! I'll start using you improved script for the weekly reports.
>
> Later,
> /B
> --
> Brian Pepple <bpepple at fedoraproject.org>

The script is now up
https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py
I have already added in Till's request as well as a few minor display
issues (newline and verbose). None of these actually change the
calculation of results.

Regards,
--Brennan Ashton



From chris.stone at gmail.com  Mon Dec 15 16:34:33 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 15 Dec 2008 08:34:33 -0800
Subject: RFC: Description text in packages
In-Reply-To: <1229355476.3432.89.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
Message-ID: <d9c612bf0812150834q5df8ef93sfd65f91106535f65@mail.gmail.com>

On Mon, Dec 15, 2008 at 7:37 AM, Richard Hughes <hughsient at gmail.com> wrote:
> Although some features are under development, currently Mousepad has following
> features:
>
>    * Complete support for UTF-8 text
>    * Cut/Copy/Paste and Select All text
>    * Search and Replace
>    * Font selecton
>    * Word Wrap
>    * Character coding selection
>    * Auto character coding detection (UTF-8 and some codesets)
>    * Manual codeset setting
>    * Infinite Undo/Redo by word
>    * Auto Indent
>    * Multi-line Indent
>    * Display line numbers
>    * Drag and Drop
>    * Printing


Putting feature lists in descriptions is stupid.  Obviously, you would
have to update the description after each release which is stupid.  It
is most likely that feature lists in descriptions are simply cut &
paste jobs from an upstream web site which is stupid.



From a.badger at gmail.com  Mon Dec 15 16:41:14 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 15 Dec 2008 08:41:14 -0800
Subject: RFC: Description text in packages
In-Reply-To: <0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
Message-ID: <494688AA.8060505@gmail.com>

Nicolas Mailhot wrote:
> 
> Le Lun 15 d?cembre 2008 16:37, Richard Hughes a ?crit :
> 
>> Next on my list are insane descriptions.
> 
> Specs files and most notably human-targeted text inside them are
> UTF-8. Please do not invent any broken application-side transcoding
> system. Writing correctly encoded text is the packager and translator
> responsability.
> 
+1

> If the fugly ASCII-zation some packagers use offends you,
> 1. write a best practices wiki page with recommended UTF-8 sequences
> 2. get it reviewed/approved by FPC and FESCO
> 3. open bugs for offending packages
> 4. get some broken-ASCII checks added to our package linting/review
> tools.
> 
Currently, I'm opposed to having a Guideline that mandates UTF-8 over
ASCII.  Description is an area almost completely left to the
maintainer's discretion (we've talked to the enlightenment maintainer
about taking out some of the marketing-speak but otherwise kept a pretty
much hands-off approach).

ASCii can be useful on the console whether the system is setup with a
utf-8 locale (which is our default, and therefore if we do mandate using
an encoding other than ASCii it's what we should use) or something more
limited (for instance, Asian countries still haven't settled on utf-8
everywhere.)

Note that this is an area where I'd change my stance if package
maintianers were to say that they want to have this sort of change.  I
just want to avoid alienating maintainers with conformance to this sort
of rule on descriptions without a higher return.

> This is how our guidelines process works, it's long and bureaucratic
> but it ensures everyone has its say and no gratuituous bikesheding is
> pushed on packagers.
> 
+1

>> Question 2: What's the maximum permitted length of a description?
> 
> What matters is not the description length but its quality and
> usefulness to users. Some domains use long descriptions, because the
> target audience expects them.
> 
+1

> Note that that because rpmlint insists on forcing 79 character
> line-wraps to help dumb terminal users, it's effectively impossible
> right now to get correct paragraph flow and breaks in descriptions
> (aye for optimizing the minority case at the expense of everyone
> else).
> 
If we were to mandate an encoding standard, we could make this work
similar to how various wikis and blogs take plain-text input and turn it
into formatted text.  Given my penchant for python, I like
ReStructuredText[1]_ for this but I'm sure we could get into a huge
flamewar over the right text-formatting language to use.

.. _[1]: http://docutils.sourceforge.net/rst.html

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/5fbdde14/attachment.sig>

From pemboa at gmail.com  Mon Dec 15 16:46:15 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 15 Dec 2008 10:46:15 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <494624C6.9070409@nicubunu.ro>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<1229330605.24419.265.camel@lenovo.local.net>
	<16de708d0812150046j4073b8b3i8cd602ec111bea3f@mail.gmail.com>
	<494624C6.9070409@nicubunu.ro>
Message-ID: <16de708d0812150846l74a50efaxc4ff30cb633b7734@mail.gmail.com>

On Mon, Dec 15, 2008 at 3:35 AM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> Arthur Pemberton wrote:
>>
>> Of course it is an important use case. No one is saying DVD installs
>> are useless. However if you have the bandwith to dload the DVD image
>> yourself, it is a lot more efficient to dload a live CD and install
>> from that.
>
> No if:
> - you perform the install on more than one machine;
> - you download in one location and install on another;
> - you want control over the way the download is performed (bittorrent,
> download rate control with gwget etc.)

> - you want a downtime as small as possible.

I fail to see how this is true with a DVD install. But this really
isn't that important as no one is trying to take away DVD installs.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From rawhide at fedoraproject.org  Mon Dec 15 16:49:55 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 15 Dec 2008 16:49:55 +0000 (UTC)
Subject: rawhide report: 20081215 changes
Message-ID: <20081215164955.59F5E1F8243@releng2.fedora.phx.redhat.com>

Compose started at Mon Dec 15 06:01:08 UTC 2008

New package bandwidthd
        Tracks network usage and builds html and graphs
New package bindfs
        Fuse filesystem to mirror a directory
New package diffpdf
        PDF files comparator
New package guiloader
        GuiXml Loader Library
New package libgdbus
        Library for simple D-Bus integration with GLib
New package mythes-ga
        Irish thesarus
New package palp
        A Package for Analyzing Lattice Polytopes
New package perl-Apache-DBI-Cache
        Perl DBI connection cache
New package perl-Catalyst-Controller-HTML-FormFu
        HTML::FormFu controller for Catalyst
New package perl-Data-TreeDumper-Renderer-GTK
        Gtk2::TreeView renderer for Data::TreeDumper
New package perl-Directory-Scratch
        Self-cleaning scratch space for tests
New package perl-URI-Find
        Find URIs in plain text
New package pytagger
        ID3 Tag Reader and Writer Library for Python
New package vbindiff
        Visual binary diff
Updated Packages:

Django-1.0.2-1.fc11
-------------------
* Sun Dec 14 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 1.0.2-1
- Update to 1.0.2


aiccu-2007.01.15-5.fc11
-----------------------
* Fri Oct 17 18:00:00 2008 Matt Domsch <mdomsch at fedoraproject.org> - 2007.01.15-5
- close file descriptors on exec (BZ#467381)


comix-4.0.1-1.fc11
------------------
* Mon Dec 15 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 4.0.1-1
- 4.0.1


fedora-business-cards-0.2.3-1.fc11
----------------------------------
* Sun Dec 14 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.2.3-1
- Add EPS as an export option

* Sun Dec 14 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.2.2-3
- Change summary to be more helpful


gdb-6.8.50.20081214-1.fc11
--------------------------
* Sun Dec 14 17:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.8.50.20081214-1
- Upgrade to the upstream gdb-6.8.50 snapshot.

* Mon Dec  1 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 6.8-32
- Remove trivial BuildRequires, use rpm macros in a few remaining places.

* Mon Dec  1 17:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.8-33
- Make `--with testsuite' BuildRequires properly conditional.

* Tue Nov 18 17:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.8-31
- Enable ia64 hardware watchpoints if created before starting inferior.


haddock-2.4.1-1.fc11
--------------------
* Mon Dec 15 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 2.4.1-1
- update to 2.4.1 release needed for gtk2hs
- update source url
- drop coreutils and autoconf from buildrequires
- add haddock-2.4.1-no-ghc-paths.patch to workaround no ghc-paths package yet
- provide devel package
- use rpm macros to build and package
- version haddock program since it is also in ghc
- buildrequire autoconf


jd-2.1.0-0.1.svn2562_trunk.fc11
-------------------------------
* Mon Dec 15 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2562


kernel-2.6.28-0.129.rc8.git2.fc11
---------------------------------
* Sat Dec 13 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com>
- Add "scsi_esp_register" to the search terms for modules.block so we pick up sun_esp.ko

* Sat Dec 13 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
- 2.6.28-rc8-git2


konq-plugins-4.1.3-3.fc11
-------------------------
* Sun Dec 14 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.3-3
- rebuild for Python 2.6 (contains Python bytecode despite no dependencies)


libcanberra-0.10-4.fc11
-----------------------
* Sun Dec 14 17:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.10-4
- Moved login sound to "Application" startup phase.


libdiscid-0.2.2-2.fc11
----------------------
* Sun Dec 14 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.2.2-2
- rebuild for pkgconfig deps


libgee-0.1.4-2.fc11
-------------------

lyx-1.6.1-1.fc11
----------------
* Sun Dec 14 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.6.1-1
- lyx-1.6.1


mksh-36b-1.fc11
---------------
* Sun Dec 14 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 36b-1
- Upgrade to 36b and updated arc4random.c file


osmo-0.2.4-2.fc11
-----------------
* Sun Dec 14 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.2.4-2
- Fixed crash due to SIGABRT using patch written by Tomasz Maka.


purple-facebookchat-1.44-1.fc11
-------------------------------
* Wed Oct 29 18:00:00 2008 Mat??j Cepl <mcepl at redhat.com> 1.38-1
- New upstream release
- My patch was finally accepted upstream -- removing it here.


rubberband-1.2-2.fc11
---------------------
* Sun Dec 14 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 1.2-2
- Rebuild for vamp-plugins-sdk-2.0


sonic-visualiser-1.4-2.fc11
---------------------------
* Sun Dec 14 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 1.4-2
- Fix qmake profiles to properly detect 64-bit Linux

* Sun Dec 14 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 1.4-1
- Update to 1.4
- Replace PortAudio dependency with PulseAudio


telepathy-gabble-0.7.17-1.fc11
------------------------------
* Sun Dec 14 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.17-1
- Update to 0.7.17.


twitux-0.68-1.fc11
------------------
* Sun Dec 14 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.68-1
- Update to 0.68.
- Add BR on gnome-doc-utils and libcanberra-devel.
- Add help files.
- Drop popup menu patch.  Fixed upstream.


vamp-plugin-sdk-2.0-1.fc11
--------------------------
* Sun Dec 14 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 2.0-1
- Update to 2.0


vdr-osdteletext-0.6.0-1.fc11
----------------------------
* Sun Dec 14 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.6.0-1
- 0.6.0 (new community upstream), patches applied upstream.


w3c-libwww-5.4.1-0.12.20060206cvs.fc11
--------------------------------------
* Wed Dec  3 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 5.4.1-0.12.20060206cvs
- Updated patches to fix FTBFS. Closes Red Hat Bugzilla bug #465034.
- Fixed linkage problems to reduce the number of undefined non-weak symbols.
- Omitted unused direct shared library dependencies.

* Wed May 21 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 5.4.1-0.11.20060206cvs
- fix license tag


wfmath-0.3.8-1.fc11
-------------------
* Sun Dec 14 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.3.8-1
- Update to 0.3.8
- Don't run unit tests on PPC64


xfce4-dict-0.5.2-1.fc11
-----------------------

xorg-x11-drv-synaptics-0.99.3-1.fc11
------------------------------------
* Mon Dec 15 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 0.99.3-1
- synaptics 1.0 RC 3


yum-cron-0.8.3-1.fc11
---------------------
* Sun Dec 14 17:00:00 2008 Alec Habig <ahabig at umn.edu> - 0.8.3-1
- Change writes to YUMTMP to be appends to work around selinux policy
  oddness in bug 431588
- this requires the added policycoreutils dependancy


Summary:
Added Packages: 14
Removed Packages: 0
Modified Packages: 27
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	audacity-1.3.5-0.8.beta.fc10.i386 requires libvamp-hostsdk.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bacula-client-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.i386 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.i386 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.i386 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.i386 requires libltdl.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.i386 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.i386 requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	audacity-1.3.5-0.8.beta.fc10.x86_64 requires libvamp-hostsdk.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.x86_64 requires libltdl.so.3()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.i386 requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.x86_64 requires pkgconfig(libsynce)
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.x86_64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.x86_64 requires olpcupdate >= 0:2.10
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	openct-0.6.15-1.fc10.i386 requires libltdl.so.3
	openct-0.6.15-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.i386 requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.x86_64 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.x86_64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.x86_64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	audacity-1.3.5-0.8.beta.fc10.ppc requires libvamp-hostsdk.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-mysql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-postgresql-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-director-sqlite-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	bacula-storage-common-2.4.3-3.fc11.ppc requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	1:eclipse-pydev-1.3.24-3.fc11.noarch requires python-psyco
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	librapi-devel-0.11.1-2.fc11.ppc requires pkgconfig(libsynce)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-6.fc11.ppc requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc requires libltdl.so.3
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openldap-servers-2.4.12-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc requires libltdl.so.3
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.ppc requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.ppc requires libltdl.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc requires libpython2.5.so.1.0
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	audacity-1.3.5-0.8.beta.fc10.ppc64 requires libvamp-hostsdk.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-client-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-mysql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-postgresql-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-director-sqlite-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	bacula-storage-common-2.4.3-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:eclipse-pydev-1.3.24-3.fc11.noarch requires python-psyco
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	librapi-devel-0.11.1-2.fc11.ppc64 requires pkgconfig(libsynce)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-6.fc11.ppc64 requires /usr/bin/python2.5
	olpc-utils-0.89-6.fc11.ppc64 requires olpcupdate >= 0:2.10
	openct-0.6.15-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openldap-servers-2.4.12-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	opensc-devel-0.11.6-1.fc10.ppc64 requires libltdl.so.3()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.ppc64 requires perl(XML::LibXML) = 0:1.66
	pinball-0.3.1-11.fc9.ppc64 requires libltdl.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python-abi = 0:2.5
	python-psycopg-1.1.21-8.fc10.ppc64 requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qtiplot-0.9-8.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tinyerp-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tinyerp-server-4.2.3.3-1.fc10.noarch requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From skvidal at fedoraproject.org  Mon Dec 15 17:06:15 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 15 Dec 2008 12:06:15 -0500 (EST)
Subject: RFC: Description text in packages
In-Reply-To: <0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
Message-ID: <alpine.LFD.2.00.0812151203470.28634@localhost.localdomain>



On Mon, 15 Dec 2008, Nicolas Mailhot wrote:

>
>
> Le Lun 15 d?cembre 2008 16:37, Richard Hughes a ?crit :
>
>> Next on my list are insane descriptions.
>
> Specs files and most notably human-targeted text inside them are
> UTF-8. Please do not invent any broken application-side transcoding
> system.

+1.

If we make description (or any field) a special format and try to rely on 
it I think you'll find that ISVs and 3rd party providers of packages will 
ignore it/not know about it and then screw up PK. It's better to accept 
all sorts of wackiness and live with it. If the package maintainer wants 
their descriptions to be useful to people then they can clean them up to 
look better in PK.

Having said that an rpmlint check that says no description can be > than 
512bytes might not be a terrible thing.

-sv

From sundaram at fedoraproject.org  Mon Dec 15 17:21:16 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 15 Dec 2008 22:51:16 +0530
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229356244.6392.13.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<20081211124523.GA31161@hurricane.linuxnetz.de>	<1229017523.30987.138.camel@code.and.org>	<20081212001005.GA15306@hurricane.linuxnetz.de>	<ghsht6$gpk$1@ger.gmane.org>	<20081214183354.GB31351@hurricane.linuxnetz.de>
	<1229356244.6392.13.camel@code.and.org>
Message-ID: <4946920C.9040504@fedoraproject.org>

James Antill wrote:
> 
>  By default yum sets the metadata cache timeout to 90 minutes, now if
> you want to optimize for Fedora you might be tempted to change this to
> "1d" so yum will only re-check it's metadata once a day. However if you
> turn on your laptop at 22:00 Sunday, then you'll miss any updates from
> Monday until 22:00 Monday night.
>  Or more technically, from any given Fedora update you'll have to wait
> _upto_ 1 day later to see them.
>  This then only gets worse with mirrors.

90 mins is just too often. Isn't it? 1d would be more appropriate as a 
default, I think if we somehow manage to sync the metadata expiry time 
to factor in the delay caused by mirrors.

>  I've said for a long time, if you want a "zero network" yum the best
> thing you can do is run yum-updatesd it metadata only mode.

This probably needs to go into a FAQ. The question on why yum has to hit 
the network for every operation comes up way too often. Perhaps the FAQ 
can answer that as well.

Rahul




From skvidal at fedoraproject.org  Mon Dec 15 17:27:43 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 15 Dec 2008 12:27:43 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4946920C.9040504@fedoraproject.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
	<1229356244.6392.13.camel@code.and.org>
	<4946920C.9040504@fedoraproject.org>
Message-ID: <alpine.LFD.2.00.0812151225100.28634@localhost.localdomain>



On Mon, 15 Dec 2008, Rahul Sundaram wrote:

> James Antill wrote:
>>
>>  By default yum sets the metadata cache timeout to 90 minutes, now if
>> you want to optimize for Fedora you might be tempted to change this to
>> "1d" so yum will only re-check it's metadata once a day. However if you
>> turn on your laptop at 22:00 Sunday, then you'll miss any updates from
>> Monday until 22:00 Monday night.
>>  Or more technically, from any given Fedora update you'll have to wait
>> _upto_ 1 day later to see them.
>>  This then only gets worse with mirrors.
>
> 90 mins is just too often. Isn't it? 1d would be more appropriate as a 
> default, I think if we somehow manage to sync the metadata expiry time to 
> factor in the delay caused by mirrors.


AFAICT there is no best number. If someone would like to play with it and 
tell us what is more sensible it is utterly trivial to set.

I don't think 1day is a good number - it'll drive some folks insane. Maybe 
6 hours? That means in an average working day you'll only get one update. 
And if you are SURE that there are updates you're missing you can always 
do:

yum clean expire-cache

> This probably needs to go into a FAQ. The question on why yum has to hit the 
> network for every operation comes up way too often. Perhaps the FAQ can 
> answer that as well.

it doesn't hit the network on every operation. And the cache timeout is 
documented in the man page.

-sv



From sundaram at fedoraproject.org  Mon Dec 15 17:33:30 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 15 Dec 2008 23:03:30 +0530
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <alpine.LFD.2.00.0812151225100.28634@localhost.localdomain>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>	<20081211124523.GA31161@hurricane.linuxnetz.de>	<1229017523.30987.138.camel@code.and.org>	<20081212001005.GA15306@hurricane.linuxnetz.de>	<ghsht6$gpk$1@ger.gmane.org>	<20081214183354.GB31351@hurricane.linuxnetz.de>	<1229356244.6392.13.camel@code.and.org>	<4946920C.9040504@fedoraproject.org>
	<alpine.LFD.2.00.0812151225100.28634@localhost.localdomain>
Message-ID: <494694EA.5050900@fedoraproject.org>

Seth Vidal wrote:
> 
> AFAICT there is no best number. If someone would like to play with it 
> and tell us what is more sensible it is utterly trivial to set.
> 
> I don't think 1day is a good number - it'll drive some folks insane.

Why? We shouldn't be pushing out updates more than once per day. Right?

> it doesn't hit the network on every operation. And the cache timeout is 
> documented in the man page.

Yes, it doesn't hit the network on every operation but that's the 
perception. For operations, it does, it isn't always obvious why.  Why 
does remove hit the network for example? I would like to see such things 
documented somewhere. It is certainly a FAQ. If we had a reference to 
point out to users, it would help a lot. Thanks.

Rahul











From james at fedoraproject.org  Mon Dec 15 17:41:38 2008
From: james at fedoraproject.org (James Antill)
Date: Mon, 15 Dec 2008 12:41:38 -0500
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <494694EA.5050900@fedoraproject.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
	<1229356244.6392.13.camel@code.and.org>
	<4946920C.9040504@fedoraproject.org>
	<alpine.LFD.2.00.0812151225100.28634@localhost.localdomain>
	<494694EA.5050900@fedoraproject.org>
Message-ID: <1229362898.6392.19.camel@code.and.org>

On Mon, 2008-12-15 at 23:03 +0530, Rahul Sundaram wrote:
> Seth Vidal wrote:
> > 
> > AFAICT there is no best number. If someone would like to play with it 
> > and tell us what is more sensible it is utterly trivial to set.
> > 
> > I don't think 1day is a good number - it'll drive some folks insane.
> 
> Why? We shouldn't be pushing out updates more than once per day. Right?

 Read the emails again, 3 or 6 hours might be worth trying ... as then
even the worst case would probably be fine (for Fedora, anyway).

>  For operations, it does, it isn't always obvious why.  Why 
> does remove hit the network for example?

 It doesn't.

-- 
James Antill <james at fedoraproject.org>
Fedora



From rjones at redhat.com  Mon Dec 15 17:42:38 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 15 Dec 2008 17:42:38 +0000
Subject: RFC: Description text in packages
In-Reply-To: <d9c612bf0812150834q5df8ef93sfd65f91106535f65@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<d9c612bf0812150834q5df8ef93sfd65f91106535f65@mail.gmail.com>
Message-ID: <20081215174238.GA20033@amd.home.annexia.org>

On Mon, Dec 15, 2008 at 08:34:33AM -0800, Christopher Stone wrote:
> Putting feature lists in descriptions is stupid.  Obviously, you would
> have to update the description after each release which is stupid.  It
> is most likely that feature lists in descriptions are simply cut &
> paste jobs from an upstream web site which is stupid.

I happen to think that it's reasonable to do this in some
circumstances -- where the upstream website author has written a good,
concise description of the package, and is clearly more familiar with
the package than the Fedora maintainer.  And in any case, what is
wrong with feature lists (even if they need to be updated)?  If
someone has gone to the effort of doing 'yum info package' then it's
quite likely they're interested in the features of that package.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From pemboa at gmail.com  Mon Dec 15 17:43:55 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 15 Dec 2008 11:43:55 -0600
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229362898.6392.19.camel@code.and.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
	<1229356244.6392.13.camel@code.and.org>
	<4946920C.9040504@fedoraproject.org>
	<alpine.LFD.2.00.0812151225100.28634@localhost.localdomain>
	<494694EA.5050900@fedoraproject.org>
	<1229362898.6392.19.camel@code.and.org>
Message-ID: <16de708d0812150943y3aee319awa6a0f1af77c47113@mail.gmail.com>

On Mon, Dec 15, 2008 at 11:41 AM, James Antill <james at fedoraproject.org> wrote:
> On Mon, 2008-12-15 at 23:03 +0530, Rahul Sundaram wrote:
>> Seth Vidal wrote:
>> >
>> > AFAICT there is no best number. If someone would like to play with it
>> > and tell us what is more sensible it is utterly trivial to set.
>> >
>> > I don't think 1day is a good number - it'll drive some folks insane.
>>
>> Why? We shouldn't be pushing out updates more than once per day. Right?
>
>  Read the emails again, 3 or 6 hours might be worth trying ... as then
> even the worst case would probably be fine (for Fedora, anyway).
>
>>  For operations, it does, it isn't always obvious why.  Why
>> does remove hit the network for example?
>
>  It doesn't.


I believe that had been bugged and fixed already.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From chris.stone at gmail.com  Mon Dec 15 17:47:40 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 15 Dec 2008 09:47:40 -0800
Subject: RFC: Description text in packages
In-Reply-To: <20081215174238.GA20033@amd.home.annexia.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<d9c612bf0812150834q5df8ef93sfd65f91106535f65@mail.gmail.com>
	<20081215174238.GA20033@amd.home.annexia.org>
Message-ID: <d9c612bf0812150947n5ec43896se873c6dd0f23fc9@mail.gmail.com>

On Mon, Dec 15, 2008 at 9:42 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Mon, Dec 15, 2008 at 08:34:33AM -0800, Christopher Stone wrote:
>> Putting feature lists in descriptions is stupid.  Obviously, you would
>> have to update the description after each release which is stupid.  It
>> is most likely that feature lists in descriptions are simply cut &
>> paste jobs from an upstream web site which is stupid.
>
> I happen to think that it's reasonable to do this in some
> circumstances -- where the upstream website author has written a good,
> concise description of the package, and is clearly more familiar with
> the package than the Fedora maintainer.  And in any case, what is
> wrong with feature lists (even if they need to be updated)?  If
> someone has gone to the effort of doing 'yum info package' then it's
> quite likely they're interested in the features of that package.
>
> Rich.

So, why not just go to the upstream website?  Spec file descriptions
are not the place to look for feature lists...

I am certain that in 100% of all cases where feature lists are in spec
files, these lists are out of date, inaccurate, and not updated with
new features.  I also maintain that in 100% of all cases like this,
the package maintainer is just being lazy and simply cut&pasted the
feature list from the upstream web site, and has no intention
whatsoever of actually keeping the list up to date and accurate.



From jmoyer at redhat.com  Mon Dec 15 17:53:03 2008
From: jmoyer at redhat.com (Jeff Moyer)
Date: Mon, 15 Dec 2008 12:53:03 -0500
Subject: Alternatives to serial console for capturing oopses
In-Reply-To: <cone.1229122645.115179.23287.500@commodore.email-scan.com> (Sam
	Varshavchik's message of "Fri, 12 Dec 2008 17:57:25 -0500")
References: <cone.1229122645.115179.23287.500@commodore.email-scan.com>
Message-ID: <x491vw9xr40.fsf@segfault.boston.devel.redhat.com>

Sam Varshavchik <mrsam at courier-mta.com> writes:

> I've got a quad-core dual x86_64 server that, so far, reproducably
> locks up under every 2.6.27 kernel released for F9 so far, when I run
> a build cycle. The last kernel that manages to survive under load is
> 2.6.26.6-79.fc9, so I'll continue to boot it until I get a 2.6.27
> kernel that doesn't croak on me.
>
> Given that the hardware does not have a serial port, how else can I
> capture an oops, if one is being generated? At least I hope that
> there'll be an oops for me to capture.

Try netconsole:
  https://fedoraproject.org/wiki/Netconsole



From rjones at redhat.com  Mon Dec 15 17:55:49 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 15 Dec 2008 17:55:49 +0000
Subject: RFC: Description text in packages
In-Reply-To: <d9c612bf0812150947n5ec43896se873c6dd0f23fc9@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<d9c612bf0812150834q5df8ef93sfd65f91106535f65@mail.gmail.com>
	<20081215174238.GA20033@amd.home.annexia.org>
	<d9c612bf0812150947n5ec43896se873c6dd0f23fc9@mail.gmail.com>
Message-ID: <20081215175549.GA20204@amd.home.annexia.org>

On Mon, Dec 15, 2008 at 09:47:40AM -0800, Christopher Stone wrote:
> So, why not just go to the upstream website?  Spec file descriptions
> are not the place to look for feature lists...

Because I want to have 'yum search' do something useful and find those
features.  eg. If I want a blog tool with spam filtering that's
supported in Fedora, how do you propose to answer that question by
going to a website?

> I am certain that in 100% of all cases where feature lists are in spec
> files, these lists are out of date, inaccurate, and not updated with
> new features.

Well, I'll assert that you're wrong, but if there are any packages
which are like this, file bugs for them ...

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From skvidal at fedoraproject.org  Mon Dec 15 18:03:12 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 15 Dec 2008 13:03:12 -0500 (EST)
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <494694EA.5050900@fedoraproject.org>
References: <20081209002540.GA25637@hurricane.linuxnetz.de>
	<da159fda0812081836r7449eee7u78d7629684ad55b3@mail.gmail.com>
	<20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
	<1229356244.6392.13.camel@code.and.org>
	<4946920C.9040504@fedoraproject.org>
	<alpine.LFD.2.00.0812151225100.28634@localhost.localdomain>
	<494694EA.5050900@fedoraproject.org>
Message-ID: <alpine.LFD.2.00.0812151302520.28634@localhost.localdomain>



On Mon, 15 Dec 2008, Rahul Sundaram wrote:

> Seth Vidal wrote:
>> 
>> AFAICT there is no best number. If someone would like to play with it and 
>> tell us what is more sensible it is utterly trivial to set.
>> 
>> I don't think 1day is a good number - it'll drive some folks insane.
>
> Why? We shouldn't be pushing out updates more than once per day. Right?
>
>> it doesn't hit the network on every operation. And the cache timeout is 
>> documented in the man page.
>
> Yes, it doesn't hit the network on every operation but that's the perception. 
> For operations, it does, it isn't always obvious why.  Why does remove hit 
> the network for example? I would like to see such things documented 
> somewhere. It is certainly a FAQ. If we had a reference to point out to 
> users, it would help a lot. Thanks.


Faq:
http://yum.baseurl.org/wiki/Faq
http://yum.baseurl.org/wiki/Faq#Q.17:WhydoesyumalwaysseemtoupdatethemetadataonEVERYrun


-sv



From nicolas.mailhot at laposte.net  Mon Dec 15 18:18:11 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Dec 2008 19:18:11 +0100
Subject: RFC: Description text in packages
In-Reply-To: <494688AA.8060505@gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com>
Message-ID: <1229365091.25084.25.camel@arekh.okg>

Le lundi 15 d?cembre 2008 ? 08:41 -0800, Toshio Kuratomi a ?crit :

> Currently, I'm opposed to having a Guideline that mandates UTF-8 over
> ASCII.

And I'm opposed to continuing to abuse ASCII glyphs and pretend they
stand for something other than their creators intended. One couldn't
avoid it when the available encoding didn't provide a clean way to write
some stuff, but doing it in 2008 is plain dumb.

People who want to write pure ASCII descriptions in UTF-8 locales just
have to find a wording that does not put them in the situation where
non-ASCII UTF-8 is the clean way to write things. They're no more
special than the people whose stuff we refuse because it uses
non-standard deprecated legacy encodings.

> Description is an area almost completely left to the
> maintainer's discretion

The encoding isn't.

> ASCii can be useful on the console whether the system is setup with a
> utf-8 locale (which is our default, and therefore if we do mandate using
> an encoding other than ASCii it's what we should use) or something more
> limited (for instance, Asian countries still haven't settled on utf-8
> everywhere.)

But Red Hat and Fedora did. And our default Asian locales are UTF-8.

If someone acually wants a pure ASCII environment, he should work on an
en_US at ASCII locale and stop trying to mess up the distro UTF-8 defaults.

> Note that this is an area where I'd change my stance if package
> maintianers were to say that they want to have this sort of change.  I
> just want to avoid alienating maintainers with conformance to this sort
> of rule on descriptions without a higher return.

Red Hat didn't choose UTF-8 over ASCII just to annoy ASCII users. UTF-8
brings very desirable text features. Letting the ASCII crowd mandate
avoiding the use of non-ASCII UTF-8 negates the original encoding change
decision, and brings back the stupid brittle transcoding hacks that
UTF-8 was supposed to eliminate (as the OP message clearly shows).

I'd rather have our package descriptions look good in our default
encoding and default GUI update tool than have them look good in
marginally used legacy equipments that do not support current technical
standards.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/5b3bd7a7/attachment.sig>

From frankly3d at fedoraproject.org  Mon Dec 15 18:27:04 2008
From: frankly3d at fedoraproject.org (Frank Murphy)
Date: Mon, 15 Dec 2008 18:27:04 +0000
Subject: Server SIG - work areas
In-Reply-To: <4944F811.1040206@kanarip.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>
	<4944F811.1040206@kanarip.com>
Message-ID: <4946A178.9040703@fedoraproject.org>

Jeroen van Meeuwen wrote:


> Integration of Provisioning utilities such as Cobbler, Genome,
> Kickstart, Configuration Management utilities such as CFEngine, Puppet,
> Augeas, iClasssify, and Monitoring utilities such as Nagios, Zabbix,
> Zenos, Monit
> 
> Kind regards,
> 
> Jeroen van Meeuwen
> -kanarip
> 

As someone who doesn't know what I'm talking about yet,
would ebox fit in?
http://ebox-platform.com/

Frank



From mlichvar at redhat.com  Mon Dec 15 18:28:23 2008
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Mon, 15 Dec 2008 19:28:23 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <gi5svv$jvc$1@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
Message-ID: <20081215182823.GA28317@localhost>

On Mon, Dec 15, 2008 at 04:26:55PM +0100, Harald Hoyer wrote:
>> http://www.harald-hoyer.de/files/bootchart-16.png
>
> with newaliases this was 100% reproducable.

The fdatasync call comes from db4.

It would be nice if newaliases was executed only when /etc/aliases.db
is older than /etc/aliases, but other MTAs may use the same db file,
so it needs to be updated also after switching mta in the alternatives
system.

Maybe copy the timestamp in the init script to another file and don't
call newaliases only when the timestamps are equal?

Suggestions welcomed.

-- 
Miroslav Lichvar



From mclasen at redhat.com  Mon Dec 15 18:34:37 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 15 Dec 2008 13:34:37 -0500
Subject: RFC: Description text in packages
In-Reply-To: <1229365091.25084.25.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com>  <1229365091.25084.25.camel@arekh.okg>
Message-ID: <1229366077.3343.9.camel@matthiasc>

On Mon, 2008-12-15 at 19:18 +0100, Nicolas Mailhot wrote:

> Red Hat didn't choose UTF-8 over ASCII just to annoy ASCII users. UTF-8
> brings very desirable text features. Letting the ASCII crowd mandate
> avoiding the use of non-ASCII UTF-8 negates the original encoding change
> decision, and brings back the stupid brittle transcoding hacks that
> UTF-8 was supposed to eliminate (as the OP message clearly shows).

When we are talking about paragraph boundaries and lists, that leaves
the area of 'transcoding hacks' and enters the realm or markup. 



From nicolas.mailhot at laposte.net  Mon Dec 15 18:42:19 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Dec 2008 19:42:19 +0100
Subject: RFC: Description text in packages
In-Reply-To: <1229366077.3343.9.camel@matthiasc>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com>  <1229365091.25084.25.camel@arekh.okg>
	<1229366077.3343.9.camel@matthiasc>
Message-ID: <1229366539.25084.31.camel@arekh.okg>

Le lundi 15 d?cembre 2008 ? 13:34 -0500, Matthias Clasen a ?crit :
> On Mon, 2008-12-15 at 19:18 +0100, Nicolas Mailhot wrote:
> 
> > Red Hat didn't choose UTF-8 over ASCII just to annoy ASCII users. UTF-8
> > brings very desirable text features. Letting the ASCII crowd mandate
> > avoiding the use of non-ASCII UTF-8 negates the original encoding change
> > decision, and brings back the stupid brittle transcoding hacks that
> > UTF-8 was supposed to eliminate (as the OP message clearly shows).
> 
> When we are talking about paragraph boundaries and lists, that leaves
> the area of 'transcoding hacks' and enters the realm or markup. 

This part is not ?transcoding hacks?, it's letting paragraphs flow
naturally instead of forcing 79-column lines and then eating all the LFs
(including paragraph breaks) at yum/pk time in an effort to stitch the
bits back together.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/1cc242ab/attachment.sig>

From alsadi at gmail.com  Mon Dec 15 19:52:10 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 15 Dec 2008 21:52:10 +0200
Subject: RFC: Description text in packages
In-Reply-To: <1229366539.25084.31.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<1229366077.3343.9.camel@matthiasc>
	<1229366539.25084.31.camel@arekh.okg>
Message-ID: <385866f0812151152y15bfeaam70e321c6d294997e@mail.gmail.com>

> Question 1: Should we use '', "", or the UTF-8 quote characters? If we

for some crazy reason unicode has removed mirrored proprietary from quotes
so I suggest using "" quotes not any of U+2018-U+201F



From robert at fedoraproject.org  Mon Dec 15 20:00:02 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 15 Dec 2008 21:00:02 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1229362898.6392.19.camel@code.and.org>
References: <20081211124523.GA31161@hurricane.linuxnetz.de>
	<1229017523.30987.138.camel@code.and.org>
	<20081212001005.GA15306@hurricane.linuxnetz.de>
	<ghsht6$gpk$1@ger.gmane.org>
	<20081214183354.GB31351@hurricane.linuxnetz.de>
	<1229356244.6392.13.camel@code.and.org>
	<4946920C.9040504@fedoraproject.org>
	<alpine.LFD.2.00.0812151225100.28634@localhost.localdomain>
	<494694EA.5050900@fedoraproject.org>
	<1229362898.6392.19.camel@code.and.org>
Message-ID: <20081215200002.GA3055@hurricane.linuxnetz.de>

On Mon, 15 Dec 2008, James Antill wrote:
> On Mon, 2008-12-15 at 23:03 +0530, Rahul Sundaram wrote:
> > Why? We shouldn't be pushing out updates more than once per day. Right?
> 
>  Read the emails again, 3 or 6 hours might be worth trying ... as then
> even the worst case would probably be fine (for Fedora, anyway).

Well, 6 hours should be an interesting test case. That's still four times
as much as currently updates are getting pushed. Can we maybe try that for
Rawhide (which also gets only one push per day AFAIK)?


Greetings,
  Robert



From skvidal at fedoraproject.org  Mon Dec 15 17:56:45 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 15 Dec 2008 12:56:45 -0500 (EST)
Subject: RFC: Description text in packages
In-Reply-To: <d9c612bf0812150947n5ec43896se873c6dd0f23fc9@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<d9c612bf0812150834q5df8ef93sfd65f91106535f65@mail.gmail.com>
	<20081215174238.GA20033@amd.home.annexia.org>
	<d9c612bf0812150947n5ec43896se873c6dd0f23fc9@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0812151255380.28634@localhost.localdomain>



On Mon, 15 Dec 2008, Christopher Stone wrote:

> On Mon, Dec 15, 2008 at 9:42 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
>> On Mon, Dec 15, 2008 at 08:34:33AM -0800, Christopher Stone wrote:
>>> Putting feature lists in descriptions is stupid.  Obviously, you would
>>> have to update the description after each release which is stupid.  It
>>> is most likely that feature lists in descriptions are simply cut &
>>> paste jobs from an upstream web site which is stupid.
>>
>> I happen to think that it's reasonable to do this in some
>> circumstances -- where the upstream website author has written a good,
>> concise description of the package, and is clearly more familiar with
>> the package than the Fedora maintainer.  And in any case, what is
>> wrong with feature lists (even if they need to be updated)?  If
>> someone has gone to the effort of doing 'yum info package' then it's
>> quite likely they're interested in the features of that package.
>>
>> Rich.
>
> So, why not just go to the upstream website?  Spec file descriptions
> are not the place to look for feature lists...


Well, to be fair - 'yum search' does search description. So there are two 
ways of looking at this:

1. we can overload description with keywords, etc and then yum search can 
find them there. :(
2. we can work on the keyword additional metadata I talked about a month 
or so ago here.

-sv



From notting at redhat.com  Mon Dec 15 20:28:31 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 15 Dec 2008 15:28:31 -0500
Subject: Alternatives to serial console for capturing oopses
In-Reply-To: <cone.1229130654.603222.26677.500@commodore.email-scan.com>
References: <cone.1229122645.115179.23287.500@commodore.email-scan.com>
	<1229123204.2898.1.camel@sb-home>
	<cone.1229130654.603222.26677.500@commodore.email-scan.com>
Message-ID: <20081215202831.GD23506@nostromo.devel.redhat.com>

Sam Varshavchik (mrsam at courier-mta.com) said: 
> 1) Only the server component is present in Fedora. There is no client. 
> And, of course, I need the client.
>
> 2) The client package requires additional kernel modules to be built. If 
> you are actually using netdump in Fedora, please explain how.

If you're just interested in the messages, netconsole should work
fine. You can load the module by hand with the proper parameters,
or use the netconsole init script.

(For the server side I tend to be lazy and just do nc | tee on another
local box. YMMV.)

Bill



From notting at redhat.com  Mon Dec 15 20:29:39 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 15 Dec 2008 15:29:39 -0500
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <4943D18E.60107@BitWagon.com>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>
	<4943D18E.60107@BitWagon.com>
Message-ID: <20081215202939.GE23506@nostromo.devel.redhat.com>

John Reiser (jreiser at BitWagon.com) said: 
> Chitlesh GOORAH wrote:
> > ... With a category "Electronics" in comps.xml, users
> > can easily identify the electronic specific rpms on kpackageki.
> 
> Please list the existing packages which should be included
> in an Electronics category.

Also, 'Electronics' seems vague ... 'Electronic Design'? 'EDA'?

Bill



From robert at fedoraproject.org  Mon Dec 15 20:32:51 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 15 Dec 2008 21:32:51 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228955195.3394.69.camel@beck.corsepiu.local>
References: <1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
Message-ID: <20081215203251.GA3700@hurricane.linuxnetz.de>

On Thu, 11 Dec 2008, Ralf Corsepius wrote:
> On Wed, 2008-12-10 at 18:51 -0500, Josh Boyer wrote:
> > On Wed, Dec 10, 2008 at 11:48:04PM +0100, Ralf Corsepius wrote:
> > >Why is this not fair? The technical facts on FC10 speak for themselves: 
> > >Rawhide and Fedora's release procedures as means for "Fedora release
> > >preparation testing" don't work out.
> > 
> > Examples of this? 
> 
> Some random examples, which I have been hit myself:

You're forgetting gdm-setup in your list which is now AFAIK unavailable
since F9 for a similar reason.
 
> PackageKit: A trouble area of its own.
>   https://bugzilla.redhat.com/show_bug.cgi?id=469293
>   https://bugzilla.redhat.com/show_bug.cgi?id=469324
>   IMO, PackageKit is too immature and has been prematurely rushed out.

Simply +1

> Besides the numerous NEVR issues between Fedora release, which FC10 (as
> usual) suffers from, this time another kind of repo screw up took place:
> 
> updates/10 contains packages with an older NEVR than Everything and
> Fedora, e.g.:

Why doesn't the nice bodhi perform version checks to the packages before it
accepts them, whether e.g. the upgrade path F8 -> F9 -> F10 and so on is
guaranted? Or would that be too much work somehow or to somebody? IMHO this
is something really needed. AFAIK glibc in Fedora 10 is still newer than in
Rawhide currently.


Greetings,
  Robert



From pemboa at gmail.com  Mon Dec 15 20:32:05 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 15 Dec 2008 14:32:05 -0600
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <20081215202939.GE23506@nostromo.devel.redhat.com>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>
	<4943D18E.60107@BitWagon.com>
	<20081215202939.GE23506@nostromo.devel.redhat.com>
Message-ID: <16de708d0812151232y5e5ac70bx2f34b9404619576b@mail.gmail.com>

On Mon, Dec 15, 2008 at 2:29 PM, Bill Nottingham <notting at redhat.com> wrote:
> John Reiser (jreiser at BitWagon.com) said:
>> Chitlesh GOORAH wrote:
>> > ... With a category "Electronics" in comps.xml, users
>> > can easily identify the electronic specific rpms on kpackageki.
>>
>> Please list the existing packages which should be included
>> in an Electronics category.
>
> Also, 'Electronics' seems vague ... 'Electronic Design'? 'EDA'?

+1


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From sundaram at fedoraproject.org  Mon Dec 15 20:40:31 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 16 Dec 2008 02:10:31 +0530
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081215203251.GA3700@hurricane.linuxnetz.de>
References: <1228849604.30987.31.camel@code.and.org>	<493EE81B.6000909@gmail.com>	<1228861426.30987.57.camel@code.and.org>	<493F0BA8.1050300@gmail.com>	<1228927014.3863.38.camel@localhost.localdomain>	<1228945609.3394.10.camel@beck.corsepiu.local>	<1228947640.31448.39.camel@arekh.okg>	<1228949284.3394.36.camel@beck.corsepiu.local>	<20081210235117.GB11018@zod.rchland.ibm.com>	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081215203251.GA3700@hurricane.linuxnetz.de>
Message-ID: <4946C0BF.5090202@fedoraproject.org>

Robert Scheck wrote:

> 
> Why doesn't the nice bodhi perform version checks to the packages before it
> accepts them, whether e.g. the upgrade path F8 -> F9 -> F10 and so on is
> guaranted? Or would that be too much work somehow or to somebody? IMHO this
> is something really needed. AFAIK glibc in Fedora 10 is still newer than in
> Rawhide currently.

Refer

https://fedorahosted.org/bodhi/ticket/79

Rahul




From robert at fedoraproject.org  Mon Dec 15 20:43:30 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 15 Dec 2008 21:43:30 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <1228974732.17799.TMDA@tmda.severn.wwwdotorg.org>
References: <493EE81B.6000909@gmail.com>
	<1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<81487f820812101117t5e0b1d2cq13dbb7040cc181ef@mail.gmail.com>
	<1228938532.3863.46.camel@localhost.localdomain>
	<20081210234811.GA11018@zod.rchland.ibm.com>
	<ghpktm$vou$1@ger.gmane.org> <ghq7vu$5to$5@ger.gmane.org>
	<1228974732.17799.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <20081215204330.GB3700@hurricane.linuxnetz.de>

On Wed, 10 Dec 2008, Stephen Warren wrote:
> If it's a bugfix, backport it.

That's possible, if upstream is straight forward on a stable branch. Ever
had an upstream putting the bugfix into a development version, because the
software got developed further and the fix was done to already rewritten
code? Backporting gets a mess and lots of work then. This is something,
which better should left to people getting paid for that, such as some Red
Hat employees... ;-)


Greetings,
  Robert



From mw_triad at users.sourceforge.net  Mon Dec 15 20:50:49 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 15 Dec 2008 14:50:49 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <1229330605.24419.265.camel@lenovo.local.net>
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>	<49421D9C.8080307@nicubunu.ro>
	<4944A7AF.5060904@fedoraproject.org>	<4945FFF3.8050009@nicubunu.ro>	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<1229330605.24419.265.camel@lenovo.local.net>
Message-ID: <gi6fv9$rtq$1@ger.gmane.org>

Adam Williamson wrote:
> This is an important use case for DVD images.

I haven't seen anyone else mention an important use case of a Live DVD, 
namely, providing a complete experience to someone that is not familiar 
with Linux. So far, everyone is talking about Live CD's strictly as an 
install medium (which, admittedly, fits the subject of this thread). 
However my understanding of, and my primary use for, Live Media is "try 
before you buy".

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Me: wtf?? "#warning This is temporary since Dec 2000". Seven-year 
"temporary" code?
Mathieu Chouinard: Sounds like the correct definition of temporary :)



From nicolas.mailhot at laposte.net  Mon Dec 15 20:50:43 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Dec 2008 21:50:43 +0100
Subject: RFC: Description text in packages
In-Reply-To: <385866f0812151152y15bfeaam70e321c6d294997e@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<1229366077.3343.9.camel@matthiasc>
	<1229366539.25084.31.camel@arekh.okg>
	<385866f0812151152y15bfeaam70e321c6d294997e@mail.gmail.com>
Message-ID: <1229374243.27493.3.camel@arekh.okg>

Le lundi 15 d?cembre 2008 ? 21:52 +0200, Muayyad AlSadi a ?crit :
> > Question 1: Should we use '', "", or the UTF-8 quote characters? If we
> 
> for some crazy reason unicode has removed mirrored proprietary from quotes

It's not some crazy reason.
What you call left quote in ASCII was always defined as the grave
accent.
The grave accent was never a mirror of '. Some people abused it this
way. With unicode there was no reason for the abuse to continue so it
returned to its initial intended definition.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/ea338730/attachment.sig>

From vonbrand at inf.utfsm.cl  Mon Dec 15 21:00:41 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 15 Dec 2008 18:00:41 -0300
Subject: X taking upto 99% processor time
In-Reply-To: <1229354497.3343.7.camel@matthiasc>
References: <1229208496.5890.2.camel@PB3.Linux>
	<1229347508.11859.0.camel@localhost.localdomain>
	<1229354497.3343.7.camel@matthiasc>
Message-ID: <200812152100.mBFL0fcZ023090@laptop14.inf.utfsm.cl>

Matthias Clasen <mclasen at redhat.com> wrote:
> On Mon, 2008-12-15 at 14:25 +0100, Kjartan Maraas wrote:
> > l??., 13.12.2008 kl. 22.48 +0000, skrev Paul:
> > > Hi,
> > > 
> > > Anyone any ideas why X should be taking 99% of my available processor
> > > time? I'm using a dual core Intel x86 box with an nVidia graphics card
> > > (I'm using the default X driver for it, not the nasty proprietory one
> > > with it's nasty 3d acceleration and stuff ;-p)
> > > 
> > 
> > I asked the same thing on irc this weekend and was told it was
> > gnome-screensaver tickling some bug somewhere. Terminating
> > gnome-screensaver fixed it for me at least.
> > 
> 
> It was a bug in the SYNC extension. Ajax fixed it last week.

Packages with the fix? I don't want to lug too many old packages around...
-- 
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 nicolas.mailhot at laposte.net  Mon Dec 15 21:08:12 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Dec 2008 22:08:12 +0100
Subject: RFC: Description text in packages
In-Reply-To: <1229374243.27493.3.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<1229366077.3343.9.camel@matthiasc>
	<1229366539.25084.31.camel@arekh.okg>
	<385866f0812151152y15bfeaam70e321c6d294997e@mail.gmail.com>
	<1229374243.27493.3.camel@arekh.okg>
Message-ID: <1229375292.27867.1.camel@arekh.okg>

Le lundi 15 d?cembre 2008 ? 21:50 +0100, Nicolas Mailhot a ?crit :
> Le lundi 15 d?cembre 2008 ? 21:52 +0200, Muayyad AlSadi a ?crit :
> > > Question 1: Should we use '', "", or the UTF-8 quote characters? If we
> > 
> > for some crazy reason unicode has removed mirrored proprietary from quotes
> 
> It's not some crazy reason.
> What you call left quote in ASCII was defined as the grave
> accent.

(ISO TC 97/SC 2 meeting, October 29-31, 1963, according to
http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/ff545a8b/attachment.sig>

From ianweller at gmail.com  Mon Dec 15 21:17:27 2008
From: ianweller at gmail.com (Ian Weller)
Date: Mon, 15 Dec 2008 15:17:27 -0600
Subject: from fedora.client import Wiki
In-Reply-To: <20081215154245.GD3336@x300>
References: <20081215154245.GD3336@x300>
Message-ID: <20081215211727.GB14142@gmail.com>

On Mon, Dec 15, 2008 at 10:42:45AM -0500, Luke Macken wrote:
> http://lewk.org/blog/wiki
> 
\o/

[and cc'ing fedora-wiki]

-- 
Ian Weller <ianweller at gmail.com>                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/ddcfe912/attachment.sig>

From tgl at redhat.com  Mon Dec 15 21:24:27 2008
From: tgl at redhat.com (Tom Lane)
Date: Mon, 15 Dec 2008 16:24:27 -0500
Subject: NFS broken by recent Fedora 9 update?
Message-ID: <11986.1229376267@sss.pgh.pa.us>

Anyone else seeing $SUBJECT?  Both incoming and outgoing automounts
don't work for me anymore.  It times out in a way that makes me suspect
a firewall problem, but iptables doesn't seem to have been changed ...

			regards, tom lane



From robert at fedoraproject.org  Mon Dec 15 21:26:53 2008
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 15 Dec 2008 22:26:53 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <4946C0BF.5090202@fedoraproject.org>
References: <1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081215203251.GA3700@hurricane.linuxnetz.de>
	<4946C0BF.5090202@fedoraproject.org>
Message-ID: <20081215212653.GA12493@hurricane.linuxnetz.de>

On Tue, 16 Dec 2008, Rahul Sundaram wrote:
> Refer
>
> https://fedorahosted.org/bodhi/ticket/79

"Opened 1 year ago; Last modified 5 months ago" -> STALLED.

If I now shall believe, that this gets assigned and done, I need
to believe first that there's a Christ Child...sorry.


Greetings,
  Robert



From tibbs at math.uh.edu  Mon Dec 15 21:27:15 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 15 Dec 2008 15:27:15 -0600
Subject: NFS broken by recent Fedora 9 update?
In-Reply-To: <11986.1229376267@sss.pgh.pa.us>
References: <11986.1229376267@sss.pgh.pa.us>
Message-ID: <ufahc55164s.fsf@epithumia.math.uh.edu>

>>>>> "TL" == Tom Lane <tgl at redhat.com> writes:

TL> Anyone else seeing $SUBJECT?

Maybe the rpcbind update, which has been discussed in a few places
already?  You don't mention seeing any selinux denials in your
logs, so it's tough to tell, but if so then pulling the selinux
p0olicy packages from updates-testing should fix the issue.

 - J<



From pemboa at gmail.com  Mon Dec 15 21:41:23 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 15 Dec 2008 15:41:23 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <gi6fv9$rtq$1@ger.gmane.org>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<1229330605.24419.265.camel@lenovo.local.net>
	<gi6fv9$rtq$1@ger.gmane.org>
Message-ID: <16de708d0812151341j8a08819j67014b1b9369781@mail.gmail.com>

On Mon, Dec 15, 2008 at 2:50 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Adam Williamson wrote:
>>
>> This is an important use case for DVD images.
>
> I haven't seen anyone else mention an important use case of a Live DVD,
> namely, providing a complete experience to someone that is not familiar with
> Linux. So far, everyone is talking about Live CD's strictly as an install
> medium (which, admittedly, fits the subject of this thread). However my
> understanding of, and my primary use for, Live Media is "try before you
> buy".


My primary use for a Live DVD image is for installing to a USB drive.
Seriously, 9.99USD for a 4GB drive at MicroCenter USA.

And that need may disappear as soon as I learn to roll my own Live images.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From bruno at wolff.to  Mon Dec 15 21:48:59 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 15 Dec 2008 15:48:59 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812151341j8a08819j67014b1b9369781@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>
	<20081211181856.GB27793@localhost.localdomain>
	<49421D9C.8080307@nicubunu.ro> <4944A7AF.5060904@fedoraproject.org>
	<4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<1229330605.24419.265.camel@lenovo.local.net>
	<gi6fv9$rtq$1@ger.gmane.org>
	<16de708d0812151341j8a08819j67014b1b9369781@mail.gmail.com>
Message-ID: <20081215214859.GA3236@wolff.to>

On Mon, Dec 15, 2008 at 15:41:23 -0600,
  Arthur Pemberton <pemboa at gmail.com> wrote:
> 
> My primary use for a Live DVD image is for installing to a USB drive.
> Seriously, 9.99USD for a 4GB drive at MicroCenter USA.
> 
> And that need may disappear as soon as I learn to roll my own Live images.

livecd-creator is easy to use. Get a copy of Everything, updates and maybe
updates-testing (or alternatively rawhide). Install livecd-tools and
spin-kickstarts and you have what you need.
You can copy kickstart files from /usr/share/spin-kickstarts/ and edit
them to do what you want. Be sure to copy included files over or add the
full path in the ones you have copied. In particular you are going to want
fedora-live-base.ks and change the repos in it to point to your local
repos using file: urls.
I am working on getting the live games dvd back in shape for f11 and can
probably answer simple questions for you.



From opensource at till.name  Mon Dec 15 21:50:28 2008
From: opensource at till.name (Till Maas)
Date: Mon, 15 Dec 2008 22:50:28 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081215212653.GA12493@hurricane.linuxnetz.de>
References: <1228861426.30987.57.camel@code.and.org>
	<4946C0BF.5090202@fedoraproject.org>
	<20081215212653.GA12493@hurricane.linuxnetz.de>
Message-ID: <200812152250.40402.opensource@till.name>

On Mon December 15 2008, Robert Scheck wrote:
> On Tue, 16 Dec 2008, Rahul Sundaram wrote:
> > Refer
> >
> > https://fedorahosted.org/bodhi/ticket/79
>
> "Opened 1 year ago; Last modified 5 months ago" -> STALLED.
>
> If I now shall believe, that this gets assigned and done, I need
> to believe first that there's a Christ Child...sorry.

If you supply a working patch, it will probably applied pretty soon.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/f1867bf2/attachment.sig>

From konrad at tylerc.org  Mon Dec 15 22:03:40 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 15 Dec 2008 14:03:40 -0800
Subject: RFC: Description text in packages
In-Reply-To: <1229365091.25084.25.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
Message-ID: <200812151403.41097.konrad@tylerc.org>

On Monday 15 December 2008 10:18:11 am Nicolas Mailhot wrote:
> Le lundi 15 d?cembre 2008 ? 08:41 -0800, Toshio Kuratomi a ?crit :
> > Currently, I'm opposed to having a Guideline that mandates UTF-8 over
> > ASCII.
>
> And I'm opposed to continuing to abuse ASCII glyphs and pretend they
> stand for something other than their creators intended. One couldn't
> avoid it when the available encoding didn't provide a clean way to write
> some stuff, but doing it in 2008 is plain dumb.

Granted, UTF-8 glyphs can be abused as well; see %changelog in the following:

http://cvs.fedoraproject.org/viewvc/rpms/perl-Convert-UUlib/devel/perl-Convert-UUlib.spec?revision=1.21&view=markup
http://cvs.fedoraproject.org/viewvc/rpms/lzop/devel/lzop.spec?revision=1.14&view=markup

You even used two different glyphs for "fixed the license"!

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>





From konrad at tylerc.org  Mon Dec 15 22:06:00 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 15 Dec 2008 14:06:00 -0800
Subject: RFC: Description text in packages
In-Reply-To: <20081215175549.GA20204@amd.home.annexia.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<d9c612bf0812150947n5ec43896se873c6dd0f23fc9@mail.gmail.com>
	<20081215175549.GA20204@amd.home.annexia.org>
Message-ID: <200812151406.00638.konrad@tylerc.org>

On Monday 15 December 2008 09:55:49 am Richard W.M. Jones wrote:
> On Mon, Dec 15, 2008 at 09:47:40AM -0800, Christopher Stone wrote:
> > So, why not just go to the upstream website?  Spec file descriptions
> > are not the place to look for feature lists...
>
> Because I want to have 'yum search' do something useful and find those
> features.  eg. If I want a blog tool with spam filtering that's
> supported in Fedora, how do you propose to answer that question by
> going to a website?

Doesn't yum do OR searches by default still? That "feature" made searching for 
multiple terms pretty useless.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From nicolas.mailhot at laposte.net  Mon Dec 15 22:11:45 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Dec 2008 23:11:45 +0100
Subject: RFC: Description text in packages
In-Reply-To: <200812151403.41097.konrad@tylerc.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<200812151403.41097.konrad@tylerc.org>
Message-ID: <1229379105.28402.2.camel@arekh.okg>

Le lundi 15 d?cembre 2008 ? 14:03 -0800, Conrad Meyer a ?crit :

> Granted, UTF-8 glyphs can be abused as well; see %changelog in the following:

None of those are proeminently exposed to users in the default distro
installer and none of those pretend a glyph is something else than what
it was defined.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/c5ad48d1/attachment.sig>

From skvidal at fedoraproject.org  Mon Dec 15 22:12:13 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 15 Dec 2008 17:12:13 -0500 (EST)
Subject: RFC: Description text in packages
In-Reply-To: <200812151406.00638.konrad@tylerc.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<d9c612bf0812150947n5ec43896se873c6dd0f23fc9@mail.gmail.com>
	<20081215175549.GA20204@amd.home.annexia.org>
	<200812151406.00638.konrad@tylerc.org>
Message-ID: <alpine.LFD.2.00.0812151711280.5976@localhost.localdomain>



On Mon, 15 Dec 2008, Conrad Meyer wrote:

> On Monday 15 December 2008 09:55:49 am Richard W.M. Jones wrote:
>> On Mon, Dec 15, 2008 at 09:47:40AM -0800, Christopher Stone wrote:
>>> So, why not just go to the upstream website?  Spec file descriptions
>>> are not the place to look for feature lists...
>>
>> Because I want to have 'yum search' do something useful and find those
>> features.  eg. If I want a blog tool with spam filtering that's
>> supported in Fedora, how do you propose to answer that question by
>> going to a website?
>
> Doesn't yum do OR searches by default still? That "feature" made searching for
> multiple terms pretty useless.

No.

It does multiple term results like google does:
- items matching all the terms
- items matching most of the terms
- items matching any of the terms

-sv



From jkeating at redhat.com  Mon Dec 15 22:16:31 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 15 Dec 2008 14:16:31 -0800
Subject: RFC: Description text in packages
In-Reply-To: <200812151403.41097.konrad@tylerc.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<200812151403.41097.konrad@tylerc.org>
Message-ID: <1229379391.3518.11.camel@localhost.localdomain>

On Mon, 2008-12-15 at 14:03 -0800, Conrad Meyer wrote:
> Granted, UTF-8 glyphs can be abused as well; see %changelog in the
> following:
> 
> http://cvs.fedoraproject.org/viewvc/rpms/perl-Convert-UUlib/devel/perl-Convert-UUlib.spec?revision=1.21&view=markup
> http://cvs.fedoraproject.org/viewvc/rpms/lzop/devel/lzop.spec?revision=1.14&view=markup

Yeah, these always felt like "UTF-8 because I can!!"  not actually
adding value at all.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/cf2e17f4/attachment.sig>

From wwoods at redhat.com  Mon Dec 15 22:26:26 2008
From: wwoods at redhat.com (Will Woods)
Date: Mon, 15 Dec 2008 17:26:26 -0500
Subject: A way out of the update trap
In-Reply-To: <6d06ce20812141000q60b74d1ehc1379aeedbd9b2ca@mail.gmail.com>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
	<20081212195950.GA2866@free.fr>
	<604aa7910812121240q46058b61g98d329e250194797@mail.gmail.com>
	<6d06ce20812141000q60b74d1ehc1379aeedbd9b2ca@mail.gmail.com>
Message-ID: <1229379987.3388.25.camel@metroid.rdu.redhat.com>

On Sun, 2008-12-14 at 12:00 -0600, Jerry Amundson wrote:
> On Fri, Dec 12, 2008 at 2:40 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> > On Fri, Dec 12, 2008 at 10:59 AM, Patrice Dumas <pertusus at free.fr> wrote:
> >> I'd propose, more largely @code, @base and dependencies.
> >
> > I think that's too broad a target to start with and you don't have the
> > QA resourses in place to support a policy that broad.

Definitely too large.. but not by a lot.

> > Right now. I am asking us as a project to suck it up and identify a
> > top functionality priority and to live within our means as it comes to
> > existing QA expectations.

The informal Critical Path for current QA testing is: yum and its deps.

No matter how bad *other* things are broken, as long as yum works you
can 'yum update' and download fixes. But if yum breaks, you have a
Severity CFF issue [1].

Note that by "yum and its deps" I don't mean the actual "Requires:" on
the 'yum' package, I mean "everything required to have yum run
properly". So this includes stuff like - duh - networking. 

So, throw in NetworkManager and its deps. Like it or not, NetworkManager
is the default network management system, and if it doesn't work, we are
once again registering Severity CFF issues.

Since this discussion is about defining a *formal* critical path, I
propose the following:

Bootloader: grub (yaboot on ppc), kernel, and all dependent packages.
Networking: NetworkManager and all dependent packages.
Update system: yum and all dependent packages.

I *believe* that would pull in everything Patrice mentioned earlier
(e.g. kernel requires initscripts, mkinitrd, module-init-tools, etc.
mkinitrd requires lvm, e2fsprogs, bash, coreutils, etc.) and all those
things that are completely vital that sometimes we don't think about
(dbus, cough cough cough).

This will define our Tier-1 / Core / Critical Path / NTBFW[2] package
set, which should have some additional sanity checks / scrutiny applied
during updates, release testing, and so on.

-w

[1] Completely Fucking Fucked. A common QA term that I just now made up.
[2] Not To Be Fucked With. More QA parlance that I just now made up.[3]
[3] Us QA guys have dirty mouths. Or, at least, I do.[4]
[4] Oh come on. Show me a QA engineer who has *not* shouted curses so
vile as to cause scarring and/or spontaneous combustion in lab animals,
and I will show you a ticking time bomb of rage. Or a mute. Or someone
who is no fun at parties.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3153 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/2568c0f9/attachment.bin>

From alsadi at gmail.com  Mon Dec 15 22:27:45 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 16 Dec 2008 00:27:45 +0200
Subject: RFC: Description text in packages
In-Reply-To: <1229374243.27493.3.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<1229366077.3343.9.camel@matthiasc>
	<1229366539.25084.31.camel@arekh.okg>
	<385866f0812151152y15bfeaam70e321c6d294997e@mail.gmail.com>
	<1229374243.27493.3.camel@arekh.okg>
Message-ID: <385866f0812151427v10517fe0qcb68a054afbd13d@mail.gmail.com>

> It's not some crazy reason.
> What you call left quote in ASCII was always defined as the grave
> accent.
> The grave accent was never a mirror of '. Some people abused it this
> way. With unicode there was no reason for the abuse to continue so it
> returned to its initial intended definition.
>
> --
I was talking about U+2018-U+201F not grave accent
> so I suggest using "" quotes not any of U+2018-U+201F

U+2018 LEFT SINGLE QUOTATION MARK
U+2019 RIGHT SINGLE QUOTATION MARK
...
U+201C LEFT DOUBLE QUOTATION MARK
U+201D RIGHT DOUBLE QUOTATION MARK

they are mirrors of each other
they used to be so
before things went out of mind

and the typographic directed quotation marks U+2018 and U+2019 as in <
http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

this won't work because unicode no longer mark them as mirrors in
Arabic one should write
U+2019 then text then U+2018 ie. reversed because renderers no longer
mirror them



From ajax at redhat.com  Mon Dec 15 22:40:48 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 15 Dec 2008 17:40:48 -0500
Subject: X taking upto 99% processor time
In-Reply-To: <200812152100.mBFL0fcZ023090@laptop14.inf.utfsm.cl>
References: <1229208496.5890.2.camel@PB3.Linux>
	<1229347508.11859.0.camel@localhost.localdomain>
	<1229354497.3343.7.camel@matthiasc>
	<200812152100.mBFL0fcZ023090@laptop14.inf.utfsm.cl>
Message-ID: <1229380848.29700.195.camel@atropine.boston.devel.redhat.com>

On Mon, 2008-12-15 at 18:00 -0300, Horst H. von Brand wrote:
> Matthias Clasen <mclasen at redhat.com> wrote:
> > On Mon, 2008-12-15 at 14:25 +0100, Kjartan Maraas wrote:
> > > l?., 13.12.2008 kl. 22.48 +0000, skrev Paul:
> > > > Hi,
> > > > 
> > > > Anyone any ideas why X should be taking 99% of my available processor
> > > > time? I'm using a dual core Intel x86 box with an nVidia graphics card
> > > > (I'm using the default X driver for it, not the nasty proprietory one
> > > > with it's nasty 3d acceleration and stuff ;-p)
> > > > 
> > > 
> > > I asked the same thing on irc this weekend and was told it was
> > > gnome-screensaver tickling some bug somewhere. Terminating
> > > gnome-screensaver fixed it for me at least.
> > > 
> > 
> > It was a bug in the SYNC extension. Ajax fixed it last week.
> 
> Packages with the fix? I don't want to lug too many old packages around...

https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11200

Should get auto-promoted to stable shortly.

Don't think I built this for rawhide yet though.  Will fix.

- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/c32674ac/attachment.sig>

From ajax at redhat.com  Mon Dec 15 22:43:05 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 15 Dec 2008 17:43:05 -0500
Subject: RFC: Description text in packages
In-Reply-To: <1229355476.3432.89.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
Message-ID: <1229380985.29700.197.camel@atropine.boston.devel.redhat.com>

On Mon, 2008-12-15 at 15:37 +0000, Richard Hughes wrote:
> It seems many packagers have committed new summary text for their
> packages, and I thank you all for that.
> 
> Next on my list are insane descriptions. For instance, just take a look
> at the description for enlightenment (many pages in length) and various
> packages using ``quoting'' or ''quoting''. Many packages also try to do
> a bullet list using '*' or '-', usually with a random amount of spacing.
> 
> Question 1: Should we use '', "", or the UTF-8 quote characters? If we
> use LaTeX style ``double'' and `single' formatters then it's trivial for
> the session programs to either use ?? or ?? depending on the locale.

GNU is wrong and ` is not the mate of '.  '' or "" or utf8 quotes are
fine.

- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/da9df695/attachment.sig>

From paul at all-the-johnsons.co.uk  Mon Dec 15 23:15:00 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Mon, 15 Dec 2008 23:15:00 +0000
Subject: buildsys or mono at fault here
Message-ID: <1229382900.10450.10.camel@PB3.Linux>

Hi,

I keep getting the same fail from the x86_64 build system when trying to
build mono. Is the fault being seen down to mono or koji?

http://koji.fedoraproject.org/koji/getfile?taskID=1000973&name=build.log

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/be5a282c/attachment.sig>

From triad at df.lth.se  Mon Dec 15 23:34:05 2008
From: triad at df.lth.se (Linus Walleij)
Date: Tue, 16 Dec 2008 00:34:05 +0100
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <20081215202939.GE23506@nostromo.devel.redhat.com>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>
	<4943D18E.60107@BitWagon.com>
	<20081215202939.GE23506@nostromo.devel.redhat.com>
Message-ID: <1229384045.3919.29.camel@fecusia>

m?n 2008-12-15 klockan 15:29 -0500 skrev Bill Nottingham:

> Also, 'Electronics' seems vague ... 'Electronic Design'? 'EDA'?

"Electronic Design" is nice!

EDA is "Electronic Design Automation" the last word there was added in
the days when it was mostly not automated, i.e. when electronics was
drawn on vellum paper. So let's conclude we don't do that much anymore.

Linus



From opensource at till.name  Mon Dec 15 23:52:39 2008
From: opensource at till.name (Till Maas)
Date: Tue, 16 Dec 2008 00:52:39 +0100
Subject: Fedora GIS SIG
In-Reply-To: <1229277582.5977.23.camel@pali-desktop.lisilan.cz>
References: <1229271874.5977.9.camel@pali-desktop.lisilan.cz>
	<adf480660812140842t1b1d596cvede2bc2b7bce0bb7@mail.gmail.com>
	<1229277582.5977.23.camel@pali-desktop.lisilan.cz>
Message-ID: <200812160052.44310.opensource@till.name>

On Sun December 14 2008, Pavel Lis? wrote:
> Peter Lemenkov p??e v Ne 14. 12. 2008 v 19:42 +0300:

> > https://fedoraproject.org/wiki/GIS
>
> I know this place but there is no information about members or how to
> make first contact. Can anybody add it there?

You can use this mailinglist to discuss stuff, until there is a need for a 
separate mailinglist because of huge discussions. You can also add more GIS 
related packages or other information to the wiki page if you want. That's why 
it is a wiki. :-) 

Btw. I just noticed that someone added a package there that I submitted for 
review, but I just heard about this SIG for the first time.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/7b76ea53/attachment.sig>

From adamwill at shaw.ca  Tue Dec 16 00:08:17 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Mon, 15 Dec 2008 16:08:17 -0800
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
In-Reply-To: <20081215203251.GA3700@hurricane.linuxnetz.de>
References: <1228849604.30987.31.camel@code.and.org>
	<493EE81B.6000909@gmail.com> <1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081215203251.GA3700@hurricane.linuxnetz.de>
Message-ID: <1229386097.24419.310.camel@lenovo.local.net>

On Mon, 2008-12-15 at 21:32 +0100, Robert Scheck wrote:

> AFAIK glibc in Fedora 10 is still newer than in
> Rawhide currently.

As is gnome-panel, which is stopping me testing Rawhide until I get
sufficiently un-lazy to hack around it manually. There's some problems
with setools stuff trying to upgrade current updated F10 to Rawhide too,
but I didn't look into exactly what's going on there, yet.
-- 
adamw



From tgl at redhat.com  Tue Dec 16 00:16:49 2008
From: tgl at redhat.com (Tom Lane)
Date: Mon, 15 Dec 2008 19:16:49 -0500
Subject: NFS broken by recent Fedora 9 update? 
In-Reply-To: <ufahc55164s.fsf@epithumia.math.uh.edu> 
References: <11986.1229376267@sss.pgh.pa.us>
	<ufahc55164s.fsf@epithumia.math.uh.edu>
Message-ID: <14497.1229386609@sss.pgh.pa.us>

Jason L Tibbitts III <tibbs at math.uh.edu> writes:
> "TL" == Tom Lane <tgl at redhat.com> writes:
> TL> Anyone else seeing $SUBJECT?

> Maybe the rpcbind update, which has been discussed in a few places
> already?  You don't mention seeing any selinux denials in your
> logs, so it's tough to tell, but if so then pulling the selinux
> p0olicy packages from updates-testing should fix the issue.

Hmm ... nothing from selinux, but I do see several repetitions of this
when attempting an outbound automount:

Dec 15 19:06:14 rh2 kernel: rpcbind: server localhost not responding, timed out
Dec 15 19:06:14 rh2 kernel: RPC: failed to contact local rpcbind server (errno 5).

Nothing at all in /var/log/messages for an inbound automount, though.
[tries some other stuff ...]  Incoming afpd sessions not very happy
either.  I feel fortunate that I can still ssh into the box.

Grumble.  Why the heck are we doing major breakage in F9 rather than
rawhide, or at least F10 where people could expect some instability at
this point!?

			regards, tom lane



From mrmazda at ij.net  Tue Dec 16 00:43:17 2008
From: mrmazda at ij.net (Felix Miata)
Date: Mon, 15 Dec 2008 19:43:17 -0500
Subject: NFS broken by recent Fedora 9 update?
In-Reply-To: <14497.1229386609@sss.pgh.pa.us>
References: <11986.1229376267@sss.pgh.pa.us>	<ufahc55164s.fsf@epithumia.math.uh.edu>
	<14497.1229386609@sss.pgh.pa.us>
Message-ID: <4946F9A5.8000301@ij.net>

On 2008/12/15 19:16 (GMT-0500) Tom Lane composed:

> Jason L Tibbitts III <tibbs at math.uh.edu> writes:

>> Maybe the rpcbind update, which has been discussed in a few places
>> already?  You don't mention seeing any selinux denials in your
>> logs, so it's tough to tell, but if so then pulling the selinux
>> p0olicy packages from updates-testing should fix the issue.

> Hmm ... nothing from selinux, but I do see several repetitions of this
> when attempting an outbound automount:

> Dec 15 19:06:14 rh2 kernel: rpcbind: server localhost not responding, timed out
> Dec 15 19:06:14 rh2 kernel: RPC: failed to contact local rpcbind server (errno 5).

This happened in openSUSE when portmap was replaced with rpcbind because the
update did not turn rpcbind on.
https://bugzilla.novell.com/show_bug.cgi?id=431722

At almost exactly the same time, what seems to have been the same thing
happened on my Rawhide box. Turning rpcbind on only fixed openSUSE, not
Rawhide, and I have no idea how to get nfs to work again on that box. Sounds
like we both have same problem. :-(

> Nothing at all in /var/log/messages for an inbound automount, though.
> [tries some other stuff ...]  Incoming afpd sessions not very happy
> either.  I feel fortunate that I can still ssh into the box.

> Grumble.  Why the heck are we doing major breakage in F9 rather than
> rawhide, or at least F10 where people could expect some instability at
> this point!?

I didn't file or find a Fedora bug about it. I figured surely someone else
would find something so important and an update would show up before F10
release. :-(
-- 
"Unless the Lord builds the house, its builders labor
in vain."			Psalm 127:1 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From ghosler at redhat.com  Tue Dec 16 01:01:57 2008
From: ghosler at redhat.com (Gregory Hosler)
Date: Tue, 16 Dec 2008 09:01:57 +0800
Subject: Broken dependencies in Fedora 10 - 2008-12-14
In-Reply-To: <20081215144104.b4aec581.mschwendt@gmail.com>
References: <20081214172129.17830.82330@faldor.intranet>	<49464DB6.4040602@fedoraproject.org>	<20081215134948.44dc2305.mschwendt@gmail.com>	<4946558A.3060105@fedoraproject.org>
	<20081215144104.b4aec581.mschwendt@gmail.com>
Message-ID: <4946FE05.9010506@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Schwendt wrote:
> On Mon, 15 Dec 2008 18:33:06 +0530, Rahul wrote:
> 
>>> Btw, the wrong Obsoletes in gyachi have been discussed in private mail.
>>> I'm unsure whether the packager has understood the problem and the fix.
>> It appears he does but he seems offline for a couple of weeks. He also 
>> told me, you had informed him that the issue isn't a urgent priority. Is 
>> that because the updates are in testing repository?
> 
> No, they have been marked stable after just three hours in testing.
> 
> The first attempt at fixing it was half-hearted.

I'm not sure I would agree with "half hearted", but I'll not argue that it was
not well tested.

Since then, I have a better spec file, which I HAVE tested, for both backward
and forward compatibility. I tested it out on my home system, just right before
the current 2 week offsite that I am now engaged in. I did not want to commit
it, and then not be there for immediate follow up (should the need arise). Since
the current commit was broken, but in a known way, I made the decision to not
introduce my new commit until I get back (which will be the 22nd).

Hope that clarifies.

All the best,

- -Greg

> That's when I said:
> 
> | Take your time. Don't rush. The current commit in cvs is insufficient.
> 
> Without taking the time to fully understand RPM Obsoletes,
> Obsoletes+Provides pairs and how they are entered into a spec file, the
> problem will return sooner or late. Either that or -- almost guaranteed --
> the %dist pitfall will be hit.
> 


- --
+---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information.
                (from /var/log/Xorg.setup.log)

| Greg Hosler                                   ghosler at redhat.com    |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklG/gMACgkQ404fl/0CV/TsTACg0AJv5gStXfAclRSHascHqfid
4jUAoLlFrb4BBUcEfa+IB5X/103zy55L
=VplS
-----END PGP SIGNATURE-----



From jkeating at redhat.com  Tue Dec 16 01:12:38 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 15 Dec 2008 17:12:38 -0800
Subject: Coordination of updates and reading of bodhi comments
Message-ID: <1229389958.3518.21.camel@localhost.localdomain>

Here is another example where maintainers need to coordinate more and
pay attention.

https://admin.fedoraproject.org/updates/F9/FEDORA-2008-10000
(rpcbind-0.1.7-1.fc9) went into Fedora 9 updates testing on 11-22.  On
the 25th bodhi feedback showed that this requires selinux changes.

https://admin.fedoraproject.org/updates/F9/FEDORA-2008-11122
(selinux-policy-3.3.1-115.fc9) went into Fedora 9 updates testing on
12-10.  This was the build to fix rpcbind.

On 12-10 rpcbind was submitted for stable.  On the same day, bodhi
feedback requested that this update not go out until the matching
selinux-policy went out to stable.

On 12-11 rpcbind went into stable.

selinux-policy remained in -testing, until 12-15 (today) when it was
obsoleted by a newer policy, which is also going into -testing.

This means our F9 users on a supposedly stable release will have
non-functional rpcbind (and dependent software) until at least sometime
late tomorrow (today's push is still going, won't start another one for
at least another 15 hours.

This could have easily been solved if the maintainers for rpcbind and
selinux-policy worked together to ensure that the updates went to the
same places at the same time.

In the future, please do be aware if your update requires fixes in
something else, that everything goes together in lock step.

mgrepl, can you request the latest -policy go to stable so that F9 users
can get the proper fixes as soon as possible?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/6f872cb7/attachment.sig>

From mw_triad at users.sourceforge.net  Tue Dec 16 01:16:22 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 15 Dec 2008 19:16:22 -0600
Subject: RFC: Description text in packages
In-Reply-To: <1229365091.25084.25.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>	<494688AA.8060505@gmail.com>
	<1229365091.25084.25.camel@arekh.okg>
Message-ID: <gi6vh6$cpr$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Le lundi 15 d?cembre 2008 ? 08:41 -0800, Toshio Kuratomi a ?crit :
>> Currently, I'm opposed to having a Guideline that mandates UTF-8 over
>> ASCII.
> 
> And I'm opposed to continuing to abuse ASCII glyphs and pretend they
> stand for something other than their creators intended. One couldn't
> avoid it when the available encoding didn't provide a clean way to write
> some stuff, but doing it in 2008 is plain dumb.

I must have missed the 'fancy quotes' keys on my keyboard. Not to 
mention that ?? don't seem to be in any of the fonts I'm using 
(newsreader, terminal, FF's text entry box...) and therefore show up as 
ugly boxes.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Me: wtf?? "#warning This is temporary since Dec 2000". Seven-year 
"temporary" code?
Mathieu Chouinard: Sounds like the correct definition of temporary :)



From jamundso at gmail.com  Tue Dec 16 01:26:28 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Mon, 15 Dec 2008 19:26:28 -0600
Subject: NFS broken by recent Fedora 9 update?
In-Reply-To: <4946F9A5.8000301@ij.net>
References: <11986.1229376267@sss.pgh.pa.us>
	<ufahc55164s.fsf@epithumia.math.uh.edu>
	<14497.1229386609@sss.pgh.pa.us> <4946F9A5.8000301@ij.net>
Message-ID: <6d06ce20812151726m31fff10cl9b51593941c417d3@mail.gmail.com>

On Mon, Dec 15, 2008 at 6:43 PM, Felix Miata <mrmazda at ij.net> wrote:
> On 2008/12/15 19:16 (GMT-0500) Tom Lane composed:
>
>> Jason L Tibbitts III <tibbs at math.uh.edu> writes:
>> Grumble.  Why the heck are we doing major breakage in F9 rather than
>> rawhide, or at least F10 where people could expect some instability at
>> this point!?
>
> I didn't file or find a Fedora bug about it. I figured surely someone else
> would find something so important and an update would show up before F10
> release. :-(

In case it was missed, note jkeating's very recent post "Coordination
of updates and reading of bodhi comments".

jerry

-- 
To be named later.



From cra at WPI.EDU  Tue Dec 16 01:51:18 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 15 Dec 2008 20:51:18 -0500
Subject: A way out of the update trap
In-Reply-To: <1229379987.3388.25.camel@metroid.rdu.redhat.com>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
	<20081212195950.GA2866@free.fr>
	<604aa7910812121240q46058b61g98d329e250194797@mail.gmail.com>
	<6d06ce20812141000q60b74d1ehc1379aeedbd9b2ca@mail.gmail.com>
	<1229379987.3388.25.camel@metroid.rdu.redhat.com>
Message-ID: <20081216015118.GF32016@angus.ind.WPI.EDU>

On Mon, Dec 15, 2008 at 05:26:26PM -0500, Will Woods wrote:
> [4] Oh come on. Show me a QA engineer who has *not* shouted curses so
> vile as to cause scarring and/or spontaneous combustion in lab animals,
> and I will show you a ticking time bomb of rage. Or a mute. Or someone
> who is no fun at parties.

Usually it's the programmers/developers/engineers that shout curses at 
the QA guy when he tells them their product is fucked.



From tgl at redhat.com  Tue Dec 16 01:52:45 2008
From: tgl at redhat.com (Tom Lane)
Date: Mon, 15 Dec 2008 20:52:45 -0500
Subject: NFS broken by recent Fedora 9 update? 
In-Reply-To: <6d06ce20812151726m31fff10cl9b51593941c417d3@mail.gmail.com> 
References: <11986.1229376267@sss.pgh.pa.us>
	<ufahc55164s.fsf@epithumia.math.uh.edu>
	<14497.1229386609@sss.pgh.pa.us> <4946F9A5.8000301@ij.net>
	<6d06ce20812151726m31fff10cl9b51593941c417d3@mail.gmail.com>
Message-ID: <17182.1229392365@sss.pgh.pa.us>

"Jerry Amundson" <jamundso at gmail.com> writes:
> In case it was missed, note jkeating's very recent post "Coordination
> of updates and reading of bodhi comments".

Yeah, that may explain it.  At first I didn't think it was selinux,
because of the lack of any selinux complaints in my logs.  However,
looking back to the last boot found

Dec 14 19:21:46 rh2 rpcbind: setgid to 'rpc' (32) failed: Operation not permitted
Dec 14 19:21:48 rh2 setroubleshoot: SELinux is preventing rpcbind (rpcbind_t) "setgid" rpcbind_t. For complete SELinux messages. run sealert -l 2e7e0f7b-d206-4999-a02c-91bf0cc9d1e2

For anyone who needs a fix right now, I can confirm that reverting
rpcbind to rpcbind-0.1.4-14.fc9 (the latest prior version I could find
on the download servers) makes the NFS and AFP problems go away.

			regards, tom lane



From silfreed at silfreed.net  Tue Dec 16 03:00:16 2008
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Mon, 15 Dec 2008 22:00:16 -0500
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <1229389958.3518.21.camel@localhost.localdomain>
References: <1229389958.3518.21.camel@localhost.localdomain>
Message-ID: <494719C0.9020307@silfreed.net>

Jesse Keating wrote:
> This could have easily been solved if the maintainers for rpcbind and
> selinux-policy worked together to ensure that the updates went to the
> same places at the same time.
> 
> In the future, please do be aware if your update requires fixes in
> something else, that everything goes together in lock step.

This would probably be better if it was easier to contact other packagers. 
Filing bugs to ask questions is painful, but so is finding contact information.
For example, the user info page in pkgdb is empty [1]; having basic contact 
info here would be a huge improvement.  The best alternative I know if is to 
go look in the changelogs in the CVS web frontend.

-Doug

[1] https://admin.fedoraproject.org/pkgdb/users/info/silfreed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/0c227489/attachment.sig>

From orion at cora.nwra.com  Tue Dec 16 03:32:26 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 15 Dec 2008 20:32:26 -0700 (MST)
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <494719C0.9020307@silfreed.net>
References: <1229389958.3518.21.camel@localhost.localdomain>
	<494719C0.9020307@silfreed.net>
Message-ID: <3541.71.208.67.249.1229398346.squirrel@www.cora.nwra.com>


On Mon, December 15, 2008 8:00 pm, Douglas E. Warner wrote:
> This would probably be better if it was easier to contact other packagers.
> Filing bugs to ask questions is painful, but so is finding contact
> information.
> For example, the user info page in pkgdb is empty [1]; having basic
> contact
> info here would be a huge improvement.  The best alternative I know if is
> to
> go look in the changelogs in the CVS web frontend.
>
> -Doug
>
> [1] https://admin.fedoraproject.org/pkgdb/users/info/silfreed

There is <package>-owner at fedoraproject.org.  Needs more advertising?

-- 
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 tibbs at math.uh.edu  Tue Dec 16 03:35:54 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 15 Dec 2008 21:35:54 -0600
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <494719C0.9020307@silfreed.net>
References: <1229389958.3518.21.camel@localhost.localdomain>
	<494719C0.9020307@silfreed.net>
Message-ID: <ufamyewlrl1.fsf@epithumia.math.uh.edu>

>>>>> "DEW" == Douglas E Warner <silfreed at silfreed.net> writes:

DEW> Filing bugs to ask questions is painful, but so is finding
DEW> contact information.

Really?  package-owner at fedoraproject.org should work for every package
in the distro.  If it doesn't, please report it.

 - J<



From skvidal at fedoraproject.org  Tue Dec 16 03:38:31 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 15 Dec 2008 22:38:31 -0500 (EST)
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <494719C0.9020307@silfreed.net>
References: <1229389958.3518.21.camel@localhost.localdomain>
	<494719C0.9020307@silfreed.net>
Message-ID: <alpine.LFD.2.00.0812152238260.8181@localhost.localdomain>



On Mon, 15 Dec 2008, Douglas E. Warner wrote:

> Jesse Keating wrote:
>> This could have easily been solved if the maintainers for rpcbind and
>> selinux-policy worked together to ensure that the updates went to the
>> same places at the same time.
>> 
>> In the future, please do be aware if your update requires fixes in
>> something else, that everything goes together in lock step.
>
> This would probably be better if it was easier to contact other packagers. 
> Filing bugs to ask questions is painful, but so is finding contact 
> information.
> For example, the user info page in pkgdb is empty [1]; having basic contact 
> info here would be a huge improvement.  The best alternative I know if is to 
> go look in the changelogs in the CVS web frontend.
>

emailing packagename-owner at fedoraproject.org will work.

-sv



From jkeating at redhat.com  Tue Dec 16 05:13:46 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 15 Dec 2008 21:13:46 -0800
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
Message-ID: <1229404426.3518.25.camel@localhost.localdomain>

On Tue, 2008-12-16 at 03:35 +0000, updates at fedoraproject.org wrote:
> dchen has requested the pushing of the following update to testing:
> 
> ================================================================================
>      libchewing-0.3.2-0.fc8
> ================================================================================
>     Release: Fedora 8
>      Status: pending
>        Type: bugfix
>       Karma: 0
>     Request: testing
>       Notes: Upstream update
>   Submitter: dchen
>   Submitted: 2008-12-16 03:35:37
>    Comments: dchen - 2008-12-16 03:35:38 (karma 0)
>              This update has been submitted for testing
> 
>   http://admin.fedoraproject.org/updates/libchewing-0.3.2-0.fc8
> 
What is the purpose of this version bump (0.3.1 -> 0.3.2) in F8, which
only has a few weeks of lifespan yet.  There is no information in the
update request that would help users understand why they should consume
this update.  Please fill in some details, and consider whether the
update is suitable for Fedora 8.
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/c283adba/attachment.sig>

From jkeating at redhat.com  Tue Dec 16 05:15:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 15 Dec 2008 21:15:25 -0800
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <494719C0.9020307@silfreed.net>
References: <1229389958.3518.21.camel@localhost.localdomain>
	<494719C0.9020307@silfreed.net>
Message-ID: <1229404525.3518.26.camel@localhost.localdomain>

On Mon, 2008-12-15 at 22:00 -0500, Douglas E. Warner wrote:
> 
> This would probably be better if it was easier to contact other packagers. 
> Filing bugs to ask questions is painful, but so is finding contact information.
> For example, the user info page in pkgdb is empty [1]; having basic contact 
> info here would be a huge improvement.  The best alternative I know if is to 
> go look in the changelogs in the CVS web frontend.
> 
> -Doug
> 
> [1] https://admin.fedoraproject.org/pkgdb/users/info/silfreed

As others have mentioned, package-owner at fedoraproject.org  Or since you
seem to already have username information, user at fedoraproject.org works
as well.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/c189a07c/attachment.sig>

From konrad at tylerc.org  Tue Dec 16 05:16:39 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 15 Dec 2008 21:16:39 -0800
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <1229404426.3518.25.camel@localhost.localdomain>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<1229404426.3518.25.camel@localhost.localdomain>
Message-ID: <200812152116.39354.konrad@tylerc.org>

On Monday 15 December 2008 09:13:46 pm Jesse Keating wrote:
> On Tue, 2008-12-16 at 03:35 +0000, updates at fedoraproject.org wrote:
> > dchen has requested the pushing of the following update to testing:
> >
> > =========================================================================
> >======= libchewing-0.3.2-0.fc8
> > =========================================================================
> >======= Release: Fedora 8
> >      Status: pending
> >        Type: bugfix
> >       Karma: 0
> >     Request: testing
> >       Notes: Upstream update
> >   Submitter: dchen
> >   Submitted: 2008-12-16 03:35:37
> >    Comments: dchen - 2008-12-16 03:35:38 (karma 0)
> >              This update has been submitted for testing
> >
> >   http://admin.fedoraproject.org/updates/libchewing-0.3.2-0.fc8
>
> What is the purpose of this version bump (0.3.1 -> 0.3.2) in F8, which
> only has a few weeks of lifespan yet.  There is no information in the
> update request that would help users understand why they should consume
> this update.  Please fill in some details, and consider whether the
> update is suitable for Fedora 8.
> http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#M
>aintain_stability_for_users

Do these really need to go to the list? It seems more like public humiliation 
than constructive advice.

-- 
Conrad Meyer <konrad at tylerc.org>




From jkeating at redhat.com  Tue Dec 16 05:23:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 15 Dec 2008 21:23:53 -0800
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <200812152116.39354.konrad@tylerc.org>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<1229404426.3518.25.camel@localhost.localdomain>
	<200812152116.39354.konrad@tylerc.org>
Message-ID: <1229405033.3518.27.camel@localhost.localdomain>

On Mon, 2008-12-15 at 21:16 -0800, Conrad Meyer wrote:
> 
> Do these really need to go to the list? It seems more like public humiliation 
> than constructive advice.

It's peer review.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/f6d34b6b/attachment.sig>

From fedora at leemhuis.info  Tue Dec 16 05:57:41 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 16 Dec 2008 06:57:41 +0100
Subject: RFC: Description text in packages
In-Reply-To: <1229355476.3432.89.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
Message-ID: <49474355.6000703@leemhuis.info>

On 15.12.2008 16:37, Richard Hughes wrote:
> [...]
> Next on my list are insane descriptions. For instance, just take a look
> at the description for enlightenment (many pages in length) 

FYI, this was noticed, reported, discussed and forgotten again:
https://www.redhat.com/archives/fedora-packaging/2008-September/msg00011.html

 > [...]

CU
knurd



From mtasaka at ioa.s.u-tokyo.ac.jp  Tue Dec 16 06:01:02 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Tue, 16 Dec 2008 15:01:02 +0900
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <1229405033.3518.27.camel@localhost.localdomain>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>	<1229404426.3518.25.camel@localhost.localdomain>	<200812152116.39354.konrad@tylerc.org>
	<1229405033.3518.27.camel@localhost.localdomain>
Message-ID: <4947441E.90600@ioa.s.u-tokyo.ac.jp>

Jesse Keating wrote, at 12/16/2008 02:23 PM +9:00:
> On Mon, 2008-12-15 at 21:16 -0800, Conrad Meyer wrote:
>> Do these really need to go to the list? It seems more like public humiliation 
>> than constructive advice.
> 
> It's peer review.

I also think that this is not just a advice but rather a 
criticism on public space

Mamoru



From mike at cchtml.com  Tue Dec 16 06:10:38 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Tue, 16 Dec 2008 00:10:38 -0600
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <4947441E.90600@ioa.s.u-tokyo.ac.jp>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>	<1229404426.3518.25.camel@localhost.localdomain>	<200812152116.39354.konrad@tylerc.org>	<1229405033.3518.27.camel@localhost.localdomain>
	<4947441E.90600@ioa.s.u-tokyo.ac.jp>
Message-ID: <4947465E.1040102@cchtml.com>

Mamoru Tasaka wrote:
> I also think that this is not just a advice but rather a criticism on 
> public space
>
> Mamoru
>

Fedora is already filled to the brim with people cuddling each other. It 
really must stop somewhere or else the package system will get worse and 
worse and worse...

If you can't take a simple e-mail review question, you shouldn't be in 
charge of packaging, in my humble opinion. Yes, you're giving your time 
and effort for free, but you're left in charge of a big responsibility 
to provide a safe and half-way stable environment.



From konrad at tylerc.org  Tue Dec 16 06:14:13 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 15 Dec 2008 22:14:13 -0800
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <4947465E.1040102@cchtml.com>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<4947441E.90600@ioa.s.u-tokyo.ac.jp> <4947465E.1040102@cchtml.com>
Message-ID: <200812152214.14035.konrad@tylerc.org>

On Monday 15 December 2008 10:10:38 pm Michael Cronenworth wrote:
> Mamoru Tasaka wrote:
> > I also think that this is not just a advice but rather a criticism on
> > public space
> >
> > Mamoru
>
> Fedora is already filled to the brim with people cuddling each other. It
> really must stop somewhere or else the package system will get worse and
> worse and worse...

What? Fedora is filled with a ridiculous amount of in-fighting. And "the 
packaging system" has nothing to do with sending an email to just the 
maintainer, or also CC'ing a public mailing list.

> If you can't take a simple e-mail review question, you shouldn't be in
> charge of packaging, in my humble opinion. Yes, you're giving your time
> and effort for free, but you're left in charge of a big responsibility
> to provide a safe and half-way stable environment.

I'm not asking Jesse not to email the maintainer, just to do it off-list.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From petersen at redhat.com  Tue Dec 16 07:10:16 2008
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 16 Dec 2008 02:10:16 -0500 (EST)
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <1229405033.3518.27.camel@localhost.localdomain>
Message-ID: <872091706.371881229411416892.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

How about locking the tag for security updates only near EOL?
Otherwise these kind of things are kind of bound to happen I guess.

Jens



From mclasen at redhat.com  Tue Dec 16 07:11:08 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 16 Dec 2008 02:11:08 -0500
Subject: nautilus depends on a lot of stuff via gvfs
In-Reply-To: <1228900250.3616.21.camel@eagle.danny.cz>
References: <1228818420.3626.52.camel@eagle.danny.cz>
	<1228871905.24963.646.camel@cookie.hadess.net>
	<1228873368.7475.5.camel@matthiasc>
	<1228900250.3616.21.camel@eagle.danny.cz>
Message-ID: <1229411468.27938.0.camel@localhost.localdomain>

On Wed, 2008-12-10 at 10:10 +0100, Dan Hor?k wrote:
> Matthias Clasen p??e v ?t 09. 12. 2008 v 20:42 -0500:
> > On Wed, 2008-12-10 at 01:18 +0000, Bastien Nocera wrote:
> > 
> > > > 
> > > > So my proposal is to split nautilus into nautilus-core, that will
> > > > contains the content of the current nautilus package, and nautilus
> > > > "meta" package that will contains all the dependencies plus dependency
> > > > on nautilus-core. This solution will install all the deps as today, but
> > > > leave the option to remove the unnecessary packages afterwards.
> > > > 
> > > > Only 3 packages will be affected with this split
> > > > nautilus-devel
> > > > nautilus-python
> > > > seahorse-plugins
> > > > and they should be made to depend on nautilus-core instead of nautilus.
> > > > 
> > > > I will file a bug with the proposed change to nautilus spec file.
> > > 
> > > That's not workable. You'd probably rather rejigger the samba packages
> > > so it's possible to use Samba in any appropriate environment without
> > > dragging in the server, or the excessively big packages. You should do
> > > the same for other dependencies.
> > > 
> > > Removing functionality from nautilus as it is installed by default won't
> > > fix that problem.
> > 
> > Fwiw, I don't think it is a big problem to change things so that gvfs
> > subpackages are pulled in by comps instead of by hard deps from
> > nautilus, as long as they are all in the default install. I don't
> > introducing a nautilus metapackage for this purpose is necessary or a
> > good idea. 
> > 
> 
> Yes, pulling the deps via comps could be a nice solution.

Done, in 2.25.2-1



From harald at redhat.com  Tue Dec 16 07:14:02 2008
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 16 Dec 2008 08:14:02 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49467E08.2080806@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <49467E08.2080806@redhat.com>
Message-ID: <4947553A.1090807@redhat.com>

Eric Sandeen wrote:
> Harald Hoyer wrote:
>> So all in all we have nearly accomplished the 30 Second Startup Feature 
>> http://fedoraproject.org/wiki/Features/30SecondStartup.
> 
> Well, no; not if this requires data=writeback.  We can't ship that way,
> it's a potential security hole.  You don't want someone's maildir
> suddenly containing pieces of /etc/shadow or whatnot.  The old data that
> may be exposed by data=writeback may not belong to that user.

For my single user desktop with an encrypted filesystem, it makes no difference 
from a security standpoint. Even the pieces of /etc/shadow would be encrypted 
and only I can enter the decryption password after a (power?) failure.



From mclasen at redhat.com  Tue Dec 16 07:15:31 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 16 Dec 2008 02:15:31 -0500
Subject: eel2 is going away
Message-ID: <1229411731.27938.5.camel@localhost.localdomain>

eel2 has been merged back into nautilus, and will no longer be available
as a separate library. I've added an Obsoletes to the nautilus package.

This only affects a handful of packages, and for most of them a simple
rebuild should suffice:

$repoquery -q --whatrequires libeel-2.so.2
nautilus-python-0:0.5.1-1.fc10.i386
control-center-1:2.24.0.1-9.fc10.i386
nautilus-cd-burner-0:2.24.0-1.fc10.i386
nautilus-share-0:0.7.2-13.fc10.i386
gnome-translate-0:0.99-12.fc9.i386
nautilus-search-tool-0:0.2.2-4.fc10.i386


Matthias



From jkeating at redhat.com  Tue Dec 16 07:25:02 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 15 Dec 2008 23:25:02 -0800
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <200812152214.14035.konrad@tylerc.org>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<4947441E.90600@ioa.s.u-tokyo.ac.jp> <4947465E.1040102@cchtml.com>
	<200812152214.14035.konrad@tylerc.org>
Message-ID: <1229412302.3518.30.camel@localhost.localdomain>

On Mon, 2008-12-15 at 22:14 -0800, Conrad Meyer wrote:
> I'm not asking Jesse not to email the maintainer, just to do it
> off-list.

By asking on list, I'm providing the conversation in an open and public
way.  I'm also helping to remind others of what to do when preparing
their own updates.

To paraphrase a good friend: I mean where would open source be if people
just openly complained about other people's #*^$$!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/279115a1/attachment.sig>

From jkeating at redhat.com  Tue Dec 16 07:26:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 15 Dec 2008 23:26:25 -0800
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <1229412302.3518.30.camel@localhost.localdomain>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<4947441E.90600@ioa.s.u-tokyo.ac.jp> <4947465E.1040102@cchtml.com>
	<200812152214.14035.konrad@tylerc.org>
	<1229412302.3518.30.camel@localhost.localdomain>
Message-ID: <1229412385.3518.31.camel@localhost.localdomain>

On Mon, 2008-12-15 at 23:25 -0800, Jesse Keating wrote:
> By asking on list, I'm providing the conversation in an open and public
> way.  I'm also helping to remind others of what to do when preparing
> their own updates.

I'll also note that I've yet to receive a reply, of any kind, from any
of the maintainers or co-maintainers of the software, nor the
maintainer's sponsor.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081215/5697beb4/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Dec 16 07:38:57 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 08:38:57 +0100
Subject: RFC: Description text in packages
In-Reply-To: <gi6vh6$cpr$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<gi6vh6$cpr$1@ger.gmane.org>
Message-ID: <1229413137.7794.1.camel@arekh.okg>

Le lundi 15 d?cembre 2008 ? 19:16 -0600, Matthew Woehlke a ?crit :
> Nicolas Mailhot wrote:
> > Le lundi 15 d?cembre 2008 ? 08:41 -0800, Toshio Kuratomi a ?crit :
> >> Currently, I'm opposed to having a Guideline that mandates UTF-8 over
> >> ASCII.
> > 
> > And I'm opposed to continuing to abuse ASCII glyphs and pretend they
> > stand for something other than their creators intended. One couldn't
> > avoid it when the available encoding didn't provide a clean way to write
> > some stuff, but doing it in 2008 is plain dumb.
> 
> I must have missed the 'fancy quotes' keys on my keyboard.

Complain to your xkb maintainer. Mine has ????????


-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/837a4949/attachment.sig>

From nicu_fedora at nicubunu.ro  Tue Dec 16 08:05:34 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Tue, 16 Dec 2008 10:05:34 +0200
Subject: Installing from Live CD is the new black?
In-Reply-To: <16de708d0812150846l74a50efaxc4ff30cb633b7734@mail.gmail.com>
References: <1228955078.3037.10.camel@fecusia>	<20081211181856.GB27793@localhost.localdomain>	<49421D9C.8080307@nicubunu.ro>
	<4944A7AF.5060904@fedoraproject.org>	<4945FFF3.8050009@nicubunu.ro>	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>	<1229330605.24419.265.camel@lenovo.local.net>	<16de708d0812150046j4073b8b3i8cd602ec111bea3f@mail.gmail.com>	<494624C6.9070409@nicubunu.ro>
	<16de708d0812150846l74a50efaxc4ff30cb633b7734@mail.gmail.com>
Message-ID: <4947614E.3070806@nicubunu.ro>

Arthur Pemberton wrote:
> On Mon, Dec 15, 2008 at 3:35 AM, Nicu Buculei wrote:
>> Arthur Pemberton wrote:
>>> Of course it is an important use case. No one is saying DVD installs
>>> are useless. However if you have the bandwith to dload the DVD image
>>> yourself, it is a lot more efficient to dload a live CD and install
>>> from that.
>> No if:
>> - you want a downtime as small as possible.
> 
> I fail to see how this is true with a DVD install. But this really

Installing from a DVD your downtime is only during the install from 
media, installing from a Live CD the downtime is during the install from 
media *and* the yum install of all the applications you need to do the 
real work.
What good is a desktop without applications?

> isn't that important as no one is trying to take away DVD installs.

Fortunately no, but a bit earlier in the thread we have seen such wishes.

-- 
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 dchen at redhat.com  Tue Dec 16 08:07:33 2008
From: dchen at redhat.com (Ding Yi Chen)
Date: Tue, 16 Dec 2008 03:07:33 -0500 (EST)
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <1490171691.458211229414724532.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <717912397.458301229414853161.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>

Hi,
I am the maintainer of libchewing, sorry my package causes some trouble here.

The reason I do the updating at this moment is I received the upstream update a couple weeks ago,
and merely reflecting upstream update, since it is still in the lifespan.

I've posted the detail changelog in bodhi if you are interested.

IMHO, I see no reason why it cannot be updated in F-8, but I will follow the policy and drop the update
if necessary. Should we have soft/hard deadline for legacy update?

BTW, I don't track the fedora-devel list everyday, so please cc to my mailbox.

Regards,

Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.

----- "Jesse Keating" <jkeating at redhat.com> wrote:

> On Mon, 2008-12-15 at 23:25 -0800, Jesse Keating wrote:
> > By asking on list, I'm providing the conversation in an open and
> public
> > way.  I'm also helping to remind others of what to do when
> preparing
> > their own updates.
> 
> I'll also note that I've yet to receive a reply, of any kind, from
> any
> of the maintainers or co-maintainers of the software, nor the
> maintainer's sponsor.
> 
> -- 
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From kevin.kofler at chello.at  Tue Dec 16 08:22:07 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 16 Dec 2008 09:22:07 +0100
Subject: buildsys or mono at fault here
References: <1229382900.10450.10.camel@PB3.Linux>
Message-ID: <gi7off$48v$1@ger.gmane.org>

Paul wrote:
> I keep getting the same fail from the x86_64 build system when trying to
> build mono. Is the fault being seen down to mono or koji?
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=1000973&name=build.log

Looks pretty clearly like a Mono bug, it's trying to free an invalid
pointer.

        Kevin Kofler



From pemboa at gmail.com  Tue Dec 16 08:27:01 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 16 Dec 2008 02:27:01 -0600
Subject: Installing from Live CD is the new black?
In-Reply-To: <4947614E.3070806@nicubunu.ro>
References: <1228955078.3037.10.camel@fecusia> <49421D9C.8080307@nicubunu.ro>
	<4944A7AF.5060904@fedoraproject.org> <4945FFF3.8050009@nicubunu.ro>
	<6d06ce20812142319j652b2e52ue159ef4af03922ae@mail.gmail.com>
	<1229330605.24419.265.camel@lenovo.local.net>
	<16de708d0812150046j4073b8b3i8cd602ec111bea3f@mail.gmail.com>
	<494624C6.9070409@nicubunu.ro>
	<16de708d0812150846l74a50efaxc4ff30cb633b7734@mail.gmail.com>
	<4947614E.3070806@nicubunu.ro>
Message-ID: <16de708d0812160027m2ba589depc973ff57652880da@mail.gmail.com>

On Tue, Dec 16, 2008 at 2:05 AM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> Arthur Pemberton wrote:
>>
>> On Mon, Dec 15, 2008 at 3:35 AM, Nicu Buculei wrote:
>>>
>>> Arthur Pemberton wrote:
>>>>
>>>> Of course it is an important use case. No one is saying DVD installs
>>>> are useless. However if you have the bandwith to dload the DVD image
>>>> yourself, it is a lot more efficient to dload a live CD and install
>>>> from that.
>>>
>>> No if:
>>> - you want a downtime as small as possible.
>>
>> I fail to see how this is true with a DVD install. But this really
>
> Installing from a DVD your downtime is only during the install from media,
> installing from a Live CD the downtime is during the install from media
> *and* the yum install of all the applications you need to do the real work.
> What good is a desktop without applications?

The first thing I used to do after installing from a DVD was yum
update. Now I do yum install, and the actuall CD to hard time is much
shorter with the Live media. So I'm not sure that installing from DVD
is clearly faster in anyways. Having switched from only DVD to Live,
I'd say that it is much quicker to get up and running from live cd.

>> isn't that important as no one is trying to take away DVD installs.
>
> Fortunately no, but a bit earlier in the thread we have seen such wishes.

I must have missed that.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From kevin.kofler at chello.at  Tue Dec 16 08:32:09 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 16 Dec 2008 09:32:09 +0100
Subject: What Fedora makes sucking for me - or why I am NOT Fedora
References: <1228861426.30987.57.camel@code.and.org>
	<493F0BA8.1050300@gmail.com>
	<1228927014.3863.38.camel@localhost.localdomain>
	<1228945609.3394.10.camel@beck.corsepiu.local>
	<1228947640.31448.39.camel@arekh.okg>
	<1228949284.3394.36.camel@beck.corsepiu.local>
	<20081210235117.GB11018@zod.rchland.ibm.com>
	<1228955195.3394.69.camel@beck.corsepiu.local>
	<20081215203251.GA3700@hurricane.linuxnetz.de>
	<4946C0BF.5090202@fedoraproject.org>
	<20081215212653.GA12493@hurricane.linuxnetz.de>
Message-ID: <gi7p29$48v$2@ger.gmane.org>

Robert Scheck wrote:
> If I now shall believe, that this gets assigned and done, I need
> to believe first that there's a Christ Child...sorry.

For those who didn't get that reference:
http://en.wikipedia.org/wiki/Christkind
:-)

        Kevin Kofler



From hughsient at gmail.com  Tue Dec 16 08:33:33 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 16 Dec 2008 08:33:33 +0000
Subject: RFC: Description text in packages
In-Reply-To: <1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
Message-ID: <1229416413.3434.3.camel@hughsie-work.lan>

On Mon, 2008-12-15 at 17:43 -0500, Adam Jackson wrote:
> GNU is wrong and ` is not the mate of '.  '' or "" or utf8 quotes are
> fine.

Right. Should I file bugs for packages that use ``quotes'' or just
change them?

Richard.




From rjones at redhat.com  Tue Dec 16 09:02:17 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 16 Dec 2008 09:02:17 +0000
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <494719C0.9020307@silfreed.net>
References: <1229389958.3518.21.camel@localhost.localdomain>
	<494719C0.9020307@silfreed.net>
Message-ID: <20081216090217.GA23497@amd.home.annexia.org>


Mine is empty too:

https://admin.fedoraproject.org/pkgdb/users/info/rjones

Is there some way to edit this?

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From kanarip at kanarip.com  Tue Dec 16 09:28:22 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Tue, 16 Dec 2008 10:28:22 +0100
Subject: Server SIG - work areas
In-Reply-To: <4946A178.9040703@fedoraproject.org>
References: <1228140140.3664.72.camel@eagle.danny.cz>	<4944F811.1040206@kanarip.com>
	<4946A178.9040703@fedoraproject.org>
Message-ID: <494774B6.2040502@kanarip.com>

Frank Murphy wrote:
> As someone who doesn't know what I'm talking about yet,
> would ebox fit in?
> http://ebox-platform.com/
> 

If you get it packaged and in Fedora, sure ;-)

Maybe list this as one of the things that the Server SIG can do; package 
these sorts of packages.

Kind regards,

Jeroen van Meeuwen
-kanarip



From opensource at till.name  Tue Dec 16 09:33:53 2008
From: opensource at till.name (Till Maas)
Date: Tue, 16 Dec 2008 10:33:53 +0100
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <1229412385.3518.31.camel@localhost.localdomain>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<1229412302.3518.30.camel@localhost.localdomain>
	<1229412385.3518.31.camel@localhost.localdomain>
Message-ID: <200812161034.01979.opensource@till.name>

On Tue December 16 2008, Jesse Keating wrote:
> On Mon, 2008-12-15 at 23:25 -0800, Jesse Keating wrote:
> > By asking on list, I'm providing the conversation in an open and public
> > way.  I'm also helping to remind others of what to do when preparing
> > their own updates.
>
> I'll also note that I've yet to receive a reply, of any kind, from any
> of the maintainers or co-maintainers of the software, nor the
> maintainer's sponsor.

Afaics you only cc'ed the maintainer (and not the co-maintainers or sponsor) 
and did not add the comment to the update itself in Bodhi, which is where the 
comment belongs at least to, e.g. with an additional pointer to the 
mailinglist archive.

But in general I think it's good that you help you improve the information in 
updates announcements. :-)

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/05bd2c27/attachment.sig>

From pertusus at free.fr  Tue Dec 16 09:47:40 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 10:47:40 +0100
Subject: orphaning all my packages
Message-ID: <20081216094739.GA3877@free.fr>

Hello,

I am orphaning all my packages. I orphan the devel branch, but I'd
prefer
also orphan the stable branches too, so if you are interested don't
hesitate to ask. I am still willing to maintain the EPEL branches, but
here, also, if you want to take over, say so.

I am nco, ncview, glib 1 and gtk+ 1 de-facto main packager, so
somebody else should take care of those packages.

I think that lesstif, perl-File-MimeInfo and fcron are strategic for
fedora.


Low maintainance but very complicated packages:
The cernlib packages are quite complicated and unusual, this is fortran,
uses imake :-/ and upstream is moribund since 2003, and dead since 2006.
Debian was like a substitution upstream, but the debian maintainer has
also abandonned cernlib. Still it is known that there are users for this
package.
* cernlib
* cernlib-g77

Normal packages:
* lesstif
* libdap
* libnc-dap

Very low maintainance packages:
* asa
* bibexport
* BibTool
* bitmap
* libsx
* libdockapp
* ooo2txt
* perl-Parse-Yapp
* perl-Text-Unidecode
* tetex-elsevier
* uread
* wmix
* xbae
* xdialog

Low maintainance packages:
* acpitool
* boolstuff
* cppunit
* esmtp
* fcron
* halevt
* grads
there is an update available for grads, but it has some functionalities
removed, and also upstream is complicated, with a friendly fork at
opengrads and last libgadap can be packaged now. I'll still be working 
with upstream, so I could help with chosing which version to package and 
things like that.
* perl-Algorithm-CurveFit
* perl-File-BaseDir
* perl-File-DesktopEntry
* perl-File-MimeInfo
* perl-Math-MatrixReal
* perl-Math-Symbolic

Recently added packages:
* g2clib
* grib_api
* w3lib

--
Pat



From konrad at tylerc.org  Tue Dec 16 09:59:23 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Tue, 16 Dec 2008 01:59:23 -0800
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <200812160159.23336.konrad@tylerc.org>

I'll take boolstuff and xdialog.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From pertusus at free.fr  Tue Dec 16 10:00:07 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 11:00:07 +0100
Subject: leaving fedora
Message-ID: <20081216100007.GB3877@free.fr>

Hello,

I am leaving fedora (though not EPEL), and since I have been quite
vocal in the last months, I thought it would deserve some explanation.
All that follows is highly subjective, and I don't think it
should lead to much discussion, and since it is very subjective, I
won't give names or facts to prove what I say, these are my feelings.

My use case is old non desktop stuff, fluxbox, xdm, vim, xterms,
mutt, irssi, firefox, latex/texinfo, xfig, xpdf, numerical models,
openoffice (because I have to). Fedora is unsuitable for me as a user
since quite a long time, too much regressions, lack of interest for
integrating what I use (xdm, no vfs daemon...) too short lived.
But I still used it as a contributor, one of the aim being to help
testing regressions and integrating oldish environment such that
people in my case don't have to go through the workarounds I had to
use in rawhide to have their setup working, while still benefiting
from progress in free software (new hardware support, new
frameworks...), in fedora and in RHEL+EPEL.

The cost of running rawhide (or a rawhide/stable mix), has always
been high, but it was ok, as the price for testing and being in
touch with latest innovations. However I have clearly seen now,
that the benefits are negligible. Many other maintainers, and
especially many important people in fedora lead don't care about
my use case and my bugs and patches get unanswered for months or
years, the local fixes I have don't get propagated to other users,
or maintainers refuse to support what I want. I don't blame the
maintainers, supporting my use case has a cost, and even if I am
ready to pay a part, it may still be too high for Fedora.

I also feel that I have become a stranger to the fedora community.
In the past it seems that power users like me, that is people who
like the desktop for others but not for themselves, and like simple
oldish UNIX stuff, were much more present, now it seems to me that
only a tiny (but very vocal...) minority remains. One thing that
really disturbed me was the latest FESCo election, I only voted
for one candidate, who was not elected. People in current FESCo
are nice and capable, indeed, but they don't represent me, and it
was very different in the past.

In the latest months, I remarked that most of the discussions
I was involved in here turned to flamewars and in the end my
wishes and solutions were always disregarded. Otherwise said I
have become a noise maker, certainly impairing communication
within the fedora project, and making everybody lose time for no
gain.

Lastly, I think that, on the packaging side, my wishes are
fulfilled since there are now many alternate desktops (or window
managers...) and all the display mananger I know about are
in fedora, and correctly integrated at the packaging level.
I also have all the command-line interfaces I want. Integration
didn't happen though, and I now think that fedora isn't the place
where it can happen.

I really enjoyed all this time in the Fedora project, and I learned
a lot, too. Last, I wish Fedora to be succesful, I think that Fedora 
is very useful for the advance of free software, and I thank the 
Fedora users and contributors, and RedHat support.

--
Pat



From pertusus at free.fr  Tue Dec 16 10:05:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 11:05:37 +0100
Subject: some tasks I won't be able to complete
Message-ID: <20081216100537.GC3877@free.fr>

Hello,

I did some things in fedora that I will not be able to finish, I thought
it was a good idea to list them so that these are not forgotten.

* most important, I begun reviewing Mattias Ellert submissions of globus
and associated packages
https://bugzilla.redhat.com/show_bug.cgi?id=453847
I think that it would be nice if somebody continued the reviews. Mattias
already helped me in the cernlib packaging, I think he should be
sponsored, and I wanted to sponsor him after his first package was 
accepted. I am not in position to sponsor anybody now, though.

* There are 3 bugs opened for smtpdaemon -> server(smtp). Keeping
smtpdaemon for backward compat is right, it is just that it shouldn't 
be forgotten in the future:
https://bugzilla.redhat.com/show_bug.cgi?id=438078
https://bugzilla.redhat.com/show_bug.cgi?id=438081
https://bugzilla.redhat.com/show_bug.cgi?id=438080

* I think that fcron should replace cronie as the default scheduler
(though cronie should be kept too).

* it would be nice if somebody moved forward the mail(local) virtual
provides stuff, if it doesn't fly by itself:
https://bugzilla.redhat.com/show_bug.cgi?id=472710

* I used to jump on all the reviews were the name seemed too generic to
me (I am not the only one to do that, though).
http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace
Tibbs said he wanted to make a guideline. I think that distributions
should really coordinate to sanitize the namespaces, using the
distributions mailing list would certainly be interesting in that
regard.

* I think that it would be nice to coordinate and document all the
virtual provides:
http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
http://fedoraproject.org/wiki/VilleSkytt?/VirtualProvides

* I attach a script I used once to check how static packages are used.
It is certainly very sub-optimal. Still open issues from that time:
I found one real bug:
https://bugzilla.redhat.com/show_bug.cgi?id=428384
and there is a package for which I couldn't convince the packager to
requires -devel and not -static
https://bugzilla.redhat.com/show_bug.cgi?id=441814

* consolekit support integration:
Most important bug:
https://bugzilla.redhat.com/show_bug.cgi?id=452156
Then xdm support for xdmcp:
https://bugzilla.redhat.com/show_bug.cgi?id=237621
The wdm bug (information on that bug is obsolete, better look at the
above
bugs):
https://bugzilla.redhat.com/show_bug.cgi?id=228079

For reference other related bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=430388
https://bugzilla.redhat.com/show_bug.cgi?id=228110

* I have 2 package submissions opened (I'll close them in few weeks if
nobody steps up):
cnvgrib https://bugzilla.redhat.com/show_bug.cgi?id=257781
g2lib https://bugzilla.redhat.com/show_bug.cgi?id=257761

--
Pat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: get_static_req.sh
Type: application/x-sh
Size: 2465 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/ca706a5a/attachment.sh>

From paul at city-fan.org  Tue Dec 16 10:06:14 2008
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 16 Dec 2008 10:06:14 +0000
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <49477D96.5000907@city-fan.org>

Patrice Dumas wrote:
> Hello,
> 
> I am orphaning all my packages. I orphan the devel branch, but I'd
> prefer
> also orphan the stable branches too, so if you are interested don't
> hesitate to ask. I am still willing to maintain the EPEL branches, but
> here, also, if you want to take over, say so.
> 
> I am nco, ncview, glib 1 and gtk+ 1 de-facto main packager, so
> somebody else should take care of those packages.

I'll take (or co-maintain if existing co-maintainer Rex wants them) glib 
and gtk+ as they're deps of the rest of the gnome 1 stack, some of which 
I look after.

Paul.



From pertusus at free.fr  Tue Dec 16 10:06:11 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 11:06:11 +0100
Subject: orphaning all my packages
In-Reply-To: <200812160159.23336.konrad@tylerc.org>
References: <20081216094739.GA3877@free.fr>
	<200812160159.23336.konrad@tylerc.org>
Message-ID: <20081216100611.GD3877@free.fr>

On Tue, Dec 16, 2008 at 01:59:23AM -0800, Conrad Meyer wrote:
> I'll take boolstuff and xdialog.

Also the stable branches?

--
Pat



From sundaram at fedoraproject.org  Tue Dec 16 10:06:16 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 16 Dec 2008 15:36:16 +0530
Subject: leaving fedora
In-Reply-To: <20081216100007.GB3877@free.fr>
References: <20081216100007.GB3877@free.fr>
Message-ID: <49477D98.7050105@fedoraproject.org>

Patrice Dumas wrote:
> 
> I really enjoyed all this time in the Fedora project, and I learned
> a lot, too. Last, I wish Fedora to be succesful, I think that Fedora 
> is very useful for the advance of free software, and I thank the 
> Fedora users and contributors, and RedHat support.

Thank you Patrice for all your contributions to Fedora. Hopefully you 
stay around still to review packages, which I found very useful while 
you are contributing to EPEL.

Rahul



From kevin.kofler at chello.at  Tue Dec 16 10:06:39 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 16 Dec 2008 11:06:39 +0100
Subject: orphaning many packages
References: <20081206122420.GC2932@free.fr>
Message-ID: <gi7ujf$ogo$1@ger.gmane.org>

I'm taking gnash and its dependencies agg and docbook2X. It's still the only
Free (if not the only) Flash plugin which works in Konqueror and I was the
one who got the KDE 4 port built, so I was already a de-facto comaintainer
if not maintainer.

Still, any comaintainers are welcome, anybody interested should just request
it through pkgdb.

As for flasm, it's not really a dependency of gnash, is it? I think somebody
actually interested in Flash authoring should take that one.

        Kevin Kofler



From frankly3d at fedoraproject.org  Tue Dec 16 10:10:22 2008
From: frankly3d at fedoraproject.org (Frank Murphy)
Date: Tue, 16 Dec 2008 10:10:22 +0000
Subject: Server SIG - work areas
In-Reply-To: <494774B6.2040502@kanarip.com>
References: <1228140140.3664.72.camel@eagle.danny.cz>	<4944F811.1040206@kanarip.com>	<4946A178.9040703@fedoraproject.org>
	<494774B6.2040502@kanarip.com>
Message-ID: <49477E8E.2040704@fedoraproject.org>

Jeroen van Meeuwen wrote:
> Frank Murphy wrote:
>> As someone who doesn't know what I'm talking about yet,
>> would ebox fit in?
>> http://ebox-platform.com/
>>
> 
> If you get it packaged and in Fedora, sure ;-)
> 
> Maybe list this as one of the things that the Server SIG can do; package
> these sorts of packages.
> 
>
As soon as I learn how will do.


Frank



From konrad at tylerc.org  Tue Dec 16 10:12:08 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Tue, 16 Dec 2008 02:12:08 -0800
Subject: orphaning all my packages
In-Reply-To: <20081216100611.GD3877@free.fr>
References: <20081216094739.GA3877@free.fr>
	<200812160159.23336.konrad@tylerc.org>
	<20081216100611.GD3877@free.fr>
Message-ID: <200812160212.09221.konrad@tylerc.org>

On Tuesday 16 December 2008 02:06:11 am Patrice Dumas wrote:
> On Tue, Dec 16, 2008 at 01:59:23AM -0800, Conrad Meyer wrote:
> > I'll take boolstuff and xdialog.
>
> Also the stable branches?
>
> --
> Pat

I'll take F-10 and F-9 branches, sure.

-- 
Conrad Meyer <konrad at tylerc.org>




From dominik at greysector.net  Tue Dec 16 10:37:59 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 16 Dec 2008 11:37:59 +0100
Subject: eel2 is going away
In-Reply-To: <1229411731.27938.5.camel@localhost.localdomain>
References: <1229411731.27938.5.camel@localhost.localdomain>
Message-ID: <20081216103759.GA12671@mokona.greysector.net>

On Tuesday, 16 December 2008 at 08:15, Matthias Clasen wrote:
> eel2 has been merged back into nautilus, and will no longer be available
> as a separate library. I've added an Obsoletes to the nautilus package.
> 
> This only affects a handful of packages, and for most of them a simple
> rebuild should suffice:
> 
> $repoquery -q --whatrequires libeel-2.so.2
> nautilus-python-0:0.5.1-1.fc10.i386
> control-center-1:2.24.0.1-9.fc10.i386
> nautilus-cd-burner-0:2.24.0-1.fc10.i386
> nautilus-share-0:0.7.2-13.fc10.i386
> gnome-translate-0:0.99-12.fc9.i386
> nautilus-search-tool-0:0.2.2-4.fc10.i386

IIUC, it's just the library moving from eel2 package to nautilus, right?
So why would the packages need a rebuild? The specfiles may need updating
to use nautilus-devel instead of eel2-devel, but I'd say a rebuild just
for that reason is unnecessary.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From arjan at infradead.org  Tue Dec 16 11:07:57 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 16 Dec 2008 12:07:57 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <gi5qm4$bbq$1@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
Message-ID: <20081216120757.6932da20@infradead.org>

On Mon, 15 Dec 2008 15:47:32 +0100
Harald Hoyer <harald at redhat.com> wrote:

> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
> 
> A brief Fedora 10 boot analysis.
> 
> To reach the 20 Second Startup Feature 

this begs the question, and you knew I as going to ask ;), if Fedora
wants to reach the 5 second boot that is quite possible on this
hardware, even without too insane compromises.
(which translates to something like 2 to 3 seconds on a full sized
laptop-with-ssd)

If not, I would regret that but it's not something I would have to live
without; I can get a fast boot myself quite fine. 
If so, something needs to happen NOW for F11, with a real serious push
for this. It'll involve quite a few people and quite a few packages
that need to get things right, but it's not at all impossible nor does
it require impossible-for-fedora compromises.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From arjan at infradead.org  Tue Dec 16 11:08:56 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 16 Dec 2008 12:08:56 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081215182823.GA28317@localhost>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
Message-ID: <20081216120856.5339ec63@infradead.org>

On Mon, 15 Dec 2008 19:28:23 +0100
Miroslav Lichvar <mlichvar at redhat.com> wrote:

> Suggestions welcomed.

how about not running a full MTA on a laptop/client install... at all?


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From pbrobinson at gmail.com  Tue Dec 16 11:44:16 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 16 Dec 2008 12:44:16 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216120856.5339ec63@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
Message-ID: <5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>

>> Suggestions welcomed.
>
> how about not running a full MTA on a laptop/client install... at all?

I agree. Any of the daemons such as cron, or the jobs that run through
them mail locally by default and in most desktop/laptop style of use
that would never be changed. So to have a full blown MTA for local
delivery is overkill for a vast majority of situations. I filed a bug
[1] against cronie for OLPC when it started pulling in exim because I
think it was basically first on the list to provide
/usr/sbin/sendmail. It was mentioned in the bug that MTAs that can do
local delivery and other local delivery agents (procmail?) should
provide mail(local) and then those sort of apps Require it rather than
the explicit sendmail binary. I'm not sure how that deals with the
exim style first in the list though. Anyone who works out that they
want the mail delivered elsewhere should be able to work out how to
install a full MTA.

Peter

[1] https://bugzilla.redhat.com/show_bug.cgi?id=472710



From pbrobinson at gmail.com  Tue Dec 16 12:02:17 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 16 Dec 2008 13:02:17 +0100
Subject: Review trades?
Message-ID: <5256d0b0812160402h21b6a9f6l807c07e27837bbe4@mail.gmail.com>

Hi All,

I've got some package reviews (all fairly simple) that I'm wondering
if anyone wants to swap for some other reviews. They all fairly basic
and with the other reviews that have been done should be fairly
simple.

gupnp-ui https://bugzilla.redhat.com/show_bug.cgi?id=454664
gupnp-vala https://bugzilla.redhat.com/show_bug.cgi?id=454668
opal voip library merge review
https://bugzilla.redhat.com/show_bug.cgi?id=226210
iFuse https://bugzilla.redhat.com/show_bug.cgi?id=473591

Peter



From nicolas.mailhot at laposte.net  Tue Dec 16 12:12:43 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 13:12:43 +0100 (CET)
Subject: eel2 is going away
In-Reply-To: <20081216103759.GA12671@mokona.greysector.net>
References: <1229411731.27938.5.camel@localhost.localdomain>
	<20081216103759.GA12671@mokona.greysector.net>
Message-ID: <3d4082a4fe76fc81818e385493ada1f9.squirrel@arekh.dyndns.org>



Le Mar 16 d?cembre 2008 11:37, Dominik 'Rathann' Mierzejewski a ?crit :

> IIUC, it's just the library moving from eel2 package to nautilus,
> right?
> So why would the packages need a rebuild?

I'd say this is a sane precautionary measure to avoid discovering in a
few months that someone made a mistake somewhere.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Tue Dec 16 12:18:08 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 13:18:08 +0100 (CET)
Subject: leaving fedora
In-Reply-To: <20081216100007.GB3877@free.fr>
References: <20081216100007.GB3877@free.fr>
Message-ID: <13976bffe2fdde59497c6b08b1b0262b.squirrel@arekh.dyndns.org>



Le Mar 16 d?cembre 2008 11:00, Patrice Dumas a ?crit :

Hi Patrice,

> My use case is old non desktop stuff, fluxbox, xdm, vim, xterms,
> mutt, irssi, firefox, latex/texinfo, xfig, xpdf, numerical models,
> openoffice (because I have to).

I think the TEX part needs a lot of work right now, and if TEX users
leave Fedora, the situation is unlikely to get better (and that will
propagate to RHEL/EEPEL/Centos someday)

We need people with all kinds of different objectives to balance the
distribution and even though we didn't always agree you were one of
the people providing this balance.

-- 
Nicolas Mailhot



From rjones at redhat.com  Tue Dec 16 12:20:15 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 16 Dec 2008 12:20:15 +0000
Subject: Review trades?
In-Reply-To: <5256d0b0812160402h21b6a9f6l807c07e27837bbe4@mail.gmail.com>
References: <5256d0b0812160402h21b6a9f6l807c07e27837bbe4@mail.gmail.com>
Message-ID: <20081216122015.GA24385@amd.home.annexia.org>

On Tue, Dec 16, 2008 at 01:02:17PM +0100, Peter Robinson wrote:
> gupnp-ui https://bugzilla.redhat.com/show_bug.cgi?id=454664
> gupnp-vala https://bugzilla.redhat.com/show_bug.cgi?id=454668

I've grabbed these two.

I've got about fifty you can choose from ...

https://bugzilla.redhat.com/buglist.cgi?quicksearch=mingw32
https://bugzilla.redhat.com/buglist.cgi?quicksearch=ocaml&component=Package%20Review

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From jnovy at redhat.com  Tue Dec 16 12:21:36 2008
From: jnovy at redhat.com (Jindrich Novy)
Date: Tue, 16 Dec 2008 13:21:36 +0100
Subject: leaving fedora
In-Reply-To: <20081216100007.GB3877@free.fr>
References: <20081216100007.GB3877@free.fr>
Message-ID: <20081216122136.GA28903@pucmeloud.brq.redhat.com>

Hi Patrice,

On Tue, Dec 16, 2008 at 11:00:07AM +0100, Patrice Dumas wrote:
> Hello,
> 
> I am leaving fedora (though not EPEL), and since I have been quite

Thanks for all the work and testing on the TeX side of the Fedora.
Hope you chnage your mind sometime so that we can go on cooperating.

Thanks,
Jindrich

-- 
Jindrich Novy <jnovy at redhat.com>   http://people.redhat.com/jnovy/



From buc at odusz.so-cdu.ru  Tue Dec 16 12:26:17 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 16 Dec 2008 15:26:17 +0300
Subject: leaving fedora
In-Reply-To: <20081216100007.GB3877@free.fr>
References: <20081216100007.GB3877@free.fr>
Message-ID: <49479E69.8050702@odu.neva.ru>

Patrice Dumas wrote:
> I am leaving fedora (though not EPEL)

Sad...

My use case seems the same as yours, hence I would like to ask you what 
the actual Linux solution you have found for yourself instead? The 
switching to CentOS from (soon unsupported) F8 is a backward step for me...


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From pertusus at free.fr  Tue Dec 16 13:01:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 14:01:37 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
Message-ID: <20081216121759.GA2414@free.fr>

On Tue, Dec 16, 2008 at 12:44:16PM +0100, Peter Robinson wrote:
> >> Suggestions welcomed.
> >
> > how about not running a full MTA on a laptop/client install... at all?
> 
> that would never be changed. So to have a full blown MTA for local
> delivery is overkill for a vast majority of situations. I filed a bug

It is true, but more to the point, full blown MTA can do local delivery 
without being started as daemons. So no MTA should be started in the 
default case.

That being said using a specific provides for local mail delivery,
like mail(local), such that something lighter than full blown MTAs, 
like esmtp+procmail can be used as cronie dependency is a good thing,
but it avoids dependency bloat, not startup time bloat.

--
Pat



From silfreed at silfreed.net  Tue Dec 16 13:17:05 2008
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Tue, 16 Dec 2008 08:17:05 -0500
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <1229404525.3518.26.camel@localhost.localdomain>
References: <1229389958.3518.21.camel@localhost.localdomain>	<494719C0.9020307@silfreed.net>
	<1229404525.3518.26.camel@localhost.localdomain>
Message-ID: <4947AA51.6080105@silfreed.net>

Jesse Keating wrote:
> As others have mentioned, package-owner at fedoraproject.org  Or since you
> seem to already have username information, user at fedoraproject.org works
> as well.
> 

With the number of packages I maintain this comes up so rarely that I don't 
remember these aliases and have to look them up as well; I'm sure I'm not alone.

-Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/336de37c/attachment.sig>

From pertusus at free.fr  Tue Dec 16 13:17:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 14:17:15 +0100
Subject: leaving fedora
In-Reply-To: <49479E69.8050702@odu.neva.ru>
References: <20081216100007.GB3877@free.fr> <49479E69.8050702@odu.neva.ru>
Message-ID: <20081216131715.GB2414@free.fr>

On Tue, Dec 16, 2008 at 03:26:17PM +0300, Dmitry Butskoy wrote:
> Patrice Dumas wrote:
>> I am leaving fedora (though not EPEL)
>
> Sad...
>
> My use case seems the same as yours, hence I would like to ask you what  
> the actual Linux solution you have found for yourself instead? The  
> switching to CentOS from (soon unsupported) F8 is a backward step for 
> me...

I am evaluating debian unstable currently. Since I don't have a simple 
way to boot my computer, I used debootstrap from fedora to bootstrap 
the debian system... Debian unstable is not bad, it is refreshing
to be able to administer my computer the way I did it 4 years ago ;-).
Modern packages are also packaged such that it is also possible to have 
something more modern, but the lack of integration of modern stuff means 
more work on that side. On the plus side, it means that the integration 
can go slower which is better for my use case.

I know quite well debian packaging after all those years in fedora 
cooperating with debian packagers ;-), but I really dislike it, so
currently I am not doing packages and I am back to installing in 
/usr/local and using cpan... Right for my personal computer, but 
doesn't scale well.

I had a look at Suse, but there was no community rebuild of their 
entreprise spin-off, which was not a proof of a very healthy community.

I use Centos 5 in the labs for computers I administer, I think that I 
won't ever switch. But I still don't know what I will use in the future,
Centos 6 or debian stable.

--
Pat



From pertusus at free.fr  Tue Dec 16 13:20:21 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 14:20:21 +0100
Subject: leaving fedora
In-Reply-To: <20081216122136.GA28903@pucmeloud.brq.redhat.com>
References: <20081216100007.GB3877@free.fr>
	<20081216122136.GA28903@pucmeloud.brq.redhat.com>
Message-ID: <20081216132021.GC2414@free.fr>

On Tue, Dec 16, 2008 at 01:21:36PM +0100, Jindrich Novy wrote:
> 
> Thanks for all the work and testing on the TeX side of the Fedora.
> Hope you chnage your mind sometime so that we can go on cooperating.

In any case, it was a real pleasure to cooperate with you (and with
Jonathan Underwood too) on the TeX packaging and testing.

--
Pat



From debarshi.ray at gmail.com  Tue Dec 16 13:24:15 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 16 Dec 2008 18:54:15 +0530
Subject: some tasks I won't be able to complete
In-Reply-To: <20081216100537.GC3877@free.fr>
References: <20081216100537.GC3877@free.fr>
Message-ID: <3170f42f0812160524v2ef6bb69m4993f73df92ab071@mail.gmail.com>

> and there is a package for which I couldn't convince the packager to
> requires -devel and not -static
> https://bugzilla.redhat.com/show_bug.cgi?id=441814

The packager in question here is me and the package in question is
nget. I did give my reasons for not making the change, but did not
hear from you fro quite some time. I am still open to suggestions and
discussions around the matter, and we can always re-open the bug if
needed.

Cheers,
Debarshi



From ricky at fedoraproject.org  Tue Dec 16 08:41:15 2008
From: ricky at fedoraproject.org (Ricky Zhou)
Date: Tue, 16 Dec 2008 03:41:15 -0500
Subject: Outage Notification: Koji, Wiki, Smolt, Transifex
Message-ID: <20081216084115.GA7779@sphe.res.cmu.edu>

Outage Notification - 2008-12-16 08:10 UTC

There has been an unplanned outage beginning at 2008-12-16 08:10 UTC.
There is currently no ETA for resolving these issues.  

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d 'YYYY-MM-DD HH:MM UTC'

Affected Services:

Buildsystem (Koji)
Database (all postgresql and mysql databases on db3)
Websites (Transifex, Smolt, Wiki)
Translation Services

Unaffected Services:

CVS / Source Control
DNS
Fedora Hosted
Fedora People
Fedora Talk
Mail
Mirror System
Torrent

Ticket Link:

https://fedorahosted.org/fedora-infrastructure/ticket/1059

Reason for Outage:

db3, our current Koji PostgreSQL server and MySQL server is having disk
problems.

Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email
to track the status of this outage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/2a32192c/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From pertusus at free.fr  Tue Dec 16 13:31:03 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 14:31:03 +0100
Subject: leaving fedora
In-Reply-To: <13976bffe2fdde59497c6b08b1b0262b.squirrel@arekh.dyndns.org>
References: <20081216100007.GB3877@free.fr>
	<13976bffe2fdde59497c6b08b1b0262b.squirrel@arekh.dyndns.org>
Message-ID: <20081216133103.GD2414@free.fr>

On Tue, Dec 16, 2008 at 01:18:08PM +0100, Nicolas Mailhot wrote:
> 
> I think the TEX part needs a lot of work right now, and if TEX users
> leave Fedora, the situation is unlikely to get better (and that will
> propagate to RHEL/EEPEL/Centos someday)

I thought a bit about that, and in fact it is not that obvious. The 
time I devote to free software as a whole is quite constant, it is my
hobby time. Therefore, not contributing to fedora will leave more time 
for upstream work. And it is possible that doing things upstream is 
in fact more profitable for my use case in fedora than doing it in
fedora. Sure, being in fedora helps having directions for upstream 
work, since fedora is basically a snapshot of the future of linux. 
But the cost of being in fedora has become too important, both for me,
and, in my opinion, for fedora.

Jose Matos is now a sponsor, he can sponsor interested TeX 
contributors.

> We need people with all kinds of different objectives to balance the
> distribution and even though we didn't always agree you were one of
> the people providing this balance.

Maybe, but the balance has been lost in the distro as a whole some
time ago. It is inertia on my side that caused be to stay that long,
if I had thought a bit more about it I would have left earlier.

--
Pat



From pertusus at free.fr  Tue Dec 16 13:39:39 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 14:39:39 +0100
Subject: some tasks I won't be able to complete
In-Reply-To: <3170f42f0812160524v2ef6bb69m4993f73df92ab071@mail.gmail.com>
References: <20081216100537.GC3877@free.fr>
	<3170f42f0812160524v2ef6bb69m4993f73df92ab071@mail.gmail.com>
Message-ID: <20081216133939.GE2414@free.fr>

On Tue, Dec 16, 2008 at 06:54:15PM +0530, Debarshi Ray wrote:
> > and there is a package for which I couldn't convince the packager to
> > requires -devel and not -static
> > https://bugzilla.redhat.com/show_bug.cgi?id=441814
> 
> The packager in question here is me and the package in question is
> nget. I did give my reasons for not making the change, but did not
> hear from you fro quite some time. I am still open to suggestions and
> discussions around the matter, and we can always re-open the bug if
> needed.

I know all that, that's why I list it as an open task. I think that 
using devel is better, but I still haven't a compelling argument, that's
why I didn't came back to you. I wanted first to improve the script I
sent to be able to do some automated QA on static packages, such that 
there is a way to warn packagers who build against a static library 
when the static library has been rebuilt, and also scripts to help 
with rebuilding all the packages that depends on the static library if
the change in the static library deserves it, and also warn packagers 
that are not in initialcc but build against a static library. After 
that I think that using -devel would have been compelling, but we're
not here yet ;-).

I hadn't time to progress in this directions, and it is not high on 
my list (and it wouldn't have been high even if I hadn't left fedora).

--
Pat



From bpepple at fedoraproject.org  Tue Dec 16 13:56:20 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 16 Dec 2008 08:56:20 -0500
Subject: Package Review Stats for the week ending December 14, 2008
Message-ID: <1229435781.4103.5.camel@localhost.localdomain>

Top three  FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending December 14th, 2008
were Parag AN(????), Manuel Wolfshant, and Jason Tibbitts.  Below is the
number of completed package reviews done.

Parag AN(????) - 8
manuel wolfshant - 5
Jason Tibbitts - 4
Orcan 'oget' Ogetbil - 3
Brennan Ashton - 2
Jesse Keating - 2
Mamoru Tasaka - 2
Rex Dieter - 2
Till Maas - 2
Dan Hor?k - 1
Dominik 'Rathann' Mierzejewski - 1
Fabian Affolter - 1
Felix Kaechele - 1
Jon Ciesla - 1
Kevin Fenzi - 1
Kevin Kofler - 1
Lucian Langa - 1
Marek Mahut - 1
Sergio Pascual - 1
Sven Lankes - 1

Merge Reviews: 3
Review Requests: 38
Total reviews: 41

Also, last week I screwed up and ran the report for 2007, and not 2008
(yeah, I suck).  So, here are the correct stats for the week ending
December 7th, 2008:

Jason Tibbitts - 9
manuel wolfshant - 3
Jon Ciesla - 2
Bill Nottingham - 1
Kevin Fenzi - 1
Lubomir Rintel - 1
Lucian Langa - 1
Mamoru Tasaka - 1
Marcela Maslanova - 1
Matthias Clasen - 1
Michael Schwendt - 1
Orcan 'oget' Ogetbil - 1
Patrice Dumas - 1
Rakesh Pandit - 1
Ville Skytt? - 1

Merge Reviews: 2
Review Requests: 24
Total reviews: 26

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/af372e8d/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Tue Dec 16 14:01:45 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Tue, 16 Dec 2008 23:01:45 +0900
Subject: some tasks I won't be able to complete
In-Reply-To: <3170f42f0812160524v2ef6bb69m4993f73df92ab071@mail.gmail.com>
References: <20081216100537.GC3877@free.fr>
	<3170f42f0812160524v2ef6bb69m4993f73df92ab071@mail.gmail.com>
Message-ID: <4947B4C9.2070105@ioa.s.u-tokyo.ac.jp>

Debarshi Ray wrote, at 12/16/2008 10:24 PM +9:00:
>> and there is a package for which I couldn't convince the packager to
>> requires -devel and not -static
>> https://bugzilla.redhat.com/show_bug.cgi?id=441814
> 
> The packager in question here is me and the package in question is
> nget. I did give my reasons for not making the change, but did not
> hear from you fro quite some time. I am still open to suggestions and
> discussions around the matter, and we can always re-open the bug if
> needed.
> 
> Cheers,
> Debarshi

I thought that in this case using "BuildRequires: foo-static"
was _mandatory_ ...

https://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries

Quoted:
Packages which explicitly need to link against the static version _must_ 
BuildRequire: foo-static, so that the usage can be tracked. 

Mamoru



From j.w.r.degoede at hhs.nl  Tue Dec 16 14:07:22 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Dec 2008 15:07:22 +0100
Subject: leaving fedora
In-Reply-To: <20081216100007.GB3877@free.fr>
References: <20081216100007.GB3877@free.fr>
Message-ID: <4947B61A.5020904@hhs.nl>

Patrice Dumas wrote:
> Hello,
> 
> I am leaving fedora (though not EPEL)

Thanks for all the good work you've done the past years, it was always a 
pleasure to work with you, so thank you and good bye.

Below I'll respond to one point of your farewell mail, this is in no way meant 
to convince you to come back, the purpose of my remarks is to discuss 
possibilities for those who remain behind to hopefully do better at your use 
cases :)

> My use case is old non desktop stuff, fluxbox, xdm, vim, xterms,
> mutt, irssi, firefox, latex/texinfo, xfig, xpdf, numerical models,
> openoffice (because I have to). Fedora is unsuitable for me as a user
> since quite a long time, too much regressions, lack of interest for
> integrating what I use (xdm, no vfs daemon...)

As someone who is now a day maintaining xfig and ImageMagick (not listed but 
sort of fits in the list), let me chime in here. I think the biggest issue with 
quite a lot of these, is that they are maintained by @redhat.com people (yes 
I'm @redhat.com now too). The problem is that most of these packages as part of 
former Fedora Core, got these maintainers because someone had to do it, not 
because they care a whole lot about the package. Those maintainers have more 
packages to maintain / other work to do and given that these packages do not 
have a lot of users, any issues with them will get low priority if any at all.

So what can we do to make this better? Simple become a co-maintainer and fix 
any issues yourself. That is how I did things with xfig and ImageMagick when I 
got fed up with ping-ing in bugzilla (officially I'm still a co-maintainer of 
both, but in practice I seem to be the maintainer).

So I hereby call on everyone who care about these older tools: if it itches 
scratch. I know that many of you have probably submitted bugs with patches. 
That is not going to work when a package maintainer is overworked. The solution 
in my experience is to become a co-maintainer and do any fixes yourself.

###

Talking about Patrice leaving and packages of older software, this leaves 
(amongst others) lesstif orphaned. As I've co-maintained it for a while and I 
believe that offering the possibility to run old (FREE) motif apps is 
important, I will pick it up (call me crazy). But I could really use some help 
here, upstream lesstif is dead and it could really use some loving. So any 
volunteers?

Regards,

Hans



From j.w.r.degoede at hhs.nl  Tue Dec 16 14:09:12 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Dec 2008 15:09:12 +0100
Subject: leaving fedora
In-Reply-To: <49479E69.8050702@odu.neva.ru>
References: <20081216100007.GB3877@free.fr> <49479E69.8050702@odu.neva.ru>
Message-ID: <4947B688.6080600@hhs.nl>

Dmitry Butskoy wrote:
> Patrice Dumas wrote:
>> I am leaving fedora (though not EPEL)
> 
> Sad...
> 
> My use case seems the same as yours, hence I would like to ask you what 
> the actual Linux solution you have found for yourself instead? The 
> switching to CentOS from (soon unsupported) F8 is a backward step for me...
> 

See my reply to Patrice's original mail about a possible way to fix any issues 
for users like you, without having to leave Fedora.

Regards,

Hans



From mlichvar at redhat.com  Tue Dec 16 14:11:56 2008
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Tue, 16 Dec 2008 15:11:56 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216121759.GA2414@free.fr>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr>
Message-ID: <20081216141156.GA30911@localhost>

On Tue, Dec 16, 2008 at 02:01:37PM +0100, Patrice Dumas wrote:
> On Tue, Dec 16, 2008 at 12:44:16PM +0100, Peter Robinson wrote:
> > >> Suggestions welcomed.
> > >
> > > how about not running a full MTA on a laptop/client install... at all?
> > 
> > that would never be changed. So to have a full blown MTA for local
> > delivery is overkill for a vast majority of situations. I filed a bug
> 
> It is true, but more to the point, full blown MTA can do local delivery 
> without being started as daemons. So no MTA should be started in the 
> default case.

With default configuration, only exim can deliver directly. Postfix
and sendmail need a daemon running or a cron job to actually deliver
the mail.

-- 
Miroslav Lichvar



From j.w.r.degoede at hhs.nl  Tue Dec 16 14:17:03 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Dec 2008 15:17:03 +0100
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <4947B85F.9050004@hhs.nl>

Patrice Dumas wrote:
> Hello,
> 

<snip>

> 
> I think that lesstif, perl-File-MimeInfo and fcron are strategic for
> fedora.
> 

I agree that lesstif is important. As I've co-maintained it for a while and I 
believe that offering the possibility to run old (FREE) motif apps is 
important, I will pick it up (call me crazy). But I could really use some help 
here, upstream lesstif is dead and it could really use some loving. So any 
volunteers?

Regards,

Hans

p.s.

I'm fine with taking over the F-10 and F-9 branches too.



From pertusus at free.fr  Tue Dec 16 14:17:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 15:17:30 +0100
Subject: some tasks I won't be able to complete
In-Reply-To: <4947B4C9.2070105@ioa.s.u-tokyo.ac.jp>
References: <20081216100537.GC3877@free.fr>
	<3170f42f0812160524v2ef6bb69m4993f73df92ab071@mail.gmail.com>
	<4947B4C9.2070105@ioa.s.u-tokyo.ac.jp>
Message-ID: <20081216141730.GG2414@free.fr>

On Tue, Dec 16, 2008 at 11:01:45PM +0900, Mamoru Tasaka wrote:
>
> I thought that in this case using "BuildRequires: foo-static"
> was _mandatory_ ...
>
> https://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries
>
> Quoted:
> Packages which explicitly need to link against the static version _must_  
> BuildRequire: foo-static, so that the usage can be tracked. 

Well, my interpretation of that is that the BuildRequires foo-static
is here to track packages that must link against a static library, that
is, that cannot link against a shared library. Those that can link 
against either a shared or a static library (even if the shared library
doesn't exist yet) should BuildRequires -devel.

However, rereading 
https://fedoraproject.org/wiki/Packaging/Guidelines#Programs_which_don.27t_need_to_notify_FESCo
it seems that I am wrong and indeed the BuildRequires should be 
foo-static. I have a bunch of nonconformant packages, then...

In any case I think that those guidelines cannot really be effective 
without tools to automatically find out non conformant packages, that
is the aim of my script.

--
Pat



From pertusus at free.fr  Tue Dec 16 14:20:06 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 15:20:06 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216141156.GA30911@localhost>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
Message-ID: <20081216142006.GH2414@free.fr>

On Tue, Dec 16, 2008 at 03:11:56PM +0100, Miroslav Lichvar wrote:
> 
> With default configuration, only exim can deliver directly. Postfix
> and sendmail need a daemon running or a cron job to actually deliver
> the mail.

I recall an somewhat old thread in which it was told that sendmail 
didn't need to be run to perform local delivery. I don't have the
reference at hand, though, and I don't know myself.

At least MTA that don't need to be started as a daemon for local
delivery should not (and, in my opinion, it is a valid point for 
changing the default in comps).

--
Pat



From mefoster at gmail.com  Tue Dec 16 14:25:19 2008
From: mefoster at gmail.com (Mary Ellen Foster)
Date: Tue, 16 Dec 2008 15:25:19 +0100
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>

On Tue, Dec 16, 2008 at 10:47 AM, Patrice Dumas <pertusus at free.fr> wrote:
> * bibexport
> * BibTool
> * tetex-elsevier

I'll take these ...

MEF (fellow TeX user)

-- 
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 lesmikesell at gmail.com  Tue Dec 16 14:26:29 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 16 Dec 2008 08:26:29 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216141156.GA30911@localhost>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>
	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>
Message-ID: <4947BA95.4010704@gmail.com>

Miroslav Lichvar wrote:
> On Tue, Dec 16, 2008 at 02:01:37PM +0100, Patrice Dumas wrote:
>> On Tue, Dec 16, 2008 at 12:44:16PM +0100, Peter Robinson wrote:
>>>>> Suggestions welcomed.
>>>> how about not running a full MTA on a laptop/client install... at all?
>>> that would never be changed. So to have a full blown MTA for local
>>> delivery is overkill for a vast majority of situations. I filed a bug
>> It is true, but more to the point, full blown MTA can do local delivery 
>> without being started as daemons. So no MTA should be started in the 
>> default case.
> 
> With default configuration, only exim can deliver directly. Postfix
> and sendmail need a daemon running or a cron job to actually deliver
> the mail.

But note that (a) the daemon startup can be delayed so as not to impact 
bootup time and (b) making sleep/hibernate reliable is what laptop users 
need instead of booting all the time anyway because it is much faster if 
you can simply close the lid and open it later with all your apps 
working as you left them.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pbrobinson at gmail.com  Tue Dec 16 14:29:23 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 16 Dec 2008 15:29:23 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216141156.GA30911@localhost>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
Message-ID: <5256d0b0812160629q42be4daeka7ca76908303a4ae@mail.gmail.com>

>> > > how about not running a full MTA on a laptop/client install... at all?
>> >
>> > that would never be changed. So to have a full blown MTA for local
>> > delivery is overkill for a vast majority of situations. I filed a bug
>>
>> It is true, but more to the point, full blown MTA can do local delivery
>> without being started as daemons. So no MTA should be started in the
>> default case.
>
> With default configuration, only exim can deliver directly. Postfix
> and sendmail need a daemon running or a cron job to actually deliver
> the mail.

and exim needs perl and other massives dependencies. is there just a
local delivery agent?

Peter



From mclasen at redhat.com  Tue Dec 16 14:32:51 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 16 Dec 2008 09:32:51 -0500
Subject: eel2 is going away
In-Reply-To: <20081216103759.GA12671@mokona.greysector.net>
References: <1229411731.27938.5.camel@localhost.localdomain>
	<20081216103759.GA12671@mokona.greysector.net>
Message-ID: <1229437971.3419.1.camel@localhost.localdomain>

On Tue, 2008-12-16 at 11:37 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Tuesday, 16 December 2008 at 08:15, Matthias Clasen wrote:
> > eel2 has been merged back into nautilus, and will no longer be available
> > as a separate library. I've added an Obsoletes to the nautilus package.
> > 
> > This only affects a handful of packages, and for most of them a simple
> > rebuild should suffice:
> > 
> > $repoquery -q --whatrequires libeel-2.so.2
> > nautilus-python-0:0.5.1-1.fc10.i386
> > control-center-1:2.24.0.1-9.fc10.i386
> > nautilus-cd-burner-0:2.24.0-1.fc10.i386
> > nautilus-share-0:0.7.2-13.fc10.i386
> > gnome-translate-0:0.99-12.fc9.i386
> > nautilus-search-tool-0:0.2.2-4.fc10.i386
> 
> IIUC, it's just the library moving from eel2 package to nautilus, right?
> So why would the packages need a rebuild? The specfiles may need updating
> to use nautilus-devel instead of eel2-devel, but I'd say a rebuild just
> for that reason is unnecessary.

No, there's no installed library anymore. libeel is merged into
libnautilus-private, which is just a convenience library, not something
thats available for linking against.



From mmcgrath at redhat.com  Tue Dec 16 14:58:15 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 16 Dec 2008 08:58:15 -0600 (CST)
Subject: Outage Notification: Koji, Wiki, Smolt, Transifex
In-Reply-To: <20081216084115.GA7779@sphe.res.cmu.edu>
References: <20081216084115.GA7779@sphe.res.cmu.edu>
Message-ID: <alpine.LFD.2.00.0812160852160.11298@laptop.mmcgrath.net>

On Tue, 16 Dec 2008, Ricky Zhou wrote:

> Outage Notification - 2008-12-16 08:10 UTC
>
> There has been an unplanned outage beginning at 2008-12-16 08:10 UTC.
> There is currently no ETA for resolving these issues.
>
> Ticket Link:
>
> https://fedorahosted.org/fedora-infrastructure/ticket/1059
>

Most of these services should now be back online (some have been for quite
some time).  See:

https://fedorahosted.org/fedora-infrastructure/ticket/1059

For more information.  Everything except the buildsystem should be fine
from now on.  The buildsystem is in a temporary state.  I've been able to
get it back online so at least builds can happen this morning.  I'm
waiting for a tech to get on site to replace some parts.  After that time
I'll schedule another outage to move it back.

Sorry for the inconvenience this has caused.  If you're interested in
keeping tabs on this just add yourself to the cc of that ticket.  Most
verbose communication/update information will be there.  Please direct any
questions or comments to me or stop by #fedora-admin on irc.freenode.net.

	-Mike

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From drago01 at gmail.com  Tue Dec 16 15:01:43 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 16 Dec 2008 16:01:43 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216120757.6932da20@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<20081216120757.6932da20@infradead.org>
Message-ID: <f6ca9fed0812160701l6c23a203nee0fbf59ff0208c2@mail.gmail.com>

On Tue, Dec 16, 2008 at 12:07 PM, Arjan van de Ven <arjan at infradead.org> wrote:
> On Mon, 15 Dec 2008 15:47:32 +0100
> Harald Hoyer <harald at redhat.com> wrote:
>
>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>
>> A brief Fedora 10 boot analysis.
>>
>> To reach the 20 Second Startup Feature
>
> this begs the question, and you knew I as going to ask ;), if Fedora
> wants to reach the 5 second boot that is quite possible on this
> hardware, even without too insane compromises.
> (which translates to something like 2 to 3 seconds on a full sized
> laptop-with-ssd)
>
> If not, I would regret that but it's not something I would have to live
> without; I can get a fast boot myself quite fine.
> If so, something needs to happen NOW for F11, with a real serious push
> for this. It'll involve quite a few people and quite a few packages
> that need to get things right, but it's not at all impossible nor does
> it require impossible-for-fedora compromises.

Yes that definitely should be the goal ... if it is possible to boot
in 5 seconds there is no reason to aim for 20.



From mmcgrath at redhat.com  Tue Dec 16 15:05:49 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 16 Dec 2008 09:05:49 -0600 (CST)
Subject: Outage Notification: Koji, Wiki, Smolt, Transifex
In-Reply-To: <20081216084115.GA7779@sphe.res.cmu.edu>
References: <20081216084115.GA7779@sphe.res.cmu.edu>
Message-ID: <alpine.LFD.2.00.0812160905180.11298@laptop.mmcgrath.net>

On Tue, 16 Dec 2008, Ricky Zhou wrote:

> Outage Notification - 2008-12-16 08:10 UTC
>
> There has been an unplanned outage beginning at 2008-12-16 08:10 UTC.
> There is currently no ETA for resolving these issues.
>
> Ticket Link:
>
> https://fedorahosted.org/fedora-infrastructure/ticket/1059
>

Most of these services should now be back online (some have been for quite
some time).  See:

https://fedorahosted.org/fedora-infrastructure/ticket/1059

For more information.  Everything except the buildsystem should be fine
from now on.  The buildsystem is in a temporary state.  I've been able to
get it back online so at least builds can happen this morning.  I'm
waiting for a tech to get on site to replace some parts.  After that time
I'll schedule another outage to move it back.

Sorry for the inconvenience this has caused.  If you're interested in
keeping tabs on this just add yourself to the cc of that ticket.  Most
verbose communication/update information will be there.  Please direct any
questions or comments to me or stop by #fedora-admin on irc.freenode.net.

        -Mike

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From harald at redhat.com  Tue Dec 16 15:05:27 2008
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 16 Dec 2008 16:05:27 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216120757.6932da20@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<20081216120757.6932da20@infradead.org>
Message-ID: <4947C3B7.5080400@redhat.com>

Arjan van de Ven wrote:
> On Mon, 15 Dec 2008 15:47:32 +0100
> Harald Hoyer <harald at redhat.com> wrote:
> 
>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>
>> A brief Fedora 10 boot analysis.
>>
>> To reach the 20 Second Startup Feature 
> 
> this begs the question, and you knew I as going to ask ;), if Fedora
> wants to reach the 5 second boot that is quite possible on this
> hardware, even without too insane compromises.
> (which translates to something like 2 to 3 seconds on a full sized
> laptop-with-ssd)
> 
> If not, I would regret that but it's not something I would have to live
> without; I can get a fast boot myself quite fine. 
> If so, something needs to happen NOW for F11, with a real serious push
> for this. It'll involve quite a few people and quite a few packages
> that need to get things right, but it's not at all impossible nor does
> it require impossible-for-fedora compromises.
> 
> 

Push your kernel patches, so we have a kernel fast boot and sreadahead.
Persuade our kernel maintainer to compile more modules in the kernel.

But, we can't / don't want to drop gnome and most other services, you dropped to 
reach 5 seconds.



From pertusus at free.fr  Tue Dec 16 15:12:13 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 16:12:13 +0100
Subject: leaving fedora
In-Reply-To: <4947B61A.5020904@hhs.nl>
References: <20081216100007.GB3877@free.fr> <4947B61A.5020904@hhs.nl>
Message-ID: <20081216151213.GI2414@free.fr>

On Tue, Dec 16, 2008 at 03:07:22PM +0100, Hans de Goede wrote:
>
> As someone who is now a day maintaining xfig and ImageMagick (not listed 
> but sort of fits in the list), let me chime in here. I think the biggest 

I haven't listed everything I used, but indeed, fits here.

> So what can we do to make this better? Simple become a co-maintainer and 
> fix any issues yourself. That is how I did things with xfig and 
> ImageMagick when I got fed up with ping-ing in bugzilla (officially I'm 
> still a co-maintainer of both, but in practice I seem to be the 
> maintainer).

That's also how I helped with a2ps, I would have liked to do the same 
for xdm. Also, as can be seen in packagedb, I watch over some 'core' 
packages I used, at least to help against mistakes.

> So I hereby call on everyone who care about these older tools: if it 
> itches scratch. I know that many of you have probably submitted bugs with 
> patches. That is not going to work when a package maintainer is 
> overworked. The solution in my experience is to become a co-maintainer 
> and do any fixes yourself.

That only works if the maintainer accepts, and at least show some
interest in the potential co-maintainer. I devised a policy with Rahul 
to force co-maintainership when maintainers didn't answered to patches 
and solutions but it got turned down. It is clear that this is not a 
policy I am very fond of, it is a rather harsh policy, so I don't 
think that this is a bad thing that it got turned down, but I really
wanted to have things moved on, and I couldn't see anything else than
constraint.


That being said, I am quite convinced that people more interested 
will take over those oldish packages over time. But it still isn't 
enough to have them rightly integrated. As I said in my mail, on the 
packaging side things are perfect. Some time ago fvwm and icewm weren't
in fedora, now they are here, and there is also all the lxde stuff
which is very nice. I have done halevt to be able to mount my usb key
automatically, and a hack to have the sessions in xdm, there is 
perl-File-MimeInfo for xdg-open to work in old 'desktops', acpitool
for the acpi and I certainly forget about other similar useful 
packages.

However all those packages never worked correctly at the same 
time in fedora (though they worked for me with modified or additional 
packages), because of constant changes in 'core' packages. The 
other issue being the ability to disable and remove 'core' packages
that I don't need, it still isn't possible. The issue here is really 
integration and not packaging.

--
Pat



From pertusus at free.fr  Tue Dec 16 15:14:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 16:14:15 +0100
Subject: orphaning all my packages
In-Reply-To: <f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>
References: <20081216094739.GA3877@free.fr>
	<f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>
Message-ID: <20081216151415.GJ2414@free.fr>

On Tue, Dec 16, 2008 at 03:25:19PM +0100, Mary Ellen Foster wrote:
> On Tue, Dec 16, 2008 at 10:47 AM, Patrice Dumas <pertusus at free.fr> wrote:
> > * bibexport
> > * BibTool
> > * tetex-elsevier
> 
> I'll take these ...

Do you also want the F9 and F10 branches?

--
Pat



From mefoster at gmail.com  Tue Dec 16 15:17:16 2008
From: mefoster at gmail.com (Mary Ellen Foster)
Date: Tue, 16 Dec 2008 16:17:16 +0100
Subject: orphaning all my packages
In-Reply-To: <20081216151415.GJ2414@free.fr>
References: <20081216094739.GA3877@free.fr>
	<f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>
	<20081216151415.GJ2414@free.fr>
Message-ID: <f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>

On Tue, Dec 16, 2008 at 4:14 PM, Patrice Dumas <pertusus at free.fr> wrote:
> On Tue, Dec 16, 2008 at 03:25:19PM +0100, Mary Ellen Foster wrote:
>> On Tue, Dec 16, 2008 at 10:47 AM, Patrice Dumas <pertusus at free.fr> wrote:
>> > * bibexport
>> > * BibTool
>> > * tetex-elsevier
>>
>> I'll take these ...
>
> Do you also want the F9 and F10 branches?

Yes please. :)

(NB: why does the "reply-to" get set so weirdly on this list? Is it a
gmail thing or what? I see the list address in there at least twice
...)

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 dominik at greysector.net  Tue Dec 16 15:20:26 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 16 Dec 2008 16:20:26 +0100
Subject: eel2 is going away
In-Reply-To: <1229437971.3419.1.camel@localhost.localdomain>
References: <1229411731.27938.5.camel@localhost.localdomain>
	<20081216103759.GA12671@mokona.greysector.net>
	<1229437971.3419.1.camel@localhost.localdomain>
Message-ID: <20081216152025.GA15967@mokona.greysector.net>

On Tuesday, 16 December 2008 at 15:32, Matthias Clasen wrote:
> On Tue, 2008-12-16 at 11:37 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > On Tuesday, 16 December 2008 at 08:15, Matthias Clasen wrote:
> > > eel2 has been merged back into nautilus, and will no longer be available
> > > as a separate library. I've added an Obsoletes to the nautilus package.
> > > 
> > > This only affects a handful of packages, and for most of them a simple
> > > rebuild should suffice:
> > > 
> > > $repoquery -q --whatrequires libeel-2.so.2
> > > nautilus-python-0:0.5.1-1.fc10.i386
> > > control-center-1:2.24.0.1-9.fc10.i386
> > > nautilus-cd-burner-0:2.24.0-1.fc10.i386
> > > nautilus-share-0:0.7.2-13.fc10.i386
> > > gnome-translate-0:0.99-12.fc9.i386
> > > nautilus-search-tool-0:0.2.2-4.fc10.i386
> > 
> > IIUC, it's just the library moving from eel2 package to nautilus, right?
> > So why would the packages need a rebuild? The specfiles may need updating
> > to use nautilus-devel instead of eel2-devel, but I'd say a rebuild just
> > for that reason is unnecessary.
> 
> No, there's no installed library anymore. libeel is merged into
> libnautilus-private, which is just a convenience library, not something
> thats available for linking against.

Ah, that explains things. So my comments are irrelevant, then. Thanks
for explaining.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From j.w.r.degoede at hhs.nl  Tue Dec 16 15:27:28 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Dec 2008 16:27:28 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4947C3B7.5080400@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<20081216120757.6932da20@infradead.org>
	<4947C3B7.5080400@redhat.com>
Message-ID: <4947C8E0.6030002@hhs.nl>

Harald Hoyer wrote:
> Arjan van de Ven wrote:
>> On Mon, 15 Dec 2008 15:47:32 +0100
>> Harald Hoyer <harald at redhat.com> wrote:
>>
>>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>>
>>> A brief Fedora 10 boot analysis.
>>>
>>> To reach the 20 Second Startup Feature 
>>
>> this begs the question, and you knew I as going to ask ;), if Fedora
>> wants to reach the 5 second boot that is quite possible on this
>> hardware, even without too insane compromises.
>> (which translates to something like 2 to 3 seconds on a full sized
>> laptop-with-ssd)
>>
>> If not, I would regret that but it's not something I would have to live
>> without; I can get a fast boot myself quite fine. If so, something 
>> needs to happen NOW for F11, with a real serious push
>> for this. It'll involve quite a few people and quite a few packages
>> that need to get things right, but it's not at all impossible nor does
>> it require impossible-for-fedora compromises.
>>
>>
> 
> Push your kernel patches, so we have a kernel fast boot and sreadahead.
> Persuade our kernel maintainer to compile more modules in the kernel.
> 
> But, we can't / don't want to drop gnome and most other services, you 
> dropped to reach 5 seconds.
> 

I agree with not dropping gnome :) But if we want faster startup we really 
should be taking a serious look at trimming startup services.

Some ideas:
1) Make more services not start when not needed, for example bluetooth when 
there is no bluetooth hardware, etc. We could even completely stop them from 
being a service controlled by runlevel and make them be started from udev instead.

2) Load some services after gdm is up, for example cron, anacron, at,
setroubleshootd

3) Outright remove some services from the default started set, such as a
certain local mta.

Regards,

Hans



From pertusus at free.fr  Tue Dec 16 15:33:41 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 16:33:41 +0100
Subject: orphaning all my packages
In-Reply-To: <f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>
References: <20081216094739.GA3877@free.fr>
	<f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>
	<20081216151415.GJ2414@free.fr>
	<f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>
Message-ID: <20081216153341.GL2414@free.fr>

On Tue, Dec 16, 2008 at 04:17:16PM +0100, Mary Ellen Foster wrote:
> 
> Yes please. :)

Done.

Maybe you missed the first wave of orphanage, some days ago I orphaned,
among others, tetex-tex4ht. Do you also want to maintain it? It is a
package that needs some work, upstream is quite active, and ensuring 
that it builds from the literate sources can require some work.

--
Pat



From vonbrand at inf.utfsm.cl  Tue Dec 16 15:22:54 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 16 Dec 2008 12:22:54 -0300
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216120856.5339ec63@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
Message-ID: <200812161522.mBGFMsiq032572@laptop14.inf.utfsm.cl>

Arjan van de Ven <arjan at infradead.org> wrote:
> On Mon, 15 Dec 2008 19:28:23 +0100
> Miroslav Lichvar <mlichvar at redhat.com> wrote:
> 
> > Suggestions welcomed.
> 
> how about not running a full MTA on a laptop/client install... at all?

That works if you have reliable, continuous access to the 'net. Not my
case, sorry.
-- 
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 jonathan.underwood at gmail.com  Tue Dec 16 15:41:16 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 16 Dec 2008 15:41:16 +0000
Subject: orphaning all my packages
In-Reply-To: <f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>
References: <20081216094739.GA3877@free.fr>
	<f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>
	<20081216151415.GJ2414@free.fr>
	<f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>
Message-ID: <645d17210812160741jcda052dr9a8d28ac9ddfb78b@mail.gmail.com>

2008/12/16 Mary Ellen Foster <mefoster at gmail.com>:
> On Tue, Dec 16, 2008 at 4:14 PM, Patrice Dumas <pertusus at free.fr> wrote:
>> On Tue, Dec 16, 2008 at 03:25:19PM +0100, Mary Ellen Foster wrote:
>>> On Tue, Dec 16, 2008 at 10:47 AM, Patrice Dumas <pertusus at free.fr> wrote:
>>> > * bibexport
>>> > * BibTool
>>> > * tetex-elsevier
>>>
>>> I'll take these ...
>>
>> Do you also want the F9 and F10 branches?
>
> Yes please. :)
>
> (NB: why does the "reply-to" get set so weirdly on this list? Is it a
> gmail thing or what? I see the list address in there at least twice
> ...)
>

Mary, I'll happily co-maintain these with you, if you're happy to have
a co-maintainer.



From pertusus at free.fr  Tue Dec 16 15:42:16 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 16:42:16 +0100
Subject: orphaning many packages
In-Reply-To: <gi7ujf$ogo$1@ger.gmane.org>
References: <20081206122420.GC2932@free.fr> <gi7ujf$ogo$1@ger.gmane.org>
Message-ID: <20081216154216.GM2414@free.fr>

On Tue, Dec 16, 2008 at 11:06:39AM +0100, Kevin Kofler wrote:
> I'm taking gnash and its dependencies agg and docbook2X. It's still the only
> Free (if not the only) Flash plugin which works in Konqueror and I was the
> one who got the KDE 4 port built, so I was already a de-facto comaintainer
> if not maintainer.

Do you want the F9 and F10 branches of all those packages?

> As for flasm, it's not really a dependency of gnash, is it? I think somebody
> actually interested in Flash authoring should take that one.

It is not strictly a dependency, but it may be needed to be able to 
debug gnash. What is interesting, indeed, is the possibility to 
disassemble a swf to understand what is in it. I brought it in fedora
because I needed it for a bug report, and I saw it used more than once
for gnash debugging on the gnash mailing list.

Si it is not strictly needed, but convenient. It guess that it is also 
of some interest for swfdec.

--
Pat



From sandeen at redhat.com  Tue Dec 16 15:47:15 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 16 Dec 2008 09:47:15 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4947C3B7.5080400@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<20081216120757.6932da20@infradead.org>
	<4947C3B7.5080400@redhat.com>
Message-ID: <4947CD83.90207@redhat.com>

Harald Hoyer wrote:

> Push your kernel patches, so we have a kernel fast boot and sreadahead.
> Persuade our kernel maintainer to compile more modules in the kernel.


Which ones?  A lot have already been done.

http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/config-generic?r1=1.166&r2=1.167

was the big one.

Do you have more in mind?

-Eric



From lesmikesell at gmail.com  Tue Dec 16 15:50:46 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 16 Dec 2008 09:50:46 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>
	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
Message-ID: <4947CE56.3020900@gmail.com>

Peter Robinson wrote:
> Anyone who works out that they
> want the mail delivered elsewhere should be able to work out how to
> install a full MTA.

Errr, do you mean by installing a unix-like operating system instead of 
whatever it is you have in mind that fedora should be?

--
   Les Mikesell
     lesmikesell at gmail.com



From pertusus at free.fr  Tue Dec 16 15:55:50 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Dec 2008 16:55:50 +0100
Subject: leaving fedora
In-Reply-To: <49477D98.7050105@fedoraproject.org>
References: <20081216100007.GB3877@free.fr>
	<49477D98.7050105@fedoraproject.org>
Message-ID: <20081216155550.GN2414@free.fr>

On Tue, Dec 16, 2008 at 03:36:16PM +0530, Rahul Sundaram wrote:
>
> Thank you Patrice for all your contributions to Fedora. Hopefully you  
> stay around still to review packages, which I found very useful while  
> you are contributing to EPEL.

I don't think that it would be reasonable, since I don't run Fedora
anymore (though I have kept it, at least to help with bugs in my 
packages in stable branches nobody wants). I already installed plague 
on my debian -- it is strictly required for EPEL, and I guess that it 
would be possible to install koji and bodhi clients (and I will need
them if EPEL switches to bodhi/koji), yum and mock, but it is a bit 
dubious that it makes sense. I want to finish the mailutils and ltsp
doc reviews, but I don't think I'll do more.

--
Pat



From dwmw2 at infradead.org  Tue Dec 16 16:01:01 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 16 Dec 2008 16:01:01 +0000
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <1229435781.4103.5.camel@localhost.localdomain>
References: <1229435781.4103.5.camel@localhost.localdomain>
Message-ID: <1229443261.4049.324.camel@macbook.infradead.org>

On Tue, 2008-12-16 at 08:56 -0500, Brian Pepple wrote:
> Top three  FAS account holders who have completed reviewing "Package
> review" components on bugzilla for the week ending December 14th, 2008
> were Parag AN(????), Manuel Wolfshant, and Jason Tibbitts.  Below is
> the number of completed package reviews done.

Thanks for doing these reports -- it's useful. And it reminds me that I
haven't done many reviews in the last few weeks, while my DSL line has
been crap. I'll try to catch up.

Any chance we could include the number of open review bugs in the
report? And the number of _new_ reviews opened since the previous
report?

-- 
dwmw2



From mclasen at redhat.com  Tue Dec 16 16:02:28 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 16 Dec 2008 11:02:28 -0500
Subject: eel2 is going away
In-Reply-To: <1229411731.27938.5.camel@localhost.localdomain>
References: <1229411731.27938.5.camel@localhost.localdomain>
Message-ID: <1229443348.3419.4.camel@localhost.localdomain>

On Tue, 2008-12-16 at 02:15 -0500, Matthias Clasen wrote:
> eel2 has been merged back into nautilus, and will no longer be available
> as a separate library. I've added an Obsoletes to the nautilus package.
> 
> This only affects a handful of packages, and for most of them a simple
> rebuild should suffice:
> 
> $repoquery -q --whatrequires libeel-2.so.2
> nautilus-python-0:0.5.1-1.fc10.i386
> control-center-1:2.24.0.1-9.fc10.i386
> nautilus-cd-burner-0:2.24.0-1.fc10.i386
> nautilus-share-0:0.7.2-13.fc10.i386
> gnome-translate-0:0.99-12.fc9.i386
> nautilus-search-tool-0:0.2.2-4.fc10.i386

I added an Obsoletes: eel2 when I built nautilus last night, but looking
at these packages today, there is some real porting effort required (at
least in gnome-translate), so I'm going to drop the Obsoletes
temporarily, to give people some time to port. 

I'll have another go at it in January.


Matthias



From harald at redhat.com  Tue Dec 16 16:08:03 2008
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 16 Dec 2008 17:08:03 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4947C8E0.6030002@hhs.nl>
References: <gi5qm4$bbq$1@ger.gmane.org>	<20081216120757.6932da20@infradead.org>	<4947C3B7.5080400@redhat.com>
	<4947C8E0.6030002@hhs.nl>
Message-ID: <gi8jp3$5na$1@ger.gmane.org>

Hans de Goede wrote:
> Harald Hoyer wrote:
>> Arjan van de Ven wrote:
>>> On Mon, 15 Dec 2008 15:47:32 +0100
>>> Harald Hoyer <harald at redhat.com> wrote:
>>>
>>>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>>>
>>>> A brief Fedora 10 boot analysis.
>>>>
>>>> To reach the 20 Second Startup Feature 
>>>
>>> this begs the question, and you knew I as going to ask ;), if Fedora
>>> wants to reach the 5 second boot that is quite possible on this
>>> hardware, even without too insane compromises.
>>> (which translates to something like 2 to 3 seconds on a full sized
>>> laptop-with-ssd)
>>>
>>> If not, I would regret that but it's not something I would have to live
>>> without; I can get a fast boot myself quite fine. If so, something 
>>> needs to happen NOW for F11, with a real serious push
>>> for this. It'll involve quite a few people and quite a few packages
>>> that need to get things right, but it's not at all impossible nor does
>>> it require impossible-for-fedora compromises.
>>>
>>>
>>
>> Push your kernel patches, so we have a kernel fast boot and sreadahead.
>> Persuade our kernel maintainer to compile more modules in the kernel.
>>
>> But, we can't / don't want to drop gnome and most other services, you 
>> dropped to reach 5 seconds.
>>
> 
> I agree with not dropping gnome :) But if we want faster startup we 
> really should be taking a serious look at trimming startup services.
> 
> Some ideas:
> 1) Make more services not start when not needed, for example bluetooth 
> when there is no bluetooth hardware, etc. We could even completely stop 
> them from being a service controlled by runlevel and make them be 
> started from udev instead.

right, directly (and as an upstart event "/sbin/start bluetooth") or via 
HAL/DeviceKit

> 
> 2) Load some services after gdm is up, for example cron, anacron, at,
> setroubleshootd

or start them in parallel via upstart

> 
> 3) Outright remove some services from the default started set, such as a
> certain local mta.
> 
> Regards,
> 
> Hans
> 




From rakesh.pandit at gmail.com  Tue Dec 16 16:08:57 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 16 Dec 2008 21:38:57 +0530
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <1229443261.4049.324.camel@macbook.infradead.org>
References: <1229435781.4103.5.camel@localhost.localdomain>
	<1229443261.4049.324.camel@macbook.infradead.org>
Message-ID: <b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>

2008/12/16 David Woodhouse <dwmw2 at infradead.org>:
> On Tue, 2008-12-16 at 08:56 -0500, Brian Pepple wrote:
>> Top three  FAS account holders who have completed reviewing "Package
>> review" components on bugzilla for the week ending December 14th, 2008
>> were Parag AN(????), Manuel Wolfshant, and Jason Tibbitts.  Below is
>> the number of completed package reviews done.
>
> Thanks for doing these reports -- it's useful. And it reminds me that I
> haven't done many reviews in the last few weeks, while my DSL line has
> been crap. I'll try to catch up.
>
> Any chance we could include the number of open review bugs in the
> report? And the number of _new_ reviews opened since the previous
> report?
>

Yes we can do that easily, and I will extend the script to that
anyway. Hopefully if list is not too long it makes sense to include
bugs here.

-- 
rakesh



From pbrobinson at gmail.com  Tue Dec 16 16:09:47 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 16 Dec 2008 17:09:47 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812161522.mBGFMsiq032572@laptop14.inf.utfsm.cl>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<200812161522.mBGFMsiq032572@laptop14.inf.utfsm.cl>
Message-ID: <5256d0b0812160809t68f0cc48w8dd573e9d95dac34@mail.gmail.com>

>> > Suggestions welcomed.
>>
>> how about not running a full MTA on a laptop/client install... at all?
>
> That works if you have reliable, continuous access to the 'net. Not my
> case, sorry.

Nothing to say you can't re-enable it yourself. I don't have a
permanent connection to the net but evolution happily holds it in my
outbox until I go back online and can connect to a network. Fedora can
never cater to everyone's needs out of the box without a little
tweaking.

Peter



From harald at redhat.com  Tue Dec 16 16:08:50 2008
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 16 Dec 2008 17:08:50 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4947CD83.90207@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<20081216120757.6932da20@infradead.org>	<4947C3B7.5080400@redhat.com>
	<4947CD83.90207@redhat.com>
Message-ID: <gi8jqi$5na$2@ger.gmane.org>

Eric Sandeen wrote:
> Harald Hoyer wrote:
> 
>> Push your kernel patches, so we have a kernel fast boot and sreadahead.
>> Persuade our kernel maintainer to compile more modules in the kernel.
> 
> 
> Which ones?  A lot have already been done.
> 
> http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/config-generic?r1=1.166&r2=1.167
> 
> was the big one.
> 
> Do you have more in mind?
> 
> -Eric
> 

mmmmhh :) looks good :)



From cebbert at redhat.com  Tue Dec 16 16:09:01 2008
From: cebbert at redhat.com (Chuck Ebbert)
Date: Tue, 16 Dec 2008 11:09:01 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4947CD83.90207@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<20081216120757.6932da20@infradead.org>
	<4947C3B7.5080400@redhat.com> <4947CD83.90207@redhat.com>
Message-ID: <20081216110901.7b5dca73@dhcp-100-2-144.bos.redhat.com>

On Tue, 16 Dec 2008 09:47:15 -0600
Eric Sandeen <sandeen at redhat.com> wrote:

> Harald Hoyer wrote:
> 
> > Push your kernel patches, so we have a kernel fast boot and sreadahead.
> > Persuade our kernel maintainer to compile more modules in the kernel.
> 
> 
> Which ones?  A lot have already been done.
> 
> http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/config-generic?r1=1.166&r2=1.167
> 
> was the big one.
> 

Some of those didn't actually work due to higher-level menu items being configured
as modular. (I just noticed this a few days ago.)



From dpquigl at tycho.nsa.gov  Tue Dec 16 15:57:10 2008
From: dpquigl at tycho.nsa.gov (David P. Quigley)
Date: Tue, 16 Dec 2008 10:57:10 -0500
Subject: NFS broken by recent Fedora 9 update?
In-Reply-To: <17182.1229392365@sss.pgh.pa.us>
References: <11986.1229376267@sss.pgh.pa.us>
	<ufahc55164s.fsf@epithumia.math.uh.edu>
	<14497.1229386609@sss.pgh.pa.us> <4946F9A5.8000301@ij.net>
	<6d06ce20812151726m31fff10cl9b51593941c417d3@mail.gmail.com>
	<17182.1229392365@sss.pgh.pa.us>
Message-ID: <1229443030.31766.4.camel@moss-terrapins.epoch.ncsc.mil>

On Mon, 2008-12-15 at 20:52 -0500, Tom Lane wrote:
> "Jerry Amundson" <jamundso at gmail.com> writes:
> > In case it was missed, note jkeating's very recent post "Coordination
> > of updates and reading of bodhi comments".
> 
> Yeah, that may explain it.  At first I didn't think it was selinux,
> because of the lack of any selinux complaints in my logs.  However,
> looking back to the last boot found
> 
> Dec 14 19:21:46 rh2 rpcbind: setgid to 'rpc' (32) failed: Operation not permitted
> Dec 14 19:21:48 rh2 setroubleshoot: SELinux is preventing rpcbind (rpcbind_t) "setgid" rpcbind_t. For complete SELinux messages. run sealert -l 2e7e0f7b-d206-4999-a02c-91bf0cc9d1e2
> 
> For anyone who needs a fix right now, I can confirm that reverting
> rpcbind to rpcbind-0.1.4-14.fc9 (the latest prior version I could find
> on the download servers) makes the NFS and AFP problems go away.
> 
> 			regards, tom lane
> 

I'm not sure if he fix for this is in the SELinux policy package yet but
if you don't want to revert your rpcbind package this policy module
should be a temporary fix.

policy_module(myrpcbind, 1.0)

require {
        type rpcbind_t;
}

allow rpcbind_t self:capability setgid;


1) Create directory, enter directory, and copy the policy module into
myrpcbind.te in that directory.

2) make -f /usr/share/selinux/devel/Makefile

3) as root /usr/sbin/semodule -i myrpcbind.pp

Dave



From orion at cora.nwra.com  Tue Dec 16 16:29:05 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 16 Dec 2008 09:29:05 -0700
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <1229389958.3518.21.camel@localhost.localdomain>
References: <1229389958.3518.21.camel@localhost.localdomain>
Message-ID: <4947D751.7000806@cora.nwra.com>

Jesse Keating wrote:
> Here is another example where maintainers need to coordinate more and
> pay attention.
> 
> https://admin.fedoraproject.org/updates/F9/FEDORA-2008-10000
> (rpcbind-0.1.7-1.fc9) went into Fedora 9 updates testing on 11-22.  On
> the 25th bodhi feedback showed that this requires selinux changes.
> 
> https://admin.fedoraproject.org/updates/F9/FEDORA-2008-11122
> (selinux-policy-3.3.1-115.fc9) went into Fedora 9 updates testing on
> 12-10.  This was the build to fix rpcbind.
> 
> On 12-10 rpcbind was submitted for stable.  On the same day, bodhi
> feedback requested that this update not go out until the matching
> selinux-policy went out to stable.
> 
> On 12-11 rpcbind went into stable.

Yeah, this is what prompted my earlier post.  This also makes me wonder 
why I bother running updates-testing on some of my machines.  Seems like 
half the time I report an issue, the update gets pushed to stable anyways.


-- 
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 arjan at infradead.org  Tue Dec 16 16:52:19 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 16 Dec 2008 17:52:19 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <5256d0b0812160809t68f0cc48w8dd573e9d95dac34@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<200812161522.mBGFMsiq032572@laptop14.inf.utfsm.cl>
	<5256d0b0812160809t68f0cc48w8dd573e9d95dac34@mail.gmail.com>
Message-ID: <20081216175219.3d280df2@infradead.org>

On Tue, 16 Dec 2008 17:09:47 +0100
"Peter Robinson" <pbrobinson at gmail.com> wrote:

> >> > Suggestions welcomed.
> >>
> >> how about not running a full MTA on a laptop/client install... at
> >> all?
> >
> > That works if you have reliable, continuous access to the 'net. Not
> > my case, sorry.
> 
> Nothing to say you can't re-enable it yourself. I don't have a
> permanent connection to the net but evolution happily holds it in my
> outbox until I go back online and can connect to a network. Fedora can
> never cater to everyone's needs out of the box without a little
> tweaking.

and it's not like sendmail/exim/whatever can't decide to become a daemon
if it can't deliver... but only then.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From dpquigl at tycho.nsa.gov  Tue Dec 16 16:31:26 2008
From: dpquigl at tycho.nsa.gov (David P. Quigley)
Date: Tue, 16 Dec 2008 11:31:26 -0500
Subject: NFS broken by recent Fedora 9 update?
In-Reply-To: <1229443030.31766.4.camel@moss-terrapins.epoch.ncsc.mil>
References: <11986.1229376267@sss.pgh.pa.us>
	<ufahc55164s.fsf@epithumia.math.uh.edu>
	<14497.1229386609@sss.pgh.pa.us> <4946F9A5.8000301@ij.net>
	<6d06ce20812151726m31fff10cl9b51593941c417d3@mail.gmail.com>
	<17182.1229392365@sss.pgh.pa.us>
	<1229443030.31766.4.camel@moss-terrapins.epoch.ncsc.mil>
Message-ID: <1229445086.31766.13.camel@moss-terrapins.epoch.ncsc.mil>

On Tue, 2008-12-16 at 10:57 -0500, David P. Quigley wrote:
> On Mon, 2008-12-15 at 20:52 -0500, Tom Lane wrote:
> > "Jerry Amundson" <jamundso at gmail.com> writes:
> > > In case it was missed, note jkeating's very recent post "Coordination
> > > of updates and reading of bodhi comments".
> > 
> > Yeah, that may explain it.  At first I didn't think it was selinux,
> > because of the lack of any selinux complaints in my logs.  However,
> > looking back to the last boot found
> > 
> > Dec 14 19:21:46 rh2 rpcbind: setgid to 'rpc' (32) failed: Operation not permitted
> > Dec 14 19:21:48 rh2 setroubleshoot: SELinux is preventing rpcbind (rpcbind_t) "setgid" rpcbind_t. For complete SELinux messages. run sealert -l 2e7e0f7b-d206-4999-a02c-91bf0cc9d1e2
> > 
> > For anyone who needs a fix right now, I can confirm that reverting
> > rpcbind to rpcbind-0.1.4-14.fc9 (the latest prior version I could find
> > on the download servers) makes the NFS and AFP problems go away.
> > 
> > 			regards, tom lane
> > 
> 
> I'm not sure if he fix for this is in the SELinux policy package yet but
> if you don't want to revert your rpcbind package this policy module
> should be a temporary fix.
> 
> policy_module(myrpcbind, 1.0)
> 
> require {
>         type rpcbind_t;
> }
> 
> allow rpcbind_t self:capability setgid;
> 
> 
> 1) Create directory, enter directory, and copy the policy module into
> myrpcbind.te in that directory.
> 
> 2) make -f /usr/share/selinux/devel/Makefile
> 
> 3) as root /usr/sbin/semodule -i myrpcbind.pp
> 
> Dave
> 

Supposedly the fix is in updates-testing, so that is another option.

yum --enablerepo=updates-testing update selinux-policy*

Dave



From dpquigl at tycho.nsa.gov  Tue Dec 16 16:34:44 2008
From: dpquigl at tycho.nsa.gov (David P. Quigley)
Date: Tue, 16 Dec 2008 11:34:44 -0500
Subject: NFS broken by recent Fedora 9 update?
In-Reply-To: <1229445086.31766.13.camel@moss-terrapins.epoch.ncsc.mil>
References: <11986.1229376267@sss.pgh.pa.us>
	<ufahc55164s.fsf@epithumia.math.uh.edu>
	<14497.1229386609@sss.pgh.pa.us> <4946F9A5.8000301@ij.net>
	<6d06ce20812151726m31fff10cl9b51593941c417d3@mail.gmail.com>
	<17182.1229392365@sss.pgh.pa.us>
	<1229443030.31766.4.camel@moss-terrapins.epoch.ncsc.mil>
	<1229445086.31766.13.camel@moss-terrapins.epoch.ncsc.mil>
Message-ID: <1229445284.31766.15.camel@moss-terrapins.epoch.ncsc.mil>

On Tue, 2008-12-16 at 11:31 -0500, David P. Quigley wrote:
> On Tue, 2008-12-16 at 10:57 -0500, David P. Quigley wrote:
> > On Mon, 2008-12-15 at 20:52 -0500, Tom Lane wrote:
> > > "Jerry Amundson" <jamundso at gmail.com> writes:
> > > > In case it was missed, note jkeating's very recent post "Coordination
> > > > of updates and reading of bodhi comments".
> > > 
> > > Yeah, that may explain it.  At first I didn't think it was selinux,
> > > because of the lack of any selinux complaints in my logs.  However,
> > > looking back to the last boot found
> > > 
> > > Dec 14 19:21:46 rh2 rpcbind: setgid to 'rpc' (32) failed: Operation not permitted
> > > Dec 14 19:21:48 rh2 setroubleshoot: SELinux is preventing rpcbind (rpcbind_t) "setgid" rpcbind_t. For complete SELinux messages. run sealert -l 2e7e0f7b-d206-4999-a02c-91bf0cc9d1e2
> > > 
> > > For anyone who needs a fix right now, I can confirm that reverting
> > > rpcbind to rpcbind-0.1.4-14.fc9 (the latest prior version I could find
> > > on the download servers) makes the NFS and AFP problems go away.
> > > 
> > > 			regards, tom lane
> > > 
> > 
> > I'm not sure if he fix for this is in the SELinux policy package yet but
> > if you don't want to revert your rpcbind package this policy module
> > should be a temporary fix.
> > 
> > policy_module(myrpcbind, 1.0)
> > 
> > require {
> >         type rpcbind_t;
> > }
> > 
> > allow rpcbind_t self:capability setgid;
> > 
> > 
> > 1) Create directory, enter directory, and copy the policy module into
> > myrpcbind.te in that directory.
> > 
> > 2) make -f /usr/share/selinux/devel/Makefile
> > 
> > 3) as root /usr/sbin/semodule -i myrpcbind.pp
> > 
> > Dave
> > 
> 
> Supposedly the fix is in updates-testing, so that is another option.
> 
> yum --enablerepo=updates-testing update selinux-policy*
> 
> Dave
> 

correction

yum --enablerepo=updates-testing-newkey update selinux-policy*



From arjan at infradead.org  Tue Dec 16 17:02:44 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 16 Dec 2008 18:02:44 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4947C3B7.5080400@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<20081216120757.6932da20@infradead.org>
	<4947C3B7.5080400@redhat.com>
Message-ID: <20081216180244.03b02e39@infradead.org>

On Tue, 16 Dec 2008 16:05:27 +0100
Harald Hoyer <harald at redhat.com> wrote:

> 
> Push your kernel patches, so we have a kernel fast boot and

there's nothing left needed for that, 2.6.28-rc has all you need.

> sreadahead.

more tricky; kyle has a cleaned up patch but the fs-devel list tends to
be a black hole ;(

> Persuade our kernel maintainer to compile more modules in
> the kernel.
> 
> But, we can't / don't want to drop gnome and most other services, you
> dropped to reach 5 seconds.

it's a total misunderstanding or excuse to claim we dropped services.
Most are started on demand instead. And really, also Fedora could
and should consider being smart about when to start them...

NFS for example should be started on the first mount (trivially
implemented via a post script on the modprobe of the nfs module)

Just throwing in the towel and say "can't do" is how you end up with a
40+ second boot time.


> 


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From mike at cchtml.com  Tue Dec 16 17:23:22 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Tue, 16 Dec 2008 11:23:22 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216180244.03b02e39@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<20081216120757.6932da20@infradead.org>	<4947C3B7.5080400@redhat.com>
	<20081216180244.03b02e39@infradead.org>
Message-ID: <4947E40A.3070101@cchtml.com>

-------- Original Message --------
Subject: Re: Fedora 10 - Boot Analysis
From: Arjan van de Ven <arjan at infradead.org>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
CC: harald at redhat.com
Date: 12/16/2008 11:02 AM


> 
> Just throwing in the towel and say "can't do" is how you end up with a
> 40+ second boot time.
> 

The motivation is lacking. Those same people are running on systems that 
they never/hardly reboot. They might also use boot time as an excuse to 
get up and go to the company water cooler. What would they do if their 
computer booted faster then opening their e-mail?

Of course you probably know this. The only solution is to e-mail, 
e-mail, and e-mail until you get something accomplished. Good luck. I'd 
love to see a 5 second boot in Fedora, but I'm only an "end-user" (atm).



From alsadi at gmail.com  Tue Dec 16 17:32:36 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 16 Dec 2008 19:32:36 +0200
Subject: RFC: Description text in packages
In-Reply-To: <1229416413.3434.3.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
Message-ID: <385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>

>  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1

please just "" or ''
the use of UTF-8 fancy quotations should be done by the renderer

> Right. Should I file bugs for packages that use ``quotes'' or just
> change them?

If you would like a perl/sed script to do that just tell me
I play good perl kong fu



From rawhide at fedoraproject.org  Tue Dec 16 17:36:20 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 16 Dec 2008 17:36:20 +0000 (UTC)
Subject: rawhide report: 20081216 changes
Message-ID: <20081216173620.85BA71F8243@releng2.fedora.phx.redhat.com>

Compose started at Tue Dec 16 06:01:09 UTC 2008

New package assogiate
        Editor for the file types database
New package ebook-tools
        Tools for accessing and converting various ebook file formats
New package fontpackages
        Common directory and macro definitions used by font packages
New package glog
        A C++ application logging library
New package log4cpp
        C++ logging library
New package onboard
        Simple on-screen Keyboard
New package perl-Hardware-Vhdl-Parser
        Complete grammar for parsing VHDL code using perl
New package perl-Set-Object
        Set of objects and strings
New package puzzles
        A collection of one-player puzzle games
Updated Packages:

asc-2.2.0.0-1.fc11
------------------
* Mon Dec 15 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.2.0.0-1
- New upstream version 2.2.0.0


asymptote-1.57-1.fc11
---------------------
* Mon Dec 15 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.57-1
- 1.57


bacula-2.4.3-7.fc11
-------------------
* Mon Dec 15 17:00:00 2008 Jon Ciesla <limb at jcomserv.net - 2.4.3-7
- Patched to support Python 2.6, BZ 476547.

* Fri Dec 12 17:00:00 2008 Jon Ciesla <limb at jcomserv.net - 2.4.3-6
- Fix consolehelper behaviour for bat.

* Wed Dec 10 17:00:00 2008 Jon Ciesla <limb at jcomserv.net - 2.4.3-5
- Re-diffed fuzzy bacula-director-configuration and bacula-config patches.

* Mon Dec  1 17:00:00 2008 Andreas Thienemann <andreas at bawue.net> - 2.4.3-4
- Fixed dependency "issues" #473627 by adding the sysconfdir subpackage.


bash-3.2-33.fc11
----------------
* Mon Dec 15 17:00:00 2008 Roman Rakus <rrakus at redhat.com> - 3.2-33
- fc builtin fix
  Resolves: #438841

* Mon Dec 15 17:00:00 2008 Roman Rakus <rrakus at redhat.com> - 3.2-32
- Enabling auditing
  Resolves: #476216


cairo-clock-0.3.4-2.fc11
------------------------

cairo-dock-2.0.0-0.1.svn1439_trunk.fc11
---------------------------------------
* Tue Dec 16 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1439


cluster-2.99.13-1.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 2.99.13-1
- New upstream release.
- Drop gnbd* packages that are now a separate project.
- Tight dependencies with corosync/openais.


corosync-0.92-5.svn1709.fc11
----------------------------
* Mon Dec 15 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 0.92-5.svn1709
- Update to svn trunk at revision 1709 from upstream.
- Update spec file to include new include files.


curl-7.18.2-9.fc11
------------------
* Mon Dec 15 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 7.18.2-9
- rebuild for f10/rawhide cvs tag clashes


ddd-3.3.11-19.fc11
------------------
* Mon Dec 15 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 3.3.11-19
- Added fot requires, BZ 476531.


eclipse-pydev-1.3.24-4.fc11
---------------------------
* Mon Dec 15 17:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 1:1.3.24-4
- This package is not noarch due to python-psyco and mylyn issues on different platforms.


eclipse-slide-1.3.11-3.fc10
---------------------------
* Thu Dec  4 17:00:00 2008 Dave Sugar <dsugar at tresys.com> - 1.3.11-3
- missing features dir

* Tue Dec  2 17:00:00 2008 Dave Sugar <dsugar at tresys.com> - 1.3.11-2
- 1.3.11-1 was tagged incorrectly

* Tue Dec  2 17:00:00 2008 Dave Sugar <dsugar at tresys.com> - 1.3.11-1
- bunch of minor changes - mostly support for some dependant plugins 
- some bug fixes

* Mon Nov  3 17:00:00 2008 Dave Sugar <dsugar at tresys.com> - 1.3.9-4
- fix files section

* Tue Aug 19 18:00:00 2008 Dave Sugar <dsugar at tresys.com> - 1.3.10
- fix problem with bulding for header projects


evolution-2.25.3.1-1.fc11
-------------------------
* Mon Dec 15 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.3.1-1.fc11
- Update to 2.25.3.1
- New BR: libgweather-devel
- Remove patch for GNOME bug #552583 (fixed upstream).
- Bump the gtkhtml and gtk2 minimum versions.


evolution-data-server-2.25.3-1.fc11
-----------------------------------
* Mon Dec 15 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.3-1.fc11
- Update to 2.25.3
- New BR: libgweather-devel


fatsort-0.9.10-1.fc11
---------------------
* Mon Dec 15 17:00:00 2008 Till Maas <opensource at till.name> - 0.9.10-1
- Update to new release


file-4.26-7.fc11
----------------
* Mon Dec 15 17:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 4.26-7
- fix the LaTex issue in bz#474156


glib2-2.19.3-1.fc11
-------------------
* Mon Dec 15 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.19.3-1
- Update to 2.19.3


gnutls-2.6.3-1.fc11
-------------------
* Mon Dec 15 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> 2.6.3-1
- upgrade to a new upstream version


gparted-0.4.1-1.fc11
--------------------
* Mon Dec 15 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 0.4.1-1
- New upstream version


gtkhtml3-3.25.3-1.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 3.25.3-1.fc11
- Update to 3.25.3
- Bump gnome_icon_theme_version to 2.22.0


hamlib-1.2.8-1.fc11
-------------------
* Mon Dec 15 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 1.2.8-1
- New upstream release


hunspell-ne-20061217-3.fc11
---------------------------
* Mon Dec 15 17:00:00 2008 Parag <pnemade at redhat.com> - 20061217-3
- Resolves:rh#475982 - Perhaps hunspell-ne suffices for ne_IN as well as ne_NP


jack-audio-connection-kit-0.116.1-1.fc11
----------------------------------------
* Sun Dec 14 17:00:00 2008 Andy Shevchenko <andy at smile.org.ua> - 0.116.1-1
- update to last official release
- update URL tag
- update file list accordingly


kadu-0.6.5-4.fc11
-----------------
* Wed Dec 10 17:00:00 2008 Micha?? Bentkowski <mr.ecik at gmail.com> - 0.6.5-4
- More cleaning


kdegraphics-4.1.85-2.fc11
-------------------------
* Mon Dec 15 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.85-2
- BR: ebook-tools-devel


kdelibs-4.1.85-3.fc11
---------------------
* Mon Dec 15 17:00:00 2008 Than Ngo <than at redhat.com> - 4.1.85-3
- add missing ENTITY systemsettings in ru/gl/es, that fixes kde-l10-es build breakage
- rename suffix ro .xxcmake to avoid install .cmake


kdelibs3-3.5.10-3.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.5.10-3
- update the KatePart latex.xml syntax definition to the version from Kile 2.0.3


kile-2.0.3-1.fc11
-----------------
* Mon Dec 15 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 2.0.3-1
- update to 2.0.3 (#476108)


libarchive-2.5.904a-1.fc11
--------------------------
* Mon Dec 15 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> 2.5.904a-1
- Update to 2.5.904a


libextractor-0.5.20b-2.fc11
---------------------------

libgdiplus-2.2-3.pre2.20081210svn118228.fc11
--------------------------------------------
* Wed Dec 10 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-3.pre2.20081012svn118228
- Update to svn

* Fri Dec  5 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-2.pre2
- Update to 2.2 preview 2


libsynce-0.11.1-2.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.11.1-2
- rebuild to get provides pkgconfig(libsynce)


libusb1-1.0.0-1.fc11
--------------------
* Mon Dec 15 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.0.0-1
- Update to 1.0.0


mailcap-2.1.29-1.fc11
---------------------
* Mon Dec 15 17:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> 2.1.29-1
- update mime.types (Ville Skytt??) (#476455)


manaworld-0.0.27-1.fc11
-----------------------
* Mon Dec 15 17:00:00 2008 Wart <wart at kobold.org> 0.0.27-1
- Update to 0.0.27


mesa-7.2-0.15.fc10
------------------
* Thu Dec  4 17:00:00 2008 Dave Airlie <airlied at redhat.com> 7.2-0.15
- r300-dont-fail-on-fog.patch: dirty workaround hope it works


mingw32-binutils-2.19-1.fc11
----------------------------
* Mon Dec 15 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.19-1
- New upstream version 2.19.


mingw32-w32api-3.13-1.fc11
--------------------------
* Mon Dec 15 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.13-1
- New upstream version 3.13.


mysql-connector-odbc-3.51.26r1127-1.fc11
----------------------------------------

netpbm-10.35.57-1.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 10.35.57-1
- update to 10.35.57

* Thu Nov  6 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 10.35.55-1
- update to 10.35.55


nmap-4.76-2.fc11
----------------
* Mon Dec 15 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 2:4.77-2
- bump release for rebuild

* Mon Dec 15 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 2:4.76-1
- new upstream version 4.76
- use consolehelper for root auth


nss_compat_ossl-0.9.4-2.fc11
----------------------------
* Mon Dec 15 17:00:00 2008 Rob Crittenden <rcritten at redhat.com> - 0.9.4-2
- Patch to fix segfault in parsing ciphers (#476519)


ochusha-0.5.99.70-0.4.cvs20081216T0245.fc11
-------------------------------------------
* Tue Dec 16 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


olpc-utils-0.89-7.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.89-7
- Fix deps and rebuild


openais-0.91-4.svn1667.fc11
---------------------------
* Mon Dec 15 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 0.91-4.svn1667
- No change rebuild against newer corosync.


openct-0.6.15-1.fc11
--------------------

openldap-2.4.12-2.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> 2.4.11-2
- rebuild for libltdl, i.e. copy config.sub|guess from new location


opensc-0.11.6-1.fc11
--------------------

perl-Event-RPC-1.01-1.fc11
--------------------------
* Tue Dec 16 17:00:00 2008 kwizart < kwizart at gmail.com > - 1.01-1
- Update to 1.01


perl-HTTP-Server-Simple-Mason-0.11-1.fc11
-----------------------------------------
* Mon Dec 15 17:00:00 2008 Ralf Cors??pius <rc040203 at fedoraproject.org> - 0.11-1
- Upstream update.


perl-IO-All-0.39-1.fc11
-----------------------
* Mon Dec 15 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.39-1
- Update to 0.39.
- Fix permissions on *.pm.


perl-Imager-0.67-1.fc11
-----------------------
* Mon Dec 15 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.67-1
- Update to 0.67.


perl-Mail-SPF-2.006-1.fc11
--------------------------
* Fri Dec 12 17:00:00 2008 Steven Pritchard <steve at kspei.com> 2.006-1
- Update to 2.006.


perl-Module-ScanDeps-0.89-1.fc11
--------------------------------
* Mon Dec 15 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.89-1
- Update to 0.89.
- BR Test::More and prefork.
- Improve description.


perl-PAR-Dist-0.40-1.fc11
-------------------------
* Mon Dec 15 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.40-1
- Update to 0.40.
- BR Archive::Zip and YAML::Tiny for t/03merge_meta.


perl-Socket6-0.20-1.fc11
------------------------

perl-Text-SpellChecker-0.04-1.fc11
----------------------------------
* Mon Dec 15 17:00:00 2008 Paul Howarth <paul at city-fan.org> 0.04-1
- Update to 0.04


pinball-0.3.1-12.fc11
---------------------
* Mon Nov 24 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 0.3.1-12
- Cleaned up summary.


pitivi-0.11.3-1.fc11
--------------------
* Mon Dec 15 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.3-1
- Update to 0.11.3


python-kerberos-1.1-3.1.fc11
----------------------------
* Mon Dec 15 17:00:00 2008 Simo Sorce <ssorce at redhat.com> - 1.1-3.1
- Fix minor issue with delegation patch

* Fri Dec 12 17:00:00 2008 Simo Sorce <ssorce at redhat.com> - 1.1-3
- Add delegation patch


python-paver-0.8.1-5.fc11
-------------------------
* Mon Dec 15 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 0.8.1-5
- Require python-setuptools as the paver app is a setuptools script.

* Mon Dec 15 17:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.8.1-4
- Require python-devel.


python-psycopg-1.1.21-11.fc11
-----------------------------
* Mon Dec 15 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1.1.21-11
- point configure at the mx DateTime header

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.21-9
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.1.21-10
- BuildRequires: mx -> mx-devel


qtiplot-0.9-11.fc11
-------------------
* Mon Dec 15 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.9-11
- rebuild

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.9-10
- Rebuild for Python 2.6

* Mon Feb 18 17:00:00 2008 Fedora Release Engineering <rel-eng at fedoraproject.org> - 0.9-9
- Autorebuild for GCC 4.3


rdiff-backup-1.2.2-1.fc11
-------------------------
* Mon Dec 15 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 1.2.2-1
- Update to 1.2.2 (bug 476539)


rsyslog-3.21.9-1.fc11
---------------------
* Mon Dec 15 17:00:00 2008 Peter Vrabec <pvrabec at redhat.com> 3.21.9-1
- update is fixing $AllowedSender security issue


setroubleshoot-plugins-2.0.12-1.fc11
------------------------------------
* Wed Dec  3 17:00:00 2008 <dwalsh at redhat.com> - 2.0.12-1
- Fix restorecon plugin


shared-mime-info-0.51-6.fc11
----------------------------
* Mon Dec 15 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.51-6
- Update with comments from Orcan Ogetbil <orcanbahri at yahoo.com>


spamassassin-3.2.5-3.fc11
-------------------------
* Mon Dec 15 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 3.2.5-3
- Update for merge review - bug 226426


stapitrace-1.0.0-22.20080622cvs_alpha.fc11
------------------------------------------
* Fri Dec 12 17:00:00 2008 Maynard Johnson <maynardj at us.ibm.com>
- updates to match SystemTap 0.8


sugar-turtleart-23-1.fc11
-------------------------
* Mon Dec 15 17:00:00 2008 Bryan Kearney <bkearney at redhat.com> + 23-1
- caching images
- Russian support, minor fixes to FR and MN


telepathy-glib-0.7.20-1.fc11
----------------------------
* Mon Dec 15 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.20-1
- Update to 0.7.20.


tinyerp-4.2.3.4-3.fc11
----------------------
* Fri Dec  5 17:00:00 2008 Dan Hor??k <dan[at]danny.cz> 4.2.3.4-3
- add PyXML as dependency for the server subpackage (Resolves: #474674)
- add basic support for customizations stored in addons/custom (Resolves: #466089)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 4.2.3.4-2
- Rebuild for Python 2.6

* Thu Nov 20 17:00:00 2008 Dan Hor??k <dan[at]danny.cz> 4.2.3.4-1
- update to upstream version 4.2.3.4
- spec and package cleanup


ttmkfdir-3.0.9-28.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Pravin Satpute <psatpute at redhat.com> - 3.0.9-28
- modified spec file as per merge review suggestions bug 226506


xdemorse-1.3-1.fc11
-------------------
* Mon Dec 15 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.3-1
- misc cleanups
- fix desktop file
- new upstream release


xorg-x11-drv-ati-6.9.0-62.fc10
------------------------------
* Tue Dec  9 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-62
- radeon-modeset.patch: fix resume with no DRI + another 2D/3D issue


xorg-x11-server-1.5.3-6.fc10
----------------------------
* Thu Dec 11 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.5.3-6
- xserver-1.5.3-idletime-fix.patch: Fix IDLETIME infinite CPU usage.


zoneminder-1.23.3-2.fc11
------------------------
* Mon Dec 15 17:00:00 2008 Martin Ebourne <martin at zepler.org> - 1.23.3-2
- Fix permissions on zm.conf


Summary:
Added Packages: 9
Removed Packages: 0
Modified Packages: 77
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	audacity-1.3.5-0.8.beta.fc10.i386 requires libvamp-hostsdk.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.i386 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.i386 requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.i386 requires libpython2.5.so.1.0
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.i386 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	audacity-1.3.5-0.8.beta.fc10.x86_64 requires libvamp-hostsdk.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.i386 requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.x86_64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.x86_64 requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mail-notification-5.4-5.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.x86_64 requires python(abi) = 0:2.5
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.x86_64 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	raydium-1.2-10.fc10.i386 requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.x86_64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	audacity-1.3.5-0.8.beta.fc10.ppc requires libvamp-hostsdk.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	efreet-devel-0.5.0.050-1.fc11.ppc requires pkgconfig(ecore-file)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	ghc-gtk2hs-gtkglext-0.9.13-6.20081108.fc11.ppc requires ghc-ghc-gtk2hs = 0:0.9.13-6.20081108.fc11
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mail-notification-5.4-5.fc11.ppc requires libgmime-2.0.so.2
	maniadrive-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	maniadrive-track-editor-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires python(abi) = 0:2.5
	1:net-snmp-python-5.4.2.1-5.fc11.ppc requires libpython2.5.so.1.0
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.ppc requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	raydium-1.2-10.fc10.ppc requires libphp5-5.2.6.so
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	audacity-1.3.5-0.8.beta.fc10.ppc64 requires libvamp-hostsdk.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	certmaster-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	efreet-devel-0.5.0.050-1.fc11.ppc64 requires pkgconfig(ecore-file)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	func-0.23-2.fc11.noarch requires python(abi) = 0:2.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mail-notification-5.4-5.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	maniadrive-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	maniadrive-track-editor-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:net-snmp-python-5.4.2.1-5.fc11.ppc64 requires python(abi) = 0:2.5
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.16-1.fc11.noarch requires perl(Class::Adapter)
	perl-XML-LibXSLT-1.66-2.fc10.ppc64 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	raydium-1.2-10.fc10.ppc64 requires libphp5-5.2.6.so()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5





From mcepl at redhat.com  Tue Dec 16 16:27:02 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 16 Dec 2008 17:27:02 +0100
Subject: Fedora 10 - Boot Analysis
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<200812161522.mBGFMsiq032572@laptop14.inf.utfsm.cl>
	<5256d0b0812160809t68f0cc48w8dd573e9d95dac34@mail.gmail.com>
Message-ID: <mf1l16xu1e.ln2@ppp1053.in.ipex.cz>

On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
> Nothing to say you can't re-enable it yourself. I don't have a
> permanent connection to the net but evolution happily holds it in my
> outbox until I go back online and can connect to a network. Fedora can

I have a nasty surprise for you -- Fedora is not Windows, so it 
would is not only for people who use Evolution / Kmail 
/ Thunderbird.

Mat?j



From jkeating at redhat.com  Tue Dec 16 17:42:18 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Dec 2008 09:42:18 -0800
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <200812161034.01979.opensource@till.name>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<1229412302.3518.30.camel@localhost.localdomain>
	<1229412385.3518.31.camel@localhost.localdomain>
	<200812161034.01979.opensource@till.name>
Message-ID: <1229449338.2590.11.camel@localhost.localdomain>

On Tue, 2008-12-16 at 10:33 +0100, Till Maas wrote:
> 
> Afaics you only cc'ed the maintainer (and not the co-maintainers or sponsor) 
> and did not add the comment to the update itself in Bodhi, which is where the 
> comment belongs at least to, e.g. with an additional pointer to the 
> mailinglist archive.

Good points.  I didn't cc the co-maintainers as I don't have a
quick/easy way of accessing that information.  We don't expose that in
our pre-built aliases.

Also I should have commented in bodhi as well, that is a good point.

> 
> But in general I think it's good that you help you improve the information in 
> updates announcements. :-)

Thanks!  I'm just trying to take action where I think action is needed.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/a111e427/attachment.sig>

From arjan at infradead.org  Tue Dec 16 17:43:05 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 16 Dec 2008 18:43:05 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <mf1l16xu1e.ln2@ppp1053.in.ipex.cz>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<200812161522.mBGFMsiq032572@laptop14.inf.utfsm.cl>
	<5256d0b0812160809t68f0cc48w8dd573e9d95dac34@mail.gmail.com>
	<mf1l16xu1e.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081216184305.2cb96ade@infradead.org>

On Tue, 16 Dec 2008 17:27:02 +0100
Matej Cepl <mcepl at redhat.com> wrote:

> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
> > Nothing to say you can't re-enable it yourself. I don't have a
> > permanent connection to the net but evolution happily holds it in my
> > outbox until I go back online and can connect to a network. Fedora
> > can
> 
> I have a nasty surprise for you -- Fedora is not Windows, so it 
> would is not only for people who use Evolution / Kmail 
> / Thunderbird
sure. and mutt and .. and ..

there's no reason the local MTA (as opposed the thing that listens to
port 25 for the world) can't be smart enough to only go into spool mode
if it has trouble delivering.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From mw_triad at users.sourceforge.net  Tue Dec 16 18:02:29 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 16 Dec 2008 12:02:29 -0600
Subject: RFC: Description text in packages
In-Reply-To: <1229413137.7794.1.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>	<494688AA.8060505@gmail.com>
	<1229365091.25084.25.camel@arekh.okg>	<gi6vh6$cpr$1@ger.gmane.org>
	<1229413137.7794.1.camel@arekh.okg>
Message-ID: <gi8qfm$fh$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Le lundi 15 d?cembre 2008 ? 19:16 -0600, Matthew Woehlke a ?crit :
>> Nicolas Mailhot wrote:
>>> Le lundi 15 d?cembre 2008 ? 08:41 -0800, Toshio Kuratomi a ?crit :
>>>> Currently, I'm opposed to having a Guideline that mandates UTF-8 over
>>>> ASCII.
>>> And I'm opposed to continuing to abuse ASCII glyphs and pretend they
>>> stand for something other than their creators intended. One couldn't
>>> avoid it when the available encoding didn't provide a clean way to write
>>> some stuff, but doing it in 2008 is plain dumb.
>> I must have missed the 'fancy quotes' keys on my keyboard.
> 
> Complain to your xkb maintainer. Mine has ????????

And those would be what buttons again?

" is a clearly-marked key on my keyboard. Those others are not. Until 
mainstream keyboards (including "mainstream in the U.S.") have actual 
keys for fancy quotes, I think asking/requiring people to use something 
other than " is arguably unreasonable.

Saying "xkb supports it" doesn't help if I have no idea how to make xkb 
generate those characters (plus, what do I do if I'm not using X?).

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet



From tim at niemueller.de  Tue Dec 16 18:09:35 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Tue, 16 Dec 2008 19:09:35 +0100
Subject: Memory/filesystem corruption
Message-ID: <4947EEDF.9000801@niemueller.de>

Hi Fedora folks.

With F-10 I've started to see random crashes of several applications and
complete freezes of the machine. It seems that some kind of memory
and/or filesystem corruption causes these problems, as it usually can be
fixed by rebooting or re-installing the package in question.
Suspend/resume cycles seem to make the problem more likely, though it
also happens without according to comments in bugzilla.

I've filed a bug at https://bugzilla.redhat.com/show_bug.cgi?id=476203

Is anyone else seeing this? Does someone have an idea what might be
causing this? I'm trying to get more people on the train and gain
attention to get more data to narrow down the cause of the problem.

Regards,
	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From nicolas.mailhot at laposte.net  Tue Dec 16 18:15:35 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 19:15:35 +0100
Subject: RFC: Description text in packages
In-Reply-To: <gi8qfm$fh$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<gi6vh6$cpr$1@ger.gmane.org> <1229413137.7794.1.camel@arekh.okg>
	<gi8qfm$fh$1@ger.gmane.org>
Message-ID: <1229451335.13024.4.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 12:02 -0600, Matthew Woehlke a ?crit :
> Nicolas Mailhot wrote:
> > Le lundi 15 d?cembre 2008 ? 19:16 -0600, Matthew Woehlke a ?crit :
> >> Nicolas Mailhot wrote:
> >>> Le lundi 15 d?cembre 2008 ? 08:41 -0800, Toshio Kuratomi a ?crit :
> >>>> Currently, I'm opposed to having a Guideline that mandates UTF-8 over
> >>>> ASCII.
> >>> And I'm opposed to continuing to abuse ASCII glyphs and pretend they
> >>> stand for something other than their creators intended. One couldn't
> >>> avoid it when the available encoding didn't provide a clean way to write
> >>> some stuff, but doing it in 2008 is plain dumb.
> >> I must have missed the 'fancy quotes' keys on my keyboard.
> > 
> > Complain to your xkb maintainer. Mine has ????????
> 
> And those would be what buttons again?

Those would be whatever the maintainer of your xkb layout wants them to
be. Adding this stuff to an xkb layout is not rocket science and has
been possible for a long time.

> " is a clearly-marked key on my keyboard. Those others are not. Until 
> mainstream keyboards (including "mainstream in the U.S.") have actual 
> keys for fancy quotes, I think asking/requiring people to use something 
> other than " is arguably unreasonable.

There is not need to mark stuff on keyboards to assign keycodes to them
and indeed several millions on people have generated the euro using
unmarked keys for several years when it was introduced.

> Saying "xkb supports it" doesn't help if I have no idea how to make xkb 
> generate those characters (plus, what do I do if I'm not using X?).

Then you're not writing human text, you're writing computer code.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/8e72e847/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Dec 16 18:17:29 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 19:17:29 +0100
Subject: RFC: Description text in packages
In-Reply-To: <385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
Message-ID: <1229451449.13024.6.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 19:32 +0200, Muayyad AlSadi a ?crit :
> >  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
> +1
> 
> please just "" or ''
> the use of UTF-8 fancy quotations should be done by the renderer

No it should not. This is the road to incompatible software and piles of
quirks (as in, everyone just has to edit text in Microsoft word because
input and rendering logic has been implemented there instead of a
generic standard encoding level)

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/e546f26b/attachment.sig>

From cmadams at hiwaay.net  Tue Dec 16 18:31:38 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 16 Dec 2008 12:31:38 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216175219.3d280df2@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<200812161522.mBGFMsiq032572@laptop14.inf.utfsm.cl>
	<5256d0b0812160809t68f0cc48w8dd573e9d95dac34@mail.gmail.com>
	<20081216175219.3d280df2@infradead.org>
Message-ID: <20081216183138.GC1558744@hiwaay.net>

Once upon a time, Arjan van de Ven <arjan at infradead.org> said:
> and it's not like sendmail/exim/whatever can't decide to become a daemon
> if it can't deliver... but only then.

That would require more privilege in the /usr/sbin/sendmail program.
For example, with sendmail, the binary is setgid-smmsp, which is just
enough privilege to write a new entry to the MSP queue directory.  You
probably don't want to run a new daemon as a normal user, so then you
have to have a setuid-(someuser|root) binary somewhere to start a daemon
on demand.

You'd still need to do something on boot, since there could be entries
in the queue from the last time the system was up (at which point, you
might as well just start a queue monitor daemon, maybe something using
inotify to only wake up when a new queue entry is written to be a little
more efficient).

Not saying it isn't possible, but it would take some (possibly not
insignificant) changes to make it work sanely and securely and cover the
corner cases correctly.

Also, part of the justification for a local MTA is that some programs
want to use SMTP on 127.0.0.1, which requires some kind of daemon
running there (either an MTA or xinetd to fork an MTA on demand).

If you want a local MTA (which IMHO should be there) and want to make it
work differently (start running a queue only on demand for example),
you're probably going to be better off writing an MTA to match your
special requirements (or starting off with something simple like ssmtp),
rather than trying to shoe-horn such changes into a "full fledged" MTA
like sendmail/postfix/etc.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From mw_triad at users.sourceforge.net  Tue Dec 16 18:36:05 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 16 Dec 2008 12:36:05 -0600
Subject: RFC: Description text in packages
In-Reply-To: <1229451335.13024.4.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>	<494688AA.8060505@gmail.com>
	<1229365091.25084.25.camel@arekh.okg>	<gi6vh6$cpr$1@ger.gmane.org>
	<1229413137.7794.1.camel@arekh.okg>	<gi8qfm$fh$1@ger.gmane.org>
	<1229451335.13024.4.camel@arekh.okg>
Message-ID: <gi8sem$9jf$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Le mardi 16 d??cembre 2008 ?  12:02 -0600, Matthew Woehlke a ??crit :
>> And those would be what buttons again?
> 
> Those would be whatever the maintainer of your xkb layout wants them to
> be. Adding this stuff to an xkb layout is not rocket science and has
> been possible for a long time.

So one of they keys on my keyboard should do something other than what I 
expect?

>> Saying "xkb supports it" doesn't help if I have no idea how to make xkb 
>> generate those characters (plus, what do I do if I'm not using X?).
> 
> Then you're not writing human text, you're writing computer code.

Huh?

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet



From nikolay at vladimiroff.com  Tue Dec 16 18:38:25 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Tue, 16 Dec 2008 20:38:25 +0200
Subject: RFC: Description text in packages
In-Reply-To: <1229451449.13024.6.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
Message-ID: <a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>

2008/12/16 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> Le mardi 16 d?cembre 2008 ? 19:32 +0200, Muayyad AlSadi a ?crit :
>> >  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
>> +1
>>
>> please just "" or ''
>> the use of UTF-8 fancy quotations should be done by the renderer
>
> No it should not. This is the road to incompatible software and piles of
> quirks (as in, everyone just has to edit text in Microsoft word because
> input and rendering logic has been implemented there instead of a
> generic standard encoding level)
>
> --
> Nicolas Mailhot
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

>> >  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
+1

It's not piles of quirks it's a simple parser.
Take wiki syntax for example. All wikis(i know) rely on simple syntax
that uses ASCII characters to display somewhat structured and
formatted content. And it's common to use "*" to mark unordered list.
And also different languages have different types of quotes for
example in Bulgarian the quoted text looks like this : ,, quote " .
And if someone wants to translate the package summary he must go
trough the UTF symbol table to find the specific quote symbol.  This
can be simply solved with a parser.

The representation should be different from the content.

And if a machine will display some text to a person then machine code
must be written.



-- 
NV



From nicolas.mailhot at laposte.net  Tue Dec 16 18:57:58 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 19:57:58 +0100
Subject: RFC: Description text in packages
In-Reply-To: <gi8sem$9jf$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<gi6vh6$cpr$1@ger.gmane.org> <1229413137.7794.1.camel@arekh.okg>
	<gi8qfm$fh$1@ger.gmane.org> <1229451335.13024.4.camel@arekh.okg>
	<gi8sem$9jf$1@ger.gmane.org>
Message-ID: <1229453878.13999.22.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 12:36 -0600, Matthew Woehlke a ?crit :
> Nicolas Mailhot wrote:
> > Le mardi 16 d??cembre 2008 ?  12:02 -0600, Matthew Woehlke a ??crit :
> >> And those would be what buttons again?
> > 
> > Those would be whatever the maintainer of your xkb layout wants them to
> > be. Adding this stuff to an xkb layout is not rocket science and has
> > been possible for a long time.
> 
> So one of they keys on my keyboard should do something other than what I 
> expect?

Bzzt. On an average keyboard, about 50% of the alt-ed space is not
marked and let to the implementators discretion. Without going into
Canadian six-level key complexity, four-level xkb layouts are the norm
and I dare you to find a keyboard where all four levels are marked.

> Then you're not writing human text, you're writing computer code.
> Huh?

No efforts are expended by console maintainers to make it keep up with
the curreent demands of human text. Its target is ?debugging things gone
wrong? ?

? ?I know the discussions I've had with distributions on these subjects
they are thinking X is the user interface full stop, except for
debug/things gone wrong.? (Alan Cox, 2008-12-01).

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/7ce60bd5/attachment.sig>

From a.badger at gmail.com  Tue Dec 16 19:01:31 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 16 Dec 2008 11:01:31 -0800
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <20081216090217.GA23497@amd.home.annexia.org>
References: <1229389958.3518.21.camel@localhost.localdomain>	<494719C0.9020307@silfreed.net>
	<20081216090217.GA23497@amd.home.annexia.org>
Message-ID: <4947FB0B.7000400@gmail.com>

Richard W.M. Jones wrote:
> Mine is empty too:
> 
> https://admin.fedoraproject.org/pkgdb/users/info/rjones
> 
> Is there some way to edit this?
> 
No.  But I would love to see some of these ideas implemented :-)

If anyone wants to work on this, it's a relatively segregated part of
the pkgdb so it should be reasonably easy to get started on working on it.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/1972ab76/attachment.sig>

From jamundso at gmail.com  Tue Dec 16 18:45:21 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Tue, 16 Dec 2008 12:45:21 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216184305.2cb96ade@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org> <mf1l16xu1e.ln2@ppp1053.in.ipex.cz>
	<20081216184305.2cb96ade@infradead.org>
Message-ID: <200812161245.22007.jamundso@gmail.com>

On Tue December 16 2008 11:43:05 Arjan van de Ven wrote:
> On Tue, 16 Dec 2008 17:27:02 +0100
> Matej Cepl <mcepl at redhat.com> wrote:
> > I have a nasty surprise for you -- Fedora is not Windows, so it
> > would is not only for people who use Evolution / Kmail
> > / Thunderbird
>
> sure. and mutt and .. and ..
>
> there's no reason the local MTA (as opposed the thing that listens to
> port 25 for the world) can't be smart enough to only go into spool mode
> if it has trouble delivering.

Exactly the way it works in Courier, an MTA not even in Fedora (yet?).

jerry

-- 
To be named later.



From nicolas.mailhot at laposte.net  Tue Dec 16 19:07:34 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 20:07:34 +0100
Subject: RFC: Description text in packages
In-Reply-To: <a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
Message-ID: <1229454454.13999.31.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 20:38 +0200, Nikolay Vladimirov a ?crit :

> >> >  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
> +1
> 
> It's not piles of quirks it's a simple parser.

ROTFL. Sorry. 

> Take wiki syntax for example. All wikis(i know) rely on simple syntax
> that uses ASCII characters to display somewhat structured and
> formatted content.

Wiki support UTF-8 just fine

> And it's common to use "*" to mark unordered list.

And it's common to use xml tags and all kinds of other stuff but that's
irrelevant because spec syntax is plain text not wiki markup.

> And also different languages have different types of quotes for
> example in Bulgarian the quoted text looks like this : ,, quote " .

Converting text to the appropriate typography rules and symbols is part
of the job of the translator (just like applying the correct grammar and
syntax ordering rules). Translating has never been limited to
word-by-word conversion.

> And if someone wants to translate the package summary he must go
> trough the UTF symbol table to find the specific quote symbol.

If someone does not have the quote symbols appropriate to his language
in his keyboard layout he should get the maintainer of this layout to
fix it.

> This can be simply solved with a parser.

It can not. Unicode is a monster but people jumped on it because it was
still simpler than all the parsers and quirks and ?smart? parser rules
that antedated it.

> The representation should be different from the content.

This is not representation this is text encoding.
Chosing the font style and size is representation.

> And if a machine will display some text to a person then machine code
> must be written.

And the spec to write machine code in this context is plain text that
uses the UTF-8 standard.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/c48a3be3/attachment.sig>

From jkeating at redhat.com  Tue Dec 16 19:12:42 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Dec 2008 11:12:42 -0800
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <645d17210812010307m570d578aq5b652a70ba538456@mail.gmail.com>
References: <1225820483.24018.35.camel@luminos.localdomain>
	<645d17210811040956m7cbe7701mad0b49701e6222e5@mail.gmail.com>
	<3170f42f0811050629t6251d858r499d002c54ca69ca@mail.gmail.com>
	<1225921510.9784.0.camel@PB3.Linux>
	<645d17210812010307m570d578aq5b652a70ba538456@mail.gmail.com>
Message-ID: <1229454762.2590.17.camel@localhost.localdomain>

On Mon, 2008-12-01 at 11:07 +0000, Jonathan Underwood wrote:
> Jesse - any progress on this? We've requested access to the
> packages ...

Sorry for the delay.  The primary maintainer has been found, and all who
applied have been granted co-maintainer status.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/9e91e107/attachment.sig>

From a.badger at gmail.com  Tue Dec 16 19:11:26 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 16 Dec 2008 11:11:26 -0800
Subject: RFC: Description text in packages
In-Reply-To: <49474355.6000703@leemhuis.info>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<49474355.6000703@leemhuis.info>
Message-ID: <4947FD5E.8080607@gmail.com>

Thorsten Leemhuis wrote:
> On 15.12.2008 16:37, Richard Hughes wrote:
>> [...]
>> Next on my list are insane descriptions. For instance, just take a look
>> at the description for enlightenment (many pages in length) 
> 
> FYI, this was noticed, reported, discussed and forgotten again:
> https://www.redhat.com/archives/fedora-packaging/2008-September/msg00011.html
> 
<nod> The Guidelines portion had some traction then wandered off.

The Enlightenment description in specific, though, has been changed:
https://www.redhat.com/archives/fedora-packaging/2008-September/msg00031.html

(Verified that this is what's in cvs.)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/cd6042aa/attachment.sig>

From mw_triad at users.sourceforge.net  Tue Dec 16 19:17:08 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 16 Dec 2008 13:17:08 -0600
Subject: RFC: Description text in packages
In-Reply-To: <1229453878.13999.22.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>	<494688AA.8060505@gmail.com>
	<1229365091.25084.25.camel@arekh.okg>	<gi6vh6$cpr$1@ger.gmane.org>
	<1229413137.7794.1.camel@arekh.okg>	<gi8qfm$fh$1@ger.gmane.org>
	<1229451335.13024.4.camel@arekh.okg>	<gi8sem$9jf$1@ger.gmane.org>
	<1229453878.13999.22.camel@arekh.okg>
Message-ID: <gi8urk$hkv$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Le mardi 16 d??cembre 2008 ?  12:36 -0600, Matthew Woehlke a ??crit :
>> Nicolas Mailhot wrote:
>>> Le mardi 16 d????cembre 2008 ??  12:02 -0600, Matthew Woehlke a ????crit :
>>>> And those would be what buttons again?
>>> Those would be whatever the maintainer of your xkb layout wants them to
>>> be. Adding this stuff to an xkb layout is not rocket science and has
>>> been possible for a long time.
>> So one of they keys on my keyboard should do something other than what I 
>> expect?
> 
> Bzzt. On an average keyboard, about 50% of the alt-ed space is not
> marked and let to the implementators discretion. Without going into
> Canadian six-level key complexity, four-level xkb layouts are the norm
> and I dare you to find a keyboard where all four levels are marked.

So you're infringing on shortcut space instead? Well... as long as you 
aren't using letters I suppose that isn't horrible (or else, using 
alt+shift), but doesn't solve how to tell people such key combinations 
exist in the first place.

(Sigh. I need to file a bug against TB not defaulting to utf8.)

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet



From vonbrand at inf.utfsm.cl  Tue Dec 16 19:19:27 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 16 Dec 2008 16:19:27 -0300
Subject: RFC: Description text in packages
In-Reply-To: <a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
Message-ID: <200812161919.mBGJJRtK001864@laptop14.inf.utfsm.cl>

Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> 2008/12/16 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> > Le mardi 16 d??cembre 2008 ?? 19:32 +0200, Muayyad AlSadi a ??crit :
> >> >  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
> >> +1
> >>
> >> please just "" or ''
> >> the use of UTF-8 fancy quotations should be done by the renderer
> >
> > No it should not. This is the road to incompatible software and piles of
> > quirks (as in, everyone just has to edit text in Microsoft word because
> > input and rendering logic has been implemented there instead of a
> > generic standard encoding level)
> 
> >> >  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
> +1
> 
> It's not piles of quirks it's a simple parser.
> Take wiki syntax for example. All wikis(i know) rely on simple syntax
> that uses ASCII characters to display somewhat structured and
> formatted content.

I know three (moin-moin, twiki, and trac), and they use very different
syntaxes, with wildly different ranges of features. /That/ is the kind of
problem being hinted at above.
-- 
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 stlwrt at gmail.com  Tue Dec 16 19:37:08 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Tue, 16 Dec 2008 21:37:08 +0200
Subject: Looking for [co]maintainer for EFL+E17
Message-ID: <d25f375f0812161137j3d41bda9u3b1ea35cba24f40c@mail.gmail.com>

Is anyone interested in maintaining Enlightenment Foundation Libraries
and Enlightenment DR17?

I upstreamed most of the patches and specs are pretty simple now, but
combining college and job turned out to be pretty hard and i can't
spend much time hacking now =(

P.S. I updated specs to latest snapshots but building e17 failed
(looks like rawhide-specific problem)

-- 
http://scwlab.com



From davej at redhat.com  Sun Dec 14 20:30:24 2008
From: davej at redhat.com (Dave Jones)
Date: Sun, 14 Dec 2008 15:30:24 -0500
Subject: Alternatives to serial console for capturing oopses
In-Reply-To: <49435AFE.4070400@redhat.com>
References: <cone.1229122645.115179.23287.500@commodore.email-scan.com>
	<1229123204.2898.1.camel@sb-home>
	<cone.1229130654.603222.26677.500@commodore.email-scan.com>
	<49435AFE.4070400@redhat.com>
Message-ID: <20081214203024.GA11267@redhat.com>

On Sat, Dec 13, 2008 at 12:49:34AM -0600, Eric Sandeen wrote:
 > Sam Varshavchik wrote:
 > > nodata writes:
 > > 
 > >> Am Freitag, den 12.12.2008, 17:57 -0500 schrieb Sam Varshavchik:
 > >>> I've got a quad-core dual x86_64 server that, so far, reproducably locks up 
 > >>> under every 2.6.27 kernel released for F9 so far, when I run a build cycle. 
 > >>> The last kernel that manages to survive under load is 2.6.26.6-79.fc9, so 
 > >>> I'll continue to boot it until I get a 2.6.27 kernel that doesn't croak on 
 > >>> me.
 > >>>
 > >>> Given that the hardware does not have a serial port, how else can I capture 
 > >>> an oops, if one is being generated? At least I hope that there'll be an oops 
 > >>> for me to capture.
 > >>>
 > >> Take a look at netdump.
 > > 
 > > Took a look.
 > > 
 > > 1) Only the server component is present in Fedora. There is no client. And, 
 > > of course, I need the client.
 > 
 > I haven't used netdump for a while but:
 > 
 > http://kojipkgs.fedoraproject.org/packages/netdump/0.7.16/13/x86_64/
 > 
 > for example seems to have both.  *shrug*
 > 
 > > 2) The client package requires additional kernel modules to be built. If you 
 > > are actually using netdump in Fedora, please explain how.
 > > 
 > > 3) netdump only supports a small set of NICs. netdump does not support my 
 > > NIC.

Umm, wasn't that the stuff we shipped in RHEL4 that never made it upstream ?
Or has this been reworked to work with kdump?

If the former, it isn't going to work ever due to the lack of drivers
in the kernel, and should be removed from Fedora.

	Dave

-- 
http://www.codemonkey.org.uk



From nicolas.mailhot at laposte.net  Tue Dec 16 19:46:45 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 20:46:45 +0100
Subject: RFC: Description text in packages
In-Reply-To: <gi8urk$hkv$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<gi6vh6$cpr$1@ger.gmane.org> <1229413137.7794.1.camel@arekh.okg>
	<gi8qfm$fh$1@ger.gmane.org> <1229451335.13024.4.camel@arekh.okg>
	<gi8sem$9jf$1@ger.gmane.org> <1229453878.13999.22.camel@arekh.okg>
	<gi8urk$hkv$1@ger.gmane.org>
Message-ID: <1229456805.15451.2.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 13:17 -0600, Matthew Woehlke a ?crit :
> Nicolas Mailhot wrote:

> > Bzzt. On an average keyboard, about 50% of the alt-ed space is not
> > marked and let to the implementators discretion. Without going into
> > Canadian six-level key complexity, four-level xkb layouts are the norm
> > and I dare you to find a keyboard where all four levels are marked.
> 
> So you're infringing on shortcut space instead?

This is not ?infringing on shortcut space? this is using a normal
four-level or more xkb layout.

The vast majority of xkb layouts are four level. That includes the en_US
intl layout which is probably the most used one.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/d9eb6986/attachment.sig>

From nikolay at vladimiroff.com  Tue Dec 16 20:02:54 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Tue, 16 Dec 2008 22:02:54 +0200
Subject: RFC: Description text in packages
In-Reply-To: <1229454454.13999.31.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
Message-ID: <a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>

2008/12/16 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> Le mardi 16 d?cembre 2008 ? 20:38 +0200, Nikolay Vladimirov a ?crit :
>
>> >> >  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
>> +1
>>
>> It's not piles of quirks it's a simple parser.
>
> ROTFL. Sorry.

uh?
It's a development discussion forum if you think I said something
stupid or plain braindamadge. Explain why it's stupid. Don't ROTFL and
stuff, please.

>> Take wiki syntax for example. All wikis(i know) rely on simple syntax
>> that uses ASCII characters to display somewhat structured and
>> formatted content.
>
> Wiki support UTF-8 just fine

yes. i ment the actual syntax like it uses "*" to mark unordered list
but it displays "unicode bullet" ( i can't find it on my layout)
Like it detects depth with ident and replaces '*' to look nicely.

>> And it's common to use "*" to mark unordered list.
>
> And it's common to use xml tags and all kinds of other stuff but that's
> irrelevant because spec syntax is plain text not wiki markup.
>

I'm not talking about syntax in specs, i'm talking about package kit.
I agree that there must be some standard for writing descriptions with
limitations like:
length, ident, spacing ... I don't agree with using UTF characters in
summaries .
Like in mutt i can use an utf character to display threads ( it's some
angle symbol)
but i can't see this symbol with some ssh or something ( yes, my
software is buggy )
My point is that mutt allowed me to use only ASCII chars for
displaying the threads.

So  if i'm using some really outdated client to connect to my fedora
host ( like telnet or serial or something)
And I use command-line tools to browse packages and read summaries I
will not see these UTF symbols.

As I understand the problem is that PackageKit can't display stuff. So
let's make stuff more standard and leave PackageKit to do all the
friendly displaying.

>> And also different languages have different types of quotes for
>> example in Bulgarian the quoted text looks like this : ,, quote " .
>
> Converting text to the appropriate typography rules and symbols is part
> of the job of the translator (just like applying the correct grammar and
> syntax ordering rules). Translating has never been limited to
> word-by-word conversion.
>

Yes. But why do I have to do all the stuff when a machine can do it.

>> And if someone wants to translate the package summary he must go
>> trough the UTF symbol table to find the specific quote symbol.
>
> If someone does not have the quote symbols appropriate to his language
> in his keyboard layout he should get the maintainer of this layout to
> fix it.
>
>> This can be simply solved with a parser.
>
> It can not. Unicode is a monster but people jumped on it because it was
> still simpler than all the parsers and quirks and "smart" parser rules
> that antedated it.
>
>> The representation should be different from the content.
>
> This is not representation this is text encoding.
> Chosing the font style and size is representation.
>

It is representation since the encoding will be changed mainly because
in the current summaries don't look so great and are pretty chaotic in
style. Using UTF isn't going to make them more structured and
standard. Maintainers will.


>> And if a machine will display some text to a person then machine code
>> must be written.
>
> And the spec to write machine code in this context is plain text that
> uses the UTF-8 standard.
>
> --
> Nicolas Mailhot
>



--
NV



From mw_triad at users.sourceforge.net  Tue Dec 16 20:06:57 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 16 Dec 2008 14:06:57 -0600
Subject: RFC: Description text in packages
In-Reply-To: <1229456805.15451.2.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>	<494688AA.8060505@gmail.com>
	<1229365091.25084.25.camel@arekh.okg>	<gi6vh6$cpr$1@ger.gmane.org>
	<1229413137.7794.1.camel@arekh.okg>	<gi8qfm$fh$1@ger.gmane.org>
	<1229451335.13024.4.camel@arekh.okg>	<gi8sem$9jf$1@ger.gmane.org>
	<1229453878.13999.22.camel@arekh.okg>	<gi8urk$hkv$1@ger.gmane.org>
	<1229456805.15451.2.camel@arekh.okg>
Message-ID: <gi91p1$ssr$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Le mardi 16 d??cembre 2008 ?  13:17 -0600, Matthew Woehlke a ??crit :
>> Nicolas Mailhot wrote:
>>> Bzzt. On an average keyboard, about 50% of the alt-ed space is not
>>> marked and let to the implementators discretion. Without going into
>>> Canadian six-level key complexity, four-level xkb layouts are the norm
>>> and I dare you to find a keyboard where all four levels are marked.
>> So you're infringing on shortcut space instead?
> 
> This is not "infringing on shortcut space" this is using a normal
> four-level or more xkb layout.

What's the fourth level? Not alt, that's used for accelerators. Not 
ctrl, shift, meta, or any combination thereof, as those are for 
shortcuts. That leaves... menu, and combinations thereof. If 
menu+something does something special, I sure don't know about it.

You still haven't answered the education question.

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet



From bpepple at fedoraproject.org  Tue Dec 16 20:13:37 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 16 Dec 2008 15:13:37 -0500
Subject: Plan for tomorrows (20081216) FESCO meeting
Message-ID: <1229458418.6923.5.camel@localhost.localdomain>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00
UTC (13:00 EST) in #fedora-meeting on irc.freenode.org:

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/20SecondStartup

/topic FESCo-Meeting -- Meetings during holiday? Who's going to be able
to attend - 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.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/759091cd/attachment.sig>

From notting at redhat.com  Tue Dec 16 20:16:40 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 16 Dec 2008 15:16:40 -0500
Subject: RFC: Description text in packages
In-Reply-To: <1229451449.13024.6.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
Message-ID: <20081216201640.GB8506@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > please just "" or ''
> > the use of UTF-8 fancy quotations should be done by the renderer
> 
> No it should not. This is the road to incompatible software and piles of
> quirks (as in, everyone just has to edit text in Microsoft word because
> input and rendering logic has been implemented there instead of a
> generic standard encoding level)

I fail to see how using the neutral quote character ", a perfectly valid
standard unicode character, is the road to incompatible software and piles
of quirks.

Frankly, I'm surprised you don't sign your mail "???????" - think of
all the extra high bits you could use!

Bill



From katzj at redhat.com  Tue Dec 16 20:19:38 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 16 Dec 2008 15:19:38 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4947C8E0.6030002@hhs.nl>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<20081216120757.6932da20@infradead.org> <4947C3B7.5080400@redhat.com>
	<4947C8E0.6030002@hhs.nl>
Message-ID: <1229458778.5054.118.camel@erebor.bos.redhat.com>

On Tue, 2008-12-16 at 16:27 +0100, Hans de Goede wrote:
> 1) Make more services not start when not needed, for example bluetooth when 
> there is no bluetooth hardware, etc. We could even completely stop them from 
> being a service controlled by runlevel and make them be started from udev instead.

There's a tracker bug for things like this --
https://bugzilla.redhat.com/show_bug.cgi?id=222312

Jeremy



From nicolas.mailhot at laposte.net  Tue Dec 16 20:21:42 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 21:21:42 +0100
Subject: RFC: Description text in packages
In-Reply-To: <a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
Message-ID: <1229458902.15689.31.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 22:02 +0200, Nikolay Vladimirov a ?crit :
> 2008/12/16 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> > Le mardi 16 d?cembre 2008 ? 20:38 +0200, Nikolay Vladimirov a ?crit :
> >
> >> >> >  Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII.
> >> +1
> >>
> >> It's not piles of quirks it's a simple parser.
> >
> > ROTFL. Sorry.
> 
> uh?
> It's a development discussion forum if you think I said something
> stupid or plain braindamadge. Explain why it's stupid. Don't ROTFL and
> stuff, please.

There are not enough hours in my free time to expand on all the problems
trying to work around 7-bit encoding limitations without going Unicode
causes.

There is abundant literature about it (both in paper and digital form).

It's all ?simple? problems with ?easy? solutions and when you pile up
all the resulting quirks you put the Egyptians pyramids to shame.

As a bonus this stuff is highly non-standard and incompatible by
contruction.

So when you claim this is a ?simple? problem-space I'll ROTFL. Better
people than you and me hit a wall trying to solve it properly. In the
end after many failures they wrote the Unicode standard.

> >> Take wiki syntax for example. All wikis(i know) rely on simple
syntax
> >> that uses ASCII characters to display somewhat structured and
> >> formatted content.
> >
> > Wiki support UTF-8 just fine
> 
> yes. i ment the actual syntax like it uses "*" to mark unordered list
> but it displays "unicode bullet" ( i can't find it on my layout)
> Like it detects depth with ident and replaces '*' to look nicely.

You are free to write specs using wiki, tex, or sgml entities markup.
You are free to use a text editor, a word processor, an hexadecimal, or
whatever.

We expect you to convert this syntax to correct plain text in UTF-8
encoding before publication by Fedora. This is the common ground all our
package manipulating tools understand and there is no way we're going to
teach them some other markup just because you can't find some UTF-8
symbol in your layout.

If you can't write UTF-8 bullets, and can't be bothered to launch
something like gucharmap, use a sed of awk or whatever converter on your
spec files before pushing them Fedora-side, don't ask others to add code
to many tools to workaround your problems.

> >> And it's common to use "*" to mark unordered list.
> >
> > And it's common to use xml tags and all kinds of other stuff but
that's
> > irrelevant because spec syntax is plain text not wiki markup.
> >
> 
> I'm not talking about syntax in specs, 

The discussion is about the human text found in spec files.

> So  if i'm using some really outdated client to connect to my fedora
> host ( like telnet or serial or something)
> And I use command-line tools to browse packages and read summaries I
> will not see these UTF symbols.

So what? Your choice. The distro English encoding is UTF-8. If you want
things to work perfectly in the default locale use UTF-8 aware tools. We
can't be responsible for your choice to use buggy, legacy, outdated
tools. Any ASCII-oriented tool will mostly sort-of work, and anything
outside the mostly sort-of perimeter is the price you pay for using
limited tools.

If you want an ASCII-only mode (a real one, not the ?I know it's UTF-8
but please use only ASCII so I don't hit bugs in my tools?) open an
English ASCII localization group.

> As I understand the problem is that PackageKit can't display stuff.

The problem is people wrote garbage in some spec files using
ASCII-limited tools, and the PK maintainer would like this garbage
corrected so normal users are not exposed to ASCII quirks.

> So
> let's make stuff more standard and leave PackageKit to do all the
> friendly displaying.

PK is not the only tool involved, the standard already exists, and is
feature-complete without needing workaround code.

> >> And also different languages have different types of quotes for
> >> example in Bulgarian the quoted text looks like this : ,, quote " .
> >
> > Converting text to the appropriate typography rules and symbols is
part
> > of the job of the translator (just like applying the correct grammar
and
> > syntax ordering rules). Translating has never been limited to
> > word-by-word conversion.
> >
> 
> Yes. But why do I have to do all the stuff when a machine can do it.

If a machine can do it get a machine to output proper UTF-8 encoded
specfile text your side.

> It is representation since the encoding will be changed

The encoding won't be changed

>  mainly because
> in the current summaries don't look so great 

Because they have mistakes. Their authors just have to correct their
mistakes. This is no different from grammar errors and you don't expect
PK to fix the text grammar errors don't you?

> and are pretty chaotic in
> style. Using UTF isn't going to make them more structured and
> standard. Maintainers will.

Which is the whole point.
This is not a technical problem.
The current UTF-8 technical infrastructure is sufficient and there is
not need to write magic text correcting code.
People just have to do some editorial work and proof and correct their
text themselves, making sure it displays fine using simple standard
UTF-8 text rendering engines.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/2b4b6336/attachment.sig>

From bruno at wolff.to  Tue Dec 16 20:38:24 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 16 Dec 2008 14:38:24 -0600
Subject: orphaning all my packages
In-Reply-To: <f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>
References: <20081216094739.GA3877@free.fr>
	<f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>
	<20081216151415.GJ2414@free.fr>
	<f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>
Message-ID: <20081216203824.GA6656@wolff.to>

On Tue, Dec 16, 2008 at 16:17:16 +0100,
  Mary Ellen Foster <mefoster at gmail.com> wrote:
> 
> (NB: why does the "reply-to" get set so weirdly on this list? Is it a
> gmail thing or what? I see the list address in there at least twice

The reply-to header wasn't set at all. But what you were probably seeing was
related to the thread spanning two lists. On at least one message I saw,
the comment parts of the addresses in the to header were the same even
though the local parts of the addresses were different.



From nicolas.mailhot at laposte.net  Tue Dec 16 20:43:42 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 21:43:42 +0100
Subject: RFC: Description text in packages
In-Reply-To: <20081216201640.GB8506@nostromo.devel.redhat.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
Message-ID: <1229460222.15689.53.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 15:16 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > > please just "" or ''
> > > the use of UTF-8 fancy quotations should be done by the renderer
> > 
> > No it should not. This is the road to incompatible software and
> piles of
> > quirks (as in, everyone just has to edit text in Microsoft word
> because
> > input and rendering logic has been implemented there instead of a
> > generic standard encoding level)
> 
> I fail to see how using the neutral quote character ", a perfectly
> valid
> standard unicode character, is the road to incompatible software and
> piles of quirks.

And I didn't object to ?"?, I object to using accents instead of quote
characters.

> Frankly, I'm surprised you don't sign your mail "???????" -
> think of all the extra high bits you could use!

This is just another encoding abuse and it's not better than the ASCII
abuse of grave.

You want to write a latin "A" you use the Unicode latin "A" codepoint
(which is the same as the ASCII codepoint)

You want to write a quote you use a Unicode quote codepoint " or ?? or
?? there are several valid solutions in the general punctuation block
http://www.unicode.org/charts/PDF/U2000.pdf

You want to write a bullet you use the U+2022 bullet codepoint,
something in the dingbat block, or just plain en/em dash.
http://www.unicode.org/charts/PDF/U2000.pdf
http://www.unicode.org/charts/PDF/U2700.pdf

You do not use a O (oh) because it is vaguely similar to a 0 (zero)
You do not use an accent because it is vaguely similar to a quote
You do not use a cyrillic a because it looks like a latin a
You do not use a star when what you want is a bullet and there is a
standard way to encode bullets.

You encode your text properly using the correct choices in our standard
encoding so our tools can display it properly without human or computer
second-guessing.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/f2a3b0dc/attachment.sig>

From opensource at till.name  Tue Dec 16 20:52:26 2008
From: opensource at till.name (Till Maas)
Date: Tue, 16 Dec 2008 21:52:26 +0100
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <1229449338.2590.11.camel@localhost.localdomain>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<200812161034.01979.opensource@till.name>
	<1229449338.2590.11.camel@localhost.localdomain>
Message-ID: <200812162152.36842.opensource@till.name>

On Tue December 16 2008, Jesse Keating wrote:

> Good points.  I didn't cc the co-maintainers as I don't have a
> quick/easy way of accessing that information.  We don't expose that in
> our pre-built aliases.

It seemed to me that mails to package-owner fedoraproject org are also sent to 
at least some co-maintainers. I did not read it anywhere (is it somewhere 
publicly documented?), but I once sent an e-mail to one of these addresses and 
I got replies from two different maintainers.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/c1c5e60a/attachment.sig>

From jkeating at redhat.com  Tue Dec 16 20:59:28 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Dec 2008 12:59:28 -0800
Subject: [Fedora Update] [testing] libchewing-0.3.2-0.fc8
In-Reply-To: <200812162152.36842.opensource@till.name>
References: <20081216033538.8D77C208979@bastion.fedora.phx.redhat.com>
	<200812161034.01979.opensource@till.name>
	<1229449338.2590.11.camel@localhost.localdomain>
	<200812162152.36842.opensource@till.name>
Message-ID: <1229461168.2590.22.camel@localhost.localdomain>

On Tue, 2008-12-16 at 21:52 +0100, Till Maas wrote:
> 
> It seemed to me that mails to package-owner fedoraproject org are also sent to 
> at least some co-maintainers. I did not read it anywhere (is it somewhere 
> publicly documented?), but I once sent an e-mail to one of these addresses and 
> I got replies from two different maintainers.

Huh, you are correct.  I hadn't realized that before.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/0cb68e5c/attachment.sig>

From mw_triad at users.sourceforge.net  Tue Dec 16 20:58:42 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 16 Dec 2008 14:58:42 -0600
Subject: RFC: Description text in packages
In-Reply-To: <1229460222.15689.53.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>	<1229416413.3434.3.camel@hughsie-work.lan>	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>	<1229451449.13024.6.camel@arekh.okg>	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg>
Message-ID: <gi94q2$7eb$2@ger.gmane.org>

Nicolas Mailhot wrote:
> Le mardi 16 d?cembre 2008 ? 15:16 -0500, Bill Nottingham a ?crit :
>> I fail to see how using the neutral quote character ", a perfectly
>> valid
>> standard unicode character, is the road to incompatible software and
>> piles of quirks.
> 
> And I didn't object to ?"?, I object to using accents instead of quote
> characters.

And I didn't see anyone disagree. You do, however, seem to be advocating 
"fancy" quotes over ", which still sees far more usage (and which 
everyone knows how to type).

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet



From nicolas.mailhot at laposte.net  Tue Dec 16 21:14:30 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 22:14:30 +0100
Subject: RFC: Description text in packages
In-Reply-To: <gi94q2$7eb$2@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg>  <gi94q2$7eb$2@ger.gmane.org>
Message-ID: <1229462070.16645.1.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 14:58 -0600, Matthew Woehlke a ?crit :
> Nicolas Mailhot wrote:
> > Le mardi 16 d?cembre 2008 ? 15:16 -0500, Bill Nottingham a ?crit :
> >> I fail to see how using the neutral quote character ", a perfectly
> >> valid
> >> standard unicode character, is the road to incompatible software and
> >> piles of quirks.
> > 
> > And I didn't object to ?"?, I object to using accents instead of quote
> > characters.
> 
> And I didn't see anyone disagree. You do, however, seem to be advocating 
> "fancy" quotes over ", which still sees far more usage (and which 
> everyone knows how to type).

I wrote that if you wanted fancy quotes displayed you had to type fancy
quotes in your text, yes (not accents, primes, or something else that
looks similar but isn't).

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/f2d8a2fd/attachment.sig>

From mclasen at redhat.com  Tue Dec 16 21:20:07 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 16 Dec 2008 16:20:07 -0500
Subject: RFC: Description text in packages
In-Reply-To: <1229458902.15689.31.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
Message-ID: <1229462407.3529.13.camel@matthiasc>

On Tue, 2008-12-16 at 21:21 +0100, Nicolas Mailhot wrote:

> We expect you to convert this syntax to correct plain text in UTF-8
> encoding before publication by Fedora. This is the common ground all our
> package manipulating tools understand and there is no way we're going to
> teach them some other markup just because you can't find some UTF-8
> symbol in your layout.
>
> If you can't write UTF-8 bullets, and can't be bothered to launch
> something like gucharmap, use a sed of awk or whatever converter on your
> spec files before pushing them Fedora-side, don't ask others to add code
> to many tools to workaround your problems.

So how does using untypable unicode bullets magically tell PackageKit
that this is part of a list ? And which of the many bullet-like
characters in Unicode do you want to bless for this ?

If you ask me, something very simple like
http://en.wikipedia.org/wiki/Markdown is best for situations like this
where you want to include light markup into text without letting the
markup totally overwhelm the surrounding document.



From behdad at behdad.org  Tue Dec 16 21:23:09 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 16 Dec 2008 16:23:09 -0500
Subject: RFC: Description text in packages
In-Reply-To: <1229462407.3529.13.camel@matthiasc>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>	<1229416413.3434.3.camel@hughsie-work.lan>	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>	<1229451449.13024.6.camel@arekh.okg>	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>	<1229454454.13999.31.camel@arekh.okg>	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc>
Message-ID: <49481C3D.40400@behdad.org>

Matthias Clasen wrote:
> On Tue, 2008-12-16 at 21:21 +0100, Nicolas Mailhot wrote:
> 
>> We expect you to convert this syntax to correct plain text in UTF-8
>> encoding before publication by Fedora. This is the common ground all our
>> package manipulating tools understand and there is no way we're going to
>> teach them some other markup just because you can't find some UTF-8
>> symbol in your layout.
>>
>> If you can't write UTF-8 bullets, and can't be bothered to launch
>> something like gucharmap, use a sed of awk or whatever converter on your
>> spec files before pushing them Fedora-side, don't ask others to add code
>> to many tools to workaround your problems.
> 
> So how does using untypable unicode bullets magically tell PackageKit
> that this is part of a list ? And which of the many bullet-like
> characters in Unicode do you want to bless for this ?

Well, U+2022 BULLET is the clear winner.

behdad


> If you ask me, something very simple like
> http://en.wikipedia.org/wiki/Markdown is best for situations like this
> where you want to include light markup into text without letting the
> markup totally overwhelm the surrounding document.
> 



From nicolas.mailhot at laposte.net  Tue Dec 16 20:49:36 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 21:49:36 +0100
Subject: RFC: Description text in packages
In-Reply-To: <gi91p1$ssr$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<0dea71c4662ba3289e40da659e9205df.squirrel@arekh.dyndns.org>
	<494688AA.8060505@gmail.com> <1229365091.25084.25.camel@arekh.okg>
	<gi6vh6$cpr$1@ger.gmane.org> <1229413137.7794.1.camel@arekh.okg>
	<gi8qfm$fh$1@ger.gmane.org> <1229451335.13024.4.camel@arekh.okg>
	<gi8sem$9jf$1@ger.gmane.org> <1229453878.13999.22.camel@arekh.okg>
	<gi8urk$hkv$1@ger.gmane.org> <1229456805.15451.2.camel@arekh.okg>
	<gi91p1$ssr$1@ger.gmane.org>
Message-ID: <1229460576.15689.59.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 14:06 -0600, Matthew Woehlke a ?crit :

> What's the fourth level?

Read the xkb docs or look at the options the gnome keyboard switching
applet offers you.

> You still haven't answered the education question.

Education happens just like for any other computer stuff. If you want a
more specific answer, start by an exhaustive description of the existing
education solutions and why you feel they can't apply in this case.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/3bd55c32/attachment.sig>

From behdad at behdad.org  Tue Dec 16 21:03:15 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 16 Dec 2008 16:03:15 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4947BA95.4010704@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com>
Message-ID: <49481793.9060406@behdad.org>

Les Mikesell wrote:

> (b) making sleep/hibernate reliable is what laptop users
> need instead of booting all the time anyway because it is much faster if
> you can simply close the lid and open it later with all your apps
> working as you left them.

This is actually the strongest argument against spending a lot of resources on
going sub 20 seconds.  If Vista-style suspend-to-both works reliably, there is
no reason to turn a machine off at all.

That said, doesn't mean we shouldn't clean up cruft.


Hans de Goede wrote:

> 2) Load some services after gdm is up, for example cron, anacron, at,
> setroubleshootd

Please, no setroubleshootd by default.  What's the point?  Read section "The
rest" in my blog post:

  http://mces.blogspot.com/2008/12/improving-login-time-part-3.html


Horst H. von Brand wrote:

>> how about not running a full MTA on a laptop/client install... at all?
>
> That works if you have reliable, continuous access to the 'net. Not my
> case, sorry.

Don't you have to configure the MTA if you want to use it?  I mean, when a
normal user configures Thunderbird/Evo/... it puts the SMTP address that their
mail provider gave them (smtp.gmail.com, etc), NOT localhost.  If you are an
advanced-enough user to set it to localhost and configure your MTA to point it
to your remote SMTP server, sure you don't mind a "yum install sendmail"
first, do you?

I always wondered what the point of having a mail server installed and started
by default is.  The only use I have found for it is to deliver reports to
root.  But on my typical Fedora installs (that is, anything other than
servers), I don't read root mail.  The default MTA is simply useless for
normal desktop/laptop machine unless you configure it.  As such, it should be
turned off by default, and hence removed from default install.


Not it surprises me that every time I suggest something should be turned off
by default, someone shouts "please, no, I use that!"...


Matej Cepl wrote:
> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>> Nothing to say you can't re-enable it yourself. I don't have a
>> permanent connection to the net but evolution happily holds it in my
>> outbox until I go back online and can connect to a network. Fedora can
>
> I have a nasty surprise for you -- Fedora is not Windows, so it
> would is not only for people who use Evolution / Kmail
> / Thunderbird.

See above.  On a similar line of though, how about: "please install and enable
httpd, postgresql, and squid" by default because I use them...


behdad



From nikolay at vladimiroff.com  Tue Dec 16 21:39:17 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Tue, 16 Dec 2008 23:39:17 +0200
Subject: RFC: Description text in packages
In-Reply-To: <49481C3D.40400@behdad.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc> <49481C3D.40400@behdad.org>
Message-ID: <a2e85ed0812161339p6d28032au590574493c2e79b6@mail.gmail.com>

Ok, it seems that i made a mess of my ideas in the process of writing

My general ranting isn't against Unicode it's against using special
Unicode characters(bullets, and the "<<" thing).
A clean summary can be written with clear guidelines and common characters.

Is there any real benefit in using unicode bullet symbol, the double
arrow thing or quotes different from " ?




-- 
NV



From alsadi at gmail.com  Tue Dec 16 21:40:37 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 16 Dec 2008 23:40:37 +0200
Subject: RFC: Description text in packages
In-Reply-To: <49481C3D.40400@behdad.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc> <49481C3D.40400@behdad.org>
Message-ID: <385866f0812161340j20a04005p98589cdc35d46228@mail.gmail.com>

because I feel that you wasn't listen to me I'll attach a picture from gedit

the first line is "simple" with the UTF8 fancy quotes
in the second line I replaced simple with an Arabic word
notice that because quotes are marked to be neutral in direction
followed by RTL chars
they are treated as RTL chars
but because they are no longer mirrored they appear to us like
)simple(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: quotes.png
Type: image/png
Size: 35023 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/e6e644f0/attachment.png>

From skvidal at fedoraproject.org  Tue Dec 16 21:41:39 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 16 Dec 2008 16:41:39 -0500 (EST)
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49481793.9060406@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
Message-ID: <alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>



On Tue, 16 Dec 2008, Behdad Esfahbod wrote:

> Les Mikesell wrote:
>
>> (b) making sleep/hibernate reliable is what laptop users
>> need instead of booting all the time anyway because it is much faster if
>> you can simply close the lid and open it later with all your apps
>> working as you left them.
>
> This is actually the strongest argument against spending a lot of resources on
> going sub 20 seconds.  If Vista-style suspend-to-both works reliably, there is
> no reason to turn a machine off at all.
>

suspend uses LITTLE power but not none
hiberate uses no power but only happens when you've drained power already

so a good reason to power off is simply to save power

-sv



From bpepple at fedoraproject.org  Tue Dec 16 21:47:22 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 16 Dec 2008 16:47:22 -0500
Subject: Plan for tomorrows (20081216) FESCO meeting
In-Reply-To: <1229458418.6923.5.camel@localhost.localdomain>
References: <1229458418.6923.5.camel@localhost.localdomain>
Message-ID: <c6534ba10812161347tddedd94n89a393e0263e7a96@mail.gmail.com>

On Tue, Dec 16, 2008 at 3:13 PM, Brian Pepple <bpepple at fedoraproject.org> 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.  You can also propose topics
> in the meeting while it is in the "Free discussion around Fedora" phase.

Missed this topic:

/topic FESCo meeting -- Any objection to last week's report from FPC
at http://fedoraproject.org/wiki/Packaging/Minutes/20081209

Later,
/B



From behdad at behdad.org  Tue Dec 16 21:47:57 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 16 Dec 2008 16:47:57 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>
	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
Message-ID: <4948220D.9070202@behdad.org>

Seth Vidal wrote:
> 
> On Tue, 16 Dec 2008, Behdad Esfahbod wrote:
> 
>> Les Mikesell wrote:
>>
>>> (b) making sleep/hibernate reliable is what laptop users
>>> need instead of booting all the time anyway because it is much faster if
>>> you can simply close the lid and open it later with all your apps
>>> working as you left them.
>>
>> This is actually the strongest argument against spending a lot of
>> resources on
>> going sub 20 seconds.  If Vista-style suspend-to-both works reliably,
>> there is
>> no reason to turn a machine off at all.
>>
> 
> suspend uses LITTLE power but not none
> hiberate uses no power but only happens when you've drained power already
> 
> so a good reason to power off is simply to save power

Or hibernate?

> -sv
> 



From jkeating at redhat.com  Tue Dec 16 21:51:58 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Dec 2008 13:51:58 -0800
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
Message-ID: <1229464318.2590.23.camel@localhost.localdomain>

On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> so a good reason to power off is simply to save power

Or to reboot for one of our frequent updates that require it.  kernel,
dbus, etc...

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/01ccd9fd/attachment.sig>

From tibbs at math.uh.edu  Tue Dec 16 21:52:10 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 16 Dec 2008 15:52:10 -0600
Subject: Summary of the 2008-12-09 Packaging Committee meeting
Message-ID: <ufaljuf7ppx.fsf@epithumia.math.uh.edu>

My apologies for being so long in getting this out; it's been a bad week.

Meeting minutes and full logs of the 2008-12-09 FPC meeting are
online:

http://fedoraproject.org/wiki/Packaging/Minutes
http://fedoraproject.org/wiki/Packaging/Minutes/20081209

Issues pending FESCO ratification:

* Eclipse Plugin updates
 http://overholt.fedorapeople.org/EclipsePlugins.diff

* Ruby gems with native code
 https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code_spot

* Additional font package macros
 http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation

* Codifying adherence to FHS, with exceptions for libexec and
   /usr/'''target''' for cross compilers
  There is no draft; the details were worked out during the meeting.
  See the discussion starting at:
  https://fedoraproject.org/wiki/Packaging/Minutes/20081209#t11:57:02

 - J<



From nicolas.mailhot at laposte.net  Tue Dec 16 22:04:35 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Dec 2008 23:04:35 +0100
Subject: RFC: Description text in packages
In-Reply-To: <a2e85ed0812161339p6d28032au590574493c2e79b6@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc> <49481C3D.40400@behdad.org>
	<a2e85ed0812161339p6d28032au590574493c2e79b6@mail.gmail.com>
Message-ID: <1229465075.17230.4.camel@arekh.okg>

Le mardi 16 d?cembre 2008 ? 23:39 +0200, Nikolay Vladimirov a ?crit :
> Ok, it seems that i made a mess of my ideas in the process of writing
> 
> My general ranting isn't against Unicode it's against using special
> Unicode characters(bullets, and the "<<" thing).
> A clean summary can be written with clear guidelines and common characters.

A clean summary will be written with clear guidelines and correctly
encoded text.

> Is there any real benefit in using unicode bullet symbol,

There is a real benefit if you want bullets displayed on the user
systems.

> the double arrow thing or quotes different from " ?

The double arrow thing is a quoting form. It is the correct quoting form
for my country. As others noted each locale is going to have a correct
quoting form which is not necessarily ".

Since I'm no native American English speaker, I won't comment on what
the correct American English form is. As long as it's not a clear
encoding violation like the ?use accents as quotes? thing.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/2f072bd3/attachment.sig>

From bruno at wolff.to  Tue Dec 16 22:09:33 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 16 Dec 2008 16:09:33 -0600
Subject: Plan for tomorrows (20081216) FESCO meeting
In-Reply-To: <1229458418.6923.5.camel@localhost.localdomain>
References: <1229458418.6923.5.camel@localhost.localdomain>
Message-ID: <20081216220933.GA22833@wolff.to>

On Tue, Dec 16, 2008 at 15:13:37 -0500,
  Brian Pepple <bpepple at fedoraproject.org> 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.  You can also propose topics
> in the meeting while it is in the "Free discussion around Fedora" phase.

I have volunteered to work on the Games Spin Feature which was targeted
for F10, but didn't make it. I am not sure whether or not I am ready
for feature approval or not, but could use some guidance and I should
be able to attend tomorrow.



From jkeating at redhat.com  Tue Dec 16 22:12:39 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Dec 2008 14:12:39 -0800
Subject: rawhide report: 20081213 changes
In-Reply-To: <494507C4.9030404@iinet.net.au>
References: <20081213190628.CA05C1F8244@releng2.fedora.phx.redhat.com>
	<494507C4.9030404@iinet.net.au>
Message-ID: <1229465559.6191.1.camel@localhost.localdomain>

On Mon, 2008-12-15 at 00:19 +1100, David Timms wrote:
> Just for the giggle: any chance we can get the compose completion
> time 
> echoed to the end of the report.
> 
> Some statistical info would also be nice: (but not if it's
> significantly 
> slows the process down ;)
> 
> -number of source rpms
> -number of binary rpms
> -total size of source
> -total size of binaries
> -average source rpm size
> -average binary rpm size
> 
> perhaps that is already available on one of the fp.org web sites ? ( 
> and/ or this report could have a link to such external info.)

I don't think this stuff is out there.  The compose scripts are in the
rel-eng git tree though.  I'm holding a FUDCon session and hack fest on
doing automated QA and such things, this could fall in there as well.
Look for changes post-fudcon (and I'm flagging this email so that I
don't forget about your ideas)

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/7812ab13/attachment.sig>

From skvidal at fedoraproject.org  Tue Dec 16 22:16:36 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 16 Dec 2008 17:16:36 -0500 (EST)
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4948220D.9070202@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
Message-ID: <alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>



On Tue, 16 Dec 2008, Behdad Esfahbod wrote:

> Seth Vidal wrote:
>>
>> On Tue, 16 Dec 2008, Behdad Esfahbod wrote:
>>
>>> Les Mikesell wrote:
>>>
>>>> (b) making sleep/hibernate reliable is what laptop users
>>>> need instead of booting all the time anyway because it is much faster if
>>>> you can simply close the lid and open it later with all your apps
>>>> working as you left them.
>>>
>>> This is actually the strongest argument against spending a lot of
>>> resources on
>>> going sub 20 seconds.  If Vista-style suspend-to-both works reliably,
>>> there is
>>> no reason to turn a machine off at all.
>>>
>>
>> suspend uses LITTLE power but not none
>> hiberate uses no power but only happens when you've drained power already
>>
>> so a good reason to power off is simply to save power
>
> Or hibernate?

At least on my system hibernate takes as much time as a reboot.

And  as jesse said - we still need to reboot for kernels, dbus, all sorts 
of stuff.

-sv



From alan at redhat.com  Tue Dec 16 22:25:00 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 16 Dec 2008 17:25:00 -0500
Subject: RFC: Description text in packages
In-Reply-To: <1229462407.3529.13.camel@matthiasc>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc>
Message-ID: <20081216222500.GA844@shell.devel.redhat.com>

On Tue, Dec 16, 2008 at 04:20:07PM -0500, Matthias Clasen wrote:
> So how does using untypable unicode bullets magically tell PackageKit
> that this is part of a list ? And which of the many bullet-like
> characters in Unicode do you want to bless for this ?

You have confused character encoding and semantic markup.

Unicode is character encoding

HTML tags or similar are semantic markup

Trying to extrapolate semantic markup from random ascii symbols is not
a reliable or robust path, particularly when you come to internationalise
things.

> If you ask me, something very simple like
> http://en.wikipedia.org/wiki/Markdown is best for situations like this
> where you want to include light markup into text without letting the
> markup totally overwhelm the surrounding document.

Possibly, however package data in rpm headers is not wiki markdown and the
specification for RPM doesn't imply you can treat it that way.




From cmadams at hiwaay.net  Tue Dec 16 22:30:06 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 16 Dec 2008 16:30:06 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229464318.2590.23.camel@localhost.localdomain>
References: <gi5svv$jvc$1@ger.gmane.org> <20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
Message-ID: <20081216223006.GC1358034@hiwaay.net>

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> > so a good reason to power off is simply to save power
> 
> Or to reboot for one of our frequent updates that require it.  kernel,
> dbus, etc...

Why does anything other than a kernel update require a reboot?

Is it possible to use kexec to boot a new kernel from the old one?  That
would cut down on the reboot time (on some of my systems, especially
servers with SCSI and/or RAID, the POST takes much longer than the
kernel/daemon boot).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From james at fedoraproject.org  Tue Dec 16 22:30:53 2008
From: james at fedoraproject.org (James Antill)
Date: Tue, 16 Dec 2008 17:30:53 -0500
Subject: RFC: Description text in packages
In-Reply-To: <gi94q2$7eb$2@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg>  <gi94q2$7eb$2@ger.gmane.org>
Message-ID: <1229466653.6392.38.camel@code.and.org>

On Tue, 2008-12-16 at 14:58 -0600, Matthew Woehlke wrote:
> Nicolas Mailhot wrote:
> > Le mardi 16 d?cembre 2008 ? 15:16 -0500, Bill Nottingham a ?crit :
> >> I fail to see how using the neutral quote character ", a perfectly
> >> valid
> >> standard unicode character, is the road to incompatible software and
> >> piles of quirks.
> > 
> > And I didn't object to ?"?, I object to using accents instead of quote
> > characters.
> 
> And I didn't see anyone disagree. You do, however, seem to be advocating 
> "fancy" quotes over ", which still sees far more usage (and which 
> everyone knows how to type).

 The problem is that PK currently alters the description text (I think
mainly to work around a bug/feature?) substituting "fancy quotes" for
"normal" quotes (which I think is why this thread started, to try and
fix that in the packages!).
 Nicolas thinks tools altering the data in this way is bad, and I tend
to agree, with descriptions being what they are now it's not possible to
know that the alteration is always good.
 He also seems to haave a secondary argument that for lists, using o is
bad but ? is good. I'm not sure I agree there, but I see his point.

 Personally I think the use of '"', ., *, ?, o or ? ... are fine, just
as long as all the tools are displaying the same non-invisible bytes?.


? https://bugzilla.redhat.com/show_bug.cgi?id=459155

? Changing whitespace is different, I think, so the tools can do
readable wrapping ... but I'm prepared to be shown we shouldn't do that
in yum/whatever either (what we have now is certainly somewhat magic).

-- 
James Antill <james at fedoraproject.org>
Fedora



From pbrobinson at gmail.com  Tue Dec 16 22:36:23 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 16 Dec 2008 23:36:23 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216223006.GC1358034@hiwaay.net>
References: <gi5svv$jvc$1@ger.gmane.org>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
Message-ID: <5256d0b0812161436o3ef5cf4dl580db464f791326a@mail.gmail.com>

>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>> > so a good reason to power off is simply to save power
>>
>> Or to reboot for one of our frequent updates that require it.  kernel,
>> dbus, etc...
>
> Why does anything other than a kernel update require a reboot?
>
> Is it possible to use kexec to boot a new kernel from the old one?  That
> would cut down on the reboot time (on some of my systems, especially
> servers with SCSI and/or RAID, the POST takes much longer than the
> kernel/daemon boot).

Oh yes please! Some of my large servers seems to take weeks to boot :-)

Peter



From mclasen at redhat.com  Tue Dec 16 22:40:36 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 16 Dec 2008 17:40:36 -0500
Subject: RFC: Description text in packages
In-Reply-To: <20081216222500.GA844@shell.devel.redhat.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc>
	<20081216222500.GA844@shell.devel.redhat.com>
Message-ID: <1229467236.3529.18.camel@matthiasc>

On Tue, 2008-12-16 at 17:25 -0500, Alan Cox wrote:
> On Tue, Dec 16, 2008 at 04:20:07PM -0500, Matthias Clasen wrote:
> > So how does using untypable unicode bullets magically tell PackageKit
> > that this is part of a list ? And which of the many bullet-like
> > characters in Unicode do you want to bless for this ?
> 
> You have confused character encoding and semantic markup.
> 
> Unicode is character encoding
> 
> HTML tags or similar are semantic markup

Thanks Alan, I know that quite well. 

> Trying to extrapolate semantic markup from random ascii symbols is not
> a reliable or robust path, particularly when you come to internationalise
> things.

One hopes the ascii symbols in most package descriptions are not
entirely random... and extrapolating something from them can be quite
reliable if is there is a mutual understanding about the interpretation.
Hence my reference to markdown.

> Possibly, however package data in rpm headers is not wiki markdown and the
> specification for RPM doesn't imply you can treat it that way.

The specification for RPM doesn't imply anything about the description
field. And this thread is about how to possibly improve the situation by
agreeing on some form of interpretation.





From katzj at redhat.com  Tue Dec 16 22:45:20 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 16 Dec 2008 17:45:20 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49481793.9060406@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com>  <49481793.9060406@behdad.org>
Message-ID: <1229467520.5054.129.camel@erebor.bos.redhat.com>

On Tue, 2008-12-16 at 16:03 -0500, Behdad Esfahbod wrote:
> Les Mikesell wrote:
> > (b) making sleep/hibernate reliable is what laptop users
> > need instead of booting all the time anyway because it is much faster if
> > you can simply close the lid and open it later with all your apps
> > working as you left them.
> 
> This is actually the strongest argument against spending a lot of resources on
> going sub 20 seconds.  If Vista-style suspend-to-both works reliably, there is
> no reason to turn a machine off at all.
> 
> That said, doesn't mean we shouldn't clean up cruft.

Indeed.  There are still plenty of reasons why reboots happen, so
speeding up boot is worthwhile.  

> Hans de Goede wrote:
> 
> > 2) Load some services after gdm is up, for example cron, anacron, at,
> > setroubleshootd
> 
> Please, no setroubleshootd by default.  What's the point?  Read section "The
> rest" in my blog post:

Dan is working on making setroubleshoot suck less -- the idea of
notifying you of problems even if the only thing you can do is report
them isn't bad.  The implementation is less than ideal :)

> Horst H. von Brand wrote:
> >> how about not running a full MTA on a laptop/client install... at all?
> >
> > That works if you have reliable, continuous access to the 'net. Not my
> > case, sorry.
> 
> Don't you have to configure the MTA if you want to use it?  I mean, when a
> normal user configures Thunderbird/Evo/... it puts the SMTP address that their
> mail provider gave them (smtp.gmail.com, etc), NOT localhost.  If you are an
> advanced-enough user to set it to localhost and configure your MTA to point it
> to your remote SMTP server, sure you don't mind a "yum install sendmail"
> first, do you?

Yeah, I think that this is probably the right path although it
definitely is going to be a noisy path.  FWIW, even mutt users don't
need sendmail anymore -- see 'set smtp_url'.

Jeremy



From katzj at redhat.com  Tue Dec 16 22:46:31 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 16 Dec 2008 17:46:31 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
Message-ID: <1229467591.5054.131.camel@erebor.bos.redhat.com>

On Tue, 2008-12-16 at 17:16 -0500, Seth Vidal wrote:
> On Tue, 16 Dec 2008, Behdad Esfahbod wrote:
> > Seth Vidal wrote:
> >> so a good reason to power off is simply to save power
> >
> > Or hibernate?
> 
> At least on my system hibernate takes as much time as a reboot.

We should really work on fixing that too... :)

Jeremy



From katzj at redhat.com  Tue Dec 16 22:47:24 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 16 Dec 2008 17:47:24 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216223006.GC1358034@hiwaay.net>
References: <gi5svv$jvc$1@ger.gmane.org> <20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
Message-ID: <1229467644.5054.132.camel@erebor.bos.redhat.com>

On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
> Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> > On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> > > so a good reason to power off is simply to save power
> > 
> > Or to reboot for one of our frequent updates that require it.  kernel,
> > dbus, etc...
> 
> Why does anything other than a kernel update require a reboot?

The system bus cannot be restarted.  Similarly, any apps you have
running will be using old libraries so things like glibc you really want
to reboot for.  

Jeremy



From behdad at behdad.org  Tue Dec 16 22:59:10 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 16 Dec 2008 17:59:10 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229467644.5054.132.camel@erebor.bos.redhat.com>
References: <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<1229464318.2590.23.camel@localhost.localdomain>	<20081216223006.GC1358034@hiwaay.net>
	<1229467644.5054.132.camel@erebor.bos.redhat.com>
Message-ID: <494832BE.1050406@behdad.org>

Jeremy Katz wrote:
> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
>> Once upon a time, Jesse Keating <jkeating at redhat.com> said:
>>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>>> so a good reason to power off is simply to save power
>>> Or to reboot for one of our frequent updates that require it.  kernel,
>>> dbus, etc...
>> Why does anything other than a kernel update require a reboot?
> 
> The system bus cannot be restarted.  Similarly, any apps you have
> running will be using old libraries so things like glibc you really want
> to reboot for.  

Back in the days, sshd had a trigger to restart itself on glibc update.  init
had a similar thing too I guess...

behdad

> Jeremy
> 



From kevin.kofler at chello.at  Tue Dec 16 23:10:24 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 17 Dec 2008 00:10:24 +0100
Subject: orphaning many packages
References: <20081206122420.GC2932@free.fr> <gi7ujf$ogo$1@ger.gmane.org>
	<20081216154216.GM2414@free.fr>
Message-ID: <gi9ch0$v0$1@ger.gmane.org>

Patrice Dumas wrote:
> Do you want the F9 and F10 branches of all those packages?

If you want to orphan those too, sure, just orphan them and tell me and I'll
grab them.

>> As for flasm, it's not really a dependency of gnash, is it? I think
>> somebody actually interested in Flash authoring should take that one.
> 
> It is not strictly a dependency, but it may be needed to be able to
> debug gnash. What is interesting, indeed, is the possibility to
> disassemble a swf to understand what is in it. I brought it in fedora
> because I needed it for a bug report, and I saw it used more than once
> for gnash debugging on the gnash mailing list.
> 
> Si it is not strictly needed, but convenient. It guess that it is also
> of some interest for swfdec.

OK: is really nobody else interested in flasm? In that case I'll pick it up
just to save this debugging tool from getting removed, one package more or
less isn't going to change my workload drastically.

        Kevin Kofler



From dcbw at redhat.com  Tue Dec 16 23:17:19 2008
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 16 Dec 2008 18:17:19 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229467644.5054.132.camel@erebor.bos.redhat.com>
References: <gi5svv$jvc$1@ger.gmane.org> <20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
	<1229467644.5054.132.camel@erebor.bos.redhat.com>
Message-ID: <1229469439.10880.39.camel@72-58-215-36.pools.spcsdns.net>

On Tue, 2008-12-16 at 17:47 -0500, Jeremy Katz wrote:
> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
> > Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> > > On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> > > > so a good reason to power off is simply to save power
> > > 
> > > Or to reboot for one of our frequent updates that require it.  kernel,
> > > dbus, etc...
> > 
> > Why does anything other than a kernel update require a reboot?
> 
> The system bus cannot be restarted.  Similarly, any apps you have
> running will be using old libraries so things like glibc you really want
> to reboot for.  

The problem is mainly one of state.  For example, NetworkManager has
some code to handle reconnection to the system bus.  But to
transparently handle bus restarts, NetworkManager would have to perform
the following actions; none of this is NM or D-Bus specific, it would be
the same problem in any system using separate services for specific
functions, as is the unix way.

1) Sync internal device list with HAL, ie if you pulled a card out while
the system bus was down

2) Re-query dhclient state (currently impossible since dhclient doesn't
talk over D-Bus), ie if your DHCP lease got renewed or changed while the
system bus was down

3) Re-query avahi-autoipd state (currently impossible since
avahi-autoipd doesn't speak D-Bus), ie of your autoip address changed
while the system bus was down

4) Re-query pppd state (currently impossible since pppd doesn't speak
D-Bus), ie if the cellular network dropped your connection while the
system bus was down

5) Re-query all device IP addresses and routes, delete addresses/routes
that aren't known to NM and add addresses/routes that got dropped.  Also
update stuff like MTU based on the DHCP server response that we had to
wait for in step #2

6) Re-query all VPN daemons for their connection state just in case any
of that changed while the system bus was down

7) Execute the callouts and send out D-Bus signals if any of these
things changed, so that scripts in /etc/NetworkManager/dispatcher.d get
notified of changes

8) Requery wpa_supplicant for the wireless scan list

9) Requery the wifi adapter for the current settings and ensure that
they are the same as NM thinks they should be, and if not, tear down
whatever the wifi card is doing and re-init the connection

10) Trust and rely on each D-Bus service to successfully reconnect to
the bus, where each service may handle this differently with different
reconnection attempt timeouts.  Latency for handling a bus restart could
be quite large if a service like wpa_supplicant that is lower in the
stack takes a bit longer to reconnect than other services.

11) Re-query the system settings and user settings services and figure
out if any new connections were added while the bus was down, or if any
connections (including the one that was active during the bus restart)
were deleted.  If the active connection was deleted during the bus
restart, tear it down.

How does all this stuff happen when the system bus is running?  Signals
get emitted from the various components when things change, and NM
listens for those signals so it doesn't have to poll everything.  Thus,
if the system bus isn't running, signals get lost and you have to
invalidate all your state, then re-query it when the bus comes back.

We've discussed less-invasive ways of fixing this, like queuing signals
in the services on the service-side in libdbus or so until the service
reconnects to the system bus, but that could be quite tricky and error
prone.  You cannot do a 75% solution here.

Dan



From jamundso at gmail.com  Tue Dec 16 23:26:14 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Tue, 16 Dec 2008 17:26:14 -0600
Subject: To pre, or not to pre...
Message-ID: <200812161726.15508.jamundso@gmail.com>

I'm normally 'yum live upgrade' type, but trying preupgrade now.

556/742 - preupgrade/packages/openoffice.org-calc-core-3.0.1-13.2.fc11.x86_64.rp
605/742 - preupgrade/packages/libXdamage-1.1.1-5.fc11.i386.rpmTraceback (most 
recent call last):                                                                
  File "/usr/share/preupgrade/preupgrade-cli.py", line 284, in <module>         
    pu.main(myrelease)                                                          
  File "/usr/share/preupgrade/preupgrade-cli.py", line 249, in main             
    self.generate_repodata(cachedir, comps) # TODO: callback?                   
  File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 711, in 
generate_repodata                                                                
    generate_repodata(dir, comps, callback)                                     
  File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 727, in 
generate_repodata_f9                                                             
    mdgen.doPkgMetadata()
  File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 332, in 
doPkgMetadata
    self.writeMetadataDocs(packages)
  File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 475, in 
writeMetadataDocs
    clog_limit=self.conf.changelog_limit))
  File "/usr/lib/python2.5/site-packages/yum/packages.py", line 959, in 
xml_dump_other_metadata
    msg += "%s\n</package>\n" % 
misc.to_unicode(self._dump_changelog(clog_limit))
  File "/usr/lib/python2.5/site-packages/yum/packages.py", line 936, in 
_dump_changelog
    misc.to_xml(author, attrib=True), misc.to_xml(str(ts)),
  File "/usr/lib/python2.5/site-packages/yum/misc.py", line 749, in to_xml
    item = _ugly_utf8_string_hack(item)
  File "/usr/lib/python2.5/site-packages/yum/misc.py", line 728, in 
_ugly_utf8_string_hack
    print '\n%s encoding on %s\n' % (enc, item)
  File "/usr/lib64/python2.5/codecs.py", line 303, in write
    data, consumed = self.encode(object, self.errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf8 in position 34: 
ordinal not in range(128)

jerry

-- 
To be named later.



From bashton at brennanashton.com  Tue Dec 16 23:27:56 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Tue, 16 Dec 2008 15:27:56 -0800
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
References: <1229435781.4103.5.camel@localhost.localdomain>
	<1229443261.4049.324.camel@macbook.infradead.org>
	<b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
Message-ID: <981da310812161527s4d8c5a46l8736c46e0947629a@mail.gmail.com>

On Tue, Dec 16, 2008 at 8:08 AM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
> 2008/12/16 David Woodhouse <dwmw2 at infradead.org>:
>> On Tue, 2008-12-16 at 08:56 -0500, Brian Pepple wrote:
>>> Top three  FAS account holders who have completed reviewing "Package
>>> review" components on bugzilla for the week ending December 14th, 2008
>>> were Parag AN(????), Manuel Wolfshant, and Jason Tibbitts.  Below is
>>> the number of completed package reviews done.
>>
>> Thanks for doing these reports -- it's useful. And it reminds me that I
>> haven't done many reviews in the last few weeks, while my DSL line has
>> been crap. I'll try to catch up.
>>
>> Any chance we could include the number of open review bugs in the
>> report? And the number of _new_ reviews opened since the previous
>> report?
>>
>
> Yes we can do that easily, and I will extend the script to that
> anyway. Hopefully if list is not too long it makes sense to include
> bugs here.
>
> --
> rakesh
Rakesh,

I can add you to the git-triage group, so you can push updates to the
script in fedorahosted if you want, just make the request in FAS.

--Brennan Ashton



From mschwendt at gmail.com  Tue Dec 16 23:34:10 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 17 Dec 2008 00:34:10 +0100
Subject: rawhide report: 20081215 changes
In-Reply-To: <20081215164955.59F5E1F8243@releng2.fedora.phx.redhat.com>
References: <20081215164955.59F5E1F8243@releng2.fedora.phx.redhat.com>
Message-ID: <20081217003410.4be123e1.mschwendt@gmail.com>

On Mon, 15 Dec 2008 16:49:55 +0000 (UTC), Rawhide wrote:

> vamp-plugin-sdk-2.0-1.fc11
> --------------------------
> * Sun Dec 14 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 2.0-1
> - Update to 2.0

Even though this is Rawhide, this update bumps the SONAME. A notification
would have been nice.
 
> 	audacity-1.3.5-0.8.beta.fc10.i386 requires libvamp-hostsdk.so.2

These broken deps in rawhide used to be reported by private email.
I cannot find any such email.



From jkeating at redhat.com  Tue Dec 16 23:44:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Dec 2008 15:44:33 -0800
Subject: rawhide report: 20081215 changes
In-Reply-To: <20081217003410.4be123e1.mschwendt@gmail.com>
References: <20081215164955.59F5E1F8243@releng2.fedora.phx.redhat.com>
	<20081217003410.4be123e1.mschwendt@gmail.com>
Message-ID: <1229471073.6191.15.camel@localhost.localdomain>

On Wed, 2008-12-17 at 00:34 +0100, Michael Schwendt wrote:
> 
> These broken deps in rawhide used to be reported by private email.
> I cannot find any such email.


It's currently set to email <pkg>-owner at fedoraproject.org with the
broken deps.  It's possible we're getting something wrong here though, I
need to revisit this patch.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/1d4bfcd0/attachment.sig>

From alsadi at gmail.com  Tue Dec 16 23:44:43 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Wed, 17 Dec 2008 01:44:43 +0200
Subject: To pre, or not to pre...
In-Reply-To: <200812161726.15508.jamundso@gmail.com>
References: <200812161726.15508.jamundso@gmail.com>
Message-ID: <385866f0812161544h7ab614e6r5d034737054917e7@mail.gmail.com>

> print '\n%s encoding on %s\n' % (enc, item)
was it piped

because when a print is piped python won't do str.encode('utf-8')
because it does not know the encoding of the pipe

but when it's on terminal it could guess the output encoding

 am I right ?



From pertusus at free.fr  Tue Dec 16 23:52:33 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 17 Dec 2008 00:52:33 +0100
Subject: orphaning many packages
In-Reply-To: <gi9ch0$v0$1@ger.gmane.org>
References: <20081206122420.GC2932@free.fr> <gi7ujf$ogo$1@ger.gmane.org>
	<20081216154216.GM2414@free.fr> <gi9ch0$v0$1@ger.gmane.org>
Message-ID: <20081216235233.GD2334@free.fr>

On Wed, Dec 17, 2008 at 12:10:24AM +0100, Kevin Kofler wrote:
> Patrice Dumas wrote:
> > Do you want the F9 and F10 branches of all those packages?
> 
> If you want to orphan those too, sure, just orphan them and tell me and I'll
> grab them.

Done.

There are some opened bugs. Most of them are already reported upstream.

> OK: is really nobody else interested in flasm? In that case I'll pick it up
> just to save this debugging tool from getting removed, one package more or
> less isn't going to change my workload drastically.

I orphaned also the F9 and F10 branches.

This package will certainly never be updated again upstream, so it
should be very low maintainance.

--
Pat



From camilo at mesias.co.uk  Wed Dec 17 00:04:08 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Wed, 17 Dec 2008 00:04:08 +0000
Subject: Memory/filesystem corruption
In-Reply-To: <4947EEDF.9000801@niemueller.de>
References: <4947EEDF.9000801@niemueller.de>
Message-ID: <d551e0e20812161604s389a2544u935204fe143453d3@mail.gmail.com>

I've just added a pretty vague set of symptoms to the bug. It does
involve disk problems and an ATI graphics card though. If there's a
fix for the current problems it would be very welcome...

I'm seeing messages like these:

Uhhuh. NMI received for unknown reason b0 on CPU 0.
You have some hardware problem, likely on the PCI bus.
Dazed and confused, but trying to continue

Also, the characters and repeating graphics on Firefox are getting
corruption. I'm still wondering if the graphics card is
overheating/failing or something.



From alan at redhat.com  Wed Dec 17 00:12:14 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 16 Dec 2008 19:12:14 -0500
Subject: RFC: Description text in packages
In-Reply-To: <1229467236.3529.18.camel@matthiasc>
References: <1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc>
	<20081216222500.GA844@shell.devel.redhat.com>
	<1229467236.3529.18.camel@matthiasc>
Message-ID: <20081217001214.GA15516@shell.devel.redhat.com>

On Tue, Dec 16, 2008 at 05:40:36PM -0500, Matthias Clasen wrote:
> > Unicode is character encoding
> > HTML tags or similar are semantic markup
> 
> Thanks Alan, I know that quite well. 
> 
> > Trying to extrapolate semantic markup from random ascii symbols is not
> > a reliable or robust path, particularly when you come to internationalise
> > things.
> 
> One hopes the ascii symbols in most package descriptions are not
> entirely random... and extrapolating something from them can be quite

There is no reason to assume * for example is a bullet point, it could be a
footnote indicator, maths or ascii art. The Unicode bullet on the other hand
is uneqivocably a bullet point.

So extracting from UTF-8 is safer, but extracting at all is dangerous

> The specification for RPM doesn't imply anything about the description
> field. And this thread is about how to possibly improve the situation by
> agreeing on some form of interpretation.

Right - the field is plain UTF-8 textual data and has been for years. You
want to add a semantic version of it. That is fine but use a new header for
the field the way RPM intends things to be added.



From smparrish at shallowcreek.net  Wed Dec 17 00:15:52 2008
From: smparrish at shallowcreek.net (Steven M. Parrish)
Date: Tue, 16 Dec 2008 19:15:52 -0500
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <200812161915.52866.smparrish@shallowcreek.net>

On Tuesday 16 December 2008 04:47:40 Patrice Dumas wrote:
> Hello,
>
> I am orphaning all my packages. I orphan the devel branch, but I'd
> prefer
> also orphan the stable branches too, so if you are interested don't
> hesitate to ask. I am still willing to maintain the EPEL branches, but
> here, also, if you want to take over, say so.
>
> I am nco, ncview, glib 1 and gtk+ 1 de-facto main packager, so
> somebody else should take care of those packages.
>
> I think that lesstif, perl-File-MimeInfo and fcron are strategic for
> fedora.
>
>
> Low maintainance but very complicated packages:
> The cernlib packages are quite complicated and unusual, this is fortran,
> uses imake :-/ and upstream is moribund since 2003, and dead since 2006.
> Debian was like a substitution upstream, but the debian maintainer has
> also abandonned cernlib. Still it is known that there are users for this
> package.
> * cernlib
> * cernlib-g77
>
> Normal packages:
> * lesstif
> * libdap
> * libnc-dap
>
> Very low maintainance packages:
> * asa
> * bibexport
> * BibTool
> * bitmap
> * libsx
> * libdockapp
> * ooo2txt
> * perl-Parse-Yapp
> * perl-Text-Unidecode
> * tetex-elsevier
> * uread
> * wmix
> * xbae
> * xdialog
>
> Low maintainance packages:
> * acpitool
> * boolstuff
> * cppunit
> * esmtp
> * fcron
> * halevt
> * grads
> there is an update available for grads, but it has some functionalities
> removed, and also upstream is complicated, with a friendly fork at
> opengrads and last libgadap can be packaged now. I'll still be working
> with upstream, so I could help with chosing which version to package and
> things like that.
> * perl-Algorithm-CurveFit
> * perl-File-BaseDir
> * perl-File-DesktopEntry
> * perl-File-MimeInfo
> * perl-Math-MatrixReal
> * perl-Math-Symbolic
>
> Recently added packages:
> * g2clib
> * grib_api
> * w3lib
>
> --
> Pat

I'll take acpitool and cppunit  devel and F9 & F10

Steven



From smparrish at shallowcreek.net  Wed Dec 17 00:25:26 2008
From: smparrish at shallowcreek.net (Steven M. Parrish)
Date: Tue, 16 Dec 2008 19:25:26 -0500
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <200812161925.27221.smparrish@shallowcreek.net>

On Tuesday 16 December 2008 04:47:40 Patrice Dumas wrote:
> Hello,
>
> I am orphaning all my packages. I orphan the devel branch, but I'd
> prefer
> also orphan the stable branches too, so if you are interested don't
> hesitate to ask. I am still willing to maintain the EPEL branches, but
> here, also, if you want to take over, say so.
>
> I am nco, ncview, glib 1 and gtk+ 1 de-facto main packager, so
> somebody else should take care of those packages.
>
> I think that lesstif, perl-File-MimeInfo and fcron are strategic for
> fedora.
>
>
> Low maintainance but very complicated packages:
> The cernlib packages are quite complicated and unusual, this is fortran,
> uses imake :-/ and upstream is moribund since 2003, and dead since 2006.
> Debian was like a substitution upstream, but the debian maintainer has
> also abandonned cernlib. Still it is known that there are users for this
> package.
> * cernlib
> * cernlib-g77
>
> Normal packages:
> * lesstif
> * libdap
> * libnc-dap
>
> Very low maintainance packages:
> * asa
> * bibexport
> * BibTool
> * bitmap
> * libsx
> * libdockapp
> * ooo2txt
> * perl-Parse-Yapp
> * perl-Text-Unidecode
> * tetex-elsevier
> * uread
> * wmix
> * xbae
> * xdialog
>
> Low maintainance packages:
> * acpitool
> * boolstuff
> * cppunit
> * esmtp
> * fcron
> * halevt
> * grads
> there is an update available for grads, but it has some functionalities
> removed, and also upstream is complicated, with a friendly fork at
> opengrads and last libgadap can be packaged now. I'll still be working
> with upstream, so I could help with chosing which version to package and
> things like that.
> * perl-Algorithm-CurveFit
> * perl-File-BaseDir
> * perl-File-DesktopEntry
> * perl-File-MimeInfo
> * perl-Math-MatrixReal
> * perl-Math-Symbolic
>
> Recently added packages:
> * g2clib
> * grib_api
> * w3lib
>
> --
> Pat
 
I'll also take esmtp, and acpi    devel F9 & F10

Steven



From katzj at redhat.com  Wed Dec 17 00:38:21 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 16 Dec 2008 19:38:21 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494832BE.1050406@behdad.org>
References: <gi5svv$jvc$1@ger.gmane.org> <20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
	<1229467644.5054.132.camel@erebor.bos.redhat.com>
	<494832BE.1050406@behdad.org>
Message-ID: <1229474301.28858.85.camel@aglarond.local>

On Tue, 2008-12-16 at 17:59 -0500, Behdad Esfahbod wrote:
> Jeremy Katz wrote:
> > On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
> >> Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> >>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> >>>> so a good reason to power off is simply to save power
> >>> Or to reboot for one of our frequent updates that require it.  kernel,
> >>> dbus, etc...
> >> Why does anything other than a kernel update require a reboot?
> > 
> > The system bus cannot be restarted.  Similarly, any apps you have
> > running will be using old libraries so things like glibc you really want
> > to reboot for.  
> 
> Back in the days, sshd had a trigger to restart itself on glibc update.  init
> had a similar thing too I guess...

Yes, but that's not everything on your system.  Should we add triggers
for everything you can possibly run?  :)

Jeremy



From behdad at behdad.org  Wed Dec 17 00:42:51 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 16 Dec 2008 19:42:51 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229474301.28858.85.camel@aglarond.local>
References: <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<1229464318.2590.23.camel@localhost.localdomain>	<20081216223006.GC1358034@hiwaay.net>	<1229467644.5054.132.camel@erebor.bos.redhat.com>	<494832BE.1050406@behdad.org>
	<1229474301.28858.85.camel@aglarond.local>
Message-ID: <49484B0B.8000802@behdad.org>

Jeremy Katz wrote:
> On Tue, 2008-12-16 at 17:59 -0500, Behdad Esfahbod wrote:
>> Jeremy Katz wrote:
>>> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
>>>> Once upon a time, Jesse Keating <jkeating at redhat.com> said:
>>>>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>>>>> so a good reason to power off is simply to save power
>>>>> Or to reboot for one of our frequent updates that require it.  kernel,
>>>>> dbus, etc...
>>>> Why does anything other than a kernel update require a reboot?
>>> The system bus cannot be restarted.  Similarly, any apps you have
>>> running will be using old libraries so things like glibc you really want
>>> to reboot for.  
>> Back in the days, sshd had a trigger to restart itself on glibc update.  init
>> had a similar thing too I guess...
> 
> Yes, but that's not everything on your system.  Should we add triggers
> for everything you can possibly run?  :)

No, only for services that know how to restart without losing state.

behdad

> Jeremy



From pertusus at free.fr  Wed Dec 17 00:49:53 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 17 Dec 2008 01:49:53 +0100
Subject: orphaning all my packages
In-Reply-To: <200812161925.27221.smparrish@shallowcreek.net>
References: <20081216094739.GA3877@free.fr>
	<200812161925.27221.smparrish@shallowcreek.net>
Message-ID: <20081217004953.GA3802@free.fr>

On Tue, Dec 16, 2008 at 07:25:26PM -0500, Steven M. Parrish wrote:
>  
> I'll also take esmtp, and acpi    devel F9 & F10

All branches released. acpi has a new upstream, Stepan Kasel already
corrected the url in devel.

--
Pat



From pertusus at free.fr  Wed Dec 17 00:51:00 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 17 Dec 2008 01:51:00 +0100
Subject: orphaning all my packages
In-Reply-To: <20081217004953.GA3802@free.fr>
References: <20081216094739.GA3877@free.fr>
	<200812161925.27221.smparrish@shallowcreek.net>
	<20081217004953.GA3802@free.fr>
Message-ID: <20081217005100.GB3802@free.fr>

On Wed, Dec 17, 2008 at 01:49:53AM +0100, Patrice Dumas wrote:
> On Tue, Dec 16, 2008 at 07:25:26PM -0500, Steven M. Parrish wrote:
> >  
> > I'll also take esmtp, and acpi    devel F9 & F10
> 
> All branches released. acpi has a new upstream, Stepan Kasel already
> corrected the url in devel.

Stepan Kasal, sorry.

--
Pat



From poelstra at redhat.com  Wed Dec 17 01:03:30 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 16 Dec 2008 17:03:30 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-12-15
Message-ID: <49484FE2.6050806@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-dec-15

Please make corrections and clarifications to the wiki page.

== Summary ==
* See IRC log



From mschmidt at redhat.com  Wed Dec 17 01:44:45 2008
From: mschmidt at redhat.com (Michal Schmidt)
Date: Wed, 17 Dec 2008 02:44:45 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <5256d0b0812161436o3ef5cf4dl580db464f791326a@mail.gmail.com>
References: <gi5svv$jvc$1@ger.gmane.org>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
	<5256d0b0812161436o3ef5cf4dl580db464f791326a@mail.gmail.com>
Message-ID: <20081217024445.6351531a@hammerfall>

Dne Tue, 16 Dec 2008 23:36:23 +0100
"Peter Robinson" <pbrobinson at gmail.com> napsal:

> >> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> >> > so a good reason to power off is simply to save power
> >>
> >> Or to reboot for one of our frequent updates that require it.
> >> kernel, dbus, etc...
> >
> > Why does anything other than a kernel update require a reboot?
> >
> > Is it possible to use kexec to boot a new kernel from the old one?
> > That would cut down on the reboot time (on some of my systems,
> > especially servers with SCSI and/or RAID, the POST takes much
> > longer than the kernel/daemon boot).
> 
> Oh yes please! Some of my large servers seems to take weeks to
> boot :-)

Yes, it is possible. I am actually using it on my laptop right now. My
goal was to have PackageKit restart the machine using kexec instead of
the full restart.

Here are patches I made for that:
 http://michich.fedorapeople.org/kexec-fedora/

You most likely do not use PK on a server, but take a look at the
helper script ck-system-restart-quick in the ConsoleKit patch. It
can be used outside of CK. It's not perfect but works for me.

Michal



From jamundso at gmail.com  Wed Dec 17 02:21:09 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Tue, 16 Dec 2008 20:21:09 -0600
Subject: To pre, or not to pre...
In-Reply-To: <385866f0812161544h7ab614e6r5d034737054917e7@mail.gmail.com>
References: <200812161726.15508.jamundso@gmail.com>
	<385866f0812161544h7ab614e6r5d034737054917e7@mail.gmail.com>
Message-ID: <6d06ce20812161821o3945e0c5m29feb0d49a005032@mail.gmail.com>

On Tue, Dec 16, 2008 at 5:44 PM, Muayyad AlSadi <alsadi at gmail.com> wrote:
>> print '\n%s encoding on %s\n' % (enc, item)
> was it piped
>
> because when a print is piped python won't do str.encode('utf-8')
> because it does not know the encoding of the pipe
>
> but when it's on terminal it could guess the output encoding

That output was from the terminal, which I tried because I was getting
the same traceback from the graphical wizard...

jerry

-- 
To be named later.



From jkeating at redhat.com  Wed Dec 17 02:26:22 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Dec 2008 18:26:22 -0800
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217024445.6351531a@hammerfall>
References: <gi5svv$jvc$1@ger.gmane.org>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
	<5256d0b0812161436o3ef5cf4dl580db464f791326a@mail.gmail.com>
	<20081217024445.6351531a@hammerfall>
Message-ID: <1229480782.6191.22.camel@localhost.localdomain>

On Wed, 2008-12-17 at 02:44 +0100, Michal Schmidt wrote:
> You most likely do not use PK on a server, but take a look at the
> helper script ck-system-restart-quick in the ConsoleKit patch. It
> can be used outside of CK. It's not perfect but works for me.

Note that our kernel folks have said they will summarily ignore any and
all bug reports that come from any use of kexec.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/ddeffd2c/attachment.sig>

From mjg at redhat.com  Wed Dec 17 03:00:55 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 17 Dec 2008 03:00:55 +0000
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49481793.9060406@behdad.org>
References: <1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
Message-ID: <20081217030055.GA19430@srcf.ucam.org>

On Tue, Dec 16, 2008 at 04:03:15PM -0500, Behdad Esfahbod wrote:

> This is actually the strongest argument against spending a lot of resources on
> going sub 20 seconds.  If Vista-style suspend-to-both works reliably, there is
> no reason to turn a machine off at all.

It doesn't. It won't within a year. I think that makes short boot times 
a worthy goal in the interim.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From mjg at redhat.com  Wed Dec 17 03:02:12 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 17 Dec 2008 03:02:12 +0000
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229467591.5054.131.camel@erebor.bos.redhat.com>
References: <20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<1229467591.5054.131.camel@erebor.bos.redhat.com>
Message-ID: <20081217030212.GB19430@srcf.ucam.org>

On Tue, Dec 16, 2008 at 05:46:31PM -0500, Jeremy Katz wrote:
> On Tue, 2008-12-16 at 17:16 -0500, Seth Vidal wrote:
> > At least on my system hibernate takes as much time as a reboot.
> 
> We should really work on fixing that too... :)

Mm. When you say we...

(Humour. This is a genuinely difficult problem and one that inovolves 
basically rearchitecting the current implementation)

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From jkeating at redhat.com  Wed Dec 17 03:11:47 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Dec 2008 19:11:47 -0800
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217030212.GB19430@srcf.ucam.org>
References: <20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<1229467591.5054.131.camel@erebor.bos.redhat.com>
	<20081217030212.GB19430@srcf.ucam.org>
Message-ID: <1229483507.6191.24.camel@localhost.localdomain>

On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
> (Humour. This is a genuinely difficult problem and one that inovolves 
> basically rearchitecting the current implementation)

HibernateKit ?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/7d00381a/attachment.sig>

From cra at WPI.EDU  Wed Dec 17 03:21:12 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 16 Dec 2008 22:21:12 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229483507.6191.24.camel@localhost.localdomain>
References: <20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<1229467591.5054.131.camel@erebor.bos.redhat.com>
	<20081217030212.GB19430@srcf.ucam.org>
	<1229483507.6191.24.camel@localhost.localdomain>
Message-ID: <20081217032112.GQ32016@angus.ind.WPI.EDU>

On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
> On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
> > (Humour. This is a genuinely difficult problem and one that inovolves 
> > basically rearchitecting the current implementation)
> 
> HibernateKit ?

Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds.  I 
don't see much way around this.



From wwoods at redhat.com  Wed Dec 17 03:33:41 2008
From: wwoods at redhat.com (Will Woods)
Date: Tue, 16 Dec 2008 22:33:41 -0500
Subject: To pre, or not to pre...
In-Reply-To: <200812161726.15508.jamundso@gmail.com>
References: <200812161726.15508.jamundso@gmail.com>
Message-ID: <1229484821.3028.6.camel@zebes.localdomain>

On Tue, 2008-12-16 at 17:26 -0600, Jerry Amundson wrote:
> I'm normally 'yum live upgrade' type, but trying preupgrade now.
> 
> 556/742 - preupgrade/packages/openoffice.org-calc-core-3.0.1-13.2.fc11.x86_64.rp
> 605/742 - preupgrade/packages/libXdamage-1.1.1-5.fc11.i386.rpmTraceback (most 
> recent call last):                                                                
>   File "/usr/share/preupgrade/preupgrade-cli.py", line 284, in <module>         
>     pu.main(myrelease)                                                          
>   File "/usr/share/preupgrade/preupgrade-cli.py", line 249, in main             
>     self.generate_repodata(cachedir, comps) # TODO: callback?                   
>   File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 711, in 
> generate_repodata                                                                
>     generate_repodata(dir, comps, callback)                                     
>   File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 727, in 
> generate_repodata_f9                                                             
>     mdgen.doPkgMetadata()
>   File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 332, in 
> doPkgMetadata
>     self.writeMetadataDocs(packages)
>   File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 475, in 
> writeMetadataDocs
>     clog_limit=self.conf.changelog_limit))
>   File "/usr/lib/python2.5/site-packages/yum/packages.py", line 959, in 
> xml_dump_other_metadata
>     msg += "%s\n</package>\n" % 
> misc.to_unicode(self._dump_changelog(clog_limit))
>   File "/usr/lib/python2.5/site-packages/yum/packages.py", line 936, in 
> _dump_changelog
>     misc.to_xml(author, attrib=True), misc.to_xml(str(ts)),
>   File "/usr/lib/python2.5/site-packages/yum/misc.py", line 749, in to_xml
>     item = _ugly_utf8_string_hack(item)
>   File "/usr/lib/python2.5/site-packages/yum/misc.py", line 728, in 
> _ugly_utf8_string_hack
>     print '\n%s encoding on %s\n' % (enc, item)
>   File "/usr/lib64/python2.5/codecs.py", line 303, in write
>     data, consumed = self.encode(object, self.errors)
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf8 in position 34: 
> ordinal not in range(128)

You're trying to upgrade to Rawhide, I take it? It looks like createrepo
is choking on something in the changelog of the rawhide libXdamage.

File a bug, someone will take a look.

-w



From wwoods at redhat.com  Wed Dec 17 03:38:25 2008
From: wwoods at redhat.com (Will Woods)
Date: Tue, 16 Dec 2008 22:38:25 -0500
Subject: To pre, or not to pre...
In-Reply-To: <1229484821.3028.6.camel@zebes.localdomain>
References: <200812161726.15508.jamundso@gmail.com>
	<1229484821.3028.6.camel@zebes.localdomain>
Message-ID: <1229485105.3028.9.camel@zebes.localdomain>

On Tue, 2008-12-16 at 22:33 -0500, Will Woods wrote:
> On Tue, 2008-12-16 at 17:26 -0600, Jerry Amundson wrote:
> > I'm normally 'yum live upgrade' type, but trying preupgrade now.
> > 
> > 556/742 - preupgrade/packages/openoffice.org-calc-core-3.0.1-13.2.fc11.x86_64.rp
> > 605/742 - preupgrade/packages/libXdamage-1.1.1-5.fc11.i386.rpmTraceback (most 
> > recent call last):                                                                
> >   File "/usr/share/preupgrade/preupgrade-cli.py", line 284, in <module>         
> >     pu.main(myrelease)                                                          
> >   File "/usr/share/preupgrade/preupgrade-cli.py", line 249, in main             
> >     self.generate_repodata(cachedir, comps) # TODO: callback?                   
> >   File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 711, in 
> > generate_repodata                                                                
> >     generate_repodata(dir, comps, callback)                                     
> >   File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 727, in 
> > generate_repodata_f9                                                             
> >     mdgen.doPkgMetadata()
> >   File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 332, in 
> > doPkgMetadata
> >     self.writeMetadataDocs(packages)
> >   File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 475, in 
> > writeMetadataDocs
> >     clog_limit=self.conf.changelog_limit))
> >   File "/usr/lib/python2.5/site-packages/yum/packages.py", line 959, in 
> > xml_dump_other_metadata
> >     msg += "%s\n</package>\n" % 
> > misc.to_unicode(self._dump_changelog(clog_limit))
> >   File "/usr/lib/python2.5/site-packages/yum/packages.py", line 936, in 
> > _dump_changelog
> >     misc.to_xml(author, attrib=True), misc.to_xml(str(ts)),
> >   File "/usr/lib/python2.5/site-packages/yum/misc.py", line 749, in to_xml
> >     item = _ugly_utf8_string_hack(item)
> >   File "/usr/lib/python2.5/site-packages/yum/misc.py", line 728, in 
> > _ugly_utf8_string_hack
> >     print '\n%s encoding on %s\n' % (enc, item)
> >   File "/usr/lib64/python2.5/codecs.py", line 303, in write
> >     data, consumed = self.encode(object, self.errors)
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xf8 in position 34: 
> > ordinal not in range(128)
> 
> You're trying to upgrade to Rawhide, I take it? It looks like createrepo
> is choking on something in the changelog of the rawhide libXdamage.

Er, to clarify, file a bug *against preupgrade*. I'm pretty sure
createrepo handles this normally outside of preupgrade so I'm probably
setting something up wrong.

The most recent changelog entry in libXdamage is:

* Wed Dec 03 2008 Caol?n McNamara <caolanm at redhat.com> - 1.1.1-5
- rebuild to get provides pkgconfig(xdamage)

Guess we're not handling that UTF-8 '?' properly.

-w



From rakesh.pandit at gmail.com  Wed Dec 17 03:41:39 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Wed, 17 Dec 2008 09:11:39 +0530
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <981da310812161527s4d8c5a46l8736c46e0947629a@mail.gmail.com>
References: <1229435781.4103.5.camel@localhost.localdomain>
	<1229443261.4049.324.camel@macbook.infradead.org>
	<b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
	<981da310812161527s4d8c5a46l8736c46e0947629a@mail.gmail.com>
Message-ID: <b401d2530812161941t1a1facc9jf6c590397d35e77f@mail.gmail.com>

2008/12/17 Brennan Ashton <bashton at brennanashton.com>:
[..]
>>>
>>
>> Yes we can do that easily, and I will extend the script to that
>> anyway. Hopefully if list is not too long it makes sense to include
>> bugs here.
>>
>> --
>> rakesh
> Rakesh,
>
> I can add you to the git-triage group, so you can push updates to the
> script in fedorahosted if you want, just make the request in FAS.
>

Applied. May you check ?

Test results are failing. Probably something is wrong on my part.
Script  fails on edge cases. I will hopefully get some time from day
job and fix it before next weeks report comes up along with above new
option.

This time will make a point to do some though testing with fedora friends ;)

-- 
rakesh



From rakesh.pandit at gmail.com  Wed Dec 17 03:43:33 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Wed, 17 Dec 2008 09:13:33 +0530
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <b401d2530812161941t1a1facc9jf6c590397d35e77f@mail.gmail.com>
References: <1229435781.4103.5.camel@localhost.localdomain>
	<1229443261.4049.324.camel@macbook.infradead.org>
	<b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
	<981da310812161527s4d8c5a46l8736c46e0947629a@mail.gmail.com>
	<b401d2530812161941t1a1facc9jf6c590397d35e77f@mail.gmail.com>
Message-ID: <b401d2530812161943v36a0a088yfd0f68c6ac727366@mail.gmail.com>

2008/12/17 Rakesh Pandit <rakesh.pandit at gmail.com>:
>
> This time will make a point to do some though testing with fedora friends ;)
>

*thorough

-- 
rakesh



From skvidal at fedoraproject.org  Wed Dec 17 04:19:11 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 16 Dec 2008 23:19:11 -0500 (EST)
Subject: RFC: Description text in packages
In-Reply-To: <1229467236.3529.18.camel@matthiasc>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc>
	<20081216222500.GA844@shell.devel.redhat.com>
	<1229467236.3529.18.camel@matthiasc>
Message-ID: <alpine.LFD.2.00.0812162318450.14515@localhost.localdomain>



On Tue, 16 Dec 2008, Matthias Clasen wrote:

>
>> Possibly, however package data in rpm headers is not wiki markdown and the
>> specification for RPM doesn't imply you can treat it that way.
>
> The specification for RPM doesn't imply anything about the description
> field. And this thread is about how to possibly improve the situation by
> agreeing on some form of interpretation.

Then it shouldn't be discussed here, as fedora is not the only 
user/consumer of rpm.

-sv



From skvidal at fedoraproject.org  Wed Dec 17 04:20:03 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 16 Dec 2008 23:20:03 -0500 (EST)
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229474301.28858.85.camel@aglarond.local>
References: <gi5svv$jvc$1@ger.gmane.org> <20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
	<1229467644.5054.132.camel@erebor.bos.redhat.com>
	<494832BE.1050406@behdad.org>
	<1229474301.28858.85.camel@aglarond.local>
Message-ID: <alpine.LFD.2.00.0812162319530.14515@localhost.localdomain>



On Tue, 16 Dec 2008, Jeremy Katz wrote:

> On Tue, 2008-12-16 at 17:59 -0500, Behdad Esfahbod wrote:
>> Jeremy Katz wrote:
>>> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
>>>> Once upon a time, Jesse Keating <jkeating at redhat.com> said:
>>>>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>>>>> so a good reason to power off is simply to save power
>>>>> Or to reboot for one of our frequent updates that require it.  kernel,
>>>>> dbus, etc...
>>>> Why does anything other than a kernel update require a reboot?
>>>
>>> The system bus cannot be restarted.  Similarly, any apps you have
>>> running will be using old libraries so things like glibc you really want
>>> to reboot for.
>>
>> Back in the days, sshd had a trigger to restart itself on glibc update.  init
>> had a similar thing too I guess...
>
> Yes, but that's not everything on your system.  Should we add triggers
> for everything you can possibly run?  :)
>

There's this yum plugin..... ;)

-sv



From peter at thecodergeek.com  Wed Dec 17 04:46:56 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 16 Dec 2008 20:46:56 -0800
Subject: License Revert: Deluge (CC-BY-SA Tango images removed)
In-Reply-To: <1228472491.9341.370.camel@localhost.localdomain>
References: <1228472491.9341.370.camel@localhost.localdomain>
Message-ID: <1229489216.11653.6.camel@localhost.localdomain>

On Fri, 2008-12-05 at 02:21 -0800, Peter Gordon wrote:
> I just committed a version bump to the devel branch for Deluge 1.0.6
> (with an F-10 sync on my TODO list for tomorrow) which includes some
> images from the Tango project in the directory
> "deluge/ui/webui/static/images/tango" of the unpacked tarball. (These
> are installed to their final destination of the same directory tree
> under %python_sitearch during the build process.) These images are under
> the Creative Commons Attribution Share-Alike license, version 2.5.
> 

I'm going to push an update to 1.0.7 shortly which removes these Tango
images - and causes the licensing to revert to the "GPLv2+" as it was in
versions prior to 1.0.6.

This was an upstream decision to replace the icons, as the CC-BY-SA
license in use for these was version 2 and therefore not DFSG-compatible
for their Debian/Ubuntu packaging.

In short, the License is once again simply "GPLv2+"; and please feel
free to yell at me or inquire about any issues again if they arise.

Thanks.
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081216/3108cf77/attachment.sig>

From wtogami at redhat.com  Wed Dec 17 05:48:45 2008
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 17 Dec 2008 00:48:45 -0500
Subject: PPC netboot on F-10?
Message-ID: <494892BD.6060603@redhat.com>

http://wtogami.livejournal.com/29574.html
Has anyone successfully netbooted any PPC Mac with F-10?  I tried a G3 
iMac and G5 tower today with only failure.

Warren Togami
wtogami at redhat.com



From bashton at brennanashton.com  Wed Dec 17 06:02:02 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Tue, 16 Dec 2008 22:02:02 -0800
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <b401d2530812161941t1a1facc9jf6c590397d35e77f@mail.gmail.com>
References: <1229435781.4103.5.camel@localhost.localdomain>
	<1229443261.4049.324.camel@macbook.infradead.org>
	<b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
	<981da310812161527s4d8c5a46l8736c46e0947629a@mail.gmail.com>
	<b401d2530812161941t1a1facc9jf6c590397d35e77f@mail.gmail.com>
Message-ID: <981da310812162202t359c2629r7ea8126fec918fd2@mail.gmail.com>

On Tue, Dec 16, 2008 at 7:41 PM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
> 2008/12/17 Brennan Ashton <bashton at brennanashton.com>:
> [..]
>>>>
>>>
>>> Yes we can do that easily, and I will extend the script to that
>>> anyway. Hopefully if list is not too long it makes sense to include
>>> bugs here.
>>>
>>> --
>>> rakesh
>> Rakesh,
>>
>> I can add you to the git-triage group, so you can push updates to the
>> script in fedorahosted if you want, just make the request in FAS.
>>
>
> Applied. May you check ?
>
> Test results are failing. Probably something is wrong on my part.
> Script  fails on edge cases. I will hopefully get some time from day
> job and fix it before next weeks report comes up along with above new
> option.
>
> This time will make a point to do some though testing with fedora friends ;)
>
> --
> rakesh

Rakesh,

Sorry it turns out that while I have admin privileges on the
fedorahosted project, I did not have sponsorship privileges on the
group. I got jds2001 to sponsor you.

--Brennan Ashton



From james at fedoraproject.org  Wed Dec 17 06:17:42 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 17 Dec 2008 01:17:42 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217032112.GQ32016@angus.ind.WPI.EDU>
References: <20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<1229467591.5054.131.camel@erebor.bos.redhat.com>
	<20081217030212.GB19430@srcf.ucam.org>
	<1229483507.6191.24.camel@localhost.localdomain>
	<20081217032112.GQ32016@angus.ind.WPI.EDU>
Message-ID: <1229494662.6392.42.camel@code.and.org>

On Tue, 2008-12-16 at 22:21 -0500, Chuck Anderson wrote:
> On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
> > On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
> > > (Humour. This is a genuinely difficult problem and one that inovolves 
> > > basically rearchitecting the current implementation)
> > 
> > HibernateKit ?
> 
> Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds.  I 
> don't see much way around this.

 Why would you need to do that? I mean I can understand that it's
probably "easy" to do it that way ... but how much harder is it to do:

1. Write all the dirty pages to swap/disk.

2. Drop all the clean droppable pages.

3. write out what's left.

-- 
James Antill <james at fedoraproject.org>
Fedora



From lesmikesell at gmail.com  Wed Dec 17 07:10:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 01:10:50 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217032112.GQ32016@angus.ind.WPI.EDU>
References: <20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<4948220D.9070202@behdad.org>	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>	<1229467591.5054.131.camel@erebor.bos.redhat.com>	<20081217030212.GB19430@srcf.ucam.org>	<1229483507.6191.24.camel@localhost.localdomain>
	<20081217032112.GQ32016@angus.ind.WPI.EDU>
Message-ID: <4948A5FA.3080902@gmail.com>

Chuck Anderson wrote:
> On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
>> On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
>>> (Humour. This is a genuinely difficult problem and one that inovolves 
>>> basically rearchitecting the current implementation)
>> HibernateKit ?
> 
> Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds.  I 
> don't see much way around this.

On a laptop, can't you suspend first, then hibernate only if power drops 
dangerously low (and while no one is waiting)?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Wed Dec 17 07:20:30 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 01:20:30 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49481793.9060406@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
Message-ID: <4948A83E.4060007@gmail.com>

Behdad Esfahbod wrote:
> > Matej Cepl wrote:
>> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>>> Nothing to say you can't re-enable it yourself. I don't have a
>>> permanent connection to the net but evolution happily holds it in my
>>> outbox until I go back online and can connect to a network. Fedora can
>> I have a nasty surprise for you -- Fedora is not Windows, so it
>> would is not only for people who use Evolution / Kmail
>> / Thunderbird.
> 
> See above.  On a similar line of though, how about: "please install and enable
> httpd, postgresql, and squid" by default because I use them...

Yes, how about it?  What's the point of booting quickly - or at all, if 
the machine won't provide any services?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From fedora at leemhuis.info  Wed Dec 17 07:24:49 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 17 Dec 2008 08:24:49 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4948A5FA.3080902@gmail.com>
References: <20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<4948220D.9070202@behdad.org>	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>	<1229467591.5054.131.camel@erebor.bos.redhat.com>	<20081217030212.GB19430@srcf.ucam.org>	<1229483507.6191.24.camel@localhost.localdomain>	<20081217032112.GQ32016@angus.ind.WPI.EDU>
	<4948A5FA.3080902@gmail.com>
Message-ID: <4948A941.20600@leemhuis.info>

On 17.12.2008 08:10, Les Mikesell wrote:
> Chuck Anderson wrote:
>> On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
>>> On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
>>>> (Humour. This is a genuinely difficult problem and one that inovolves 
>>>> basically rearchitecting the current implementation)
>>> HibernateKit ?
>> Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds.  I 
>> don't see much way around this.
> On a laptop, can't you suspend first, then hibernate only if power drops 
> dangerously low (and while no one is waiting)?

You would need to power up to hibernate -- not something laptops should 
do automatically, as they might be in a bag without fresh air for 
cooling (which obviously could lead to damaged hardware if hibernating 
fails).

CU
knurd



From arjan at infradead.org  Wed Dec 17 07:46:16 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Wed, 17 Dec 2008 08:46:16 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081216183138.GC1558744@hiwaay.net>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<200812161522.mBGFMsiq032572@laptop14.inf.utfsm.cl>
	<5256d0b0812160809t68f0cc48w8dd573e9d95dac34@mail.gmail.com>
	<20081216175219.3d280df2@infradead.org>
	<20081216183138.GC1558744@hiwaay.net>
Message-ID: <20081217084616.3d46bd8f@infradead.org>

On Tue, 16 Dec 2008 12:31:38 -0600
Chris Adams <cmadams at hiwaay.net> wrote:

> Also, part of the justification for a local MTA is that some programs
> want to use SMTP on 127.0.0.1, which requires some kind of daemon
> running there (either an MTA or xinetd to fork an MTA on demand).

name one .
seriously.

(and this is what xinetd is for anyway)



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From nikolay at vladimiroff.com  Wed Dec 17 07:48:05 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Wed, 17 Dec 2008 09:48:05 +0200
Subject: RFC: Description text in packages
In-Reply-To: <20081217001214.GA15516@shell.devel.redhat.com>
References: <1229416413.3434.3.camel@hughsie-work.lan>
	<1229451449.13024.6.camel@arekh.okg>
	<a2e85ed0812161038v3d8f9d61tb3e1801a3954da14@mail.gmail.com>
	<1229454454.13999.31.camel@arekh.okg>
	<a2e85ed0812161202m78643d0aqfae93510569c6587@mail.gmail.com>
	<1229458902.15689.31.camel@arekh.okg>
	<1229462407.3529.13.camel@matthiasc>
	<20081216222500.GA844@shell.devel.redhat.com>
	<1229467236.3529.18.camel@matthiasc>
	<20081217001214.GA15516@shell.devel.redhat.com>
Message-ID: <a2e85ed0812162348i7af8150eu9e9df8ba0e44f321@mail.gmail.com>

2008/12/17 Alan Cox <alan at redhat.com>:
> On Tue, Dec 16, 2008 at 05:40:36PM -0500, Matthias Clasen wrote:
>>
> Right - the field is plain UTF-8 textual data and has been for years. You
> want to add a semantic version of it. That is fine but use a new header for
> the field the way RPM intends things to be added.

That seems like a good solution.



-- 
NV



From lesmikesell at gmail.com  Wed Dec 17 07:48:31 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 01:48:31 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4948A941.20600@leemhuis.info>
References: <20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<4948220D.9070202@behdad.org>	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>	<1229467591.5054.131.camel@erebor.bos.redhat.com>	<20081217030212.GB19430@srcf.ucam.org>	<1229483507.6191.24.camel@localhost.localdomain>	<20081217032112.GQ32016@angus.ind.WPI.EDU>	<4948A5FA.3080902@gmail.com>
	<4948A941.20600@leemhuis.info>
Message-ID: <4948AECF.60808@gmail.com>

Thorsten Leemhuis wrote:
>
>>>> HibernateKit ?
>>> Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds.  I 
>>> don't see much way around this.
>> On a laptop, can't you suspend first, then hibernate only if power 
>> drops dangerously low (and while no one is waiting)?
> 
> You would need to power up to hibernate -- not something laptops should 
> do automatically, as they might be in a bag without fresh air for 
> cooling (which obviously could lead to damaged hardware if hibernating 
> fails).

I thought my old G4 powerbook did that years ago - and current XP.  Did 
I imagine that?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From arjan at infradead.org  Wed Dec 17 07:51:08 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Wed, 17 Dec 2008 08:51:08 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
Message-ID: <20081217085108.6cdc5d21@infradead.org>

On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
Seth Vidal <skvidal at fedoraproject.org> wrote:

> 
> > Or hibernate?
> 
> At least on my system hibernate takes as much time as a reboot.
> 

btw this is a very fundamental property of hibernate. You need to do all
disk IO to get the system state to disk. And then at resume, you need
to do all disk IO to get the state from disk again. That's twice ;)

This is compounded by the property that a hibernate tends to flush at
least half the disk cache (it has to, to get space to work in), which
you then need to page right back in, so even when you're back, the first
minute or two sucks badly.

I suspect you will always be able to boot faster than you can
hibernate+resume.




-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From bashton at brennanashton.com  Wed Dec 17 07:51:10 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Tue, 16 Dec 2008 23:51:10 -0800
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <981da310812162202t359c2629r7ea8126fec918fd2@mail.gmail.com>
References: <1229435781.4103.5.camel@localhost.localdomain>
	<1229443261.4049.324.camel@macbook.infradead.org>
	<b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
	<981da310812161527s4d8c5a46l8736c46e0947629a@mail.gmail.com>
	<b401d2530812161941t1a1facc9jf6c590397d35e77f@mail.gmail.com>
	<981da310812162202t359c2629r7ea8126fec918fd2@mail.gmail.com>
Message-ID: <981da310812162351q65c5e6d5n85f3faac26e89826@mail.gmail.com>

>> Test results are failing. Probably something is wrong on my part.
>> Script  fails on edge cases. I will hopefully get some time from day
>> job and fix it before next weeks report comes up along with above new
>> option.
>>
>> This time will make a point to do some though testing with fedora friends ;)
>>
>> --
>> rakesh

I just fixed a somewhat large bug, where bugs that should have been
counted, but were modified after the script end time would not be
counted.  So as time passes more would be lost. It was a very simple
fix (one liner), and I have pushed it.  Thank you paragn for pointing
out something was not quite right.

https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py

Other then that it seems to be responding correctly.

--Brennan Ashton



From behdad at behdad.org  Wed Dec 17 07:56:14 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 02:56:14 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4948A83E.4060007@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>
	<4948A83E.4060007@gmail.com>
Message-ID: <4948B09E.5080400@behdad.org>

Les Mikesell wrote:
> Behdad Esfahbod wrote:
>> > Matej Cepl wrote:
>>> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>>>> Nothing to say you can't re-enable it yourself. I don't have a
>>>> permanent connection to the net but evolution happily holds it in my
>>>> outbox until I go back online and can connect to a network. Fedora can
>>> I have a nasty surprise for you -- Fedora is not Windows, so it
>>> would is not only for people who use Evolution / Kmail
>>> / Thunderbird.
>>
>> See above.  On a similar line of though, how about: "please install
>> and enable
>> httpd, postgresql, and squid" by default because I use them...
> 
> Yes, how about it?  What's the point of booting quickly - or at all, if
> the machine won't provide any services?

Why would I install the desktop spin if I need those?  Fedora has been taking
the lets-start-any-services-that-someone-may-need approach so far.  It doesn't
work.  Spins are a neat way to customize the default install for different
sectors.  The desktop spin should not install an MTA in my opinion.  That's
all I'm saying.

behdad



From behdad at behdad.org  Wed Dec 17 07:59:41 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 02:59:41 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217085108.6cdc5d21@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>
	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<4948220D.9070202@behdad.org>	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<20081217085108.6cdc5d21@infradead.org>
Message-ID: <4948B16D.4000402@behdad.org>

Arjan van de Ven wrote:

> I suspect you will always be able to boot faster than you can
> hibernate+resume.

Hard to argue with that.  But if hibernate is the less common thing, and 90%
of time suspend works, it's a win.  And lets not forget that hibernate gets
you back where you left, where shutdown/boot-up doesn't.

I know suspend-to-both doesn't work and is not expected to work soon.  But
just making suspend work reliably gets us mostly there.  My laptop suspends
and resumes in about 5 seconds each way.  And fails perhaps once every 30
suspends.  Has done wonders.  I can't imagine having to shutdown all the time.

behdad



From panemade at gmail.com  Wed Dec 17 08:36:31 2008
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Wed, 17 Dec 2008 14:06:31 +0530
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <981da310812162351q65c5e6d5n85f3faac26e89826@mail.gmail.com>
References: <1229435781.4103.5.camel@localhost.localdomain>
	<1229443261.4049.324.camel@macbook.infradead.org>
	<b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
	<981da310812161527s4d8c5a46l8736c46e0947629a@mail.gmail.com>
	<b401d2530812161941t1a1facc9jf6c590397d35e77f@mail.gmail.com>
	<981da310812162202t359c2629r7ea8126fec918fd2@mail.gmail.com>
	<981da310812162351q65c5e6d5n85f3faac26e89826@mail.gmail.com>
Message-ID: <f4586a2e0812170036t37bccd4av794d4ee06539460f@mail.gmail.com>

Hi,
On Wed, Dec 17, 2008 at 1:21 PM, Brennan Ashton
<bashton at brennanashton.com>wrote:

> >> Test results are failing. Probably something is wrong on my part.
> >> Script  fails on edge cases. I will hopefully get some time from day
> >> job and fix it before next weeks report comes up along with above new
> >> option.
> >>
> >> This time will make a point to do some though testing with fedora
> friends ;)
> >>
> >> --
> >> rakesh
>
> I just fixed a somewhat large bug, where bugs that should have been
> counted, but were modified after the script end time would not be
> counted.  So as time passes more would be lost. It was a very simple
> fix (one liner), and I have pushed it.  Thank you paragn for pointing
> out something was not quite right.
>
> https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py
>
> Other then that it seems to be responding correctly.


  Yes. It looks working correctly now. Thanks for fixing it.

Regards,
Parag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/70d1057d/attachment.htm>

From mefoster at gmail.com  Wed Dec 17 08:58:26 2008
From: mefoster at gmail.com (Mary Ellen Foster)
Date: Wed, 17 Dec 2008 09:58:26 +0100
Subject: orphaning all my packages
In-Reply-To: <20081216153341.GL2414@free.fr>
References: <20081216094739.GA3877@free.fr>
	<f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>
	<20081216151415.GJ2414@free.fr>
	<f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>
	<20081216153341.GL2414@free.fr>
Message-ID: <f58861e00812170058n77b09d31uf721d6db3d1504d5@mail.gmail.com>

On Tue, Dec 16, 2008 at 4:33 PM, Patrice Dumas <pertusus at free.fr> wrote:
> Maybe you missed the first wave of orphanage, some days ago I orphaned,
> among others, tetex-tex4ht. Do you also want to maintain it? It is a
> package that needs some work, upstream is quite active, and ensuring
> that it builds from the literate sources can require some work.

Yes, I'll also take that one (all branches). And in response to
Jonathan Underwood's question: I'm happy to co-maintain all of these
packages.

Sorry for the delay in replying,

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 pertusus at free.fr  Wed Dec 17 09:07:55 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 17 Dec 2008 10:07:55 +0100
Subject: orphaning all my packages
In-Reply-To: <f58861e00812170058n77b09d31uf721d6db3d1504d5@mail.gmail.com>
References: <20081216094739.GA3877@free.fr>
	<f58861e00812160625m32c8f86fk87c36178cc4aee34@mail.gmail.com>
	<20081216151415.GJ2414@free.fr>
	<f58861e00812160717l62a01ee6j74571b81e04f3797@mail.gmail.com>
	<20081216153341.GL2414@free.fr>
	<f58861e00812170058n77b09d31uf721d6db3d1504d5@mail.gmail.com>
Message-ID: <20081217090755.GA2341@free.fr>

On Wed, Dec 17, 2008 at 09:58:26AM +0100, Mary Ellen Foster wrote:
> On Tue, Dec 16, 2008 at 4:33 PM, Patrice Dumas <pertusus at free.fr> wrote:
> > Maybe you missed the first wave of orphanage, some days ago I orphaned,
> > among others, tetex-tex4ht. Do you also want to maintain it? It is a
> > package that needs some work, upstream is quite active, and ensuring
> > that it builds from the literate sources can require some work.
> 
> Yes, I'll also take that one (all branches). And in response to
> Jonathan Underwood's question: I'm happy to co-maintain all of these
> packages.

Branch realeased, thanks for taking tex4ht, I think that it is an 
important package for fedora. The name should be tex-tex4ht (or could 
even be tex4ht), but since the process to change the name was a rereview 
it seemed to be a loss of time for me. But since this package is new for 
you, maybe you'll want to do that.

--
Pat



From pertusus at free.fr  Wed Dec 17 09:34:09 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 17 Dec 2008 10:34:09 +0100
Subject: xchm orphaned
Message-ID: <20081217093409.GB2341@free.fr>

Hello,

I missed xchm... I orphaned the devel, F9 and F10 branches, I keep 
the EPEL branches. Manuel Wolfshant is already co-maintainer, but I am 
sure that he won't mind some help. 
It is a low maintainance package.

I hope I didn't forgot more packages...

--
Pat



From hughsient at gmail.com  Wed Dec 17 09:49:40 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 17 Dec 2008 09:49:40 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229466653.6392.38.camel@code.and.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg>  <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
Message-ID: <1229507380.1951.15.camel@hughsie-work.lan>

On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
>  Personally I think the use of '"', ., *, ?, o or ? ... are fine, just
> as long as all the tools are displaying the same non-invisible bytes?.

Right, this discussion is going nowhere, and there are a lot of egos in
play. At the moment I'm thinking PK should just do this:

---------------------------------------------
This is a spec file description or
an update description in bohdi.

The following things 'were' fixed:
- Fix `dave'
- Fubar update because of "security"
--------------------------------------------

This will be converted by gnome-packagekit into:

---------------------------------------------
This is a spec file description or an update description in bohdi.

The following things ?were? fixed:
? Fix ?dave?
? Fubar update because of ?security?
---------------------------------------------

The double quotes will be marked translated as left and right chars (so
? and ? can be used), the LaTeX single quotes (and double  will be
expanded and "- " converted to bullets.

If you're doing to use ? or ? in a spec file, then the text box is going
to look rubbish and be all on one line. If you use a description longer
than a few hundred words, gnome-packagekit will truncate it.

Now I'm going to go back to coding, rather than talking to angry people.

Richard.




From nicolas.mailhot at laposte.net  Wed Dec 17 10:01:42 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 17 Dec 2008 11:01:42 +0100 (CET)
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229507380.1951.15.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
Message-ID: <f29e4132384237edd07b2786b861567d.squirrel@arekh.dyndns.org>



Le Mer 17 d?cembre 2008 10:49, Richard Hughes a ?crit :
>
> On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
>>  Personally I think the use of '"', ., *, ?, o or ? ... are fine,
>> just
>> as long as all the tools are displaying the same non-invisible
>> bytes?.
>
> Right, this discussion is going nowhere, and there are a lot of egos
> in play. At the moment I'm thinking PK should just do this:

So now you are defining a new gnome-PK only syntax that won't work in
yum, rpm, urpmi, apt, synaptic, gnorpm, yumex, anaconda, LSB rpm, etc
and will encourage people to produce badly encoded descriptions
instead of fixing their text.

And you can't even be bothered to get it reviewed at the distro level
(let alone upstream rpm or lsb-side)

While you are at it, please also integrate a spell and grammar checker
so users are not exposed to spelling and grammar mistakes and
packagers do not have to worry about grammar or spell problems.

Seriously. This stuff is already defined and standardised. You may not
like what the currebt official choices are, but workarounding them at
your app level instead of fixing them at the right level (upstream, ie
in this case in the distro spec files) is not the right thing to do.

-- 
Nicolas Mailhot



From tim at niemueller.de  Wed Dec 17 10:21:52 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Wed, 17 Dec 2008 11:21:52 +0100
Subject: Build problem with kernel header
Message-ID: <4948D2C0.4020508@niemueller.de>

Hi Fedora.

I'm trying to build the player package. It bails out with the following
error message:

bin/sh ../../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../../.. -I../../../libplayercore
-I../../../client_libs/libplayerc++ -I../../../client_libs/libplayerc
-Wall -I../../..   -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic -MT sicklms200.lo -MD -MP -MF .deps/sicklms200.Tpo -c -o
sicklms200.lo sicklms200.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../..
-I../../../libplayercore -I../../../client_libs/libplayerc++
-I../../../client_libs/libplayerc -Wall -I../../.. -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -MT sicklms200.lo -MD -MP
-MF .deps/sicklms200.Tpo -c sicklms200.cc  -fPIC -DPIC -o .libs/sicklms200.o
In file included from sicklms200.cc:206:
/usr/include/linux/serial.h:164: error: '__u32' does not name a type
/usr/include/linux/serial.h:168: error: '__u32' does not name a type
/usr/include/linux/serial.h:169: error: '__u32' does not name a type
make[4]: *** [sicklms200.lo] Error 1

The full log is at
http://koji.fedoraproject.org/koji/getfile?taskID=1003066&name=build.log

On my local (F-10) system I do not see any reference to __u32 in
serial.h, likewise this type is not used in the sicklms200.cc file. Any
idea what is causing this? I do not have a rawhide system at hand, so I
couldn't verify kernel-headers-2.6.28-0.129.rc8.git2.fc11 that is
mentioned in root.log.

Regards from Aachen,
	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From pbrobinson at gmail.com  Wed Dec 17 10:26:09 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 17 Dec 2008 11:26:09 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4948B09E.5080400@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org> <20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<4948A83E.4060007@gmail.com> <4948B09E.5080400@behdad.org>
Message-ID: <5256d0b0812170226t51309b37wfd57489a24a637fa@mail.gmail.com>

>>>> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>>>>> Nothing to say you can't re-enable it yourself. I don't have a
>>>>> permanent connection to the net but evolution happily holds it in my
>>>>> outbox until I go back online and can connect to a network. Fedora can
>>>> I have a nasty surprise for you -- Fedora is not Windows, so it
>>>> would is not only for people who use Evolution / Kmail
>>>> / Thunderbird.
>>>
>>> See above.  On a similar line of though, how about: "please install
>>> and enable
>>> httpd, postgresql, and squid" by default because I use them...
>>
>> Yes, how about it?  What's the point of booting quickly - or at all, if
>> the machine won't provide any services?
>
> Why would I install the desktop spin if I need those?  Fedora has been taking
> the lets-start-any-services-that-someone-may-need approach so far.  It doesn't
> work.  Spins are a neat way to customize the default install for different
> sectors.  The desktop spin should not install an MTA in my opinion.  That's
> all I'm saying.

Exactly! But to do that we need a standard to all those apps require
the sendmail binary just in case you need to use the mail feature.

Peter



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Dec 17 10:39:43 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 17 Dec 2008 19:39:43 +0900
Subject: Build problem with kernel header
In-Reply-To: <4948D2C0.4020508@niemueller.de>
References: <4948D2C0.4020508@niemueller.de>
Message-ID: <4948D6EF.9060202@ioa.s.u-tokyo.ac.jp>

Tim Niemueller wrote, at 12/17/2008 07:21 PM +9:00:
> Hi Fedora.
> 
> I'm trying to build the player package. It bails out with the following
> error message:
> 
> bin/sh ../../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H
> -I. -I../../.. -I../../../libplayercore
> -I../../../client_libs/libplayerc++ -I../../../client_libs/libplayerc
> -Wall -I../../..   -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
> -mtune=generic -MT sicklms200.lo -MD -MP -MF .deps/sicklms200.Tpo -c -o
> sicklms200.lo sicklms200.cc
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../..
> -I../../../libplayercore -I../../../client_libs/libplayerc++
> -I../../../client_libs/libplayerc -Wall -I../../.. -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m64 -mtune=generic -MT sicklms200.lo -MD -MP
> -MF .deps/sicklms200.Tpo -c sicklms200.cc  -fPIC -DPIC -o .libs/sicklms200.o
> In file included from sicklms200.cc:206:
> /usr/include/linux/serial.h:164: error: '__u32' does not name a type
> /usr/include/linux/serial.h:168: error: '__u32' does not name a type
> /usr/include/linux/serial.h:169: error: '__u32' does not name a type
> make[4]: *** [sicklms200.lo] Error 1
> 
> The full log is at
> http://koji.fedoraproject.org/koji/getfile?taskID=1003066&name=build.log
> 
> On my local (F-10) system I do not see any reference to __u32 in
> serial.h, likewise this type is not used in the sicklms200.cc file. Any
> idea what is causing this? I do not have a rawhide system at hand, so I
> couldn't verify kernel-headers-2.6.28-0.129.rc8.git2.fc11 that is
> mentioned in root.log.
> 
> Regards from Aachen,
> 	Tim

I already reported this issue several days ago:
https://bugzilla.redhat.com/show_bug.cgi?id=476327

Also by other people:
http://lkml.org/lkml/2008/12/2/75

Mamoru



From caolanm at redhat.com  Wed Dec 17 10:58:12 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Wed, 17 Dec 2008 10:58:12 +0000
Subject: Build problem with kernel header
In-Reply-To: <4948D2C0.4020508@niemueller.de>
References: <4948D2C0.4020508@niemueller.de>
Message-ID: <1229511492.28851.1777.camel@Vain>

On Wed, 2008-12-17 at 11:21 +0100, Tim Niemueller wrote:
> Hi Fedora.
> 
> I'm trying to build the player package. It bails out with the following
> error message:
> /usr/include/linux/serial.h:164: error: '__u32' does not name a type
> /usr/include/linux/serial.h:168: error: '__u32' does not name a type
> /usr/include/linux/serial.h:169: error: '__u32' does not name a type
> make[4]: *** [sicklms200.lo] Error 1

Perhaps simply include linux/types.h before linux/serial.h, e.g. this
attached patch.

C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: player-2.1.1-types.patch
Type: text/x-patch
Size: 990 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/303f40f0/attachment.bin>

From hughsient at gmail.com  Wed Dec 17 11:19:18 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 17 Dec 2008 11:19:18 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <f29e4132384237edd07b2786b861567d.squirrel@arekh.dyndns.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<f29e4132384237edd07b2786b861567d.squirrel@arekh.dyndns.org>
Message-ID: <1229512758.1951.22.camel@hughsie-work.lan>

On Wed, 2008-12-17 at 11:01 +0100, Nicolas Mailhot wrote:
> Le Mer 17 d?cembre 2008 10:49, Richard Hughes a ?crit :
> >
> > On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
> >>  Personally I think the use of '"', ., *, ?, o or ? ... are fine,
> >> just
> >> as long as all the tools are displaying the same non-invisible
> >> bytes?.
> >
> > Right, this discussion is going nowhere, and there are a lot of egos
> > in play. At the moment I'm thinking PK should just do this:
> 
> So now you are defining a new gnome-PK only syntax that won't work in
> yum, rpm, urpmi, apt, synaptic, gnorpm, yumex, anaconda, LSB rpm, etc
> and will encourage people to produce badly encoded descriptions
> instead of fixing their text.

Ohh, it'll work just fine. In other frontends you'll get:

This is a description, la al la.
List of things fixed:
- one
- two
- three

and in GNOME PK you'll get UTF8 bullets and paragraph unwinding.

> And you can't even be bothered to get it reviewed at the distro level
> (let alone upstream rpm or lsb-side)

No, I'm fed up of being flamed.

> While you are at it, please also integrate a spell and grammar checker
> so users are not exposed to spelling and grammar mistakes and
> packagers do not have to worry about grammar or spell problems.

ROFL.

> Seriously. This stuff is already defined and standardised. You may not
> like what the currebt official choices are, but workarounding them at
> your app level instead of fixing them at the right level (upstream, ie
> in this case in the distro spec files) is not the right thing to do.

* Fri Feb 08 2008  Nicolas Mailhot <nicolas.mailhot at laposte.net>
- 1:1.09-3
? gcc 4.3 rebuild

* Mon Aug 13 2007 Nicolas Mailhot <nicolas.mailhot at laposte.net>
? 1:1.09-2
? Fix License

So, you've discussed those changes with upstream, defined a set of
enumerated values, and standardised the other spec files right?

I tend to agree with Matthias, markdown
http://en.wikipedia.org/wiki/Markdown seems to be the best compromise,
and I'll adjust my formatter to adhere to this.

Richard.




From konrad at tylerc.org  Wed Dec 17 11:41:19 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 17 Dec 2008 03:41:19 -0800
Subject: Review Swaps
Message-ID: <200812170341.19903.konrad@tylerc.org>

Hey, I'm looking to swap reviews for:

jcodings - https://bugzilla.redhat.com/show_bug.cgi?id=473537
python-zope-filesystem - https://bugzilla.redhat.com/show_bug.cgi?id=476475

(Warning, jcodings is java.)

jcodings should be pretty simple as java libraries go.

python-zope-filesystem is a trivial package to own the %{python_sitelib}/zope 
and %{python_sitearch}/zope directories for python-zope-* packages.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From caolanm at redhat.com  Wed Dec 17 11:46:54 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Wed, 17 Dec 2008 11:46:54 +0000
Subject: Build problem with kernel header
In-Reply-To: <1229511492.28851.1777.camel@Vain>
References: <4948D2C0.4020508@niemueller.de> <1229511492.28851.1777.camel@Vain>
Message-ID: <1229514414.28851.1850.camel@Vain>

On Wed, 2008-12-17 at 10:58 +0000, Caol?n McNamara wrote:
> On Wed, 2008-12-17 at 11:21 +0100, Tim Niemueller wrote:
> > Hi Fedora.
> > 
> > I'm trying to build the player package. It bails out with the following
> > error message:
> > /usr/include/linux/serial.h:164: error: '__u32' does not name a type
> > /usr/include/linux/serial.h:168: error: '__u32' does not name a type
> > /usr/include/linux/serial.h:169: error: '__u32' does not name a type
> > make[4]: *** [sicklms200.lo] Error 1
> 
> Perhaps simply include linux/types.h before linux/serial.h, e.g. this
> attached patch.

After trying a test-build, you probably also need something like this to
get past the next set of errors.

C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: player-2.1.1-gcc44.patch
Type: text/x-patch
Size: 2327 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/a7507f16/attachment.bin>

From nicolas.mailhot at laposte.net  Wed Dec 17 11:56:36 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 17 Dec 2008 12:56:36 +0100 (CET)
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229512758.1951.22.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<f29e4132384237edd07b2786b861567d.squirrel@arekh.dyndns.org>
	<1229512758.1951.22.camel@hughsie-work.lan>
Message-ID: <a154c2107e108c2f5644d397a84009c7.squirrel@arekh.dyndns.org>



Le Mer 17 d?cembre 2008 12:19, Richard Hughes a ?crit :

> * Fri Feb 08 2008  Nicolas Mailhot <nicolas.mailhot at laposte.net>
> - 1:1.09-3
> ? gcc 4.3 rebuild
>
> So, you've discussed those changes with upstream, defined a set of
> enumerated values, and standardised the other spec files right?

This is plain UTF-8 text that passes the current guidelines, that
passes rpmlint, and without non-standard magic post-processing markup
application side. It works in vi, emacs, eclipse, gedit, etc the same
way.

Which is what standardisation are about. Apps do not have to know
about a special syntax and I don't have to know about special app
quirks because we use the same plain UTF-8 text without magic spec.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Wed Dec 17 12:15:13 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 17 Dec 2008 13:15:13 +0100 (CET)
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <a154c2107e108c2f5644d397a84009c7.squirrel@arekh.dyndns.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<f29e4132384237edd07b2786b861567d.squirrel@arekh.dyndns.org>
	<1229512758.1951.22.camel@hughsie-work.lan>
	<a154c2107e108c2f5644d397a84009c7.squirrel@arekh.dyndns.org>
Message-ID: <b2bf6bce454fd8e95a4b3591e182615f.squirrel@arekh.dyndns.org>



Le Mer 17 d?cembre 2008 12:56, Nicolas Mailhot a ?crit :
>
>
>
> Le Mer 17 d?cembre 2008 12:19, Richard Hughes a ?crit :
>
>> * Fri Feb 08 2008  Nicolas Mailhot <nicolas.mailhot at laposte.net>
>> - 1:1.09-3
>> ? gcc 4.3 rebuild
>>
>> So, you've discussed those changes with upstream, defined a set of
>> enumerated values, and standardised the other spec files right?
>
> This is plain UTF-8 text that passes the current guidelines, that
> passes rpmlint, and without non-standard magic post-processing markup
> application side. It works in vi, emacs, eclipse, gedit, etc the same
> way.

And it seems to work in all the MUAs we've used too.

OTOH your stuff will only work in PK, and in the course of trying to
workaround badly encoded text you'll break correctly encoded text (and
probably mess up the display thoroughly for some locales).

I guess I'll just have to add packagekit to the list of apps with
broken unicode support we track in the Fonts SIG. You call that ego I
call that regression.

-- 
Nicolas Mailhot



From tim at niemueller.de  Wed Dec 17 12:16:32 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Wed, 17 Dec 2008 13:16:32 +0100
Subject: Build problem with kernel header
In-Reply-To: <4948D6EF.9060202@ioa.s.u-tokyo.ac.jp>
References: <4948D2C0.4020508@niemueller.de>
	<4948D6EF.9060202@ioa.s.u-tokyo.ac.jp>
Message-ID: <4948EDA0.4010500@niemueller.de>

Mamoru Tasaka schrieb:
> 
> I already reported this issue several days ago:
> https://bugzilla.redhat.com/show_bug.cgi?id=476327
> 
> Also by other people:
> http://lkml.org/lkml/2008/12/2/75

Thanks for the info. I'm watching the bug now and will use the patches
provided by Caolan (thanks!) as a workaround for now.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From mefoster at gmail.com  Wed Dec 17 12:17:06 2008
From: mefoster at gmail.com (Mary Ellen Foster)
Date: Wed, 17 Dec 2008 13:17:06 +0100
Subject: Review Swaps
In-Reply-To: <200812170341.19903.konrad@tylerc.org>
References: <200812170341.19903.konrad@tylerc.org>
Message-ID: <f58861e00812170417s704c61c3jb0e41e04c9c29580@mail.gmail.com>

On Wed, Dec 17, 2008 at 12:41 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> Hey, I'm looking to swap reviews for:
>
> jcodings - https://bugzilla.redhat.com/show_bug.cgi?id=473537
> (Warning, jcodings is java.)

Cool, I've got a lot of Java libraries pending -- if you could take a
look at any of the "leaf nodes" from
http://mef.fedorapeople.org/packages/jabref-dependencies.html (ignore
onemind-commons* stuff, I'm re-evaluating that), that would be great.
:)

I'll take a look at jcodings shortly,

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 konrad at tylerc.org  Wed Dec 17 12:24:29 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 17 Dec 2008 04:24:29 -0800
Subject: Review Swaps
In-Reply-To: <f58861e00812170417s704c61c3jb0e41e04c9c29580@mail.gmail.com>
References: <200812170341.19903.konrad@tylerc.org>
	<f58861e00812170417s704c61c3jb0e41e04c9c29580@mail.gmail.com>
Message-ID: <200812170424.29963.konrad@tylerc.org>

On Wednesday 17 December 2008 04:17:06 am Mary Ellen Foster wrote:
> On Wed, Dec 17, 2008 at 12:41 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> > Hey, I'm looking to swap reviews for:
> >
> > jcodings - https://bugzilla.redhat.com/show_bug.cgi?id=473537
> > (Warning, jcodings is java.)
>
> Cool, I've got a lot of Java libraries pending -- if you could take a
> look at any of the "leaf nodes" from
> http://mef.fedorapeople.org/packages/jabref-dependencies.html (ignore
> onemind-commons* stuff, I'm re-evaluating that), that would be great.
>
> :)
>
> I'll take a look at jcodings shortly,
>
> MEF

Thanks!

-- 
Conrad Meyer <konrad at tylerc.org>




From nikolay at vladimiroff.com  Wed Dec 17 12:30:25 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Wed, 17 Dec 2008 14:30:25 +0200
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <b2bf6bce454fd8e95a4b3591e182615f.squirrel@arekh.dyndns.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<f29e4132384237edd07b2786b861567d.squirrel@arekh.dyndns.org>
	<1229512758.1951.22.camel@hughsie-work.lan>
	<a154c2107e108c2f5644d397a84009c7.squirrel@arekh.dyndns.org>
	<b2bf6bce454fd8e95a4b3591e182615f.squirrel@arekh.dyndns.org>
Message-ID: <a2e85ed0812170430k7e486bd6x570fe2f8e982dccb@mail.gmail.com>

2008/12/17 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>
>
> Le Mer 17 d?cembre 2008 12:56, Nicolas Mailhot a ?crit :
>>
>>
>>
>> Le Mer 17 d?cembre 2008 12:19, Richard Hughes a ?crit :
>>
>>> * Fri Feb 08 2008  Nicolas Mailhot <nicolas.mailhot at laposte.net>
>>> - 1:1.09-3
>>> ? gcc 4.3 rebuild
>>>
>>> So, you've discussed those changes with upstream, defined a set of
>>> enumerated values, and standardised the other spec files right?
>>
>> This is plain UTF-8 text that passes the current guidelines, that
>> passes rpmlint, and without non-standard magic post-processing markup
>> application side. It works in vi, emacs, eclipse, gedit, etc the same
>> way.
>
> And it seems to work in all the MUAs we've used too.
>
> OTOH your stuff will only work in PK, and in the course of trying to
> workaround badly encoded text you'll break correctly encoded text (and
> probably mess up the display thoroughly for some locales).
>
> I guess I'll just have to add packagekit to the list of apps with
> broken unicode support we track in the Fonts SIG. You call that ego I
> call that regression.
>
> --
> Nicolas Mailhot
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Should we bring this to FESCO ?
Since as I understand you're saying the current solution is a
regression and the only good solution is AllRPMdistros wide.

-- 
NV



From limb at jcomserv.net  Wed Dec 17 13:29:46 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 17 Dec 2008 07:29:46 -0600 (CST)
Subject: leaving fedora
In-Reply-To: <4947B61A.5020904@hhs.nl>
References: <20081216100007.GB3877@free.fr> <4947B61A.5020904@hhs.nl>
Message-ID: <357dbae53c5f3ccbc95e21febb43eff0.squirrel@mail.jcomserv.net>


> Patrice Dumas wrote:
>> Hello,
>>
>> I am leaving fedora (though not EPEL)
>
> Thanks for all the good work you've done the past years, it was always a
> pleasure to work with you, so thank you and good bye.
>
> Below I'll respond to one point of your farewell mail, this is in no way
> meant
> to convince you to come back, the purpose of my remarks is to discuss
> possibilities for those who remain behind to hopefully do better at your
> use
> cases :)
>
>> My use case is old non desktop stuff, fluxbox, xdm, vim, xterms,
>> mutt, irssi, firefox, latex/texinfo, xfig, xpdf, numerical models,
>> openoffice (because I have to). Fedora is unsuitable for me as a user
>> since quite a long time, too much regressions, lack of interest for
>> integrating what I use (xdm, no vfs daemon...)
>
> As someone who is now a day maintaining xfig and ImageMagick (not listed
> but
> sort of fits in the list), let me chime in here. I think the biggest issue
> with
> quite a lot of these, is that they are maintained by @redhat.com people
> (yes
> I'm @redhat.com now too). The problem is that most of these packages as
> part of
> former Fedora Core, got these maintainers because someone had to do it,
> not
> because they care a whole lot about the package. Those maintainers have
> more
> packages to maintain / other work to do and given that these packages do
> not
> have a lot of users, any issues with them will get low priority if any at
> all.
>
> So what can we do to make this better? Simple become a co-maintainer and
> fix
> any issues yourself. That is how I did things with xfig and ImageMagick
> when I
> got fed up with ping-ing in bugzilla (officially I'm still a co-maintainer
> of
> both, but in practice I seem to be the maintainer).
>
> So I hereby call on everyone who care about these older tools: if it
> itches
> scratch. I know that many of you have probably submitted bugs with
> patches.
> That is not going to work when a package maintainer is overworked. The
> solution
> in my experience is to become a co-maintainer and do any fixes yourself.
>
> ###
>
> Talking about Patrice leaving and packages of older software, this leaves
> (amongst others) lesstif orphaned. As I've co-maintained it for a while
> and I
> believe that offering the possibility to run old (FREE) motif apps is
> important, I will pick it up (call me crazy). But I could really use some
> help
> here, upstream lesstif is dead and it could really use some loving. So any
> volunteers?

You're crazy. :) I've applied to co-maintain, I need liesstif for ddd.

> Regards,
>
> Hans
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From limb at jcomserv.net  Wed Dec 17 13:41:56 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 17 Dec 2008 07:41:56 -0600 (CST)
Subject: leaving fedora
In-Reply-To: <20081216100007.GB3877@free.fr>
References: <20081216100007.GB3877@free.fr>
Message-ID: <554687b3df4b61a7c0d700dcd5b106af.squirrel@mail.jcomserv.net>


> Hello,
>
> I am leaving fedora (though not EPEL), and since I have been quite
> vocal in the last months, I thought it would deserve some explanation.
> All that follows is highly subjective, and I don't think it
> should lead to much discussion, and since it is very subjective, I
> won't give names or facts to prove what I say, these are my feelings.
>
> My use case is old non desktop stuff, fluxbox, xdm, vim, xterms,
> mutt, irssi, firefox, latex/texinfo, xfig, xpdf, numerical models,
> openoffice (because I have to). Fedora is unsuitable for me as a user
> since quite a long time, too much regressions, lack of interest for
> integrating what I use (xdm, no vfs daemon...) too short lived.
> But I still used it as a contributor, one of the aim being to help
> testing regressions and integrating oldish environment such that
> people in my case don't have to go through the workarounds I had to
> use in rawhide to have their setup working, while still benefiting
> from progress in free software (new hardware support, new
> frameworks...), in fedora and in RHEL+EPEL.
>
> The cost of running rawhide (or a rawhide/stable mix), has always
> been high, but it was ok, as the price for testing and being in
> touch with latest innovations. However I have clearly seen now,
> that the benefits are negligible. Many other maintainers, and
> especially many important people in fedora lead don't care about
> my use case and my bugs and patches get unanswered for months or
> years, the local fixes I have don't get propagated to other users,
> or maintainers refuse to support what I want. I don't blame the
> maintainers, supporting my use case has a cost, and even if I am
> ready to pay a part, it may still be too high for Fedora.
>
> I also feel that I have become a stranger to the fedora community.
> In the past it seems that power users like me, that is people who
> like the desktop for others but not for themselves, and like simple
> oldish UNIX stuff, were much more present, now it seems to me that
> only a tiny (but very vocal...) minority remains. One thing that
> really disturbed me was the latest FESCo election, I only voted
> for one candidate, who was not elected. People in current FESCo
> are nice and capable, indeed, but they don't represent me, and it
> was very different in the past.
>
> In the latest months, I remarked that most of the discussions
> I was involved in here turned to flamewars and in the end my
> wishes and solutions were always disregarded. Otherwise said I
> have become a noise maker, certainly impairing communication
> within the fedora project, and making everybody lose time for no
> gain.
>
> Lastly, I think that, on the packaging side, my wishes are
> fulfilled since there are now many alternate desktops (or window
> managers...) and all the display mananger I know about are
> in fedora, and correctly integrated at the packaging level.
> I also have all the command-line interfaces I want. Integration
> didn't happen though, and I now think that fedora isn't the place
> where it can happen.
>
> I really enjoyed all this time in the Fedora project, and I learned
> a lot, too. Last, I wish Fedora to be succesful, I think that Fedora
> is very useful for the advance of free software, and I thank the
> Fedora users and contributors, and RedHat support.

I'm very sorry to hear that, but I understand your reasons.  You've been a
great help and source of information. Thank you for your contribution.

Jon

> --
> Pat
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From limb at jcomserv.net  Wed Dec 17 13:53:27 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 17 Dec 2008 07:53:27 -0600 (CST)
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <6127d4ff49e510ce9d9f6ae31ed404c4.squirrel@mail.jcomserv.net>


> Hello,
>
> I am orphaning all my packages. I orphan the devel branch, but I'd
> prefer
> also orphan the stable branches too, so if you are interested don't
> hesitate to ask. I am still willing to maintain the EPEL branches, but
> here, also, if you want to take over, say so.
>
> I am nco, ncview, glib 1 and gtk+ 1 de-facto main packager, so
> somebody else should take care of those packages.
>
> I think that lesstif, perl-File-MimeInfo and fcron are strategic for
> fedora.
>
>
> Low maintainance but very complicated packages:
> The cernlib packages are quite complicated and unusual, this is fortran,
> uses imake :-/ and upstream is moribund since 2003, and dead since 2006.
> Debian was like a substitution upstream, but the debian maintainer has
> also abandonned cernlib. Still it is known that there are users for this
> package.
> * cernlib
> * cernlib-g77

I'll take these.

> Normal packages:
> * lesstif
> * libdap
> * libnc-dap
>
> Very low maintainance packages:
> * asa
> * bibexport
> * BibTool
> * bitmap
> * libsx
> * libdockapp
> * ooo2txt
> * perl-Parse-Yapp
> * perl-Text-Unidecode
> * tetex-elsevier
> * uread
> * wmix
> * xbae
> * xdialog
>
> Low maintainance packages:
> * acpitool
> * boolstuff
> * cppunit
> * esmtp
> * fcron
> * halevt
> * grads
> there is an update available for grads, but it has some functionalities
> removed, and also upstream is complicated, with a friendly fork at
> opengrads and last libgadap can be packaged now. I'll still be working
> with upstream, so I could help with chosing which version to package and
> things like that.
> * perl-Algorithm-CurveFit
> * perl-File-BaseDir
> * perl-File-DesktopEntry
> * perl-File-MimeInfo
> * perl-Math-MatrixReal
> * perl-Math-Symbolic
>
> Recently added packages:
> * g2clib
> * grib_api
> * w3lib
>
> --
> Pat
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From limb at jcomserv.net  Wed Dec 17 13:54:14 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 17 Dec 2008 07:54:14 -0600 (CST)
Subject: orphaning all my packages
In-Reply-To: <6127d4ff49e510ce9d9f6ae31ed404c4.squirrel@mail.jcomserv.net>
References: <20081216094739.GA3877@free.fr>
	<6127d4ff49e510ce9d9f6ae31ed404c4.squirrel@mail.jcomserv.net>
Message-ID: <6281b553c0ecd1705d2707b7742bbaef.squirrel@mail.jcomserv.net>


>
>> Hello,
>>
>> I am orphaning all my packages. I orphan the devel branch, but I'd
>> prefer
>> also orphan the stable branches too, so if you are interested don't
>> hesitate to ask. I am still willing to maintain the EPEL branches, but
>> here, also, if you want to take over, say so.
>>
>> I am nco, ncview, glib 1 and gtk+ 1 de-facto main packager, so
>> somebody else should take care of those packages.
>>
>> I think that lesstif, perl-File-MimeInfo and fcron are strategic for
>> fedora.
>>
>>
>> Low maintainance but very complicated packages:
>> The cernlib packages are quite complicated and unusual, this is fortran,
>> uses imake :-/ and upstream is moribund since 2003, and dead since 2006.
>> Debian was like a substitution upstream, but the debian maintainer has
>> also abandonned cernlib. Still it is known that there are users for this
>> package.
>> * cernlib
>> * cernlib-g77
>
> I'll take these.

All branches. Sorry.

>> Normal packages:
>> * lesstif
>> * libdap
>> * libnc-dap
>>
>> Very low maintainance packages:
>> * asa
>> * bibexport
>> * BibTool
>> * bitmap
>> * libsx
>> * libdockapp
>> * ooo2txt
>> * perl-Parse-Yapp
>> * perl-Text-Unidecode
>> * tetex-elsevier
>> * uread
>> * wmix
>> * xbae
>> * xdialog
>>
>> Low maintainance packages:
>> * acpitool
>> * boolstuff
>> * cppunit
>> * esmtp
>> * fcron
>> * halevt
>> * grads
>> there is an update available for grads, but it has some functionalities
>> removed, and also upstream is complicated, with a friendly fork at
>> opengrads and last libgadap can be packaged now. I'll still be working
>> with upstream, so I could help with chosing which version to package and
>> things like that.
>> * perl-Algorithm-CurveFit
>> * perl-File-BaseDir
>> * perl-File-DesktopEntry
>> * perl-File-MimeInfo
>> * perl-Math-MatrixReal
>> * perl-Math-Symbolic
>>
>> Recently added packages:
>> * g2clib
>> * grib_api
>> * w3lib
>>
>> --
>> Pat
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
>
> --
> in your fear, speak only peace
> in your fear, seek only love
>
> -d. bowie
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From bbbush.yuan at gmail.com  Wed Dec 17 13:55:36 2008
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Wed, 17 Dec 2008 21:55:36 +0800
Subject: leaving fedora
In-Reply-To: <20081216100007.GB3877@free.fr>
References: <20081216100007.GB3877@free.fr>
Message-ID: <76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>

2008/12/16 Patrice Dumas <pertusus at free.fr>:
> Hello,
>
> I am leaving fedora (though not EPEL), and since I have been quite
> vocal in the last months, I thought it would deserve some explanation.
> All that follows is highly subjective, and I don't think it
> should lead to much discussion, and since it is very subjective, I
> won't give names or facts to prove what I say, these are my feelings.
>

Just cannot believe in my eyes. Worst news.

My sponsor, please stay. :(


-- 
bbbush ^_^



From cra at WPI.EDU  Wed Dec 17 13:58:02 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 17 Dec 2008 08:58:02 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229494662.6392.42.camel@code.and.org>
References: <4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<1229467591.5054.131.camel@erebor.bos.redhat.com>
	<20081217030212.GB19430@srcf.ucam.org>
	<1229483507.6191.24.camel@localhost.localdomain>
	<20081217032112.GQ32016@angus.ind.WPI.EDU>
	<1229494662.6392.42.camel@code.and.org>
Message-ID: <20081217135802.GC1924@angus.ind.WPI.EDU>

On Wed, Dec 17, 2008 at 01:17:42AM -0500, James Antill wrote:
> On Tue, 2008-12-16 at 22:21 -0500, Chuck Anderson wrote:
> > On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
> > > On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
> > > > (Humour. This is a genuinely difficult problem and one that inovolves 
> > > > basically rearchitecting the current implementation)
> > > 
> > > HibernateKit ?
> > 
> > Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds.  I 
> > don't see much way around this.
> 
>  Why would you need to do that? I mean I can understand that it's
> probably "easy" to do it that way ... but how much harder is it to do:
> 
> 1. Write all the dirty pages to swap/disk.
> 
> 2. Drop all the clean droppable pages.
> 
> 3. write out what's left.

Oh, it probably does like you say.  Maybe it's only 2 gigs then.  It 
still takes on the order of 2 minutes to hibernate, and even longer 
than that for resume including swapping back in after the strict 
resume part is done.  Maybe hibernate-to-flash would be fast enough to 
make it worthwhile.

The main reason I hibernate is to save the state of what I was working 
on before.  Rebooting could be a solution to this if:

- Rebooting is fast enough.  This is what this thread is about.

- Applications were written to save state as a matter of normal 
operation.  Firefox is pretty good at this these days.  See also 
"Crash-Only Software" [1].

- gnome-session didn't break session saving support, or Fedora didn't 
consume the broken GNOME release with 
known-to-be-broken-session-support [2], and 
we-wont-fix-this-until-the-resdesign-of-session-support-is-done 
[3][4].


[1] http://en.wikipedia.org/wiki/Crash-only_software
[2] http://bugzilla.gnome.org/show_bug.cgi?id=552387
[3] http://live.gnome.org/SessionManagement/NewGnomeSession
[4] http://blogs.gnome.org/metacity/2008/03/08/session-management/



From lesmikesell at gmail.com  Wed Dec 17 14:00:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 08:00:02 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4948B09E.5080400@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>
	<4948B09E.5080400@behdad.org>
Message-ID: <494905E2.9030303@gmail.com>

Behdad Esfahbod wrote:
> Les Mikesell wrote:
>> Behdad Esfahbod wrote:
>>>> Matej Cepl wrote:
>>>> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>>>>> Nothing to say you can't re-enable it yourself. I don't have a
>>>>> permanent connection to the net but evolution happily holds it in my
>>>>> outbox until I go back online and can connect to a network. Fedora can
>>>> I have a nasty surprise for you -- Fedora is not Windows, so it
>>>> would is not only for people who use Evolution / Kmail
>>>> / Thunderbird.
>>> See above.  On a similar line of though, how about: "please install
>>> and enable
>>> httpd, postgresql, and squid" by default because I use them...
>> Yes, how about it?  What's the point of booting quickly - or at all, if
>> the machine won't provide any services?
> 
> Why would I install the desktop spin if I need those?  Fedora has been taking
> the lets-start-any-services-that-someone-may-need approach so far.  It doesn't
> work.  Spins are a neat way to customize the default install for different
> sectors.  The desktop spin should not install an MTA in my opinion.  That's
> all I'm saying.

Even desktop users deserve an environment that follows standards. Has 
everyone forgotten October's long discussion on this very subject?
http://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=298345&topic_id=62876
Note particularly reply #96 stating mail delivery is required by both 
posix and the LSB.

I don't understand why people who want non-standard configurations can't 
  stop the service startups themselves - and then they'll know why 
normal programs that expect a standard environment don't work.  Also, 
this doesn't really have anything to do with boot time.  The daemon 
startup can be deferred or put in the background so as not to delay bootup.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From limb at jcomserv.net  Wed Dec 17 14:05:55 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 17 Dec 2008 08:05:55 -0600 (CST)
Subject: leaving fedora
In-Reply-To: <76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>
References: <20081216100007.GB3877@free.fr>
	<76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>
Message-ID: <e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>


> 2008/12/16 Patrice Dumas <pertusus at free.fr>:
>> Hello,
>>
>> I am leaving fedora (though not EPEL), and since I have been quite
>> vocal in the last months, I thought it would deserve some explanation.
>> All that follows is highly subjective, and I don't think it
>> should lead to much discussion, and since it is very subjective, I
>> won't give names or facts to prove what I say, these are my feelings.
>>
>
> Just cannot believe in my eyes. Worst news.
>
> My sponsor, please stay. :(

Do we need to work out a sponsorship transfer?  Not sure what the policy
is for this sort of thing.

>
> --
> bbbush ^_^
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From paul at city-fan.org  Wed Dec 17 14:10:14 2008
From: paul at city-fan.org (Paul Howarth)
Date: Wed, 17 Dec 2008 14:10:14 +0000
Subject: leaving fedora
In-Reply-To: <e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
References: <20081216100007.GB3877@free.fr>	<76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>
	<e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
Message-ID: <49490846.7000706@city-fan.org>

Jon Ciesla wrote:
>> 2008/12/16 Patrice Dumas <pertusus at free.fr>:
>>> Hello,
>>>
>>> I am leaving fedora (though not EPEL), and since I have been quite
>>> vocal in the last months, I thought it would deserve some explanation.
>>> All that follows is highly subjective, and I don't think it
>>> should lead to much discussion, and since it is very subjective, I
>>> won't give names or facts to prove what I say, these are my feelings.
>>>
>> Just cannot believe in my eyes. Worst news.
>>
>> My sponsor, please stay. :(
> 
> Do we need to work out a sponsorship transfer?  Not sure what the policy
> is for this sort of thing.

I think there are a lot of people in this position, e.g. many people 
(myself included) lost their sponsor when Elliot Lee left.

Paul.



From fedora at leemhuis.info  Wed Dec 17 14:28:32 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 17 Dec 2008 15:28:32 +0100
Subject: leaving fedora
In-Reply-To: <49490846.7000706@city-fan.org>
References: <20081216100007.GB3877@free.fr>	<76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>	<e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
	<49490846.7000706@city-fan.org>
Message-ID: <49490C90.6000605@leemhuis.info>

On 17.12.2008 15:10, Paul Howarth wrote:
> Jon Ciesla wrote:
>>> 2008/12/16 Patrice Dumas <pertusus at free.fr>:
>>>> Hello,
>>>>
>>>> I am leaving fedora (though not EPEL), and since I have been quite
>>>> vocal in the last months, I thought it would deserve some explanation.
>>>> All that follows is highly subjective, and I don't think it
>>>> should lead to much discussion, and since it is very subjective, I
>>>> won't give names or facts to prove what I say, these are my feelings.
>>> Just cannot believe in my eyes. Worst news.
>>> My sponsor, please stay. :(
>> Do we need to work out a sponsorship transfer?  Not sure what the policy
>> is for this sort of thing.
> I think there are a lot of people in this position, e.g. many people 
> (myself included) lost their sponsor when Elliot Lee left.

The real question is: How long do you have to keep any eye on somebody 
you sponsored? That should get answered before  the question "Who takes 
over the sponsor burden if the sponsor doesn't do it properly or leaves" 
gets discussed.

The answer to the first question afaics depends on the person that is 
being sponsored. I for example stopped watching cwickert after just a 
few weeks or months, as I got the impression that he found its way into 
the project properly and can work on his own (he was made sponsor a few 
months later). But other people that are less involved/active I'd say it 
important to watch them for longer time-frames. But it's IMHO definitely 
shouldn't be a life-time job IMHO ;-)

Cu
knurd



From limb at jcomserv.net  Wed Dec 17 14:30:04 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 17 Dec 2008 08:30:04 -0600 (CST)
Subject: leaving fedora
In-Reply-To: <49490846.7000706@city-fan.org>
References: <20081216100007.GB3877@free.fr>
	<76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>
	<e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
	<49490846.7000706@city-fan.org>
Message-ID: <5e728779dcaf452758b7e8ec1c9e6041.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>>> 2008/12/16 Patrice Dumas <pertusus at free.fr>:
>>>> Hello,
>>>>
>>>> I am leaving fedora (though not EPEL), and since I have been quite
>>>> vocal in the last months, I thought it would deserve some explanation.
>>>> All that follows is highly subjective, and I don't think it
>>>> should lead to much discussion, and since it is very subjective, I
>>>> won't give names or facts to prove what I say, these are my feelings.
>>>>
>>> Just cannot believe in my eyes. Worst news.
>>>
>>> My sponsor, please stay. :(
>>
>> Do we need to work out a sponsorship transfer?  Not sure what the policy
>> is for this sort of thing.
>
> I think there are a lot of people in this position, e.g. many people
> (myself included) lost their sponsor when Elliot Lee left.

Maybe we need a "Sponsor the Orphans" Drive.

> Paul.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From limb at jcomserv.net  Wed Dec 17 14:32:08 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 17 Dec 2008 08:32:08 -0600 (CST)
Subject: leaving fedora
In-Reply-To: <49490C90.6000605@leemhuis.info>
References: <20081216100007.GB3877@free.fr>
	<76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>
	<e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
	<49490846.7000706@city-fan.org> <49490C90.6000605@leemhuis.info>
Message-ID: <f6575c8891bffa84bf42c9c32941de89.squirrel@mail.jcomserv.net>


> On 17.12.2008 15:10, Paul Howarth wrote:
>> Jon Ciesla wrote:
>>>> 2008/12/16 Patrice Dumas <pertusus at free.fr>:
>>>>> Hello,
>>>>>
>>>>> I am leaving fedora (though not EPEL), and since I have been quite
>>>>> vocal in the last months, I thought it would deserve some
>>>>> explanation.
>>>>> All that follows is highly subjective, and I don't think it
>>>>> should lead to much discussion, and since it is very subjective, I
>>>>> won't give names or facts to prove what I say, these are my feelings.
>>>> Just cannot believe in my eyes. Worst news.
>>>> My sponsor, please stay. :(
>>> Do we need to work out a sponsorship transfer?  Not sure what the
>>> policy
>>> is for this sort of thing.
>> I think there are a lot of people in this position, e.g. many people
>> (myself included) lost their sponsor when Elliot Lee left.
>
> The real question is: How long do you have to keep any eye on somebody
> you sponsored? That should get answered before  the question "Who takes
> over the sponsor burden if the sponsor doesn't do it properly or leaves"
> gets discussed.
>
> The answer to the first question afaics depends on the person that is
> being sponsored. I for example stopped watching cwickert after just a
> few weeks or months, as I got the impression that he found its way into
> the project properly and can work on his own (he was made sponsor a few
> months later). But other people that are less involved/active I'd say it
> important to watch them for longer time-frames. But it's IMHO definitely
> shouldn't be a life-time job IMHO ;-)

Exactly, it's important to watch people early on, but once you get past an
initial period and have a person's cluefulness demonstrated, there's
really no need.

Maybe some of the Orphans would be good sponsor material.  Some might not,
and should have a new sponsor.  FESCO fodder?

> Cu
> knurd
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From sgrubb at redhat.com  Wed Dec 17 14:54:08 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 17 Dec 2008 09:54:08 -0500
Subject: Whatever happened to make force-tag?
Message-ID: <200812170954.09054.sgrubb@redhat.com>

Hi,

I remember that there were lots of discussion about this in September. We have 
the ability to do "force-tag" in cvs directly, why have we not taken the next 
step and re-enabled the make target?

Thanks,
-Steve



From dan at danny.cz  Wed Dec 17 15:25:04 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 17 Dec 2008 16:25:04 +0100
Subject: Whatever happened to make force-tag?
In-Reply-To: <200812170954.09054.sgrubb@redhat.com>
References: <200812170954.09054.sgrubb@redhat.com>
Message-ID: <1229527504.4052.17.camel@eagle.danny.cz>

Steve Grubb p??e v St 17. 12. 2008 v 09:54 -0500:
> Hi,
> 
> I remember that there were lots of discussion about this in September. We have 
> the ability to do "force-tag" in cvs directly, why have we not taken the next 
> step and re-enabled the make target?

The official way is now "TAG_OPTS=-f make tag", but you can have "make
force-tag" too - see
http://www.redhat.com/archives/rhl-devel-list/2008-September/msg01689.html


		Dan




From opensource at till.name  Wed Dec 17 15:27:36 2008
From: opensource at till.name (Till Maas)
Date: Wed, 17 Dec 2008 16:27:36 +0100
Subject: Whatever happened to make force-tag?
In-Reply-To: <200812170954.09054.sgrubb@redhat.com>
References: <200812170954.09054.sgrubb@redhat.com>
Message-ID: <200812171627.47630.opensource@till.name>

On Wed December 17 2008, Steve Grubb wrote:

> I remember that there were lots of discussion about this in September. We
> have the ability to do "force-tag" in cvs directly, why have we not taken
> the next step and re-enabled the make target?

It is now an opt-in feature, you have to add this to your ~/.cvspkgsrc file 
(the first character in the second line is a tab) to re-enable it:

force-tag: $(SPECFILE) $(COMMON_DIR)/branches
	@$(MAKE) tag TAG_OPTS="-F $(TAG_OPTS)"

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/80ae28c9/attachment.sig>

From lfarkas at lfarkas.org  Wed Dec 17 15:29:49 2008
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Wed, 17 Dec 2008 16:29:49 +0100
Subject: Whatever happened to make force-tag?
In-Reply-To: <1229527504.4052.17.camel@eagle.danny.cz>
References: <200812170954.09054.sgrubb@redhat.com>
	<1229527504.4052.17.camel@eagle.danny.cz>
Message-ID: <49491AED.3070709@lfarkas.org>

Dan Hor?k wrote:
> Steve Grubb p??e v St 17. 12. 2008 v 09:54 -0500:
>> Hi,
>>
>> I remember that there were lots of discussion about this in September. We have 
>> the ability to do "force-tag" in cvs directly, why have we not taken the next 
>> step and re-enabled the make target?
> 
> The official way is now "TAG_OPTS=-f make tag", but you can have "make
> force-tag" too - see
> http://www.redhat.com/archives/rhl-devel-list/2008-September/msg01689.html

it'd be useful to document it somehow...

-- 
  Levente                               "Si vis pacem para bellum!"



From martin.sourada at gmail.com  Wed Dec 17 15:40:14 2008
From: martin.sourada at gmail.com (Martin Sourada)
Date: Wed, 17 Dec 2008 16:40:14 +0100
Subject: Usage of %{__macros} in our .specs?
Message-ID: <1229528414.28296.35.camel@pc-notebook>

Hi all,

I've been told, by an upstream developer of one of the packages I
maintain, that I/we should use e.g. %{__make} instead of make in
our .spec files in order to have our packages more compatible/portable.

As I understand it, if I use make, whatever make is find in the $PATH of
the user the package is build under, it will be used, however if I use
%{__make} /usr/bin/make (as per 'rpmbuild --showrc" output) will be used
regardless of what environment path I've set. It's similar for other
macros like %{__rm}, %{__sed}, %{__mv} or %{__cp}, %{__ln_s} or
%{__mkdir_p} to name a few. 

I haven't found any guideline regarding this and our packages seem to
wary in the way they use it. Should there be any guideline or
recommendation created for it? What do others think about it? 

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/d930317c/attachment.sig>

From opensource at till.name  Wed Dec 17 15:51:44 2008
From: opensource at till.name (Till Maas)
Date: Wed, 17 Dec 2008 16:51:44 +0100
Subject: Usage of %{__macros} in our .specs?
In-Reply-To: <1229528414.28296.35.camel@pc-notebook>
References: <1229528414.28296.35.camel@pc-notebook>
Message-ID: <200812171652.01375.opensource@till.name>

On Wed December 17 2008, Martin Sourada wrote:

> I've been told, by an upstream developer of one of the packages I
> maintain, that I/we should use e.g. %{__make} instead of make in
> our .spec files in order to have our packages more compatible/portable.

Can you please exlain in more detail, why this is more compatible/portable? 
Everyone can just adjust the PATH variable if some other make command is 
desired. But why should it be?

> I haven't found any guideline regarding this and our packages seem to
> wary in the way they use it. Should there be any guideline or
> recommendation created for it? What do others think about it?

I do not want my fingers to fall of when I write spec files, therefore I am 
against using these macros, but everyone is free to use them afaik.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/93809737/attachment.sig>

From lesmikesell at gmail.com  Wed Dec 17 15:52:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 09:52:23 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217135802.GC1924@angus.ind.WPI.EDU>
References: <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<4948220D.9070202@behdad.org>	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>	<1229467591.5054.131.camel@erebor.bos.redhat.com>	<20081217030212.GB19430@srcf.ucam.org>	<1229483507.6191.24.camel@localhost.localdomain>	<20081217032112.GQ32016@angus.ind.WPI.EDU>	<1229494662.6392.42.camel@code.and.org>
	<20081217135802.GC1924@angus.ind.WPI.EDU>
Message-ID: <49492037.1040401@gmail.com>

Chuck Anderson wrote:
> 
> The main reason I hibernate is to save the state of what I was working 
> on before.  Rebooting could be a solution to this if:
> 
> - Rebooting is fast enough.  This is what this thread is about.
> 
> - Applications were written to save state as a matter of normal 
> operation.  Firefox is pretty good at this these days.  See also 
> "Crash-Only Software" [1].

It's fairly easy to save state in a program that only uses a stateless 
protocol...

---
   Les Mikesell
    lesmikesell at gmail.com



From chris.stone at gmail.com  Wed Dec 17 16:08:28 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Wed, 17 Dec 2008 08:08:28 -0800
Subject: Usage of %{__macros} in our .specs?
In-Reply-To: <1229528414.28296.35.camel@pc-notebook>
References: <1229528414.28296.35.camel@pc-notebook>
Message-ID: <d9c612bf0812170808y3d20855fv61605968f131ccc4@mail.gmail.com>

2008/12/17 Martin Sourada <martin.sourada at gmail.com>:
> As I understand it, if I use make, whatever make is find in the $PATH of
> the user the package is build under, it will be used, however if I use
> %{__make} /usr/bin/make (as per 'rpmbuild --showrc" output) will be used
> regardless of what environment path I've set. It's similar for other
> macros like %{__rm}, %{__sed}, %{__mv} or %{__cp}, %{__ln_s} or
> %{__mkdir_p} to name a few.

It is my understanding that the macros are intended for use in
%pre(un)/%post(un) sections only, but please don't ask me to explain
why.



From jamundso at gmail.com  Wed Dec 17 16:10:11 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Wed, 17 Dec 2008 10:10:11 -0600
Subject: To pre, or not to pre...
In-Reply-To: <1229485105.3028.9.camel@zebes.localdomain>
References: <200812161726.15508.jamundso@gmail.com>
	<1229484821.3028.6.camel@zebes.localdomain>
	<1229485105.3028.9.camel@zebes.localdomain>
Message-ID: <6d06ce20812170810r5bc7c9b1ta062ab57eea5144c@mail.gmail.com>

On Tue, Dec 16, 2008 at 9:38 PM, Will Woods <wwoods at redhat.com> wrote:
> On Tue, 2008-12-16 at 22:33 -0500, Will Woods wrote:
>> On Tue, 2008-12-16 at 17:26 -0600, Jerry Amundson wrote:
>> > I'm normally 'yum live upgrade' type, but trying preupgrade now.
>> >
>> > 556/742 - preupgrade/packages/openoffice.org-calc-core-3.0.1-13.2.fc11.x86_64.rp
>> > 605/742 - preupgrade/packages/libXdamage-1.1.1-5.fc11.i386.rpmTraceback (most
>> > recent call last):
>> >   File "/usr/share/preupgrade/preupgrade-cli.py", line 284, in <module>
>> >     pu.main(myrelease)
>> >   File "/usr/share/preupgrade/preupgrade-cli.py", line 249, in main
>> >     self.generate_repodata(cachedir, comps) # TODO: callback?
>> >   File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 711, in
>> > generate_repodata
>> >     generate_repodata(dir, comps, callback)
>> >   File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 727, in
>> > generate_repodata_f9
>> >     mdgen.doPkgMetadata()
>> >   File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 332, in
>> > doPkgMetadata
>> >     self.writeMetadataDocs(packages)
>> >   File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 475, in
>> > writeMetadataDocs
>> >     clog_limit=self.conf.changelog_limit))
>> >   File "/usr/lib/python2.5/site-packages/yum/packages.py", line 959, in
>> > xml_dump_other_metadata
>> >     msg += "%s\n</package>\n" %
>> > misc.to_unicode(self._dump_changelog(clog_limit))
>> >   File "/usr/lib/python2.5/site-packages/yum/packages.py", line 936, in
>> > _dump_changelog
>> >     misc.to_xml(author, attrib=True), misc.to_xml(str(ts)),
>> >   File "/usr/lib/python2.5/site-packages/yum/misc.py", line 749, in to_xml
>> >     item = _ugly_utf8_string_hack(item)
>> >   File "/usr/lib/python2.5/site-packages/yum/misc.py", line 728, in
>> > _ugly_utf8_string_hack
>> >     print '\n%s encoding on %s\n' % (enc, item)
>> >   File "/usr/lib64/python2.5/codecs.py", line 303, in write
>> >     data, consumed = self.encode(object, self.errors)
>> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xf8 in position 34:
>> > ordinal not in range(128)
>>
>> You're trying to upgrade to Rawhide, I take it? It looks like createrepo
>> is choking on something in the changelog of the rawhide libXdamage.
>
> Er, to clarify, file a bug *against preupgrade*. I'm pretty sure
> createrepo handles this normally outside of preupgrade so I'm probably
> setting something up wrong.
>
> The most recent changelog entry in libXdamage is:
>
> * Wed Dec 03 2008 Caol?n McNamara <caolanm at redhat.com> - 1.1.1-5
> - rebuild to get provides pkgconfig(xdamage)
>
> Guess we're not handling that UTF-8 '?' properly.

Bug 476862

jerry

-- 
To be named later.



From jos at xos.nl  Wed Dec 17 16:15:03 2008
From: jos at xos.nl (Jos Vos)
Date: Wed, 17 Dec 2008 17:15:03 +0100
Subject: Usage of %{__macros} in our .specs?
In-Reply-To: <200812171652.01375.opensource@till.name>
References: <1229528414.28296.35.camel@pc-notebook>
	<200812171652.01375.opensource@till.name>
Message-ID: <20081217161503.GA10808@jasmine.xos.nl>

On Wed, Dec 17, 2008 at 04:51:44PM +0100, Till Maas wrote:

> On Wed December 17 2008, Martin Sourada wrote:
> 
> > I've been told, by an upstream developer of one of the packages I
> > maintain, that I/we should use e.g. %{__make} instead of make in
> > our .spec files in order to have our packages more compatible/portable.
> 
> Can you please exlain in more detail, why this is more compatible/portable? 
> Everyone can just adjust the PATH variable if some other make command is 
> desired. But why should it be?

Well, I don't like those macros too, but they *are* useful for
cross-OS/distro portability and I understand what someone means when
saying this:

(a)  Having to set PATH etc. for an RPM build is not done, IMHO,
     and you can simply give examples where the PATH order gives
     for different tools results you might not want (e.g. you
     want make from /usr/local/bin and perl from /usr/bin, while
     there is a perl in /usr/local/bin that you do not want to use).

(b)  If you want to use, say, a local "make" (e.g. GNU make on a
     UNIX system has no GNU tools) and you have that installed in,
     say, /opt/gnu/make/bin/make (just a weird example, fill in
     yourself), then you are able to use a RPM build environment
     with %__make defines as /opt/gnu/make/bin/make.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From jos at xos.nl  Wed Dec 17 16:17:50 2008
From: jos at xos.nl (Jos Vos)
Date: Wed, 17 Dec 2008 17:17:50 +0100
Subject: Usage of %{__macros} in our .specs?
In-Reply-To: <d9c612bf0812170808y3d20855fv61605968f131ccc4@mail.gmail.com>
References: <1229528414.28296.35.camel@pc-notebook>
	<d9c612bf0812170808y3d20855fv61605968f131ccc4@mail.gmail.com>
Message-ID: <20081217161750.GB10808@jasmine.xos.nl>

On Wed, Dec 17, 2008 at 08:08:28AM -0800, Christopher Stone wrote:

> It is my understanding that the macros are intended for use in
> %pre(un)/%post(un) sections only, but please don't ask me to explain
> why.

I don't see what %__make can do in pre/post scripts ;-).

No, they are explicitly intended for the build environment.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From pertusus at free.fr  Wed Dec 17 16:20:00 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 17 Dec 2008 17:20:00 +0100
Subject: Usage of %{__macros} in our .specs?
In-Reply-To: <1229528414.28296.35.camel@pc-notebook>
References: <1229528414.28296.35.camel@pc-notebook>
Message-ID: <20081217162000.GB4659@free.fr>

On Wed, Dec 17, 2008 at 04:40:14PM +0100, Martin Sourada wrote:
> Hi all,
> 
> I haven't found any guideline regarding this and our packages seem to
> wary in the way they use it. Should there be any guideline or
> recommendation created for it? What do others think about it? 

The recommentdation is to use them consistently, that is either use
%{__make} and %{__cp}... or make and cp. Otherwise there is no
other guideline, it is left to the packager to use these or not.

--
Pat



From loganjerry at gmail.com  Wed Dec 17 16:31:40 2008
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 17 Dec 2008 09:31:40 -0700
Subject: Review Swaps
In-Reply-To: <f58861e00812170417s704c61c3jb0e41e04c9c29580@mail.gmail.com>
References: <200812170341.19903.konrad@tylerc.org>
	<f58861e00812170417s704c61c3jb0e41e04c9c29580@mail.gmail.com>
Message-ID: <870180fe0812170831t24610b3du2ad266c5181404f8@mail.gmail.com>

On Wed, Dec 17, 2008 at 5:17 AM, Mary Ellen Foster <mefoster at gmail.com> wrote:
> Cool, I've got a lot of Java libraries pending -- if you could take a
> look at any of the "leaf nodes" from
> http://mef.fedorapeople.org/packages/jabref-dependencies.html (ignore
> onemind-commons* stuff, I'm re-evaluating that), that would be great.
> :)
>
> I'll take a look at jcodings shortly,
>
> 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

Since you're helping me out with a review, I'll try to reciprocate.
Your web page talks about Fedora having antlr 2.7.7 but no antlr 3.X
version.  Actually, there is an antlr3 package, but I see that bug
470729 is still open.
-- 
Jerry James
http://loganjerry.googlepages.com/



From mschwendt at gmail.com  Wed Dec 17 16:38:05 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 17 Dec 2008 17:38:05 +0100
Subject: Usage of %{__macros} in our .specs?
In-Reply-To: <1229528414.28296.35.camel@pc-notebook>
References: <1229528414.28296.35.camel@pc-notebook>
Message-ID: <20081217173805.1a2a4af6.mschwendt@gmail.com>

On Wed, 17 Dec 2008 16:40:14 +0100, Martin wrote:

> Hi all,
> 
> I've been told, by an upstream developer of one of the packages I
> maintain, that I/we should use e.g. %{__make} instead of make in
> our .spec files in order to have our packages more compatible/portable.

That is common misbelief and macro-madness. Not only does it require every
RPM target platform to define all macros, you also need the same
customisability in the upstream tarballs. Every configure script, every
hand-written Makefile fragment, every helper shell-script needs to be
customisable so you could give it the value %__rm expands to instead of
just letting it use "rm" or search PATH.

> As I understand it, if I use make, whatever make is find in the $PATH of
> the user the package is build under, it will be used,

Sufficient.

> however if I use
> %{__make} /usr/bin/make (as per 'rpmbuild --showrc" output) will be used
> regardless of what environment path I've set. It's similar for other
> macros like %{__rm}, %{__sed}, %{__mv} or %{__cp}, %{__ln_s} or
> %{__mkdir_p} to name a few. 

Some don't use absolute paths, see e.g.
  rpm --eval %__awk
  rpm --eval %__cc
  rpm --eval %__cxx
  ...
  rpm --eval %__ln_s
  rpm --eval %__libtoolize
and others.

> I haven't found any guideline regarding this and our packages seem to
> wary in the way they use it. Should there be any guideline or
> recommendation created for it? What do others think about it? 

In ordinary spec sections, use what's in PATH.

Be careful inside the package scriptlets. Only with absolute paths, you
can construct proper dependencies for any executables you run in the
scriptlets. Without absolute paths, you can only require package names,
but executables may move to a different package. Add safety checks
to you package, e.g. in the %prep or %check sections.



From jkeating at redhat.com  Wed Dec 17 17:00:21 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 09:00:21 -0800
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229507380.1951.15.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg>  <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
Message-ID: <1229533221.6191.62.camel@localhost.localdomain>

On Wed, 2008-12-17 at 09:49 +0000, Richard Hughes wrote:
> The following things 'were' fixed:
> - Fix `dave'
> - Fubar update because of "security"
> --------------------------------------------
> 
> This will be converted by gnome-packagekit into:
> 
> ---------------------------------------------
> This is a spec file description or an update description in bohdi.
> 
> The following things ?were? fixed:
> ? Fix ?dave?
> ? Fubar update because of ?security?

I don't understand why you want to mess with it at all?  Why can't you
show exactly what's in bodhi, or exactly what's in the rpm headers?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/5b3babec/attachment.sig>

From Jochen at herr-schmitt.de  Wed Dec 17 17:03:09 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 17 Dec 2008 18:03:09 +0100
Subject: Futuer of grub/grub2 to F11
Message-ID: <494930CD.70709@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

nowaday I have read in the german fedora forum, that grub is not able
to handle
ext4 file systems. In opposite grub2 should be able to support ext4.

Because Fedora/Red Hat is a leader of development of the ext4 file
system, I want to
ask about the plan for ext4 on F11 or F12.

Because, I'm assume, that you don't want to patch grub for ext4, you
have to migrate
to grub2 if you want to support ext4 on /boot.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklJMMUACgkQT2AHK6txfgyXawCg9GbiELsSBanwe/7v08HCA4xZ
IQgAoLd4M4zwW3zD32t7CO6M6CXe/JZO
=dE20
-----END PGP SIGNATURE-----



From jspaleta at gmail.com  Wed Dec 17 17:07:56 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Dec 2008 08:07:56 -0900
Subject: leaving fedora
In-Reply-To: <f6575c8891bffa84bf42c9c32941de89.squirrel@mail.jcomserv.net>
References: <20081216100007.GB3877@free.fr>
	<76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>
	<e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
	<49490846.7000706@city-fan.org> <49490C90.6000605@leemhuis.info>
	<f6575c8891bffa84bf42c9c32941de89.squirrel@mail.jcomserv.net>
Message-ID: <604aa7910812170907s6892f693m87b65c9795e72929@mail.gmail.com>

On Wed, Dec 17, 2008 at 5:32 AM, Jon Ciesla <limb at jcomserv.net> wrote:
> Exactly, it's important to watch people early on, but once you get past an
> initial period and have a person's cluefulness demonstrated, there's
> really no need.
>

That's an assumption. Policies and best practises can drift over time,
and established maintainers may find themselves inadvertently breaking
policy or best practises after a couple of releases.  Since we don't
have any performance metrics to trend, we don't know.  Are all the
less than ideal update notices that Jesse has been communicating been
from relatively new contributors?

-jef



From pemboa at gmail.com  Wed Dec 17 17:08:47 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 17 Dec 2008 11:08:47 -0600
Subject: leaving fedora
In-Reply-To: <20081216100007.GB3877@free.fr>
References: <20081216100007.GB3877@free.fr>
Message-ID: <16de708d0812170908g574b2533u64dd2a82aa943624@mail.gmail.com>

On Tue, Dec 16, 2008 at 4:00 AM, Patrice Dumas <pertusus at free.fr> wrote:
> Hello,
>
> I am leaving fedora

Peace out dude.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From a.badger at gmail.com  Wed Dec 17 17:31:58 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 17 Dec 2008 09:31:58 -0800
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229507380.1951.15.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>	<1229416413.3434.3.camel@hughsie-work.lan>	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>	<1229451449.13024.6.camel@arekh.okg>	<20081216201640.GB8506@nostromo.devel.redhat.com>	<1229460222.15689.53.camel@arekh.okg>
	<gi94q2$7eb$2@ger.gmane.org>	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
Message-ID: <4949378E.9030209@gmail.com>

Richard Hughes wrote:
> On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
>>  Personally I think the use of '"', ., *, ?, o or ? ... are fine, just
>> as long as all the tools are displaying the same non-invisible bytes?.
> 
> Right, this discussion is going nowhere, and there are a lot of egos in
> play. At the moment I'm thinking PK should just do this:
> 
> ---------------------------------------------
> This is a spec file description or
> an update description in bohdi.
> 
> The following things 'were' fixed:
> - Fix `dave'
> - Fubar update because of "security"
> --------------------------------------------
> 
> This will be converted by gnome-packagekit into:
> 
> ---------------------------------------------
> This is a spec file description or an update description in bohdi.
> 
> The following things ?were? fixed:
> ? Fix ?dave?
> ? Fubar update because of ?security?
> ---------------------------------------------
> 
> The double quotes will be marked translated as left and right chars (so
> ? and ? can be used), the LaTeX single quotes (and double  will be
> expanded and "- " converted to bullets.
> 

Few things:
1) Why convert " => ?? ? " is correct punctuation already.
2) The concern I see with conversion to bullets and `' pairs is not how
things that fit the use case are converted but how things that don't fit
the use case are converted.  ie:

This was due to dave's library's bug #12345

upstream's changelog said: `Dave's patch broke this'

# 12345 fixed

- and + formatting fixed for floating point numbers


> If you're doing to use ? or ? in a spec file, then the text box is going
> to look rubbish and be all on one line. If you use a description longer
> than a few hundred words, gnome-packagekit will truncate it.
> 
> Now I'm going to go back to coding, rather than talking to angry people.
> 
PackageKit is, of course, your baby but you're trying to add formatting
to a field that doesn't have any formatting rules inside Fedora or
cross-distro.  Please be careful (especially before introducing even
more invasive formatting like Markdown, textile, or reStructuredText as
that will wreak havoc with a great number of descriptions that don't
expect those formatting transformations to be applied.)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/6c673981/attachment.sig>

From sandeen at redhat.com  Wed Dec 17 17:35:19 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 17 Dec 2008 11:35:19 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <494930CD.70709@herr-schmitt.de>
References: <494930CD.70709@herr-schmitt.de>
Message-ID: <49493857.3090701@redhat.com>

Jochen Schmitt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hallo,
> 
> nowaday I have read in the german fedora forum, that grub is not able
> to handle
> ext4 file systems. 

Just for the record; there is an ext4 patch for grub available; grub
certainly *could* support ext4, and likely will.

> In opposite grub2 should be able to support ext4.
> 
> Because Fedora/Red Hat is a leader of development of the ext4 file
> system, I want to
> ask about the plan for ext4 on F11 or F12.

ext4 has been in since F9; it is gaining steam and will likely have very
strong support in F11.

> Because, I'm assume, that you don't want to patch grub for ext4, 

Why assume that? :)  Which version of grub we use, and whether we
support ext4 for /boot, reallly don't have to be related questions, I think.

-Eric

> you
> have to migrate
> to grub2 if you want to support ext4 on /boot.
> 
> Best Regards:
> 
> Jochen Schmitt



From loganjerry at gmail.com  Wed Dec 17 18:01:42 2008
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 17 Dec 2008 11:01:42 -0700
Subject: HTML glitch on BSD License web page
Message-ID: <870180fe0812171001w66f7f48bl2a7080c16e9ff376@mail.gmail.com>

What should appear like this:

"AS IS"

is being displayed like this:

<code></code>AS IS''

for several of the licenses on this page:

https://fedoraproject.org/wiki/Licensing/BSD

See the first line of the paragraph that starts "THIS SOFTWARE IS
PROVIDED" for "New BSD (no advertising, 3 clause)", "FreeBSD BSD
Variant (2 clause BSD)", "Hybrid BSD (half BSD, half zlib)", and "VTK
BSD variant".
-- 
Jerry James
http://loganjerry.googlepages.com/



From notting at redhat.com  Wed Dec 17 18:38:32 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 17 Dec 2008 13:38:32 -0500
Subject: FYI - no rawhide today (yet)
Message-ID: <20081217183832.GA3343@nostromo.devel.redhat.com>

Changes to help optimize the compose process ran into some issues, so
there's no tree as of yet. There may be one later; if not, tomorrow.

Bill



From tcallawa at redhat.com  Wed Dec 17 18:42:13 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 17 Dec 2008 13:42:13 -0500
Subject: HTML glitch on BSD License web page
In-Reply-To: <870180fe0812171001w66f7f48bl2a7080c16e9ff376@mail.gmail.com>
References: <870180fe0812171001w66f7f48bl2a7080c16e9ff376@mail.gmail.com>
Message-ID: <1229539333.3481.8.camel@localhost.localdomain>

On Wed, 2008-12-17 at 11:01 -0700, Jerry James wrote:
> What should appear like this:
> 
> "AS IS"
> 
> is being displayed like this:
> 
> <code></code>AS IS''
> 
> for several of the licenses on this page:
> 
> https://fedoraproject.org/wiki/Licensing/BSD

Very odd. Fixed now, thanks.

~spot



From hughsient at gmail.com  Wed Dec 17 18:56:58 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 17 Dec 2008 18:56:58 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229533221.6191.62.camel@localhost.localdomain>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg>  <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<1229533221.6191.62.camel@localhost.localdomain>
Message-ID: <1229540218.1951.98.camel@hughsie-work.lan>

On Wed, 2008-12-17 at 09:00 -0800, Jesse Keating wrote:
> I don't understand why you want to mess with it at all?  Why can't you
> show exactly what's in bodhi, or exactly what's in the rpm headers?

Because people
file bugs when
word wrapping
is not done
correctly

People also don't use the UTF8 chars in update descriptions or spec file
changelogs, and quite understandably, there's no bullet key on most
keyboards. Using a * is so 1980's.

Richard.




From hughsient at gmail.com  Wed Dec 17 18:59:21 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 17 Dec 2008 18:59:21 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <4949378E.9030209@gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<4949378E.9030209@gmail.com>
Message-ID: <1229540361.1951.100.camel@hughsie-work.lan>

On Wed, 2008-12-17 at 09:31 -0800, Toshio Kuratomi wrote:
> PackageKit is, of course, your baby

No, it's an upstream project where we try to work with al the distros to
solve a common problem. It's certainly not my baby.

> but you're trying to add formatting
> to a field that doesn't have any formatting rules inside Fedora or
> cross-distro.

Right. And I think markdown in spec files and update descriptions makes
perfect sense. If the text doesn't have such formatting, or it's
invalid, PK will just return the text with no processing.

Richard.




From skvidal at fedoraproject.org  Wed Dec 17 19:02:18 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 17 Dec 2008 14:02:18 -0500 (EST)
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229540218.1951.98.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<1229533221.6191.62.camel@localhost.localdomain>
	<1229540218.1951.98.camel@hughsie-work.lan>
Message-ID: <alpine.LFD.2.00.0812171358570.23323@localhost.localdomain>



On Wed, 17 Dec 2008, Richard Hughes wrote:

> On Wed, 2008-12-17 at 09:00 -0800, Jesse Keating wrote:
>> I don't understand why you want to mess with it at all?  Why can't you
>> show exactly what's in bodhi, or exactly what's in the rpm headers?
>
> Because people
> file bugs when
> word wrapping
> is not done
> correctly
>
> People also don't use the UTF8 chars in update descriptions or spec file
> changelogs, and quite understandably, there's no bullet key on most
> keyboards. Using a * is so 1980's.
>

Richard,
  I'm sorry but I think if you're going to suggest a specialized format for 
the description tag and/or try to change pkgs to comply with this format 
or file bugs about non-complying pkgs then your suggestion should go to 
the Fedora Packaging or Fesco for approval. A change to the existing
standard is going to need approval from more folks.

You may also consider approaching the opensuse and mandriva folks to make 
sure they are onboard, too.

-sv




From bruno at wolff.to  Wed Dec 17 19:03:09 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 17 Dec 2008 13:03:09 -0600
Subject: FYI - no rawhide today (yet)
In-Reply-To: <20081217183832.GA3343@nostromo.devel.redhat.com>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
Message-ID: <20081217190309.GA27685@wolff.to>

On Wed, Dec 17, 2008 at 13:38:32 -0500,
  Bill Nottingham <notting at redhat.com> wrote:
> Changes to help optimize the compose process ran into some issues, so
> there's no tree as of yet. There may be one later; if not, tomorrow.

Did this effect the Bohdi push from last night as well? A bunch of stuff
moved out of pending but no email notifications were sent (that I received)
nor has my normal mirror picked any update as yet, when normally it would
have.



From jkeating at redhat.com  Wed Dec 17 19:05:05 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 11:05:05 -0800
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229540218.1951.98.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg>  <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<1229533221.6191.62.camel@localhost.localdomain>
	<1229540218.1951.98.camel@hughsie-work.lan>
Message-ID: <1229540705.6191.70.camel@localhost.localdomain>

On Wed, 2008-12-17 at 18:56 +0000, Richard Hughes wrote:
> 
> Because people
> file bugs when
> word wrapping
> is not done
> correctly

Your point?  Our spec files have a 79 char limit on them, and anything
that tries to be smaller than that gets what it deserves.  You're taking
raw data with no defined markup, trying to apply some rules to that is
just going to run you into problems.

> 
> People also don't use the UTF8 chars in update descriptions or spec file
> changelogs, and quite understandably, there's no bullet key on most
> keyboards. Using a * is so 1980's.

And what's wrong with the 1980s?  What added value does (I don't even
know the compose sequence for this) ? have over * ?  Are you going to
tell me that somebody is going to see:
 * foo
 * Bar
 * Baz

and not comprehend that it's a list of items?  Are there really no other
issues with package management that you could be working on?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/361f0288/attachment.sig>

From behdad at behdad.org  Wed Dec 17 19:16:44 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 14:16:44 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494905E2.9030303@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>
	<494905E2.9030303@gmail.com>
Message-ID: <4949501C.90003@behdad.org>

Les Mikesell wrote:

> Even desktop users deserve an environment that follows standards. Has
> everyone forgotten October's long discussion on this very subject?
> http://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=298345&topic_id=62876
> 
> Note particularly reply #96 stating mail delivery is required by both
> posix and the LSB.

Who cares if my desktop is not POSIX and LSB compliant?

And what are all those applications that are claimed depend on sendmail?  Show
it to me.

> I don't understand why people who want non-standard configurations can't
>  stop the service startups themselves - and then they'll know why normal
> programs that expect a standard environment don't work.  Also, this
> doesn't really have anything to do with boot time.  The daemon startup
> can be deferred or put in the background so as not to delay bootup.

Screw standards, we're talking about how to get a decent desktop system that
boots fast.

behdad



From jspaleta at gmail.com  Wed Dec 17 19:24:41 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Dec 2008 10:24:41 -0900
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4949501C.90003@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<4948A83E.4060007@gmail.com> <4948B09E.5080400@behdad.org>
	<494905E2.9030303@gmail.com> <4949501C.90003@behdad.org>
Message-ID: <604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>

On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad at behdad.org> wrote:
> And what are all those applications that are claimed depend on sendmail?  Show
> it to me.

Ask and you shall receive, at least for F10 with rpmfusion enabled:

> repoquery --whatrequires --alldeps sendmail --qf "%{NAME}\n"|sort -u
alpine
amavisd-new
arpwatch
asterisk-voicemail
bcfg2-server
bugzilla
clamav-milter-sendmail
cronie
dbmail
dkim-milter
fcron
fvwm
mgetty
milter-regex
mlmmj
nagios-plugins-mailq
pgp-tools
quilt
ratbox-services
redhat-lsb
sagator
sendmail
sendmail-cf
sendmail-devel
sendmail-doc
spamass-milter
squirrelmail
uudeview
websec

-jef"uudeview, I remember that program..stupid mac filesystem and its
resource forks in emails"spaleta



From jkeating at redhat.com  Wed Dec 17 19:27:36 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 11:27:36 -0800
Subject: FYI - no rawhide today (yet)
In-Reply-To: <20081217190309.GA27685@wolff.to>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
	<20081217190309.GA27685@wolff.to>
Message-ID: <1229542056.6191.72.camel@localhost.localdomain>

On Wed, 2008-12-17 at 13:03 -0600, Bruno Wolff III wrote:
> Did this effect the Bohdi push from last night as well? A bunch of stuff
> moved out of pending but no email notifications were sent (that I received)
> nor has my normal mirror picked any update as yet, when normally it would
> have.

Only kind of.  The bodhi push fell over late last night, but it only
needs a little bit of work to finish the push, instead of another 12
hour run.  I'm just waiting for lmacken to trigger that so that it
completes, before we start the rawhide compose again.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/0cea73ee/attachment.sig>

From behdad at behdad.org  Wed Dec 17 19:31:00 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 14:31:00 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>
	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>
	<4949501C.90003@behdad.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
Message-ID: <49495374.1020608@behdad.org>

Jeff Spaleta wrote:
> On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad at behdad.org> wrote:
>> And what are all those applications that are claimed depend on sendmail?  Show
>> it to me.
> 
> Ask and you shall receive, at least for F10 with rpmfusion enabled:

Thanks.  And querying those on my FC10 desktop machine:

package alpine is not installed
package amavisd-new is not installed
package arpwatch is not installed
package asterisk-voicemail is not installed
package bcfg2-server is not installed
package bugzilla is not installed
package clamav-milter-sendmail is not installed
cronie-1.2-4.fc10.x86_64
package dbmail is not installed
package dkim-milter is not installed
package fcron is not installed
package fvwm is not installed
package mgetty is not installed
package milter-regex is not installed
package mlmmj is not installed
package nagios-plugins-mailq is not installed
package pgp-tools is not installed
package quilt is not installed
package ratbox-services is not installed
package redhat-lsb is not installed
package sagator is not installed
package sendmail is not installed
package sendmail-cf is not installed
package sendmail-devel is not installed
package sendmail-doc is not installed
package spamass-milter is not installed
package squirrelmail is not installed
package uudeview is not installed
package websec is not installed



behdad


>> repoquery --whatrequires --alldeps sendmail --qf "%{NAME}\n"|sort -u
> alpine
> amavisd-new
> arpwatch
> asterisk-voicemail
> bcfg2-server
> bugzilla
> clamav-milter-sendmail
> cronie
> dbmail
> dkim-milter
> fcron
> fvwm
> mgetty
> milter-regex
> mlmmj
> nagios-plugins-mailq
> pgp-tools
> quilt
> ratbox-services
> redhat-lsb
> sagator
> sendmail
> sendmail-cf
> sendmail-devel
> sendmail-doc
> spamass-milter
> squirrelmail
> uudeview
> websec
> 
> -jef"uudeview, I remember that program..stupid mac filesystem and its
> resource forks in emails"spaleta
> 



From katzj at redhat.com  Wed Dec 17 19:36:18 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 17 Dec 2008 14:36:18 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<4948A83E.4060007@gmail.com> <4948B09E.5080400@behdad.org>
	<494905E2.9030303@gmail.com> <4949501C.90003@behdad.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
Message-ID: <1229542578.28858.153.camel@aglarond.local>

On Wed, 2008-12-17 at 10:24 -0900, Jeff Spaleta wrote:
> On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad at behdad.org> wrote:
> > And what are all those applications that are claimed depend on sendmail?  Show
> > it to me.
> 
> Ask and you shall receive, at least for F10 with rpmfusion enabled:
> 
> > repoquery --whatrequires --alldeps sendmail --qf "%{NAME}\n"|sort -u

... and best of all, since those packages require sendmail, if you go to
install one of them (modulo cronie, they're not on the desktop live
image today), you'll get sendmail pulled in.

Hey, these new-fangled dependency things work! ;-)

Jeremy



From pertusus at free.fr  Wed Dec 17 19:29:29 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 17 Dec 2008 20:29:29 +0100
Subject: orphaning all my packages
In-Reply-To: <6281b553c0ecd1705d2707b7742bbaef.squirrel@mail.jcomserv.net>
References: <20081216094739.GA3877@free.fr>
	<6127d4ff49e510ce9d9f6ae31ed404c4.squirrel@mail.jcomserv.net>
	<6281b553c0ecd1705d2707b7742bbaef.squirrel@mail.jcomserv.net>
Message-ID: <20081217192929.GA2364@free.fr>

On Wed, Dec 17, 2008 at 07:54:14AM -0600, Jon Ciesla wrote:
> 
> >
> > I'll take these.
> 
> All branches. Sorry.

Very good. I invested a lot of work in this package, it would be nice 
if it wasn't lost. And since it is old, big, fortran and imake I feared
nobody would want it.

F9 and F10 branches released.

--
Pat



From mlichvar at redhat.com  Wed Dec 17 19:42:28 2008
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Wed, 17 Dec 2008 20:42:28 +0100
Subject: FYI - no rawhide today (yet)
In-Reply-To: <1229542056.6191.72.camel@localhost.localdomain>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
	<20081217190309.GA27685@wolff.to>
	<1229542056.6191.72.camel@localhost.localdomain>
Message-ID: <20081217194228.GD30911@localhost>

On Wed, Dec 17, 2008 at 11:27:36AM -0800, Jesse Keating wrote:
> On Wed, 2008-12-17 at 13:03 -0600, Bruno Wolff III wrote:
> > Did this effect the Bohdi push from last night as well? A bunch of stuff
> > moved out of pending but no email notifications were sent (that I received)
> > nor has my normal mirror picked any update as yet, when normally it would
> > have.
> 
> Only kind of.  The bodhi push fell over late last night, but it only
> needs a little bit of work to finish the push, instead of another 12
> hour run.  I'm just waiting for lmacken to trigger that so that it
> completes, before we start the rawhide compose again.

Just curious, which part of the pust takes so much time? I'd expect
that creating new repodata, verifying dependencies, conflicts, upgrade
path, and uploading the result would be matter of minutes at worst.

-- 
Miroslav Lichvar



From opensource at till.name  Wed Dec 17 19:45:29 2008
From: opensource at till.name (Till Maas)
Date: Wed, 17 Dec 2008 20:45:29 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229542578.28858.153.camel@aglarond.local>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<1229542578.28858.153.camel@aglarond.local>
Message-ID: <200812172045.39170.opensource@till.name>

On Wed December 17 2008, Jeremy Katz wrote:

> ... and best of all, since those packages require sendmail, if you go to
> install one of them (modulo cronie, they're not on the desktop live
> image today), you'll get sendmail pulled in.

They may also require /usr/bin/sendmail, e.g.:

$ LANG=C rpm -q sendmail websec
package sendmail is not installed
websec-1.9.0-5.1.noarch

Regards,
Till

-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/298be2b5/attachment.sig>

From skvidal at fedoraproject.org  Wed Dec 17 19:45:34 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 17 Dec 2008 14:45:34 -0500 (EST)
Subject: FYI - no rawhide today (yet)
In-Reply-To: <20081217194228.GD30911@localhost>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
	<20081217190309.GA27685@wolff.to>
	<1229542056.6191.72.camel@localhost.localdomain>
	<20081217194228.GD30911@localhost>
Message-ID: <alpine.LFD.2.00.0812171445160.23323@localhost.localdomain>



On Wed, 17 Dec 2008, Miroslav Lichvar wrote:

> On Wed, Dec 17, 2008 at 11:27:36AM -0800, Jesse Keating wrote:
>> On Wed, 2008-12-17 at 13:03 -0600, Bruno Wolff III wrote:
>>> Did this effect the Bohdi push from last night as well? A bunch of stuff
>>> moved out of pending but no email notifications were sent (that I received)
>>> nor has my normal mirror picked any update as yet, when normally it would
>>> have.
>>
>> Only kind of.  The bodhi push fell over late last night, but it only
>> needs a little bit of work to finish the push, instead of another 12
>> hour run.  I'm just waiting for lmacken to trigger that so that it
>> completes, before we start the rawhide compose again.
>
> Just curious, which part of the pust takes so much time? I'd expect
> that creating new repodata, verifying dependencies, conflicts, upgrade
> path, and uploading the result would be matter of minutes at worst.
>

Not across nfs :(

A LOT of data read and written. Takes time.

-sv



From ville.skytta at iki.fi  Wed Dec 17 19:52:30 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 17 Dec 2008 21:52:30 +0200
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217085108.6cdc5d21@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<20081217085108.6cdc5d21@infradead.org>
Message-ID: <200812172152.30869.ville.skytta@iki.fi>

On Wednesday 17 December 2008, Arjan van de Ven wrote:
> On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
>
> Seth Vidal <skvidal at fedoraproject.org> wrote:
> > > Or hibernate?
> >
> > At least on my system hibernate takes as much time as a reboot.
>
> btw this is a very fundamental property of hibernate. You need to do all
> disk IO to get the system state to disk. And then at resume, you need
> to do all disk IO to get the state from disk again. That's twice ;)
>
> This is compounded by the property that a hibernate tends to flush at
> least half the disk cache (it has to, to get space to work in), which
> you then need to page right back in, so even when you're back, the first
> minute or two sucks badly.
>
> I suspect you will always be able to boot faster than you can
> hibernate+resume.

I have very different experience.  For example comparable (from grub going 
away to KDE + my bunch of default apps running and usable) numbers just taken 
from the desktop box in front of which I'm right now (AMD64 3200, 2G RAM, 
SATA, F-9 x86_64 KDE):

- shutdown: 28 sec
- fresh boot: 66 sec
- suspend to disk: 17 sec
- resume from disk: 23 sec

Shutdown takes a ~5 second penalty compared to suspend to disk due to the 
shutdown sound during which everything else appears to be idling, and fresh 
boot takes a bit of a penalty because my most recent readahead-collector run 
(using the F-10 one) is not very recent, but the numbers speak for themselves 
anyway.  Also, I have a gut feeling that the sluggishness for a while after 
the desktop is up is clearly worse on a fresh reboot than in resume from disk 
case.  But it's possible that I misremember this one - I haven't really shut 
down/rebooted except for kernel updates in almost half a year.



From lesmikesell at gmail.com  Wed Dec 17 19:55:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 13:55:49 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49495374.1020608@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<49495374.1020608@behdad.org>
Message-ID: <49495945.3020100@gmail.com>

Behdad Esfahbod wrote:
> 
>> On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad at behdad.org> wrote:
>>> And what are all those applications that are claimed depend on sendmail?  Show
>>> it to me.
>> Ask and you shall receive, at least for F10 with rpmfusion enabled:
> 
> Thanks.  And querying those on my FC10 desktop machine:
> 
> package * is not installed

Where do you receive your notifications that your disk space is nearly 
full, or that smartctl thinks a drive is dangerously near death?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From bruno at wolff.to  Wed Dec 17 19:57:04 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 17 Dec 2008 13:57:04 -0600
Subject: FYI - no rawhide today (yet)
In-Reply-To: <20081217194228.GD30911@localhost>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
	<20081217190309.GA27685@wolff.to>
	<1229542056.6191.72.camel@localhost.localdomain>
	<20081217194228.GD30911@localhost>
Message-ID: <20081217195704.GC27685@wolff.to>

On Wed, Dec 17, 2008 at 20:42:28 +0100,
  Miroslav Lichvar <mlichvar at redhat.com> wrote:
> 
> Just curious, which part of the pust takes so much time? I'd expect
> that creating new repodata, verifying dependencies, conflicts, upgrade
> path, and uploading the result would be matter of minutes at worst.

I remember seeing a relatively detailed explaination posted on one of the
lists in the last couple of months. An appropiate google search should be
able to find the post.



From jspaleta at gmail.com  Wed Dec 17 19:59:14 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Dec 2008 10:59:14 -0900
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812172045.39170.opensource@till.name>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<1229542578.28858.153.camel@aglarond.local>
	<200812172045.39170.opensource@till.name>
Message-ID: <604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>

2008/12/17 Till Maas <opensource at till.name>:
> They may also require /usr/bin/sendmail, e.g.:

I think for the purposes of the discussion... anything which provides
that file is something Behdad is going to rage madly against "needing"
in modern personal desktop experience default install target.

Should I run a set of aggregate queries for everything that provides
/usr/bin/sendmail and produce a list of any package in the repo which
would pull in anything that provides that file? I doubt it be a much
bigger list.

-jef"why does fvwm need an mta?"spaleta



From lesmikesell at gmail.com  Wed Dec 17 20:00:15 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 14:00:15 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4949501C.90003@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>
	<4949501C.90003@behdad.org>
Message-ID: <49495A4F.6070304@gmail.com>

Behdad Esfahbod wrote:
> 
>> Note particularly reply #96 stating mail delivery is required by both
>> posix and the LSB.
> 
> Who cares if my desktop is not POSIX and LSB compliant?

Everyone preparing a distribution of any sort.

> Screw standards, we're talking about how to get a decent desktop system that
> boots fast.

Do you not know how to turn services on and off on your own machine?

-- 
   Les Mikesell
     lesmikesell at gmail.com



From behdad at behdad.org  Wed Dec 17 20:03:58 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 15:03:58 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49495945.3020100@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<49495374.1020608@behdad.org>
	<49495945.3020100@gmail.com>
Message-ID: <49495B2E.6010807@behdad.org>

Les Mikesell wrote:
> Behdad Esfahbod wrote:
>>
>>> On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad at behdad.org>
>>> wrote:
>>>> And what are all those applications that are claimed depend on
>>>> sendmail?  Show
>>>> it to me.
>>> Ask and you shall receive, at least for F10 with rpmfusion enabled:
>>
>> Thanks.  And querying those on my FC10 desktop machine:
>>
>> package * is not installed
> 
> Where do you receive your notifications that your disk space is nearly
> full, or that smartctl thinks a drive is dangerously near death?

Guess where those notifications go?  In /var/spool/mail/root.  Guess who pops
up a notification on my non-root desktop to notify me that my harddisk is
dying?  Nobody.

behdad



From james at fedoraproject.org  Wed Dec 17 20:05:47 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 17 Dec 2008 15:05:47 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812172045.39170.opensource@till.name>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<1229542578.28858.153.camel@aglarond.local>
	<200812172045.39170.opensource@till.name>
Message-ID: <1229544347.6392.63.camel@code.and.org>

On Wed, 2008-12-17 at 20:45 +0100, Till Maas wrote:
> On Wed December 17 2008, Jeremy Katz wrote:
> 
> > ... and best of all, since those packages require sendmail, if you go to
> > install one of them (modulo cronie, they're not on the desktop live
> > image today), you'll get sendmail pulled in.
> 
> They may also require /usr/bin/sendmail, e.g.:

 The --alldeps option accounts for that:

% repoquery --whatrequires sendmail --qf "%{NAME}\n" | \
  fgrep websec
% repoquery --whatrequires sendmail --alldeps --qf "%{NAME}\n" | \
  fgrep websec
websec
%

-- 
James Antill <james at fedoraproject.org>
Fedora



From jkeating at redhat.com  Wed Dec 17 20:06:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 12:06:53 -0800
Subject: FYI - no rawhide today (yet)
In-Reply-To: <20081217194228.GD30911@localhost>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
	<20081217190309.GA27685@wolff.to>
	<1229542056.6191.72.camel@localhost.localdomain>
	<20081217194228.GD30911@localhost>
Message-ID: <1229544413.6191.73.camel@localhost.localdomain>

On Wed, 2008-12-17 at 20:42 +0100, Miroslav Lichvar wrote:
> Just curious, which part of the pust takes so much time? I'd expect
> that creating new repodata, verifying dependencies, conflicts, upgrade
> path, and uploading the result would be matter of minutes at worst.

66 calls to createrepo across nfs, where each repo has many thousand rpm
files to read.  Work is ongoing to optimize this somewhat, but there is
just a huge amount of data to process.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/04750016/attachment.sig>

From behdad at behdad.org  Wed Dec 17 20:05:23 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 15:05:23 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49495A4F.6070304@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>
	<49495A4F.6070304@gmail.com>
Message-ID: <49495B83.6080101@behdad.org>

Les Mikesell wrote:
> Behdad Esfahbod wrote:
>>
>>> Note particularly reply #96 stating mail delivery is required by both
>>> posix and the LSB.
>>
>> Who cares if my desktop is not POSIX and LSB compliant?
> 
> Everyone preparing a distribution of any sort.

I doubt that claim.

>> Screw standards, we're talking about how to get a decent desktop
>> system that
>> boots fast.
> 
> Do you not know how to turn services on and off on your own machine?

I know.  My mother does not know.  And your mother does not know.  And my
girlfriend should not have to know.

behdad



From mschwendt at gmail.com  Wed Dec 17 20:06:17 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 17 Dec 2008 21:06:17 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
Message-ID: <20081217210617.499559ea.mschwendt@gmail.com>

[Bcc to wxGTK and audacity owners]

> DEBUG util.py:250:  No Package Found for wxGTK2-devel

Has this rename been announced?
To me it came as a surprise. :(

The root.log of a failed build contained this

DEBUG util.py:250:  /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
DEBUG util.py:250:  error: %post(bash-3.2-33.fc11.i386) scriptlet failed, exit status 127

which made me search in the wrong direction before noticing the message
about not finding wxGTK2-devel.



From mmcgrath at redhat.com  Wed Dec 17 20:12:20 2008
From: mmcgrath at redhat.com (Michael McGrath)
Date: Wed, 17 Dec 2008 15:12:20 -0500 (EST)
Subject: Outage Notification - 2008-12-17 17:00 UTC
In-Reply-To: <778814936.959011229544582527.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1579080948.959681229544740921.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

There will be an outage starting at 2008-12-17 17:00 UTC, which will last
approximately 4 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2008-12-17 17:00 UTC'

Affected Services:

Buildsystem
Database

Unaffected Services:

CVS / Source Control
DNS
Fedora Hosted
Fedora People
Fedora Talk
Mail
Mirror System
Torrent
Translation Services
Websites

Ticket Link:

https://fedorahosted.org/fedora-infrastructure/ticket/1064

Reason for Outage:

Part of the outage earlier this week involved moving our primary koji database to a temporary location.  Now that the machine has been repaired its time to move it back.  In order to keep downtime to a minimum and not interrupt the latest compose I'm scheduling this outage for a 4 hour window though it should only actually be down for an hour.  As soon as the compose finishes I'll start.

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 mattdm at mattdm.org  Wed Dec 17 20:17:27 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 17 Dec 2008 15:17:27 -0500
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <20081217210617.499559ea.mschwendt@gmail.com>
References: <20081217210617.499559ea.mschwendt@gmail.com>
Message-ID: <20081217201727.GA13357@jadzia.bu.edu>

On Wed, Dec 17, 2008 at 09:06:17PM +0100, Michael Schwendt wrote:
> Has this rename been announced?
> To me it came as a surprise. :(

Honestly, first *I've* heard of it. This is because I'm unfortunately
ridiculously overloaded with other things right now....

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From jspaleta at gmail.com  Wed Dec 17 20:18:25 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Dec 2008 11:18:25 -0900
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<1229542578.28858.153.camel@aglarond.local>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
Message-ID: <604aa7910812171218x43f286bfr9934032b167a6b1f@mail.gmail.com>

On Wed, Dec 17, 2008 at 10:59 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> Should I run a set of aggregate queries for everything that provides
> /usr/bin/sendmail and produce a list of any package in the repo which
> would pull in anything that provides that file? I doubt it be a much
> bigger list.

Okay to be pedantically comprehensive add these to the list:

exim
exim-clamav
exim-greylist
postfix
postfix-perl-scripts
postfix-pflogsumm
postgrey
sqlgrey
ssmtp

These packages depend on something provided by a package which also
provides /usr/sbin/sendmail, but do not require /usr/sbin/sendmail.
Its obvious these packages don't matter to the discussion at hand,
since they are intimately tied to a specific mail-server's operation
and not posix compliance.

-jef



From lesmikesell at gmail.com  Wed Dec 17 20:21:58 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 14:21:58 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49495B2E.6010807@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<49495374.1020608@behdad.org>	<49495945.3020100@gmail.com>
	<49495B2E.6010807@behdad.org>
Message-ID: <49495F66.3050804@gmail.com>

Behdad Esfahbod wrote:
> 
>>> package * is not installed
>> Where do you receive your notifications that your disk space is nearly
>> full, or that smartctl thinks a drive is dangerously near death?
> 
> Guess where those notifications go?  In /var/spool/mail/root.  Guess who pops
> up a notification on my non-root desktop to notify me that my harddisk is
> dying?  Nobody.

Ahh, so you've finally identified a problem that needs to be solved. 
Unless you think the distribution should cater only to people who don't 
care if their computers work or not?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Wed Dec 17 20:24:18 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Dec 2008 11:24:18 -0900
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49495F66.3050804@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <4948A83E.4060007@gmail.com>
	<4948B09E.5080400@behdad.org> <494905E2.9030303@gmail.com>
	<4949501C.90003@behdad.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<49495374.1020608@behdad.org> <49495945.3020100@gmail.com>
	<49495B2E.6010807@behdad.org> <49495F66.3050804@gmail.com>
Message-ID: <604aa7910812171224o2cc811d4s490ebcd51c55ce84@mail.gmail.com>

On Wed, Dec 17, 2008 at 11:21 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Ahh, so you've finally identified a problem that needs to be solved. Unless
> you think the distribution should cater only to people who don't care if
> their computers work or not?

a posix complaint mta may not be the answer that makes sense in the
dbus enabled live desktop.

-jef



From behdad at behdad.org  Wed Dec 17 20:25:19 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 15:25:19 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49495F66.3050804@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<49495374.1020608@behdad.org>	<49495945.3020100@gmail.com>	<49495B2E.6010807@behdad.org>
	<49495F66.3050804@gmail.com>
Message-ID: <4949602F.4020505@behdad.org>

Les Mikesell wrote:
> Behdad Esfahbod wrote:
>>
>>>> package * is not installed
>>> Where do you receive your notifications that your disk space is nearly
>>> full, or that smartctl thinks a drive is dangerously near death?
>>
>> Guess where those notifications go?  In /var/spool/mail/root.  Guess
>> who pops
>> up a notification on my non-root desktop to notify me that my harddisk is
>> dying?  Nobody.
> 
> Ahh, so you've finally identified a problem that needs to be solved.
> Unless you think the distribution should cater only to people who don't
> care if their computers work or not?

A problem needing fix was identified at the beginning of the thread.  Except
that you insist on keeping the broken status quo.

Things like hardware notifications can much easier be done using HAL and D-BUS
than using local mail.

behdad



From mmcgrath at redhat.com  Wed Dec 17 20:27:55 2008
From: mmcgrath at redhat.com (Michael McGrath)
Date: Wed, 17 Dec 2008 15:27:55 -0500 (EST)
Subject: Outage Notification - 2008-12-18 02:00 UTC
In-Reply-To: <1579080948.959681229544740921.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1230833446.986541229545675439.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

Time conversion error.  This is actually going to be at:

2008-12-18 02:00 UTC

        -Mike


----- Original Message -----
From: "Michael McGrath" <mmcgrath at redhat.com>
To: fedora-infrastructure-list at redhat.com, fedora-devel-announce at redhat.com
Sent: Wednesday, December 17, 2008 2:12:20 PM GMT -06:00 US/Canada Central
Subject: Outage Notification - 2008-12-17 17:00 UTC

There will be an outage starting at 2008-12-17 17:00 UTC, which will last
approximately 4 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2008-12-17 17:00 UTC'

Affected Services:

Buildsystem
Database

Unaffected Services:

CVS / Source Control
DNS
Fedora Hosted
Fedora People
Fedora Talk
Mail
Mirror System
Torrent
Translation Services
Websites

Ticket Link:

https://fedorahosted.org/fedora-infrastructure/ticket/1064

Reason for Outage:

Part of the outage earlier this week involved moving our primary koji database to a temporary location.  Now that the machine has been repaired its time to move it back.  In order to keep downtime to a minimum and not interrupt the latest compose I'm scheduling this outage for a 4 hour window though it should only actually be down for an hour.  As soon as the compose finishes I'll start.

Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email to track
the status of this outage.

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From jamundso at gmail.com  Wed Dec 17 20:31:46 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Wed, 17 Dec 2008 14:31:46 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812171224o2cc811d4s490ebcd51c55ce84@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <49495F66.3050804@gmail.com>
	<604aa7910812171224o2cc811d4s490ebcd51c55ce84@mail.gmail.com>
Message-ID: <200812171431.46915.jamundso@gmail.com>

On Wed December 17 2008 14:24:18 Jeff Spaleta wrote:
> On Wed, Dec 17, 2008 at 11:21 AM, Les Mikesell <lesmikesell at gmail.com> 
wrote:
> > Ahh, so you've finally identified a problem that needs to be solved.
> > Unless you think the distribution should cater only to people who don't
> > care if their computers work or not?
>
> a posix complaint mta may not be the answer that makes sense in the
> dbus enabled live desktop.

+1
In fact, s/may not be/is not/, IMHO.

jerry

-- 
To be named later.



From lsof at nodata.co.uk  Wed Dec 17 20:33:47 2008
From: lsof at nodata.co.uk (nodata)
Date: Wed, 17 Dec 2008 21:33:47 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49467EA4.2060909@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <49467E08.2080806@redhat.com>
	<49467EA4.2060909@redhat.com>
Message-ID: <1229546027.2882.3.camel@sb-home>

Am Montag, den 15.12.2008, 16:58 +0100 schrieb Harald Hoyer:
> Eric Sandeen wrote:
> >> Turning off bootchart: 30s
> >>
> >> So all in all we have nearly accomplished the 30 Second Startup Feature 
> >> http://fedoraproject.org/wiki/Features/30SecondStartup.
> > 
> > Well, no; not if this requires data=writeback.  We can't ship that way,
> > it's a potential security hole.  You don't want someone's maildir
> > suddenly containing pieces of /etc/shadow or whatnot.  The old data that
> > may be exposed by data=writeback may not belong to that user.
> > 
> > -Eric
> > 
> 
> So, we switch to xfs as the default FS? :-)


XFS has a nasty bug where it will leave files full of zeros on disk in a
crash.

I think it was Alan Cox that said this could be fixed quite easily by
changing the write ordering for XFS, but that someone who was willing to
maintain the patch would need to do it.

If this was merged I would love to move to XFS :)



From lsof at nodata.co.uk  Wed Dec 17 20:37:50 2008
From: lsof at nodata.co.uk (nodata)
Date: Wed, 17 Dec 2008 21:37:50 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081215182823.GA28317@localhost>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>
Message-ID: <1229546270.2882.4.camel@sb-home>

Am Montag, den 15.12.2008, 19:28 +0100 schrieb Miroslav Lichvar:
> On Mon, Dec 15, 2008 at 04:26:55PM +0100, Harald Hoyer wrote:
> >> http://www.harald-hoyer.de/files/bootchart-16.png
> >
> > with newaliases this was 100% reproducable.
> 
> The fdatasync call comes from db4.
> 
> It would be nice if newaliases was executed only when /etc/aliases.db
> is older than /etc/aliases, but other MTAs may use the same db file,
> so it needs to be updated also after switching mta in the alternatives
> system.
> 
> Maybe copy the timestamp in the init script to another file and don't
> call newaliases only when the timestamps are equal?

This is probably a three line fix for an immediate gain. Sounds good :)



From jamundso at gmail.com  Wed Dec 17 20:38:00 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Wed, 17 Dec 2008 14:38:00 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
Message-ID: <200812171438.00606.jamundso@gmail.com>

On Wed December 17 2008 13:59:14 Jeff Spaleta wrote:
> 2008/12/17 Till Maas <opensource at till.name>:
> > They may also require /usr/bin/sendmail, e.g.:
>
> I think for the purposes of the discussion... anything which provides
> that file is something Behdad is going to rage madly against "needing"
> in modern personal desktop experience default install target.

Rightly so, I think. For the 'modern personal desktop' (hope I used the 
correct quotes there :-), the critical system messages deserve to be delivered 
to the active (or soon to be) desktop, rather than a passive log file.
The os from M$ may give warning by way of errors, but most likely surprises 
you at next boot. IIRC, OpenSUSE aliases root to the first user, so there is at 
least possible notification there...

jerry

-- 
To be named later.



From loupgaroublond at gmail.com  Wed Dec 17 20:39:50 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Wed, 17 Dec 2008 15:39:50 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <494930CD.70709@herr-schmitt.de>
References: <494930CD.70709@herr-schmitt.de>
Message-ID: <7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>

2008/12/17 Jochen Schmitt <Jochen at herr-schmitt.de>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hallo,
>
> nowaday I have read in the german fedora forum, that grub is not able
> to handle
> ext4 file systems. In opposite grub2 should be able to support ext4.
>
> Because Fedora/Red Hat is a leader of development of the ext4 file
> system, I want to
> ask about the plan for ext4 on F11 or F12.
>
> Because, I'm assume, that you don't want to patch grub for ext4, you
> have to migrate
> to grub2 if you want to support ext4 on /boot.

/boot is a 100-200 MB partition on many machines. Unless Grub can
safely handled an encrypted partition on top of a Logical Volume
running on an encrypted Volume Group running on an encrypted Physical
Volume on an encrypted hard drive, with levels of Software RAID in
between each step, there's just no sense supporting /boot on anything
other than a 100-200 MB ext2 or ext3 volume.

Better question is, why do you need ext4 on /boot?

I suppose getting some more sophisticated volume handling from Grub
would be nice, once btrfs becomes more mainstream, because i know i'll
want everything on btrfs.

-Yaakov



From lesmikesell at gmail.com  Wed Dec 17 20:40:44 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 14:40:44 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4949602F.4020505@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<49495374.1020608@behdad.org>	<49495945.3020100@gmail.com>	<49495B2E.6010807@behdad.org>	<49495F66.3050804@gmail.com>
	<4949602F.4020505@behdad.org>
Message-ID: <494963CC.9020508@gmail.com>

Behdad Esfahbod wrote:
> 
>>>> Where do you receive your notifications that your disk space is nearly
>>>> full, or that smartctl thinks a drive is dangerously near death?
>>> Guess where those notifications go?  In /var/spool/mail/root.  Guess
>>> who pops
>>> up a notification on my non-root desktop to notify me that my harddisk is
>>> dying?  Nobody.
>> Ahh, so you've finally identified a problem that needs to be solved.
>> Unless you think the distribution should cater only to people who don't
>> care if their computers work or not?
> 
> A problem needing fix was identified at the beginning of the thread. 

Waiting for daemon startup before doing something else in the bootup 
sequence has a simple solution.  Don't wait.  You don't have to remove 
functionality.

> Except
> that you insist on keeping the broken status quo.

The status quo in terms of services is not broken.  Other programs 
should be able to assume that a reasonable operating systems includes 
mail delivery.

> Things like hardware notifications can much easier be done using HAL and D-BUS
> than using local mail.

Such notifications would not be likely to seen by me as I almost never 
sit near the machines where the disks live.  Who gets them if multiple 
users are logged in via X or freenx?  Or if no one is logged in at all, 
or if X isn't running?

-- 
   Les Mikesell
     lesmikesell at gmail.com



From jamundso at gmail.com  Wed Dec 17 20:43:36 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Wed, 17 Dec 2008 14:43:36 -0600
Subject: Outage Notification - 2008-12-18 02:00 UTC
In-Reply-To: <1230833446.986541229545675439.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1230833446.986541229545675439.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <200812171443.36653.jamundso@gmail.com>

On Wed December 17 2008 14:27:55 Michael McGrath wrote:
> Time conversion error.  This is actually going to be at:
>
> 2008-12-18 02:00 UTC

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2008-12-18 02:00 UTC'

:-)

/me ducks 
-- 
To be named later.



From cmadams at hiwaay.net  Wed Dec 17 20:43:20 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 17 Dec 2008 14:43:20 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
Message-ID: <20081217204320.GG1223969@hiwaay.net>

Once upon a time, Yaakov Nemoy <loupgaroublond at gmail.com> said:
> Better question is, why do you need ext4 on /boot?

If all the rest of your partitions are ext4, why would you want to load
additional FS module(s) (ext2 or ext3+jbd) just for one filesystem?

-- 
Chris Adams <cmadams at hiwaay.net>
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 Dec 17 20:45:15 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 14:45:15 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812171438.00606.jamundso@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<200812172045.39170.opensource@till.name>	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com>
Message-ID: <494964DB.4040808@gmail.com>

Jerry Amundson wrote:
> On Wed December 17 2008 13:59:14 Jeff Spaleta wrote:
>> 2008/12/17 Till Maas <opensource at till.name>:
>>> They may also require /usr/bin/sendmail, e.g.:
>> I think for the purposes of the discussion... anything which provides
>> that file is something Behdad is going to rage madly against "needing"
>> in modern personal desktop experience default install target.
> 
> Rightly so, I think. For the 'modern personal desktop' (hope I used the 
> correct quotes there :-), the critical system messages deserve to be delivered 
> to the active (or soon to be) desktop, rather than a passive log file.

What does that mean?  Has Linux stopped being a multiuser system?

-- 
   Les Mikesell
    lesmikesell at gmail.com




From mw_triad at users.sourceforge.net  Wed Dec 17 20:48:28 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 17 Dec 2008 14:48:28 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4949602F.4020505@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<49495374.1020608@behdad.org>	<49495945.3020100@gmail.com>	<49495B2E.6010807@behdad.org>	<49495F66.3050804@gmail.com>
	<4949602F.4020505@behdad.org>
Message-ID: <giboiu$8qg$1@ger.gmane.org>

Behdad Esfahbod wrote:
> Les Mikesell wrote:
>> Behdad Esfahbod wrote:
>>>>> package * is not installed
>>>> Where do you receive your notifications that your disk space is nearly
>>>> full, or that smartctl thinks a drive is dangerously near death?
>>> Guess where those notifications go?  In /var/spool/mail/root.  Guess
>>> who pops
>>> up a notification on my non-root desktop to notify me that my harddisk is
>>> dying?  Nobody.
>> Ahh, so you've finally identified a problem that needs to be solved.
>> Unless you think the distribution should cater only to people who don't
>> care if their computers work or not?
> 
> A problem needing fix was identified at the beginning of the thread.  Except
> that you insist on keeping the broken status quo.
> 
> Things like hardware notifications can much easier be done using HAL and D-BUS
> than using local mail.

...and cron still needs to be patched.

How's this, when I get a popup notification that the output from my cron 
jobs is going to /dev/null and would I like to install an MTA please and 
thank you, *then* I am okay making sendmail not a hard dependency :-).

...and these sorts of notifications ought to be provided by something 
that is very hard to remove. As in, --nodeps, or at least taking out 
something whose name makes it blindingly obvious that you're removing 
something important.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"...anyway, that's my 0.02 toasters"
(with apologies to Niel)



From sandeen at redhat.com  Wed Dec 17 20:50:03 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 17 Dec 2008 14:50:03 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229546027.2882.3.camel@sb-home>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<49467E08.2080806@redhat.com>	<49467EA4.2060909@redhat.com>
	<1229546027.2882.3.camel@sb-home>
Message-ID: <494965FB.7030601@redhat.com>

nodata wrote:
> Am Montag, den 15.12.2008, 16:58 +0100 schrieb Harald Hoyer:
>> Eric Sandeen wrote:
>>>> Turning off bootchart: 30s
>>>>
>>>> So all in all we have nearly accomplished the 30 Second Startup Feature 
>>>> http://fedoraproject.org/wiki/Features/30SecondStartup.
>>> Well, no; not if this requires data=writeback.  We can't ship that way,
>>> it's a potential security hole.  You don't want someone's maildir
>>> suddenly containing pieces of /etc/shadow or whatnot.  The old data that
>>> may be exposed by data=writeback may not belong to that user.
>>>
>>> -Eric
>>>
>> So, we switch to xfs as the default FS? :-)
> 
> 
> XFS has a nasty bug where it will leave files full of zeros on disk in a
> crash.


No, it doesn't.  Not any more (and technically not ever; what happened
was a truncate & extension of the file (like vi might do) led to a size
on disk but no extents so you got a sparse file.  If the apps looked
after their data as they should, this wouldn't happen either, but that's
just an aside).

But anyway,

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=commitdiff&h=ba87ea699ebd9dd577bf055ebc4a98200e337542


> I think it was Alan Cox that said this could be fixed quite easily by
> changing the write ordering for XFS, but that someone who was willing to
> maintain the patch would need to do it.
> 
> If this was merged I would love to move to XFS :)

Go for it.

-Eric



From stickster at gmail.com  Wed Dec 17 20:51:16 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 17 Dec 2008 15:51:16 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <20081217204320.GG1223969@hiwaay.net>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<20081217204320.GG1223969@hiwaay.net>
Message-ID: <20081217205116.GD4053@localhost.localdomain>

On Wed, Dec 17, 2008 at 02:43:20PM -0600, Chris Adams wrote:
> Once upon a time, Yaakov Nemoy <loupgaroublond at gmail.com> said:
> > Better question is, why do you need ext4 on /boot?
> 
> If all the rest of your partitions are ext4, why would you want to load
> additional FS module(s) (ext2 or ext3+jbd) just for one filesystem?

Doesn't the kernel now include those drivers, as opposed to having
them as modules?

$ grep '\(JBD\|EXT3\)' /boot/config-2.6.27.7-134.fc10.x86_64 
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
CONFIG_JBD2_DEBUG=y

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/eabfaad8/attachment.sig>

From dimi at lattica.com  Wed Dec 17 20:51:59 2008
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 17 Dec 2008 15:51:59 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494964DB.4040808@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com>  <494964DB.4040808@gmail.com>
Message-ID: <1229547119.23410.18.camel@dimi.lattica.com>


On Wed, 2008-12-17 at 14:45 -0600, Les Mikesell wrote:
> > Rightly so, I think. For the 'modern personal desktop' (hope I used
> the 
> > correct quotes there :-), the critical system messages deserve to be
> delivered 
> > to the active (or soon to be) desktop, rather than a passive log
> file.
> 
> What does that mean?  Has Linux stopped being a multiuser system?

No, it hasn't. But Fedora is targeted at the desktop user.
And your continuous efforts at stopping any sort of progress
for the *common* case is truly frustrating.

I've used Linux on all my desktops for 12+ years. Never have I
found the root notifications useful in that case. And even if 
they would have been, you seem to have no idea what a non-technical
person would make of them. I'll tell you: nothing.

On the other hand, boot speed is a perceived problem by most users,
technical or not. Back in '98 when I tried to install Linux for
my dad, the 1st question was: but does it start fast?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From mw_triad at users.sourceforge.net  Wed Dec 17 20:51:15 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 17 Dec 2008 14:51:15 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<1229542578.28858.153.camel@aglarond.local>	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
Message-ID: <giboo4$8qg$2@ger.gmane.org>

Jeff Spaleta wrote:
> -jef"why does fvwm need an mta?"spaleta

...I was wondering that also ;-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"...anyway, that's my 0.02 toasters"
(with apologies to Niel)



From jkeating at redhat.com  Wed Dec 17 20:57:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 12:57:41 -0800
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49495B83.6080101@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org>	<gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>
	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>
	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>
	<49495A4F.6070304@gmail.com>  <49495B83.6080101@behdad.org>
Message-ID: <1229547461.6191.75.camel@localhost.localdomain>

On Wed, 2008-12-17 at 15:05 -0500, Behdad Esfahbod wrote:
> 
> I know.  My mother does not know.  And your mother does not know.  And my
> girlfriend should not have to know.

Neither does the guy on the bus who's looking for a good replacement to
his frustrating Vista install on his laptop.  Or anybody else that I
talk to about leaving Windows or OSX for Fedora, man, woman, or child.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/d08a5ee7/attachment.sig>

From jkeating at redhat.com  Wed Dec 17 20:59:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 12:59:01 -0800
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494963CC.9020508@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>
	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>
	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<49495374.1020608@behdad.org>	<49495945.3020100@gmail.com>
	<49495B2E.6010807@behdad.org>	<49495F66.3050804@gmail.com>
	<4949602F.4020505@behdad.org>  <494963CC.9020508@gmail.com>
Message-ID: <1229547541.6191.76.camel@localhost.localdomain>

On Wed, 2008-12-17 at 14:40 -0600, Les Mikesell wrote:
> 
> Such notifications would not be likely to seen by me as I almost never 
> sit near the machines where the disks live.  Who gets them if multiple 
> users are logged in via X or freenx?  Or if no one is logged in at all, 
> or if X isn't running?

Ahh, but to flip your argument on it's head, you know how to setup mail
delivery of such notices don't you?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/c21b4068/attachment.sig>

From behdad at behdad.org  Wed Dec 17 21:00:37 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 16:00:37 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494964DB.4040808@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<200812172045.39170.opensource@till.name>	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>	<200812171438.00606.jamundso@gmail.com>
	<494964DB.4040808@gmail.com>
Message-ID: <49496875.3090403@behdad.org>

Les Mikesell wrote:
> Jerry Amundson wrote:
>> On Wed December 17 2008 13:59:14 Jeff Spaleta wrote:
>>> 2008/12/17 Till Maas <opensource at till.name>:
>>>> They may also require /usr/bin/sendmail, e.g.:
>>> I think for the purposes of the discussion... anything which provides
>>> that file is something Behdad is going to rage madly against "needing"
>>> in modern personal desktop experience default install target.
>>
>> Rightly so, I think. For the 'modern personal desktop' (hope I used
>> the correct quotes there :-), the critical system messages deserve to
>> be delivered to the active (or soon to be) desktop, rather than a
>> passive log file.
> 
> What does that mean?  Has Linux stopped being a multiuser system?

You're sounding like a troll now.  The phrase "modern personal desktop" was
quite twice in the two-paragraph you replied to.

Just install the server spin and be happy.  What's wrong with that?

behdad



From a.badger at gmail.com  Wed Dec 17 21:04:00 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 17 Dec 2008 13:04:00 -0800
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229540361.1951.100.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>	<1229416413.3434.3.camel@hughsie-work.lan>	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>	<1229451449.13024.6.camel@arekh.okg>	<20081216201640.GB8506@nostromo.devel.redhat.com>	<1229460222.15689.53.camel@arekh.okg>
	<gi94q2$7eb$2@ger.gmane.org>	<1229466653.6392.38.camel@code.and.org>	<1229507380.1951.15.camel@hughsie-work.lan>	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan>
Message-ID: <49496940.20706@gmail.com>

Richard Hughes wrote:
> On Wed, 2008-12-17 at 09:31 -0800, Toshio Kuratomi wrote:
>> PackageKit is, of course, your baby
> 
> No, it's an upstream project where we try to work with al the distros to
> solve a common problem. It's certainly not my baby.
> 
In that case, you're going to have a lot of problems with adding
Markdown in PackageKit upstream.  I doubt heavily that we'll be able to
get people within Fedora to agree to format their %descriptions as
markdown let alone the larger community of distributions.  I've already
mentioned reStructuredText which is popular in the python community and
preformatted text (whether ASCii or utf-8) is also going to have adherents.

>> but you're trying to add formatting
>> to a field that doesn't have any formatting rules inside Fedora or
>> cross-distro.
> 
> Right. And I think markdown in spec files and update descriptions makes
> perfect sense. If the text doesn't have such formatting, or it's
> invalid, PK will just return the text with no processing.
> 
The problem is that Markdown and other non-intrusive formats (like
reStructuredText) don't have enough information to tell if it's
"invalid".  For instance, if my Bodhi comments have:

# Fix an issue with char *foobar and all void* on gcc-5
# Fix call to __init__ in python bindings.

Markdown will mangle what I intended because there are three constructs
in there that look like valid Markdown.

To use a non-intrusive format, we need to specify the format being used
either in a specification or as metadata to the %description tag.  Both
of those solutions would have to be hashed out with the rpm authors.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/81ced59f/attachment.sig>

From jspaleta at gmail.com  Wed Dec 17 21:12:22 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Dec 2008 12:12:22 -0900
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229547461.6191.75.camel@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org> <4948A83E.4060007@gmail.com>
	<4948B09E.5080400@behdad.org> <494905E2.9030303@gmail.com>
	<4949501C.90003@behdad.org> <49495A4F.6070304@gmail.com>
	<49495B83.6080101@behdad.org>
	<1229547461.6191.75.camel@localhost.localdomain>
Message-ID: <604aa7910812171312r32103786h1d66989441113a2@mail.gmail.com>

2008/12/17 Jesse Keating <jkeating at redhat.com>:
> Neither does the guy on the bus who's looking for a good replacement to
> his frustrating Vista install on his laptop.  Or anybody else that I
> talk to about leaving Windows or OSX for Fedora, man, woman, or child.

Surprisingly enough, when I talk to polar bears who are waiting on the
side of the road for the bus at the end of the day...first thing they
ask is "How would I turn off services on Fedora."

-jef"You don't even want to know what the sleddogs ask me about..NSFW"spaleta



From skvidal at fedoraproject.org  Wed Dec 17 21:22:10 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 17 Dec 2008 16:22:10 -0500 (EST)
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49496875.3090403@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com>
	<494964DB.4040808@gmail.com> <49496875.3090403@behdad.org>
Message-ID: <alpine.LFD.2.00.0812171613270.24989@localhost.localdomain>



On Wed, 17 Dec 2008, Behdad Esfahbod wrote:

> Les Mikesell wrote:
>> Jerry Amundson wrote:
>>> On Wed December 17 2008 13:59:14 Jeff Spaleta wrote:
>>>> 2008/12/17 Till Maas <opensource at till.name>:
>>>>> They may also require /usr/bin/sendmail, e.g.:
>>>> I think for the purposes of the discussion... anything which provides
>>>> that file is something Behdad is going to rage madly against "needing"
>>>> in modern personal desktop experience default install target.
>>>
>>> Rightly so, I think. For the 'modern personal desktop' (hope I used
>>> the correct quotes there :-), the critical system messages deserve to
>>> be delivered to the active (or soon to be) desktop, rather than a
>>> passive log file.
>>
>> What does that mean?  Has Linux stopped being a multiuser system?
>
> You're sounding like a troll now.  The phrase "modern personal desktop" was
> quite twice in the two-paragraph you replied to.
>
> Just install the server spin and be happy.  What's wrong with that?
>

the problem is that a lot of the notification utilities/tools seem to be 
developed exclusively with a desktop/laptop in mind. Not with a server 
infrastructure and a sysadmin-controlled-environment in mind.

In short, stop talking about desktop/laptop-centric notifications.

If you want to get rid of sendmail-style notifications then using the same 
notification infrastructure make sure that at introduction there  are 
tools to notify a user on the desktop AND to get a message out in one of 
the older styles, like sending an email.

And I don't mean a tool like 'oh just run oddjob' I mean something 
tailored to do that. It's not an unreasonable request and since fedora 
(and rhel which derives from fedora) are not desktop-only distros it is a 
perfectly sensible thing to do.

The most obvious thing I've not seen, yet, is a notification->email dbus 
listener. That would allow interaction to the mail notifications that Les 
(and A LOT of sysadmins) want and it would also allow someone to learn how 
to do that better. Dbus-notifications to nagios or zabbix, for example.

Does that make sense?
-sv



From drago01 at gmail.com  Wed Dec 17 21:40:38 2008
From: drago01 at gmail.com (drago01)
Date: Wed, 17 Dec 2008 22:40:38 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229547541.6191.76.camel@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org> <4949501C.90003@behdad.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<49495374.1020608@behdad.org> <49495945.3020100@gmail.com>
	<49495B2E.6010807@behdad.org> <49495F66.3050804@gmail.com>
	<4949602F.4020505@behdad.org> <494963CC.9020508@gmail.com>
	<1229547541.6191.76.camel@localhost.localdomain>
Message-ID: <f6ca9fed0812171340t8dcce2bvd6ee197a34a03b1f@mail.gmail.com>

2008/12/17 Jesse Keating <jkeating at redhat.com>:
> On Wed, 2008-12-17 at 14:40 -0600, Les Mikesell wrote:
>>
>> Such notifications would not be likely to seen by me as I almost never
>> sit near the machines where the disks live.  Who gets them if multiple
>> users are logged in via X or freenx?  Or if no one is logged in at all,
>> or if X isn't running?
>
> Ahh, but to flip your argument on it's head, you know how to setup mail
> delivery of such notices don't you?

Yeah people how know about them know how to enable them (its not
rocket science btw) but most users don't need them and don't even know
that they exits ...
so why make the boot process slower for most users?

And why do people always shout "oh no you changed something that has
been that way for years that must be wrong even if its better for most
users"  ? ...  nobody wants to remove MTA's from fedora they just want
to not install/enable it by default.

We really need to make the boot process faster .. talking about how
important a MTA isn't the best way to accomplish this goal .. it will
ends up like every fedora release.
Talk and no changes due to flamewar = no or minimal boot time improvement.



From jspaleta at gmail.com  Wed Dec 17 21:42:08 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Dec 2008 12:42:08 -0900
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <alpine.LFD.2.00.0812171613270.24989@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com> <494964DB.4040808@gmail.com>
	<49496875.3090403@behdad.org>
	<alpine.LFD.2.00.0812171613270.24989@localhost.localdomain>
Message-ID: <604aa7910812171342n55195d22pa19f16ce2e5c23dd@mail.gmail.com>

On Wed, Dec 17, 2008 at 12:22 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> Does that make sense?

tonnes of sense.

And so would the opposite an email->notification utility which would
turn traditional local system emails meant for root into dbus
messages.  Such a beast would set at /usr/sbin/sendmail when
installed..but would be replaced by a traditional mta if systems did
not want a dbus service running.

-jef



From notting at redhat.com  Wed Dec 17 21:48:54 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 17 Dec 2008 16:48:54 -0500
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229507380.1951.15.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
Message-ID: <20081217214854.GA7105@nostromo.devel.redhat.com>

Richard Hughes (hughsient at gmail.com) said: 
> >  Personally I think the use of '"', ., *, ?, o or ? ... are fine, just
> > as long as all the tools are displaying the same non-invisible bytes?.
> 
> Right, this discussion is going nowhere, and there are a lot of egos in
> play.

Pointed out without other comment.

> ---------------------------------------------
> This is a spec file description or
> an update description in bohdi.
> 
> The following things 'were' fixed:
> - Fix `dave'
> - Fubar update because of "security"
> --------------------------------------------
> 
> This will be converted by gnome-packagekit into:
> 
> ---------------------------------------------
> This is a spec file description or an update description in bohdi.
> 
> The following things ?were? fixed:
> ? Fix ?dave?
> ? Fubar update because of ?security?
> ---------------------------------------------

Dumb question. All the complaints I've seen that come in are
about word-wrapping, but your main example is about character
escaping/transliteration. Why not just do the word-wrapping, and
leave it at that? (Note that PK at the moment wordwraps badly,
which causes other issues.)

Bill



From lesmikesell at gmail.com  Wed Dec 17 21:51:55 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 15:51:55 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49496875.3090403@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<200812172045.39170.opensource@till.name>	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>	<200812171438.00606.jamundso@gmail.com>	<494964DB.4040808@gmail.com>
	<49496875.3090403@behdad.org>
Message-ID: <4949747B.9030806@gmail.com>

Behdad Esfahbod wrote:
>
>>>>> They may also require /usr/bin/sendmail, e.g.:
>>>> I think for the purposes of the discussion... anything which provides
>>>> that file is something Behdad is going to rage madly against "needing"
>>>> in modern personal desktop experience default install target.
>>> Rightly so, I think. For the 'modern personal desktop' (hope I used
>>> the correct quotes there :-), the critical system messages deserve to
>>> be delivered to the active (or soon to be) desktop, rather than a
>>> passive log file.
>> What does that mean?  Has Linux stopped being a multiuser system?
> 
> You're sounding like a troll now.  The phrase "modern personal desktop" was
> quite twice in the two-paragraph you replied to.

I have no idea what "modern personal desktop" means to you.  For me, it 
mostly means something that can run the NX client to connect to my 
long-running desktop sessions on a few other machines.

> Just install the server spin and be happy.  What's wrong with that?

I want desktop applications.  I just don't want to be limited to one 
user at a time running them, or forced to be at any particular location 
relative to where they run, or to have to stay in one place after 
starting a session.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Wed Dec 17 22:04:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 16:04:14 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229547541.6191.76.camel@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>	<49481793.9060406@behdad.org>	<4948A83E.4060007@gmail.com>	<4948B09E.5080400@behdad.org>	<494905E2.9030303@gmail.com>	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<49495374.1020608@behdad.org>	<49495945.3020100@gmail.com>	<49495B2E.6010807@behdad.org>	<49495F66.3050804@gmail.com>	<4949602F.4020505@behdad.org>
	<494963CC.9020508@gmail.com>
	<1229547541.6191.76.camel@localhost.localdomain>
Message-ID: <4949775E.8030100@gmail.com>

Jesse Keating wrote:
> On Wed, 2008-12-17 at 14:40 -0600, Les Mikesell wrote:
>> Such notifications would not be likely to seen by me as I almost never 
>> sit near the machines where the disks live.  Who gets them if multiple 
>> users are logged in via X or freenx?  Or if no one is logged in at all, 
>> or if X isn't running?
> 
> Ahh, but to flip your argument on it's head, you know how to setup mail
> delivery of such notices don't you?

Yes, but the point of loading a distribution instead of assembling your 
own linux from scratch is to have most of the grunge work for standard 
things done for you.  Plus, if notifications are moved to dbus, I'd have 
no idea about how to catch them and deliver using standard protocols 
instead.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Wed Dec 17 22:06:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 16:06:24 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494965FB.7030601@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<49467E08.2080806@redhat.com>	<49467EA4.2060909@redhat.com>	<1229546027.2882.3.camel@sb-home>
	<494965FB.7030601@redhat.com>
Message-ID: <494977E0.1000209@gmail.com>

Eric Sandeen wrote:
> 
>>> So, we switch to xfs as the default FS? :-)
>>
>> XFS has a nasty bug where it will leave files full of zeros on disk in a
>> crash.
> 
> 
> No, it doesn't.  Not any more (and technically not ever; what happened
> was a truncate & extension of the file (like vi might do) led to a size
> on disk but no extents so you got a sparse file.  If the apps looked
> after their data as they should, this wouldn't happen either, but that's
> just an aside).
> 
> But anyway,
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=commitdiff&h=ba87ea699ebd9dd577bf055ebc4a98200e337542
> 
> 
>> I think it was Alan Cox that said this could be fixed quite easily by
>> changing the write ordering for XFS, but that someone who was willing to
>> maintain the patch would need to do it.
>>
>> If this was merged I would love to move to XFS :)

Hasn't there always been a problem with xfs and 4k stacks?  Or are you 
only talking about 64-bit versions here?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Wed Dec 17 22:12:50 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 17 Dec 2008 17:12:50 -0500
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <20081217214854.GA7105@nostromo.devel.redhat.com>
References: <1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<20081217214854.GA7105@nostromo.devel.redhat.com>
Message-ID: <20081217221250.GB7105@nostromo.devel.redhat.com>

Bill Nottingham (notting at redhat.com) said: 
> > ---------------------------------------------
> > This is a spec file description or an update description in bohdi.
> > 
> > The following things ?were? fixed:
> > ? Fix ?dave?
> > ? Fubar update because of ?security?
> > ---------------------------------------------
> 
> Dumb question. All the complaints I've seen that come in are
> about word-wrapping, but your main example is about character
> escaping/transliteration. Why not just do the word-wrapping, and
> leave it at that? (Note that PK at the moment wordwraps badly,
> which causes other issues.)

Alternatively, if we remove the requirement on the spec data
itself to be manually wrapped with newlines, this could (theoretically)
sort itself out fairly well.

Bill



From lesmikesell at gmail.com  Wed Dec 17 22:27:27 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 17 Dec 2008 16:27:27 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <f6ca9fed0812171340t8dcce2bvd6ee197a34a03b1f@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<49495374.1020608@behdad.org>
	<49495945.3020100@gmail.com>	<49495B2E.6010807@behdad.org>
	<49495F66.3050804@gmail.com>	<4949602F.4020505@behdad.org>
	<494963CC.9020508@gmail.com>	<1229547541.6191.76.camel@localhost.localdomain>
	<f6ca9fed0812171340t8dcce2bvd6ee197a34a03b1f@mail.gmail.com>
Message-ID: <49497CCF.1090102@gmail.com>

drago01 wrote:
> 
>>> Such notifications would not be likely to seen by me as I almost never
>>> sit near the machines where the disks live.  Who gets them if multiple
>>> users are logged in via X or freenx?  Or if no one is logged in at all,
>>> or if X isn't running?
>> Ahh, but to flip your argument on it's head, you know how to setup mail
>> delivery of such notices don't you?
> 
> Yeah people how know about them know how to enable them (its not
> rocket science btw) but most users don't need them and don't even know
> that they exits ...

OK, so some users are ignorant at first.  That doesn't have to last forever.

> so why make the boot process slower for most users?

That's a complete separate question, since having a standard mail 
transport doesn't have to slow the boot process.

> And why do people always shout "oh no you changed something that has
> been that way for years that must be wrong even if its better for most
> users"  ?

Why do people pretend that they just invented computers and that no one 
else understands them, ignoring standards that have developed over many 
years for good reasons?

> ...  nobody wants to remove MTA's from fedora they just want
> to not install/enable it by default.

How is not installing it different from removing it?  If a 3rd party 
program needs it, it's not there.

> We really need to make the boot process faster .. talking about how
> important a MTA isn't the best way to accomplish this goal .. it will
> ends up like every fedora release.

So do the obvious thing. Make booting faster without disabling expected 
functionality.

> Talk and no changes due to flamewar = no or minimal boot time improvement.

I don't think there would be any flamewar if someone stuck to the 
subject of boot times and just deferred the MTA startup or put it in the 
background.   There is no need to wait.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From mlichvar at redhat.com  Wed Dec 17 22:29:48 2008
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Wed, 17 Dec 2008 23:29:48 +0100
Subject: FYI - no rawhide today (yet)
In-Reply-To: <1229544413.6191.73.camel@localhost.localdomain>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
	<20081217190309.GA27685@wolff.to>
	<1229542056.6191.72.camel@localhost.localdomain>
	<20081217194228.GD30911@localhost>
	<1229544413.6191.73.camel@localhost.localdomain>
Message-ID: <20081217222948.GA1877@localhost>

On Wed, Dec 17, 2008 at 12:06:53PM -0800, Jesse Keating wrote:
> On Wed, 2008-12-17 at 20:42 +0100, Miroslav Lichvar wrote:
> > Just curious, which part of the pust takes so much time? I'd expect
> > that creating new repodata, verifying dependencies, conflicts, upgrade
> > path, and uploading the result would be matter of minutes at worst.
> 
> 66 calls to createrepo across nfs, where each repo has many thousand rpm
> files to read.  Work is ongoing to optimize this somewhat, but there is
> just a huge amount of data to process.

Is that with the --update option? The manpage says it will read only
the new packages.

-- 
Miroslav Lichvar



From notting at redhat.com  Wed Dec 17 22:34:42 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 17 Dec 2008 17:34:42 -0500
Subject: FYI - no rawhide today (yet)
In-Reply-To: <20081217222948.GA1877@localhost>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
	<20081217190309.GA27685@wolff.to>
	<1229542056.6191.72.camel@localhost.localdomain>
	<20081217194228.GD30911@localhost>
	<1229544413.6191.73.camel@localhost.localdomain>
	<20081217222948.GA1877@localhost>
Message-ID: <20081217223442.GC7105@nostromo.devel.redhat.com>

Miroslav Lichvar (mlichvar at redhat.com) said: 
> > > Just curious, which part of the pust takes so much time? I'd expect
> > > that creating new repodata, verifying dependencies, conflicts, upgrade
> > > path, and uploading the result would be matter of minutes at worst.
> > 
> > 66 calls to createrepo across nfs, where each repo has many thousand rpm
> > files to read.  Work is ongoing to optimize this somewhat, but there is
> > just a huge amount of data to process.
> 
> Is that with the --update option? The manpage says it will read only
> the new packages.

Until very very recently (in fact, the source of the problem today)
there was no code to pull any repodata from previous rawhide runs
to --update from.

Bill



From mw_triad at users.sourceforge.net  Wed Dec 17 22:44:15 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 17 Dec 2008 16:44:15 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49497CCF.1090102@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<49495374.1020608@behdad.org>	<49495945.3020100@gmail.com>	<49495B2E.6010807@behdad.org>	<49495F66.3050804@gmail.com>	<4949602F.4020505@behdad.org>	<494963CC.9020508@gmail.com>	<1229547541.6191.76.camel@localhost.localdomain>	<f6ca9fed0812171340t8dcce2bvd6ee197a34a03b1f@mail.gmail.com>
	<49497CCF.1090102@gmail.com>
Message-ID: <gibvbv$qm$1@ger.gmane.org>

Les Mikesell wrote:
> drago01 wrote:
>> Talk and no changes due to flamewar = no or minimal boot time 
>> improvement.
> 
> I don't think there would be any flamewar if someone stuck to the 
> subject of boot times and just deferred the MTA startup or put it in the 
> background.   There is no need to wait.

+1. Since I switched my Asus to Cambridge, boot time has become a topic 
near to my heart. But I still (AFAIK) have sendmail installed, because - 
even though, forced to think about it, I probably don't need it - I 
don't feel comfortable without a functional mail subsystem. (Maybe if I 
removed cron also...)

I'm in favor of deferred-startup, however. As one of the individuals 
opposed to breaking mail, I'd like to hope that's worth something :-). 
After all, compromise is about finding a position that everyone finds at 
least acceptable, if not satisfying. It would be nice if we could work 
toward that instead of this "my way or no progress" attitude that seems 
to be prevalent.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"...anyway, that's my 0.02 toasters"
(with apologies to Niel)



From jkeating at redhat.com  Wed Dec 17 22:59:08 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 14:59:08 -0800
Subject: FYI - no rawhide today (yet)
In-Reply-To: <20081217223442.GC7105@nostromo.devel.redhat.com>
References: <20081217183832.GA3343@nostromo.devel.redhat.com>
	<20081217190309.GA27685@wolff.to>
	<1229542056.6191.72.camel@localhost.localdomain>
	<20081217194228.GD30911@localhost>
	<1229544413.6191.73.camel@localhost.localdomain>
	<20081217222948.GA1877@localhost>
	<20081217223442.GC7105@nostromo.devel.redhat.com>
Message-ID: <1229554748.6191.90.camel@localhost.localdomain>

On Wed, 2008-12-17 at 17:34 -0500, Bill Nottingham wrote:
> > Is that with the --update option? The manpage says it will read only
> > the new packages.
> 
> Until very very recently (in fact, the source of the problem today)
> there was no code to pull any repodata from previous rawhide runs
> to --update from.

Not to mention that --update still has to stat the files to see if they
have changed, which is costly, 66 times, over nfs, on thousands upon
thousands of files each time.

Add to that the way we have to do multilib, there is at least one time
when 1/2 of the content you're running createrepo over doesn't exist in
any older repodata to read from (without a lot more gross hacks to stash
previous mid-run repodata somewhere).

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/cbb30c68/attachment.sig>

From kevin.kofler at chello.at  Wed Dec 17 23:01:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Dec 2008 00:01:46 +0100
Subject: Review Swaps
References: <200812170341.19903.konrad@tylerc.org>
Message-ID: <gic0cq$446$1@ger.gmane.org>

Conrad Meyer wrote:
> python-zope-filesystem -
> https://bugzilla.redhat.com/show_bug.cgi?id=476475

Well, I promised to review this one, I'll do it now.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Dec 17 23:03:30 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Dec 2008 00:03:30 +0100
Subject: Whatever happened to make force-tag?
References: <200812170954.09054.sgrubb@redhat.com>
Message-ID: <gic0g2$446$2@ger.gmane.org>

Steve Grubb wrote:
> I remember that there were lots of discussion about this in September. We
> have the ability to do "force-tag" in cvs directly, why have we not taken
> the next step and re-enabled the make target?

make tag TAG_OPTS=-F
(Note that it's -F, not -f.)

        Kevin Kofler



From bkoz at redhat.com  Wed Dec 17 23:07:12 2008
From: bkoz at redhat.com (Benjamin Kosnik)
Date: Wed, 17 Dec 2008 15:07:12 -0800
Subject: f11 boost-1.37.0 upgrade: notice of intent, and best way to
In-Reply-To: <e1760170812150628k5d37ec2apd57150960e1a87f@mail.gmail.com>
References: <20081124120549.5107aced@balbo.artheist.org>
	<e1760170812150628k5d37ec2apd57150960e1a87f@mail.gmail.com>
Message-ID: <20081217150712.6e1b9e01@balbo.artheist.org>


> > The boost maintainers are planning to update the boost versions
> > to the current release (1.37.0) in rawhide for F11. There was an
> > attempt to upgrade boost for F10, but the timing was off.
> >
> > Details on that attempt:
> >
> > https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00464.html
> >

> > 3) check in the base boost package to devel, and immediately work on
> > rebuilding the deps

... using this

> Any ETA on this attempt ?

It's now in. Deps need to be rebuilt. 

-benjamin



From kevin.kofler at chello.at  Wed Dec 17 23:05:50 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Dec 2008 00:05:50 +0100
Subject: Usage of %{__macros} in our .specs?
References: <1229528414.28296.35.camel@pc-notebook>
Message-ID: <gic0ke$446$3@ger.gmane.org>

Martin Sourada wrote:
> I've been told, by an upstream developer of one of the packages I
> maintain, that I/we should use e.g. %{__make} instead of make in
> our .spec files in order to have our packages more compatible/portable.

We normally don't use these macros in Fedora, they are completely
unnecessary. They are not forbidden, but in the interest of readability,
please don't use them.

        Kevin Kofler



From alan at redhat.com  Wed Dec 17 23:28:40 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 17 Dec 2008 18:28:40 -0500
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229540218.1951.98.camel@hughsie-work.lan>
References: <1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<1229533221.6191.62.camel@localhost.localdomain>
	<1229540218.1951.98.camel@hughsie-work.lan>
Message-ID: <20081217232840.GA23212@shell.devel.redhat.com>

On Wed, Dec 17, 2008 at 06:56:58PM +0000, Richard Hughes wrote:
> Because people
> file bugs when
> word wrapping
> is not done
> correctly

Word wrapping is an separate issue.

> People also don't use the UTF8 chars in update descriptions or spec file
> changelogs, and quite understandably, there's no bullet key on most
> keyboards. Using a * is so 1980's.

So add a new rpm header using semantic markup. You could even use an XML
markup if you wanted.



From alan at redhat.com  Wed Dec 17 23:48:53 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 17 Dec 2008 18:48:53 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229546027.2882.3.camel@sb-home>
References: <gi5qm4$bbq$1@ger.gmane.org> <49467E08.2080806@redhat.com>
	<49467EA4.2060909@redhat.com> <1229546027.2882.3.camel@sb-home>
Message-ID: <20081217234853.GE23212@shell.devel.redhat.com>

On Wed, Dec 17, 2008 at 09:33:47PM +0100, nodata wrote:
> XFS has a nasty bug where it will leave files full of zeros on disk in a
> crash.
> 
> I think it was Alan Cox that said this could be fixed quite easily by
> changing the write ordering for XFS, but that someone who was willing to
> maintain the patch would need to do it.

Not guilty.

Ext3 has a set of options for data journalling (at a performance cost). XFS
is not something I look into the innards of as I don't have enough chickens
to sacrifice




From pertusus at free.fr  Wed Dec 17 23:54:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Dec 2008 00:54:43 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229547119.23410.18.camel@dimi.lattica.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com>
	<494964DB.4040808@gmail.com>
	<1229547119.23410.18.camel@dimi.lattica.com>
Message-ID: <20081217235443.GA2361@free.fr>

On Wed, Dec 17, 2008 at 03:51:59PM -0500, Dimi Paun wrote:
> 
> No, it hasn't. But Fedora is targeted at the desktop user.
> And your continuous efforts at stopping any sort of progress
> for the *common* case is truly frustrating.

'Fedora is a Linux-based operating system that showcases the latest in free and open source software.'

It is not a distro targeted at desktop users with a common case. 
It is innovative, but it doesn't necessarily means desktop.

--
Pat



From pertusus at free.fr  Wed Dec 17 23:57:27 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Dec 2008 00:57:27 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <giboo4$8qg$2@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<1229542578.28858.153.camel@aglarond.local>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<giboo4$8qg$2@ger.gmane.org>
Message-ID: <20081217235727.GB2361@free.fr>

On Wed, Dec 17, 2008 at 02:51:15PM -0600, Matthew Woehlke wrote:
> Jeff Spaleta wrote:
>> -jef"why does fvwm need an mta?"spaleta
>
> ...I was wondering that also ;-).

It is for fvwm-bug. Guess that it calls sendmail.

--
Pat



From behdad at behdad.org  Wed Dec 17 23:58:25 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 17 Dec 2008 18:58:25 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217235443.GA2361@free.fr>
References: <gi5qm4$bbq$1@ger.gmane.org>	<200812172045.39170.opensource@till.name>	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>	<200812171438.00606.jamundso@gmail.com>	<494964DB.4040808@gmail.com>	<1229547119.23410.18.camel@dimi.lattica.com>
	<20081217235443.GA2361@free.fr>
Message-ID: <49499221.1090002@behdad.org>

Patrice Dumas wrote:
> On Wed, Dec 17, 2008 at 03:51:59PM -0500, Dimi Paun wrote:
>> No, it hasn't. But Fedora is targeted at the desktop user.
>> And your continuous efforts at stopping any sort of progress
>> for the *common* case is truly frustrating.
> 
> 'Fedora is a Linux-based operating system that showcases the latest in free and open source software.'
> 
> It is not a distro targeted at desktop users with a common case. 
> It is innovative, but it doesn't necessarily means desktop.

What about the Desktop Spin?

behdad


> --
> Pat



From pertusus at free.fr  Thu Dec 18 00:01:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Dec 2008 01:01:30 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49499221.1090002@behdad.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com>
	<494964DB.4040808@gmail.com>
	<1229547119.23410.18.camel@dimi.lattica.com>
	<20081217235443.GA2361@free.fr> <49499221.1090002@behdad.org>
Message-ID: <20081218000130.GC2361@free.fr>

On Wed, Dec 17, 2008 at 06:58:25PM -0500, Behdad Esfahbod wrote:
> 
> What about the Desktop Spin?

You want to do something different regarding the boot sequence for 
different spins? that could be doable, but I don't think this is
a road to go down.

--
Pat



From mw_triad at users.sourceforge.net  Thu Dec 18 00:09:37 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 17 Dec 2008 18:09:37 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217235727.GB2361@free.fr>
References: <gi5qm4$bbq$1@ger.gmane.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<1229542578.28858.153.camel@aglarond.local>	<200812172045.39170.opensource@till.name>	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>	<giboo4$8qg$2@ger.gmane.org>
	<20081217235727.GB2361@free.fr>
Message-ID: <gic4c1$g5e$1@ger.gmane.org>

Patrice Dumas wrote:
> On Wed, Dec 17, 2008 at 02:51:15PM -0600, Matthew Woehlke wrote:
>> Jeff Spaleta wrote:
>>> -jef"why does fvwm need an mta?"spaleta
>> ...I was wondering that also ;-).
> 
> It is for fvwm-bug. Guess that it calls sendmail.

Ah :-). That makes sense.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"...anyway, that's my 0.02 toasters"
(with apologies to Niel)



From vonbrand at inf.utfsm.cl  Thu Dec 18 00:40:06 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 17 Dec 2008 21:40:06 -0300
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229540218.1951.98.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<1229533221.6191.62.camel@localhost.localdomain>
	<1229540218.1951.98.camel@hughsie-work.lan>
Message-ID: <200812180040.mBI0e681009541@laptop14.inf.utfsm.cl>

Richard Hughes <hughsient at gmail.com> wrote:
> On Wed, 2008-12-17 at 09:00 -0800, Jesse Keating wrote:
> > I don't understand why you want to mess with it at all?  Why can't you
> > show exactly what's in bodhi, or exactly what's in the rpm headers?
> 
> Because people
> file bugs when
> word wrapping
> is not done
> correctly

Then
the
packa-
gers
should
fix
the
word-
wrap-
ping
bugs!

> People also don't use the UTF8 chars in update descriptions or spec file
> changelogs, and quite understandably, there's no bullet key on most
> keyboards. Using a * is so 1980's.

They do use UTF-8 characters just fine, thank you. Not all of them, perhaps
not even the ones you are most fond of. BZ away, sending appropiate patches.
-- 
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  Thu Dec 18 01:08:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 17:08:00 -0800
Subject: [Fedora Update] [testing] shorewall-4.0.15-1.fc8
In-Reply-To: <20081218004518.B7B67208DF8@bastion.fedora.phx.redhat.com>
References: <20081218004518.B7B67208DF8@bastion.fedora.phx.redhat.com>
Message-ID: <1229562480.6191.96.camel@localhost.localdomain>

On Thu, 2008-12-18 at 00:45 +0000, updates at fedoraproject.org wrote:
> jgu has requested the pushing of the following update to testing:
> 
> ================================================================================
>      shorewall-4.0.15-1.fc8
> ================================================================================
>     Release: Fedora 8
>      Status: pending
>        Type: bugfix
>       Karma: 0
>     Request: testing
>       Notes: New upstream bugfix version.
>   Submitter: jgu
>   Submitted: 2008-12-18 00:45:18
>    Comments: jgu - 2008-12-18 00:45:18 (karma 0)
>              This update has been submitted for testing
> 
>   http://admin.fedoraproject.org/updates/shorewall-4.0.15-1.fc8
> 

What is the purpose of this version bump (4.0.14 -> 4.0.15) in F8, which
only has a few weeks of lifespan yet.  There is no information in the
update request that would help users understand why they should consume
this update.  Please fill in some details, and consider whether the
update is suitable for Fedora 8.
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/ca98b0f4/attachment.sig>

From pertusus at free.fr  Thu Dec 18 01:13:58 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Dec 2008 02:13:58 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494905E2.9030303@gmail.com>
References: <20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org> <4948A83E.4060007@gmail.com>
	<4948B09E.5080400@behdad.org> <494905E2.9030303@gmail.com>
Message-ID: <20081218011358.GE2361@free.fr>

On Wed, Dec 17, 2008 at 08:00:02AM -0600, Les Mikesell wrote:
>
> Even desktop users deserve an environment that follows standards. Has  
> everyone forgotten October's long discussion on this very subject?
> http://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=298345&topic_id=62876
> Note particularly reply #96 stating mail delivery is required by both  
> posix and the LSB.

I have searched that on posix, but I have only seen that mailx
is specified and seems to be a mandatory utility. However 
the wordings only requires local delivery. I don't think that a 
running MTA is needed by the specification.

In the LSB, mailx and sendmail are required, but it seems to me
that only the sendmail comand line interface is needed. Even local
delivery is not mandated (though I may be missing something):
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/baselib-sendmail-1.html

However the fact that it is a mandatory posix utility doesn't
necessarily means that it should be on every install. For example
bc is mandatory. It should be brought in by the lsb virtual
package, however, and maybe a virtual posix package should exist.

--
Pat



From jonathan.underwood at gmail.com  Thu Dec 18 01:18:13 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 18 Dec 2008 01:18:13 +0000
Subject: [Fedora Update] [testing] shorewall-4.0.15-1.fc8
In-Reply-To: <1229562480.6191.96.camel@localhost.localdomain>
References: <20081218004518.B7B67208DF8@bastion.fedora.phx.redhat.com>
	<1229562480.6191.96.camel@localhost.localdomain>
Message-ID: <645d17210812171718qa3137aenfd6e2b3a0a5ed549@mail.gmail.com>

2008/12/18 Jesse Keating <jkeating at redhat.com>:
> On Thu, 2008-12-18 at 00:45 +0000, updates at fedoraproject.org wrote:
>> jgu has requested the pushing of the following update to testing:
>>
>> ================================================================================
>>      shorewall-4.0.15-1.fc8
>> ================================================================================
>>     Release: Fedora 8
>>      Status: pending
>>        Type: bugfix
>>       Karma: 0
>>     Request: testing
>>       Notes: New upstream bugfix version.
>>   Submitter: jgu
>>   Submitted: 2008-12-18 00:45:18
>>    Comments: jgu - 2008-12-18 00:45:18 (karma 0)
>>              This update has been submitted for testing
>>
>>   http://admin.fedoraproject.org/updates/shorewall-4.0.15-1.fc8
>>
>
> What is the purpose of this version bump (4.0.14 -> 4.0.15) in F8, which
> only has a few weeks of lifespan yet.  There is no information in the
> update request that would help users understand why they should consume
> this update.  Please fill in some details, and consider whether the
> update is suitable for Fedora 8.
> http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users
>

It's a minor version bump with bug fixes only. This update is about
enhancing stability - the 4.0.x release tree of shorewall is in a bug
fix mode. FWIW I had planned to leave it in updates-testing for
eternity, as I've seen other packages do near a release EOL.


> --
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jkeating at redhat.com  Thu Dec 18 01:32:15 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 17:32:15 -0800
Subject: [Fedora Update] [testing] shorewall-4.0.15-1.fc8
In-Reply-To: <645d17210812171718qa3137aenfd6e2b3a0a5ed549@mail.gmail.com>
References: <20081218004518.B7B67208DF8@bastion.fedora.phx.redhat.com>
	<1229562480.6191.96.camel@localhost.localdomain>
	<645d17210812171718qa3137aenfd6e2b3a0a5ed549@mail.gmail.com>
Message-ID: <1229563935.6191.97.camel@localhost.localdomain>

On Thu, 2008-12-18 at 01:18 +0000, Jonathan Underwood wrote:
> It's a minor version bump with bug fixes only. This update is about
> enhancing stability - the 4.0.x release tree of shorewall is in a bug
> fix mode. FWIW I had planned to leave it in updates-testing for
> eternity, as I've seen other packages do near a release EOL.

This would be great information to put in the bodhi notes, so that users
consuming this update have this information. *hint*

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/4e2767e7/attachment.sig>

From wart at kobold.org  Thu Dec 18 01:39:05 2008
From: wart at kobold.org (Michael Thomas)
Date: Wed, 17 Dec 2008 17:39:05 -0800
Subject: tclxml warning:  rename and repackage coming to F11
Message-ID: <4949A9B9.1050403@kobold.org>

Upstream has reorganized the code for tclxml, tcldom, and tclxslt so
that all three packages are now contained in the same source tarball.
The code itself has been reorganized as well, so that it's no longer
possible to ship tcldom and tclxml separately as we do now.

To fix, I'm merging these two packages for F11 (which will now include
tclxslt, which wasn't part of Fedora before).  At the same time, I'm
renaming the base package to 'tcl-tclxml' to conform with the Tcl
packaging guidelines.  Since this involves much change to the spec file,
I've requested a new package review[1].  The existing tclxml and tcldom
packages will be EOL'd once this new package has been approved.

Anyone who depends on tclxml or tcldom should be aware of this change.
F10 and earlier will not be updated to this new upstream release.

--Wart
[1]https://bugzilla.redhat.com/show_bug.cgi?id=476926



From jonathan.underwood at gmail.com  Thu Dec 18 01:42:30 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 18 Dec 2008 01:42:30 +0000
Subject: [Fedora Update] [testing] shorewall-4.0.15-1.fc8
In-Reply-To: <1229563935.6191.97.camel@localhost.localdomain>
References: <20081218004518.B7B67208DF8@bastion.fedora.phx.redhat.com>
	<1229562480.6191.96.camel@localhost.localdomain>
	<645d17210812171718qa3137aenfd6e2b3a0a5ed549@mail.gmail.com>
	<1229563935.6191.97.camel@localhost.localdomain>
Message-ID: <645d17210812171742g6cc39b98red2fff60c8a3a03f@mail.gmail.com>

2008/12/18 Jesse Keating <jkeating at redhat.com>:
> On Thu, 2008-12-18 at 01:18 +0000, Jonathan Underwood wrote:
>> It's a minor version bump with bug fixes only. This update is about
>> enhancing stability - the 4.0.x release tree of shorewall is in a bug
>> fix mode. FWIW I had planned to leave it in updates-testing for
>> eternity, as I've seen other packages do near a release EOL.
>
> This would be great information to put in the bodhi notes, so that users
> consuming this update have this information. *hint*
>

Well they did already say "New upstream bugfix version". A bit
austere, granted :). I've added some (small) detail about the bugs
actually fixed from upstream release notes.

[As an aside I am the first to admit I am guilty of not paying enough
attention to filling enough detail in the Advisory Notes for updated
packages... but largely because the hover-over for the bodhi form
refers to the Advisory Notes as "Some optional details about this
update...", so I'd never really considered the Advisory Notes as being
mandatory (because of the word "optional").]

J.



From orcanbahri at yahoo.com  Thu Dec 18 01:58:08 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Wed, 17 Dec 2008 17:58:08 -0800 (PST)
Subject: [Fedora Update] [testing] shorewall-4.0.15-1.fc8
In-Reply-To: <1229562480.6191.96.camel@localhost.localdomain>
Message-ID: <6327.61722.qm@web32804.mail.mud.yahoo.com>

Jesse Keating  wrote:
> updates at fedoraproject.org wrote:
> > jgu has requested the pushing of the following update
> to testing:
> > 
> >
> ================================================================================
> >      shorewall-4.0.15-1.fc8
> >
> ================================================================================
> >     Release: Fedora 8
> >      Status: pending
> >        Type: bugfix
> >       Karma: 0
> >     Request: testing
> >       Notes: New upstream bugfix version.
> >   Submitter: jgu
> >   Submitted: 2008-12-18 00:45:18
> >    Comments: jgu - 2008-12-18 00:45:18 (karma 0)
> >              This update has been submitted for
> testing
> > 
> >  
> http://admin.fedoraproject.org/updates/shorewall-4.0.15-1.fc8
> > 
> 
> What is the purpose of this version bump (4.0.14 ->
> 4.0.15) in F8, which
> only has a few weeks of lifespan yet.  There is no
> information in the
> update request that would help users understand why they
> should consume
> this update.  Please fill in some details, and consider
> whether the
> update is suitable for Fedora 8.
> http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users
> 
> -- 
> Jesse Keating

I was wondering. Why do I get identical copies of this email for 3 days in a row, nothing added, nothing removed, purely identical?

Is it my fault?

-Orcan


      



From justin.conover at gmail.com  Thu Dec 18 03:04:32 2008
From: justin.conover at gmail.com (Justin Conover)
Date: Wed, 17 Dec 2008 21:04:32 -0600
Subject: patching fedora kernel for eeepc
Message-ID: <a36b7e2a0812171904x60cf5716oaebf8d676c725e13@mail.gmail.com>

This might be a stupid question.... but....

How to I use these in a patch?

http://lkml.org/lkml/2008/11/20/265

http://lkml.org/lkml/2008/11/20/266

http://lkml.org/lkml/2008/11/20/267

I understand this one because its in a patch file, but these are just
e-mails.

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-staging-2.6.28-rc8.patch

I have an asus eepc 1000 with a custom kernel from fedora forums and wanted
to build my own and tinker a bit more.  Currently I'm at a 18s boot time (to
gdm)! o_0

Looking at gregkh's patch I assume the other three would start at the diff
line.  Is that correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/dc4a1a7e/attachment.htm>

From justin.conover at gmail.com  Thu Dec 18 03:06:19 2008
From: justin.conover at gmail.com (Justin Conover)
Date: Wed, 17 Dec 2008 21:06:19 -0600
Subject: patching fedora kernel for eeepc
In-Reply-To: <a36b7e2a0812171904x60cf5716oaebf8d676c725e13@mail.gmail.com>
References: <a36b7e2a0812171904x60cf5716oaebf8d676c725e13@mail.gmail.com>
Message-ID: <a36b7e2a0812171906x62b803dfse46f8604491595a0@mail.gmail.com>

On Wed, Dec 17, 2008 at 9:04 PM, Justin Conover <justin.conover at gmail.com>wrote:

> This might be a stupid question.... but....
>
> How to I use these in a patch?
>
> http://lkml.org/lkml/2008/11/20/265
>
> http://lkml.org/lkml/2008/11/20/266
>
> http://lkml.org/lkml/2008/11/20/267
>
> I understand this one because its in a patch file, but these are just
> e-mails.
>
>
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-staging-2.6.28-rc8.patch
>
> I have an asus eepc 1000 with a custom kernel from fedora forums and wanted
> to build my own and tinker a bit more.  Currently I'm at a 18s boot time (to
> gdm)! o_0
>
> Looking at gregkh's patch I assume the other three would start at the diff
> line.  Is that correct?
>


I just realized those patches have "[at] redhat [dot] com" on them..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/6e17f383/attachment.htm>

From adamwill at shaw.ca  Thu Dec 18 03:15:50 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Wed, 17 Dec 2008 19:15:50 -0800
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229474301.28858.85.camel@aglarond.local>
References: <gi5svv$jvc$1@ger.gmane.org> <20081215182823.GA28317@localhost>
	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
	<1229467644.5054.132.camel@erebor.bos.redhat.com>
	<494832BE.1050406@behdad.org>
	<1229474301.28858.85.camel@aglarond.local>
Message-ID: <1229570150.24419.591.camel@lenovo.local.net>

On Tue, 2008-12-16 at 19:38 -0500, Jeremy Katz wrote:

> Yes, but that's not everything on your system.  Should we add triggers
> for everything you can possibly run?  :)

Up to a couple of years ago, we attempted to do this in Mandriva; doing
a glibc upgrade would trigger a restart of all services.

We gave up doing this when stuff like dbus and hal started showing up,
and restarting all running services started to seriously screw up your
machine. Now we just do what Fedora does, and pop up a warning that says
"reboot your system".

It would probably be possible to have a robust system which really let
you keep the system running for all kinds of upgrade other than a kernel
upgrade, but it would be a hell of a lot of work, and probably not worth
the return on investment in practical consequences (actual time saved
and lives made better by avoiding reboots). It would certainly be
something it would make sense to do at a level higher than any one
distribution. And it would be one of those things that would *never* be
finished: someone would have to spend a substantial portion of his life
(or lots of somebodies spend a small portion) making sure this kept
working.
-- 
adamw



From adamwill at shaw.ca  Thu Dec 18 03:16:09 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Wed, 17 Dec 2008 19:16:09 -0800
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4948A5FA.3080902@gmail.com>
References: <20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<1229467591.5054.131.camel@erebor.bos.redhat.com>
	<20081217030212.GB19430@srcf.ucam.org>
	<1229483507.6191.24.camel@localhost.localdomain>
	<20081217032112.GQ32016@angus.ind.WPI.EDU> <4948A5FA.3080902@gmail.com>
Message-ID: <1229570169.24419.592.camel@lenovo.local.net>

On Wed, 2008-12-17 at 01:10 -0600, Les Mikesell wrote:

> On a laptop, can't you suspend first, then hibernate only if power drops 
> dangerously low (and while no one is waiting)?

...but what if the user wants to open up and use the system again,
without plugging it in, six hours later?

This is the fundamental problem with hybrid suspend: it has to make a
guess (when to stop suspending and start hibernating), and it can't
always guess right. Practically speaking, some people will always need
to say "go straight to hibernate".
-- 
adamw



From walters at verbum.org  Thu Dec 18 03:19:36 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 17 Dec 2008 22:19:36 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229570150.24419.591.camel@lenovo.local.net>
References: <gi5svv$jvc$1@ger.gmane.org> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
	<1229467644.5054.132.camel@erebor.bos.redhat.com>
	<494832BE.1050406@behdad.org>
	<1229474301.28858.85.camel@aglarond.local>
	<1229570150.24419.591.camel@lenovo.local.net>
Message-ID: <faa16b610812171919rd8f58e2r2902a13b698468d7@mail.gmail.com>

On Wed, Dec 17, 2008 at 10:15 PM, Adam Williamson <adamwill at shaw.ca> wrote:
>
> We gave up doing this when stuff like dbus and hal started showing up,

You restarted the X server?

Right.  It's *never* been the case that one can randomly restart
processes after upgrading.



From adamwill at shaw.ca  Thu Dec 18 03:35:30 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Wed, 17 Dec 2008 19:35:30 -0800
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <faa16b610812171919rd8f58e2r2902a13b698468d7@mail.gmail.com>
References: <gi5svv$jvc$1@ger.gmane.org> <4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<1229464318.2590.23.camel@localhost.localdomain>
	<20081216223006.GC1358034@hiwaay.net>
	<1229467644.5054.132.camel@erebor.bos.redhat.com>
	<494832BE.1050406@behdad.org>
	<1229474301.28858.85.camel@aglarond.local>
	<1229570150.24419.591.camel@lenovo.local.net>
	<faa16b610812171919rd8f58e2r2902a13b698468d7@mail.gmail.com>
Message-ID: <1229571330.24419.594.camel@lenovo.local.net>

On Wed, 2008-12-17 at 22:19 -0500, Colin Walters wrote:
> On Wed, Dec 17, 2008 at 10:15 PM, Adam Williamson <adamwill at shaw.ca> wrote:
> >
> > We gave up doing this when stuff like dbus and hal started showing up,
> 
> You restarted the X server?

Details, Colin, details =) I think it was actually everything in
runlevel 3. So yes, one of the drawbacks was you weren't really
restarting everything anyway.

> Right.  It's *never* been the case that one can randomly restart
> processes after upgrading.

Indeed.
-- 
adamw
-- 
adamw



From jkeating at redhat.com  Thu Dec 18 04:14:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 20:14:35 -0800
Subject: Broken deps from rawhide
Message-ID: <1229573675.6191.98.camel@localhost.localdomain>

Ahem...  Disregard the broken deps mail you may get from today's
rawhide.  Something in our attempted change seems to have produced bunk
repodata, so there is a lot "missing".  We'll be working to fix it up.

Welcome to rawhide (:

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/83728773/attachment.sig>

From jkeating at j2solutions.net  Thu Dec 18 04:16:37 2008
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 17 Dec 2008 20:16:37 -0800
Subject: [Fwd: Broken deps from rawhide]
Message-ID: <1229573797.6191.99.camel@localhost.localdomain>

-------- Forwarded Message --------
From: Jesse Keating <jkeating at redhat.com>
Reply-to: Development discussions related to Fedora
<fedora-devel-list at redhat.com>
To: fedora-devel-list at redhat.com
Subject: Broken deps from rawhide
Date: Wed, 17 Dec 2008 20:14:35 -0800

Ahem...  Disregard the broken deps mail you may get from today's
rawhide.  Something in our attempted change seems to have produced bunk
repodata, so there is a lot "missing".  We'll be working to fix it up.

Welcome to rawhide (:

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/f9aed2b5/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From loupgaroublond at gmail.com  Thu Dec 18 04:19:19 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Wed, 17 Dec 2008 23:19:19 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <20081217204320.GG1223969@hiwaay.net>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<20081217204320.GG1223969@hiwaay.net>
Message-ID: <7f692fec0812172019h38c90153gf8893f790121de84@mail.gmail.com>

2008/12/17 Chris Adams <cmadams at hiwaay.net>:
> Once upon a time, Yaakov Nemoy <loupgaroublond at gmail.com> said:
>> Better question is, why do you need ext4 on /boot?
>
> If all the rest of your partitions are ext4, why would you want to load
> additional FS module(s) (ext2 or ext3+jbd) just for one filesystem?

How trimmed down does your kernel need to be? Practically speaking of course.

-Yaakov



From jkeating at redhat.com  Thu Dec 18 04:25:57 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 20:25:57 -0800
Subject: [Fedora Update] [testing] shorewall-4.0.15-1.fc8
In-Reply-To: <645d17210812171742g6cc39b98red2fff60c8a3a03f@mail.gmail.com>
References: <20081218004518.B7B67208DF8@bastion.fedora.phx.redhat.com>
	<1229562480.6191.96.camel@localhost.localdomain>
	<645d17210812171718qa3137aenfd6e2b3a0a5ed549@mail.gmail.com>
	<1229563935.6191.97.camel@localhost.localdomain>
	<645d17210812171742g6cc39b98red2fff60c8a3a03f@mail.gmail.com>
Message-ID: <1229574357.6191.101.camel@localhost.localdomain>

On Thu, 2008-12-18 at 01:42 +0000, Jonathan Underwood wrote:
> [As an aside I am the first to admit I am guilty of not paying enough
> attention to filling enough detail in the Advisory Notes for updated
> packages... but largely because the hover-over for the bodhi form
> refers to the Advisory Notes as "Some optional details about this
> update...", so I'd never really considered the Advisory Notes as being
> mandatory (because of the word "optional").]

That's a good point, that's a place where we could put a blurb about the
notes being displayed by the likes of PackageKit.  Thanks for the
feedback.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/263d0713/attachment.sig>

From jkeating at redhat.com  Thu Dec 18 04:31:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Dec 2008 20:31:07 -0800
Subject: [Fedora Update] [testing] shorewall-4.0.15-1.fc8
In-Reply-To: <6327.61722.qm@web32804.mail.mud.yahoo.com>
References: <6327.61722.qm@web32804.mail.mud.yahoo.com>
Message-ID: <1229574667.6191.102.camel@localhost.localdomain>

On Wed, 2008-12-17 at 17:58 -0800, Orcan Ogetbil wrote:
> I was wondering. Why do I get identical copies of this email for 3
> days in a row, nothing added, nothing removed, purely identical?
> 
> Is it my fault?

Which mail?  The mail I sent just today, so it would be rather difficult
to get copies for 2 days past.  In fact, the original mail which I
replied to was generated today, so also rather hard to get copies of
prior to today.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081217/0e04f153/attachment.sig>

From orcanbahri at yahoo.com  Thu Dec 18 04:37:28 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Wed, 17 Dec 2008 20:37:28 -0800 (PST)
Subject: [Fedora Update] [testing] shorewall-4.0.15-1.fc8
In-Reply-To: <1229574667.6191.102.camel@localhost.localdomain>
Message-ID: <586041.25072.qm@web32808.mail.mud.yahoo.com>

--- On Wed, 12/17/08, Jesse Keating wrote:
> On Wed, 2008-12-17 at 17:58 -0800, Orcan Ogetbil wrote:
> > I was wondering. Why do I get identical copies of this
> email for 3
> > days in a row, nothing added, nothing removed, purely
> identical?
> > 
> > Is it my fault?
> 
> Which mail?  

The one I just quoted

> The mail I sent just today, so it would be
> rather difficult
> to get copies for 2 days past.  In fact, the original mail
> which I
> replied to was generated today, so also rather hard to get
> copies of
> prior to today.
> 

Really? Maybe I should reconsider believing in deja-vu.
Sorry about the spam.

-Orcan


      



From nathanael at gnat.ca  Thu Dec 18 05:18:22 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Wed, 17 Dec 2008 22:18:22 -0700
Subject: Memory/filesystem corruption
In-Reply-To: <d551e0e20812161604s389a2544u935204fe143453d3@mail.gmail.com>
References: <4947EEDF.9000801@niemueller.de>
	<d551e0e20812161604s389a2544u935204fe143453d3@mail.gmail.com>
Message-ID: <4949DD1E.7070504@gnat.ca>

Camilo Mesias wrote:
> I've just added a pretty vague set of symptoms to the bug. It does
> involve disk problems and an ATI graphics card though. If there's a
> fix for the current problems it would be very welcome...
> 
> I'm seeing messages like these:
> 
> Uhhuh. NMI received for unknown reason b0 on CPU 0.
> You have some hardware problem, likely on the PCI bus.
> Dazed and confused, but trying to continue
> 
> Also, the characters and repeating graphics on Firefox are getting
> corruption. I'm still wondering if the graphics card is
> overheating/failing or something.
> 

Could you do me a favor and do a pastebin of the output of alt-sysrq-t 
or 'echo t > /proc/sysrq-trigger' (output in /var/log/messages).

I've had some similar issues on a number of machines with different 
hardware (and fedora versions) but the only common point was corruption 
in a section of the output of the above commands.

-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From camilo at mesias.co.uk  Thu Dec 18 07:03:36 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Thu, 18 Dec 2008 07:03:36 +0000
Subject: Memory/filesystem corruption
In-Reply-To: <4949DD1E.7070504@gnat.ca>
References: <4947EEDF.9000801@niemueller.de>
	<d551e0e20812161604s389a2544u935204fe143453d3@mail.gmail.com>
	<4949DD1E.7070504@gnat.ca>
Message-ID: <d551e0e20812172303v355f681dx7824c5172285ce54@mail.gmail.com>

Hi,

2008/12/18 Nathanael D. Noblet <nathanael at gnat.ca>:
> Camilo Mesias wrote:
>>
[...]
>> I'm seeing messages like these:
>>
>> Uhhuh. NMI received for unknown reason b0 on CPU 0.
>> You have some hardware problem, likely on the PCI bus.
>> Dazed and confused, but trying to continue
>>
>
> Could you do me a favor and do a pastebin of the output of alt-sysrq-t or
> 'echo t > /proc/sysrq-trigger' (output in /var/log/messages).
>
> I've had some similar issues on a number of machines with different hardware
> (and fedora versions) but the only common point was corruption in a section
> of the output of the above commands.

http://pastebin.com/m1ff96ea5

Any use?



From loupgaroublond at gmail.com  Thu Dec 18 07:19:18 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Thu, 18 Dec 2008 02:19:18 -0500
Subject: Forcing Gnome to start sans metacity
Message-ID: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>

Hey List,

I'm trying to figure out how to put together a window manager package
that will integrate with the new Gnome in Fedora 10. Somehow, all the
window manager handling code in Gnome 2.24 got redone. I can't just
remove metacity and add xmonad to a session anymore. As I can figure
out,

/desktop/gnome/session/required_components/windowmanager

is the right gconf key for changing the window manager, but modifying
this caused no end of problems for xmonad.  Instead, i've set up an
~/.xsession script, that could be made into a normal script that calls
xmonad and then gnome-session.  The problem is that Gnome doesn't know
that xmonad is there, and doesn't know it doesn't actually need a
window manager anymore, let alone metacity.

Instead, i discovered that if i change

/desktop/gnome/session/required_components_list

from

[windowmanager,panel,filemanager]

to

[panel,filemanager]

then everything works fine.  The problem is, this key is shared
between all window managers that want to load up a new session.  I
can't just create a gconf .schema that will add a new one for a new
'xmonad_session' instead of a 'default_session'.

In short, the new gnome session configuration dialog is alot simpler
and alot less confusing, but it gives us no simple way to give
metacity the boot on a per session basis.  How do i go about doing
this via an RPM?

-Yaakov



From pertusus at free.fr  Thu Dec 18 00:19:32 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Dec 2008 01:19:32 +0100
Subject: leaving fedora
In-Reply-To: <e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
References: <20081216100007.GB3877@free.fr>
	<76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>
	<e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
Message-ID: <20081218001932.GD2361@free.fr>

On Wed, Dec 17, 2008 at 08:05:55AM -0600, Jon Ciesla wrote:
> 
> Do we need to work out a sponsorship transfer?  Not sure what the policy
> is for this sort of thing.

I think that there is not really a need for a policy. In my case
my sponsor is Spot, he is still here, so I'll try to transfer my few
duty as a sponsor to him. But my sponsoree are mostly independent now
(and I don't even remember all of them, what a shame ;-).

Maybe there should only be a person who may be a sponsor for 
the orphaned maintainers who really need a sponsor.

--
Pat



From dan at danny.cz  Thu Dec 18 08:07:51 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 18 Dec 2008 09:07:51 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <20081217210617.499559ea.mschwendt@gmail.com>
References: <20081217210617.499559ea.mschwendt@gmail.com>
Message-ID: <1229587671.3612.52.camel@eagle.danny.cz>

Michael Schwendt p??e v St 17. 12. 2008 v 21:06 +0100:
> [Bcc to wxGTK and audacity owners]
> 
> > DEBUG util.py:250:  No Package Found for wxGTK2-devel
> 
> Has this rename been announced?
> To me it came as a surprise. :(
> 

The rename must have been done years ago or better the support for GTK
1.x was dropped and only GTK 2 version of wxGTK with the required
compatibility Provides was being built since 2006 (FC-4). I was doing a
clean-up of the old things in the spec file and repoquery didn't show
any problems. But unfortunately I see that I was looking for
wxGTK2-devel in Requires in the source rpms, but not for BuildRequires.

> The root.log of a failed build contained this
> 
> DEBUG util.py:250:  /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
> DEBUG util.py:250:  error: %post(bash-3.2-33.fc11.i386) scriptlet failed, exit status 127
> 
> which made me search in the wrong direction before noticing the message
> about not finding wxGTK2-devel.
> 


		Dan




From mmaslano at redhat.com  Thu Dec 18 08:09:14 2008
From: mmaslano at redhat.com (Marcela Maslanova)
Date: Thu, 18 Dec 2008 09:09:14 +0100
Subject: tclxml warning:  rename and repackage coming to F11
In-Reply-To: <4949A9B9.1050403@kobold.org>
References: <4949A9B9.1050403@kobold.org>
Message-ID: <494A052A.2030106@redhat.com>

Michael Thomas wrote:
> Upstream has reorganized the code for tclxml, tcldom, and tclxslt so
> that all three packages are now contained in the same source tarball.
> The code itself has been reorganized as well, so that it's no longer
> possible to ship tcldom and tclxml separately as we do now.
> 
> To fix, I'm merging these two packages for F11 (which will now include
> tclxslt, which wasn't part of Fedora before).  At the same time, I'm
> renaming the base package to 'tcl-tclxml' to conform with the Tcl
> packaging guidelines.  Since this involves much change to the spec file,
> I've requested a new package review[1].  The existing tclxml and tcldom
> packages will be EOL'd once this new package has been approved.
> 
> Anyone who depends on tclxml or tcldom should be aware of this change.
> F10 and earlier will not be updated to this new upstream release.
> 
> --Wart
> [1]https://bugzilla.redhat.com/show_bug.cgi?id=476926
> 
I'm taking the review.

-- 
Marcela Ma?l??ov?
BaseOS team Brno



From arjan at infradead.org  Thu Dec 18 08:44:40 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Thu, 18 Dec 2008 09:44:40 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812172152.30869.ville.skytta@iki.fi>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<20081217085108.6cdc5d21@infradead.org>
	<200812172152.30869.ville.skytta@iki.fi>
Message-ID: <20081218094440.3c13a7f3@infradead.org>

On Wed, 17 Dec 2008 21:52:30 +0200
Ville Skytt? <ville.skytta at iki.fi> wrote:

> On Wednesday 17 December 2008, Arjan van de Ven wrote:
> > On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
> >
> > Seth Vidal <skvidal at fedoraproject.org> wrote:
> > > > Or hibernate?
> > >
> > > At least on my system hibernate takes as much time as a reboot.
> >
> > btw this is a very fundamental property of hibernate. You need to
> > do all disk IO to get the system state to disk. And then at resume,
> > you need to do all disk IO to get the state from disk again. That's
> > twice ;)
> >
> > This is compounded by the property that a hibernate tends to flush
> > at least half the disk cache (it has to, to get space to work in),
> > which you then need to page right back in, so even when you're
> > back, the first minute or two sucks badly.
> >
> > I suspect you will always be able to boot faster than you can
> > hibernate+resume.
> 
> I have very different experience.  For example comparable (from grub
> going away to KDE + my bunch of default apps running and usable)
> numbers just taken from the desktop box in front of which I'm right
> now (AMD64 3200, 2G RAM, SATA, F-9 x86_64 KDE):
> 
> - shutdown: 28 sec
> - fresh boot: 66 sec

see this is the problem; this can be 5 to 10 seconds, and should be.
that's the point of this discussion


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From dan at danny.cz  Thu Dec 18 09:02:39 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 18 Dec 2008 10:02:39 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <1229587671.3612.52.camel@eagle.danny.cz>
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229587671.3612.52.camel@eagle.danny.cz>
Message-ID: <1229590959.3612.57.camel@eagle.danny.cz>

Dan Hor?k p??e v ?t 18. 12. 2008 v 09:07 +0100:
> Michael Schwendt p??e v St 17. 12. 2008 v 21:06 +0100:
> > [Bcc to wxGTK and audacity owners]
> > 
> > > DEBUG util.py:250:  No Package Found for wxGTK2-devel
> > 
> > Has this rename been announced?
> > To me it came as a surprise. :(
> > 
> 
> The rename must have been done years ago or better the support for GTK
> 1.x was dropped and only GTK 2 version of wxGTK with the required
> compatibility Provides was being built since 2006 (FC-4). I was doing a
> clean-up of the old things in the spec file and repoquery didn't show
> any problems. But unfortunately I see that I was looking for
> wxGTK2-devel in Requires in the source rpms, but not for BuildRequires.

I have checked all packages that link with the "base" wxGTK library and
no other package is affected, they all use wxGTK-devel.


		Dan




From bkoz at redhat.com  Thu Dec 18 09:14:35 2008
From: bkoz at redhat.com (Benjamin Kosnik)
Date: Thu, 18 Dec 2008 01:14:35 -0800
Subject: boost rebuild status
Message-ID: <20081218011435.03690d24@balbo.artheist.org>


Rebuilding dependent packages for boost is progressing relatively
smoothly. Here's an update on boost rebuilds for the second half of the
deps list: hopefully Petr will update from the top.

Here's a list of some of the deps with status:

aqsis-0:1.4.1-4.fc10.x86_64
aqsis-core-0:1.4.1-4.fc10.x86_64
asc-0:2.1.0.0-2.fc10.x86_64
barry-0:0.14-4.fc10.x86_64
bmpx-0:0.40.14-7.fc10.x86_64
chess-0:1.0-20.fc10.x86_64
conexus-0:0.5.3-4.fc9.i386
conexus-0:0.5.3-4.fc9.x86_64
deluge-0:1.0.5-1.fc10.x86_64
fuse-encfs-0:1.5-1.fc10.x86_64
glob2-0:0.9.3-1.fc10.x86_64
gnash-0:0.8.4-3.fc10.x86_64
gnash-cygnal-0:0.8.4-3.fc10.x86_64
HippoDraw-python-0:1.21.1-4.fc9.x86_64
hugin-0:0.7.0-1.fc10.x86_64
hugin-base-0:0.7.0-1.fc10.i386
k3d-0:0.6.7.0-7.fc10.i386
kdeedu-math-0:4.1.2-2.fc10.x86_64
linkage-0:0.2.0-3.fc10.i386
mapnik-0:0.5.2-0.7.svn738.fc10.i386
mapnik-python-0:0.5.2-0.7.svn738.fc10.x86_64
mapnik-utils-0:0.5.2-0.7.svn738.fc10.x86_64
Miro-0:1.2.7-2.fc10.x86_64

mkvtoolnix-0:2.4.0-1.fc10.x86_64
  bump Release, rebuilt.

openvrml-0:0.17.10-1.0.fc10.i386
openvrml-xembed-0:0.17.10-1.0.fc10.x86_64
  bump Release, rebuild in progress:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1005969

pingus-0:0.7.2-3.fc9.x86_64
  bump Release, rebuilt.

player-0:2.1.1-5.fc10.x86_64
player-examples-0:2.1.1-5.fc10.x86_64
  bump Release, rebuild fails:
  
  compile error, temporary build situation?
  /usr/include/linux/serial.h:164: error: '__u32' does not name a type
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1005939

pyexiv2-0:0.1.2-4.fc10.x86_64
python-tag-0:0.94.1-1.fc10.x86_64
qmf-0:0.3.705289-1.fc10.x86_64

qpidc-0:0.3.705289-1.fc10.i386
qpidc-perftest-0:0.3.705289-1.fc10.x86_64
qpidc-rdma-0:0.3.705289-1.fc10.i386
qpidd-0:0.3.722557-1.fc10.x86_64
qpidd-cluster-0:0.3.705289-1.fc10.x86_64
qpidd-rdma-0:0.3.705289-1.fc10.x86_64
  bump Release, rebuilt?

QuantLib-test-0:0.9.0-5.fc10.x86_64
  bump Release, rebuilt.
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1005892

rb_libtorrent-0:0.13.1-3.fc10.x86_64
rb_libtorrent-python-0:0.13.1-3.fc10.x86_64
  bump Release, failed:
  configuration error with boost system library
  http://koji.fedoraproject.org/koji/getfile?taskID=1005216&name=build.log

  add --with-boost-system=mt to %configure, still compile fail:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1006006

In file included from disk_io_thread.cpp:35:
../include/libtorrent/disk_io_thread.hpp:135: error: 'condition' in namespace 'boost' does not name a type
disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::join()':
disk_io_thread.cpp:97: error: 'm_signal' was not declared in this scope
disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::stop(boost::intrusive_ptr<libtorrent::piece_manager>)':
disk_io_thread.cpp:124: error: 'm_signal' was not declared in this scope
disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::add_job(const libtorrent::disk_io_job&, const boost::function<void ()(int, const libtorrent::disk_io_job&)>&)':
disk_io_thread.cpp:209: error: 'm_signal' was not declared in this scope
disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::operator()()':
disk_io_thread.cpp:243: error: 'm_signal' was not declared in this scope


rcssbase-0:12.1.2-1.fc10.x86_64
rcsslogplayer-0:12.1.2-1.fc10.i386
rcssserver-0:12.1.4-1.fc10.i386
rcssserver3d-0:0.6-5.fc10.i386
  bump Release, rebuilt?

referencer-0:1.1.4-1.fc10.x86_64
  bump Release, rebuilt

smc-0:1.5-3.fc10.x86_64
  no devel package?

source-highlight-0:2.10-1.fc10.x86_64
  bump Release, rebuilt

twinkle-0:1.3.2-1.fc10.x86_64
  bump Release, rebuilt

vegastrike-0:0.5.0-5.fc10.x86_64
  bump Release, rebuild fails:
  http://koji.fedoraproject.org/koji/getfile?taskID=1005464&name=build.log

  boost_python compile error
/usr/include/boost/python/detail/caller.hpp:102: error: 'struct boost::python::detail::caller_arity<1u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<Vector, int>]::result_converter' has no member named 'get_pytype'


wesnoth-0:1.4.5-1.fc10.x86_64
wesnoth-server-0:1.4.5-1.fc10.x86_64
wesnoth-tools-0:1.4.5-1.fc10.x86_64
  bump Release, rebuilt

wp_tray-0:0.5.3-8.fc10.x86_64
  bump Release, rebuilt

xmms2-0:0.5-2.fc10.x86_64
  bump Release, rebuild fails:

  configure fail, ruby/python deps or temporary hostname?
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1005516

-benjamin



From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Dec 18 09:28:30 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 18 Dec 2008 18:28:30 +0900
Subject: boost rebuild status
In-Reply-To: <20081218011435.03690d24@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
Message-ID: <494A17BE.10808@ioa.s.u-tokyo.ac.jp>

Benjamin Kosnik wrote, at 12/18/2008 06:14 PM +9:00:
>
> player-0:2.1.1-5.fc10.x86_64
> player-examples-0:2.1.1-5.fc10.x86_64
>   bump Release, rebuild fails:
>   
>   compile error, temporary build situation?
>   /usr/include/linux/serial.h:164: error: '__u32' does not name a type
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=1005939

This is:
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01826.html

> xmms2-0:0.5-2.fc10.x86_64
>   bump Release, rebuild fails:
> 
>   configure fail, ruby/python deps or temporary hostname?
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=1005516

Would you retry after the following task gets complete?
http://koji.fedoraproject.org/koji/buildinfo?buildID=75345
(and now this is complete)

> 
> -benjamin
> 

Mamoru



From wolfy at nobugconsulting.ro  Thu Dec 18 09:11:55 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Thu, 18 Dec 2008 11:11:55 +0200
Subject: leaving fedora
In-Reply-To: <20081218001932.GD2361@free.fr>
References: <20081216100007.GB3877@free.fr>	<76e72f800812170555h26a17c8dxb3c2296b7c43a0e5@mail.gmail.com>	<e1a99d47cff28c71a2aa110142cd0883.squirrel@mail.jcomserv.net>
	<20081218001932.GD2361@free.fr>
Message-ID: <494A13DB.6030307@nobugconsulting.ro>

Patrice Dumas wrote:
> On Wed, Dec 17, 2008 at 08:05:55AM -0600, Jon Ciesla wrote:
>   
>> Do we need to work out a sponsorship transfer?  Not sure what the policy
>> is for this sort of thing.
>>     
>
> I think that there is not really a need for a policy. In my case
> my sponsor is Spot, he is still here, so I'll try to transfer my few
> duty as a sponsor to him. But my sponsoree are mostly independent now
> (and I don't even remember all of them, what a shame ;-).
>
> Maybe there should only be a person who may be a sponsor for 
> the orphaned maintainers who really need a sponsor.
>   
Or they could simply ask for help when needed [as I did a couple of 
times -- and I still do, to be honest] as I am pretty sure that anyone 
with the proper knowledge would assist.



From dan at danny.cz  Thu Dec 18 09:58:57 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 18 Dec 2008 10:58:57 +0100
Subject: search for BuildRequires using repoquery
Message-ID: <1229594337.3612.68.camel@eagle.danny.cz>

Hi,

the manpage for repoquery says that is is possible to search for
BuildRequires using this command:

repoquery --archlist=src --whatrequires gail-devel

But it gives me a traceback. Is it still supposed to work? There was
also a thread on yum-devel about searching BuildRequires -
http://lists.baseurl.org/pipermail/yum-devel/2006-May/002187.html


		Dan




From kwizart at gmail.com  Thu Dec 18 10:03:44 2008
From: kwizart at gmail.com (Nicolas Chauvet)
Date: Thu, 18 Dec 2008 11:03:44 +0100
Subject: boost rebuild status
In-Reply-To: <20081218011435.03690d24@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
Message-ID: <e1760170812180203q601c2906ldf175576a97150a7@mail.gmail.com>

2008/12/18 Benjamin Kosnik <bkoz at redhat.com>:
>
> Rebuilding dependent packages for boost is progressing relatively
> smoothly. Here's an update on boost rebuilds for the second half of the
> deps list: hopefully Petr will update from the top.
>
> Here's a list of some of the deps with status:
>
> aqsis-0:1.4.1-4.fc10.x86_64
http://koji.fedoraproject.org/koji/buildinfo?buildID=75343
done



From dan at danny.cz  Thu Dec 18 10:32:13 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 18 Dec 2008 11:32:13 +0100
Subject: performance test by Phoronix
Message-ID: <1229596333.3612.78.camel@eagle.danny.cz>

Did anybody see the latest distro performance test made by Phoronix -
http://www.phoronix.com/scan.php?page=article&item=intel_atom_four&num=1 ?

Looks like F-10 was loosing in gzip compression, I/O write performance
and 2 of 3 GtkPerf tests.


		Dan




From mhlavink at redhat.com  Thu Dec 18 10:34:17 2008
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Thu, 18 Dec 2008 11:34:17 +0100
Subject: RPATH vs. libtool 2.2
Message-ID: <494A2729.3090109@redhat.com>

Hi,

I've just tried to fix some bug in rawhide, but I've ended up with 
libtool/rpath error (again).

without autoreconf OR with autoreconf -f -i -v
 > error: ... contains a standard rpath '/usr/lib64' in [/usr/lib64]

with just autoreconf
 > ../libtool: line 763: X--tag=CC: command not found

In F-10 autoreconf was working fine, but in rawhide we have now new 
libtool 2.2 and rpath patch was removed.

I've heard some rumours that it's not required with this new shiny 
libtool 2.2 and everything (rpaths) should just work. So my question is: 
Am I missing something? Is there some parameter for configure (or 
something) required?

I was searching through rawhide reports and packages (commits) 
containing rpath/libtool in changelogs. I've found people are using 
chrpath, sed ..DIE_RPATH_DIE (from 
wiki/Packaging/Guidelines#Beware_of_Rpath), or patches for configure* 
and libtool.

So... what's the status of libtool 2.2? Should rpaths really just work? 
If there is some command line arguments required or something, it should 
be probably written on wiki 
(http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath).

Cheers,

Michal



From kevin.kofler at chello.at  Thu Dec 18 10:52:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Dec 2008 11:52:44 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229587671.3612.52.camel@eagle.danny.cz>
	<1229590959.3612.57.camel@eagle.danny.cz>
Message-ID: <gida1s$ap3$1@ger.gmane.org>

Dan Hor?k wrote:
> I have checked all packages that link with the "base" wxGTK library and
> no other package is affected, they all use wxGTK-devel.

I think we should have some guideline that such versioned Provides should be
kept indefinitely and packages should use them where available. You'll have
to readd them when there will be a wxGTK 3 anyway!

For example, in KDE SIG we're telling folks to keep using qt4-devel and
kdelibs4-devel and we have no plans to drop those virtual Provides.

        Kevin Kofler



From mschwendt at gmail.com  Thu Dec 18 11:01:28 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 18 Dec 2008 11:01:28 -0000
Subject: Broken dependencies in Fedora 8 - 2008-12-18
Message-ID: <20081218110128.7713.51425@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by src.rpm name):

    callweaver
    gtkmozembedmm
    idm-console-framework
    ipa
    joda-time
    libhugetlbfs
    mediawiki-HNP
    mediawiki-imagemap
    mediawiki-openid
    mediawiki-ParserFunctions
    mediawiki-SpecialInterwiki
    mediawiki-StubManager
    nxt_python
    perl-Test-AutoBuild
    syck


Summary of broken packages (by primary owner):

    Axel.Thimm AT ATrpms net
        mediawiki-openid

    berrange AT redhat com
        perl-Test-AutoBuild

    dwmw2 AT infradead org
        callweaver

    ebmunson AT us.ibm com
        libhugetlbfs                    (1 co-owner)

    ianweller AT gmail com
        mediawiki-HNP
        mediawiki-ParserFunctions
        mediawiki-StubManager

    ismael AT olea org
        mediawiki-imagemap              (1 co-owner)

    jesusfreak91 AT gmail com
        nxt_python

    karlthered AT gmail com
        gtkmozembedmm

    konrad AT tylerc org
        joda-time

    nigjones AT redhat com
        mediawiki-SpecialInterwiki

    oliver AT linux-kernel at
        syck

    rcritten AT redhat com
        ipa                             (2 co-owners)

    rmeggins AT redhat com
        idm-console-framework           (2 co-owners)


======================================================================
Broken packages in fedora-8-i386:

    callweaver-zaptel-1.2-0.3.rc4.20070822.i386  requires  libpri.so.1.0
    libhugetlbfs-test-1.1-4.fc8.i386  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.i386  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-ppc:

    callweaver-zaptel-1.2-0.3.rc4.20070822.ppc  requires  libpri.so.1.0
    libhugetlbfs-test-1.1-4.fc8.ppc  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.ppc  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-ppc64:

    callweaver-zaptel-1.2-0.3.rc4.20070822.ppc64  requires  libpri.so.1.0()(64bit)
    libhugetlbfs-test-1.1-4.fc8.ppc64  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.ppc64  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-x86_64:

    callweaver-zaptel-1.2-0.3.rc4.20070822.x86_64  requires  libpri.so.1.0()(64bit)
    libhugetlbfs-test-1.1-4.fc8.x86_64  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.x86_64  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-updates-8-i386:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.i386  requires  gecko-libs = 0:1.8.1.17
    ipa-radius-server-1.2.1-0.fc8.i386  requires  freeradius-ldap
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb


======================================================================
Broken packages in fedora-updates-8-ppc:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc  requires  gecko-libs = 0:1.8.1.17
    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc64  requires  gecko-libs = 0:1.8.1.17
    idm-console-framework-1.1.2-1.fc8.noarch  requires  java > 0:1.5.0
    ipa-radius-server-1.2.1-0.fc8.ppc  requires  freeradius-ldap
    joda-time-1.5.2-7.tzdata2008d.fc8.noarch  requires  java > 0:1.5.0
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb


======================================================================
Broken packages in fedora-updates-8-ppc64:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc64  requires  gecko-libs = 0:1.8.1.17
    idm-console-framework-1.1.2-1.fc8.noarch  requires  java > 0:1.5.0
    ipa-radius-server-1.2.1-0.fc8.ppc64  requires  freeradius-ldap
    joda-time-1.5.2-7.tzdata2008d.fc8.noarch  requires  java > 0:1.5.0
    mediawiki-HNP-1.1.2-1.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    mediawiki-StubManager-1.2.0-1.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-imagemap-0-0.1.r37906.fc8.noarch  requires  mediawiki >= 0:1.13
    mediawiki-openid-0.8.2-7.0.1.noarch  requires  mediawiki
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch  requires  darcs >= 0:1.0.0


======================================================================
Broken packages in fedora-updates-8-x86_64:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.i386  requires  gecko-libs = 0:1.8.1.17
    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.x86_64  requires  gecko-libs = 0:1.8.1.17
    ipa-radius-server-1.2.1-0.fc8.x86_64  requires  freeradius-ldap
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb



From mschwendt at gmail.com  Thu Dec 18 11:03:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 18 Dec 2008 11:03:33 -0000
Subject: Broken dependencies in Fedora 9 - 2008-12-18
Message-ID: <20081218110333.7801.81268@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by src.rpm name):

    aasaver
    audacity
    cyphesis
    gyachi
    kadu
    kbiof
    libhugetlbfs
    livecd-tools
    mediawiki-SpecialInterwiki
    openvas-libraries
    paraview
    perl-Test-AutoBuild
    pigment-python
    rubberband
    scim-bridge
    sear
    sonic-visualiser
    syck


Summary of broken packages (by primary owner):

    berrange AT redhat com
        perl-Test-AutoBuild

    ebmunson AT us.ibm com
        libhugetlbfs                    (1 co-owner)

    extras-orphan AT fedoraproject org
        aasaver
        kbiof

    gemi AT bluewin ch
        audacity                        (2 co-owners)

    huzaifas AT redhat com
        openvas-libraries

    katzj AT redhat com
        livecd-tools                    (2 co-owners)

    matthias AT rpmforge net
        pigment-python

    michel.sylvan AT gmail com
        rubberband
        sonic-visualiser

    mr.ecik AT gmail com
        kadu

    nigjones AT redhat com
        mediawiki-SpecialInterwiki

    oliver AT linux-kernel at
        syck

    orion AT cora.nwra com
        paraview                        (1 co-owner)

    phuang AT redhat com
        scim-bridge                     (2 co-owners)

    sundaram AT redhat com
        gyachi                          (1 co-owner)

    wart AT kobold org
        cyphesis                        (1 co-owner)
        sear


======================================================================
Broken packages in fedora-9-i386:

    aasaver-0.3.2-3.fc9.i386  requires  libkscreensaver.so.4
    cyphesis-selinux-0.5.15-6.fc9.i386  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.i386  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.i386  requires  gyachi = 0:1.1.0-7.fc9
    kadu-agent-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-alsa_sound-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.i386  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-antistring-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.i386  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-cenzor-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-esd_sound-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-falf_mediaplayer-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-mx610_notify-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-osdhints_notify-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-screenshot-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-spellchecker-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-water_notify-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-weather-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.i386  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.i386  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kbiof-0.3-3.fc9.i386  requires  libkscreensaver.so.4
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-gtk-0.3.so.4
    rubberband-1.0.1-1.fc9.i386  requires  libvamp-sdk.so.1.1.0
    sear-0.6.3-10.fc9.i386  requires  libmercator-0.2.so.4
    sonic-visualiser-1.2-1.fc9.i386  requires  libvamp-hostsdk.so.2.0.0
    syck-php-0.61-4.3.fc9.i386  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc:

    aasaver-0.3.2-3.fc9.ppc  requires  libkscreensaver.so.4
    cyphesis-selinux-0.5.15-6.fc9.ppc  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.ppc  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.ppc  requires  gyachi = 0:1.1.0-7.fc9
    kadu-agent-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-alsa_sound-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-antistring-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-cenzor-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-esd_sound-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-falf_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-mx610_notify-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-osdhints_notify-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-screenshot-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-spellchecker-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-water_notify-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-weather-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.ppc  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kbiof-0.3-3.fc9.ppc  requires  libkscreensaver.so.4
    libhugetlbfs-test-1.1-6.fc9.ppc  requires  libhugetlbfs = 0:1.1-6.fc9
    paraview-3.2.1-6.fc9.ppc64  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.ppc64  requires  paraview-data = 0:3.2.1-6.fc9
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-gtk-0.3.so.4
    rubberband-1.0.1-1.fc9.ppc  requires  libvamp-sdk.so.1.1.0
    rubberband-1.0.1-1.fc9.ppc64  requires  libvamp-sdk.so.1.1.0()(64bit)
    scim-bridge-qt-0.4.15-5.fc9.ppc64  requires  scim-bridge = 0:0.4.15-5.fc9
    sear-0.6.3-10.fc9.ppc  requires  libmercator-0.2.so.4
    sonic-visualiser-1.2-1.fc9.ppc  requires  libvamp-hostsdk.so.2.0.0
    syck-php-0.61-4.3.fc9.ppc  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc64:

    aasaver-0.3.2-3.fc9.ppc64  requires  libkscreensaver.so.4()(64bit)
    cyphesis-selinux-0.5.15-6.fc9.ppc64  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.ppc64  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.ppc64  requires  gyachi = 0:1.1.0-7.fc9
    kadu-agent-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-alsa_sound-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-antistring-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-cenzor-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-esd_sound-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-falf_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-mx610_notify-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-osdhints_notify-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-screenshot-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-spellchecker-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-water_notify-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-weather-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.ppc64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kbiof-0.3-3.fc9.ppc64  requires  libkscreensaver.so.4()(64bit)
    libhugetlbfs-test-1.1-6.fc9.ppc64  requires  libhugetlbfs = 0:1.1-6.fc9
    perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch  requires  darcs >= 0:1.0.0
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-0.3.so.4()(64bit)
    rubberband-1.0.1-1.fc9.ppc64  requires  libvamp-sdk.so.1.1.0()(64bit)
    sear-0.6.3-10.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    sonic-visualiser-1.2-1.fc9.ppc64  requires  libvamp-hostsdk.so.2.0.0()(64bit)
    syck-php-0.61-4.3.fc9.ppc64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-x86_64:

    aasaver-0.3.2-3.fc9.x86_64  requires  libkscreensaver.so.4()(64bit)
    cyphesis-selinux-0.5.15-6.fc9.x86_64  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.x86_64  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.x86_64  requires  gyachi = 0:1.1.0-7.fc9
    kadu-agent-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-alsa_sound-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-amarok_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-antistring-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-audacious_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kadu-cenzor-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-esd_sound-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-falf_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-mx610_notify-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-osdhints_notify-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-screenshot-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-spellchecker-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-water_notify-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-weather-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu = 0:0.6.0-3.fc9
    kadu-xmms_mediaplayer-0.6.0-3.fc9.x86_64  requires  kadu-mediaplayer = 0:0.6.0-3.fc9
    kbiof-0.3-3.fc9.x86_64  requires  libkscreensaver.so.4()(64bit)
    libhugetlbfs-test-1.1-6.fc9.x86_64  requires  libhugetlbfs = 0:1.1-6.fc9
    paraview-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-0.3.so.4()(64bit)
    rubberband-1.0.1-1.fc9.i386  requires  libvamp-sdk.so.1.1.0
    rubberband-1.0.1-1.fc9.x86_64  requires  libvamp-sdk.so.1.1.0()(64bit)
    scim-bridge-qt-0.4.15-5.fc9.i386  requires  scim-bridge = 0:0.4.15-5.fc9
    sear-0.6.3-10.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    sonic-visualiser-1.2-1.fc9.x86_64  requires  libvamp-hostsdk.so.2.0.0()(64bit)
    syck-php-0.61-4.3.fc9.x86_64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-updates-9-i386:

    audacity-1.3.5-0.7.beta.fc9.i386  requires  libvamp-hostsdk.so.2.0.0
    cyphesis-0.5.15-8.fc9.i386  requires  libmercator-0.2.so.4
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.i386  requires  libresolv.so.2(GLIBC_PRIVATE)


======================================================================
Broken packages in fedora-updates-9-ppc:

    audacity-1.3.5-0.7.beta.fc9.ppc  requires  libvamp-hostsdk.so.2.0.0
    cyphesis-0.5.15-8.fc9.ppc  requires  libmercator-0.2.so.4
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.ppc  requires  libresolv.so.2(GLIBC_PRIVATE)
    openvas-libraries-1.0.2-2.fc9.ppc64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)


======================================================================
Broken packages in fedora-updates-9-ppc64:

    audacity-1.3.5-0.7.beta.fc9.ppc64  requires  libvamp-hostsdk.so.2.0.0()(64bit)
    cyphesis-0.5.15-8.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    livecd-tools-017.1-1.fc9.ppc64  requires  yaboot
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.ppc64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)


======================================================================
Broken packages in fedora-updates-9-x86_64:

    audacity-1.3.5-0.7.beta.fc9.x86_64  requires  libvamp-hostsdk.so.2.0.0()(64bit)
    cyphesis-0.5.15-8.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.i386  requires  libresolv.so.2(GLIBC_PRIVATE)
    openvas-libraries-1.0.2-2.fc9.x86_64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)



From mschwendt at gmail.com  Thu Dec 18 11:04:56 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 18 Dec 2008 11:04:56 -0000
Subject: Broken dependencies in Fedora 10 - 2008-12-18
Message-ID: <20081218110456.7830.81427@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by src.rpm name):

    appliance-tools
    audacity
    gyachi
    kadu
    qpidc
    rubberband
    sonic-visualiser


Summary of broken packages (by primary owner):

    aconway AT redhat com
        qpidc                           (1 co-owner)

    dhuff AT redhat com
        appliance-tools

    gemi AT bluewin ch
        audacity                        (2 co-owners)

    michel.sylvan AT gmail com
        rubberband
        sonic-visualiser

    mr.ecik AT gmail com
        kadu

    sundaram AT redhat com
        gyachi                          (1 co-owner)


======================================================================
Broken packages in fedora-10-i386:

    gyachi-plugin-photo_album-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.i386  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    qpidd-cluster-0.3.705289-1.fc10.i386  requires  qpidd = 0:0.3.705289-1.fc10
    rubberband-1.2-1.fc10.i386  requires  libvamp-sdk.so.1
    sonic-visualiser-1.3-1.fc10.i386  requires  libvamp-hostsdk.so.2


======================================================================
Broken packages in fedora-10-ppc:

    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    rubberband-1.2-1.fc10.ppc  requires  libvamp-sdk.so.1
    rubberband-1.2-1.fc10.ppc64  requires  libvamp-sdk.so.1()(64bit)
    sonic-visualiser-1.3-1.fc10.ppc  requires  libvamp-hostsdk.so.2


======================================================================
Broken packages in fedora-10-ppc64:

    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.ppc64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    rubberband-1.2-1.fc10.ppc64  requires  libvamp-sdk.so.1()(64bit)
    sonic-visualiser-1.3-1.fc10.ppc64  requires  libvamp-hostsdk.so.2()(64bit)


======================================================================
Broken packages in fedora-10-x86_64:

    gyachi-plugin-photo_album-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    kadu-agent-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-alsa_sound-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-amarok_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-antistring-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    kadu-audacious_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-cenzor-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-esd_sound-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-falf_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-mx610_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-osdhints_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-screenshot-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-spellchecker-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-water_notify-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-weather-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu = 0:0.6.0.1-1.fc10
    kadu-xmms_mediaplayer-0.6.0.1-1.fc10.x86_64  requires  kadu-mediaplayer = 0:0.6.0.1-1.fc10
    qpidd-cluster-0.3.705289-1.fc10.x86_64  requires  qpidd = 0:0.3.705289-1.fc10
    rubberband-1.2-1.fc10.i386  requires  libvamp-sdk.so.1
    rubberband-1.2-1.fc10.x86_64  requires  libvamp-sdk.so.1()(64bit)
    sonic-visualiser-1.3-1.fc10.x86_64  requires  libvamp-hostsdk.so.2()(64bit)


======================================================================
Broken packages in fedora-updates-10-i386:

    audacity-1.3.5-0.8.beta.fc10.i386  requires  libvamp-hostsdk.so.2


======================================================================
Broken packages in fedora-updates-10-ppc:

    audacity-1.3.5-0.8.beta.fc10.ppc  requires  libvamp-hostsdk.so.2


======================================================================
Broken packages in fedora-updates-10-ppc64:

    appliance-tools-003.9-1.fc10.noarch  requires  qemu-img
    audacity-1.3.5-0.8.beta.fc10.ppc64  requires  libvamp-hostsdk.so.2()(64bit)


======================================================================
Broken packages in fedora-updates-10-x86_64:

    audacity-1.3.5-0.8.beta.fc10.x86_64  requires  libvamp-hostsdk.so.2()(64bit)



From dan at danny.cz  Thu Dec 18 11:09:06 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 18 Dec 2008 12:09:06 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <gida1s$ap3$1@ger.gmane.org>
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229587671.3612.52.camel@eagle.danny.cz>
	<1229590959.3612.57.camel@eagle.danny.cz> <gida1s$ap3$1@ger.gmane.org>
Message-ID: <1229598546.3612.88.camel@eagle.danny.cz>

Kevin Kofler p??e v ?t 18. 12. 2008 v 11:52 +0100:
> Dan Hor?k wrote:
> > I have checked all packages that link with the "base" wxGTK library and
> > no other package is affected, they all use wxGTK-devel.
> 
> I think we should have some guideline that such versioned Provides should be
> kept indefinitely and packages should use them where available. You'll have
> to readd them when there will be a wxGTK 3 anyway!
> 

wxGTK = wxWidgets (formerly known as wxWindows) build with GTK as the
GUI toolkit

Yea, but the "2" was related to GTK 2.x vs. GTK 1.x, so to extend that
logic, "3" would mean wxWidgets built against GTK 3.x. It was not
related to wxGTK-1.x and wxGTK-2.x

> For example, in KDE SIG we're telling folks to keep using qt4-devel and
> kdelibs4-devel and we have no plans to drop those virtual Provides.

The wxWidgets API should be stable over all GUI toolkits used (GTK,
Cocoa, X, MSWin, ...). And there were probably some
differences/incompatibilities between wxWidgets build against GTK 1 and
wxWidgets built against GTK 2, that lead the audacity developers to
require the GTK 2 version.


		Dan




From benny+usenet at amorsen.dk  Thu Dec 18 11:13:01 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 18 Dec 2008 12:13:01 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812171342n55195d22pa19f16ce2e5c23dd@mail.gmail.com>
	(Jeff Spaleta's message of "Wed\, 17 Dec 2008 12\:42\:08 -0900")
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com> <494964DB.4040808@gmail.com>
	<49496875.3090403@behdad.org>
	<alpine.LFD.2.00.0812171613270.24989@localhost.localdomain>
	<604aa7910812171342n55195d22pa19f16ce2e5c23dd@mail.gmail.com>
Message-ID: <m3vdth3feq.fsf@ursa.amorsen.dk>

"Jeff Spaleta" <jspaleta at gmail.com> writes:

> And so would the opposite an email->notification utility which would
> turn traditional local system emails meant for root into dbus
> messages.  Such a beast would set at /usr/sbin/sendmail when
> installed..but would be replaced by a traditional mta if systems did
> not want a dbus service running.

What should it do with email not meant for root?

Apart from that little problem I like the idea, but IMHO anything that
provides /usr/sbin/sendmail should be able to actually send mail.


/Benny



From thomas.moschny at gmail.com  Thu Dec 18 11:16:44 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 18 Dec 2008 12:16:44 +0100
Subject: f11 boost-1.37.0 upgrade: notice of intent, and best way to
In-Reply-To: <20081217150712.6e1b9e01@balbo.artheist.org>
References: <20081124120549.5107aced@balbo.artheist.org>
	<e1760170812150628k5d37ec2apd57150960e1a87f@mail.gmail.com>
	<20081217150712.6e1b9e01@balbo.artheist.org>
Message-ID: <a9d183c80812180316t67c3457ao1ea92a770030a9a8@mail.gmail.com>

2008/12/18 Benjamin Kosnik <bkoz at redhat.com>:
>> > 3) check in the base boost package to devel, and immediately work on
>> > rebuilding the deps
> [...]
> It's now in. Deps need to be rebuilt.

Please take also into account packages that need boost only at build
time, like monotone.

- Thomas



From billcrawford1970 at gmail.com  Thu Dec 18 11:17:34 2008
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Thu, 18 Dec 2008 11:17:34 +0000
Subject: RFC: Description text in packages
In-Reply-To: <gi91p1$ssr$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229456805.15451.2.camel@arekh.okg> <gi91p1$ssr$1@ger.gmane.org>
Message-ID: <200812181117.34596.billcrawford1970@gmail.com>

On Tuesday 16 December 2008 20:06:57 Matthew Woehlke wrote:

> What's the fourth level? Not alt, that's used for accelerators. Not
> ctrl, shift, meta, or any combination thereof, as those are for
> shortcuts. That leaves... menu, and combinations thereof. If
> menu+something does something special, I sure don't know about it.
>
> You still haven't answered the education question.

It's usually "Alt Gr" or "AltGr" (alternative graphic) and that is (again, 
*usually*) the "right alt" key. My keyboard has it labelled that way, so it is 
not intended for accelerators.



From pertusus at free.fr  Thu Dec 18 11:29:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Dec 2008 12:29:37 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <m3vdth3feq.fsf@ursa.amorsen.dk>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com>
	<494964DB.4040808@gmail.com> <49496875.3090403@behdad.org>
	<alpine.LFD.2.00.0812171613270.24989@localhost.localdomain>
	<604aa7910812171342n55195d22pa19f16ce2e5c23dd@mail.gmail.com>
	<m3vdth3feq.fsf@ursa.amorsen.dk>
Message-ID: <20081218112937.GA3177@free.fr>

On Thu, Dec 18, 2008 at 12:13:01PM +0100, Benny Amorsen wrote:
> "Jeff Spaleta" <jspaleta at gmail.com> writes:
> 
> Apart from that little problem I like the idea, but IMHO anything that
> provides /usr/sbin/sendmail should be able to actually send mail.

That's the case, but cannot necessarily deliver locally (ssmtp).

--
Pat



From alsadi at gmail.com  Thu Dec 18 11:51:27 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 18 Dec 2008 13:51:27 +0200
Subject: performance test by Phoronix
In-Reply-To: <1229596333.3612.78.camel@eagle.danny.cz>
References: <1229596333.3612.78.camel@eagle.danny.cz>
Message-ID: <385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>

Hmmmmmmmm, faster processing slower IO......
what to consider
1. SELinux
2. some ext3 fs mount options
3. having some daemon
...etc.

BTW: I'm pleased by fedora performance,
I don't care about benchmarks



From mschwendt at gmail.com  Thu Dec 18 11:51:48 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 18 Dec 2008 12:51:48 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <1229598546.3612.88.camel@eagle.danny.cz>
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229587671.3612.52.camel@eagle.danny.cz>
	<1229590959.3612.57.camel@eagle.danny.cz>
	<gida1s$ap3$1@ger.gmane.org>
	<1229598546.3612.88.camel@eagle.danny.cz>
Message-ID: <20081218125148.8229e119.mschwendt@gmail.com>

On Thu, 18 Dec 2008 12:09:06 +0100, Dan wrote:

> > For example, in KDE SIG we're telling folks to keep using qt4-devel and
> > kdelibs4-devel and we have no plans to drop those virtual Provides.
> 
> The wxWidgets API should be stable over all GUI toolkits used (GTK,
> Cocoa, X, MSWin, ...). And there were probably some
> differences/incompatibilities between wxWidgets build against GTK 1 and
> wxWidgets built against GTK 2, that lead the audacity developers to
> require the GTK 2 version.

It's the opposite.

The stable release series of Audacity, 1.2.x, is made for the GTK+ 1
version of wxWidgets. The beta releases have closed the gap and are made
for and tested with "wxWidgets 2", albeit for quite some time not the very
latest. Meanwhile the requirement is wxWidgets 2.8.x.

We used to have wxGTK, wxGTK2, compat-wxGTK, compat-wxGTK2, and
compat-wxGTK26, not just because of Audacity.

IMO, there is no need to keep virtual package names forever.  If a package
gets renamed after years, the BuildRequires in other packages can be
adjusted accordingly.

What I'd like to see, however, is that this is done with an announcement
and not for old branches. Else we offer source rpms with broken Requires.



From mschmidt at redhat.com  Thu Dec 18 12:18:41 2008
From: mschmidt at redhat.com (Michal Schmidt)
Date: Thu, 18 Dec 2008 13:18:41 +0100
Subject: performance test by Phoronix
In-Reply-To: <385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>
References: <1229596333.3612.78.camel@eagle.danny.cz>
	<385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>
Message-ID: <20081218131841.0726d6c0@brian.englab.brq.redhat.com>

On Thu, 18 Dec 2008 13:51:27 +0200
"Muayyad AlSadi" <alsadi at gmail.com> wrote:

> Hmmmmmmmm, faster processing slower IO......
> what to consider
> 1. SELinux
> 2. some ext3 fs mount options
> 3. having some daemon
> ...etc.

4. I wonder if they could have done some really stupid mistake, like
having the distributions on different partitions on the disk. 

> BTW: I'm pleased by fedora performance,
> I don't care about benchmarks

Well, benchmarks can point out real problems.

But I don't trust Phoronix. I guess I'll have to see if I can
reproduce their results (not on the same hw, alas).

Michal



From karsten at redhat.com  Thu Dec 18 12:41:01 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Thu, 18 Dec 2008 13:41:01 +0100
Subject: Automatic BuildRequires
In-Reply-To: <20081109210146.GA16833@auslistsprd01.us.dell.com>
References: <20081106110142.GA3165@amd.home.annexia.org>	<20081106192302.c2285926.mschwendt@gmail.com>	<20081109204946.GA12715@auslistsprd01.us.dell.com>
	<20081109210146.GA16833@auslistsprd01.us.dell.com>
Message-ID: <494A44DD.2050701@redhat.com>

Matt Domsch schrieb:
> On Sun, Nov 09, 2008 at 02:49:46PM -0600, Matt Domsch wrote:
>> On Thu, Nov 06, 2008 at 07:23:02PM +0100, Michael Schwendt wrote:
>>> On Thu, 6 Nov 2008 11:01:42 +0000, Richard W.M. Jones wrote:
>>>
>>>> [I'm sure this isn't the first time this has occurred to someone, or
>>>> even been done -- but couldn't find anything for it in Google ...]
>>>>
>>>> http://et.redhat.com/~rjones/auto-buildrequires/
>>> There's one slightly similar one, which is several years old:
>>>
>>> https://www.europe.redhat.com/documentation/rhl6.2/rhl_6.2_sw_repository/rhl_6.2_powertools/InDependence-1.0-6.i386.php3
>>>
>>> Download it here for example:
>>> http://www.filewatcher.com/m/InDependence-1.0-6.src.rpm.16197.0.0.html
>> this might  be useful on conjunction with the occasional "full rawhide
>> rebuilds using rpmbuild on a system with Everything installed" run
>> that someone (sorry, I forget who did this) does.  That has the added
>> benefit of picking up features that configure auto-discovers but if
>> missing BRs, won't discover.
> 
> It was Karsten Hopp back in March 2008.
> https://www.redhat.com/archives/fedora-devel-list/2008-March/msg01257.html
> 

I've used auto-br-rpmbuild with my latest full-install mass rebuild and grepped the
BuildRequires from the logs.
They are available at
	http://karsten.fedorapeople.org/buildrequires/



From kevin.kofler at chello.at  Thu Dec 18 12:42:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Dec 2008 13:42:46 +0100
Subject: boost rebuild status
References: <20081218011435.03690d24@balbo.artheist.org>
Message-ID: <gidgg7$164$1@ger.gmane.org>

Benjamin Kosnik wrote:
> gnash-0:0.8.4-3.fc10.x86_64
> gnash-cygnal-0:0.8.4-3.fc10.x86_64

These both come from gnash. Bumped and rebuilt.

> kdeedu-math-0:4.1.2-2.fc10.x86_64

This comes from kdeedu. Bumped and rebuilt.

        Kevin Kofler



From rjones at redhat.com  Thu Dec 18 12:44:47 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 18 Dec 2008 12:44:47 +0000
Subject: Automatic BuildRequires
In-Reply-To: <494A44DD.2050701@redhat.com>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
	<20081109204946.GA12715@auslistsprd01.us.dell.com>
	<20081109210146.GA16833@auslistsprd01.us.dell.com>
	<494A44DD.2050701@redhat.com>
Message-ID: <20081218124447.GA8331@amd.home.annexia.org>

On Thu, Dec 18, 2008 at 01:41:01PM +0100, Karsten Hopp wrote:
> Matt Domsch schrieb:
>> On Sun, Nov 09, 2008 at 02:49:46PM -0600, Matt Domsch wrote:
>>> On Thu, Nov 06, 2008 at 07:23:02PM +0100, Michael Schwendt wrote:
>>>> On Thu, 6 Nov 2008 11:01:42 +0000, Richard W.M. Jones wrote:
>>>>
>>>>> [I'm sure this isn't the first time this has occurred to someone, or
>>>>> even been done -- but couldn't find anything for it in Google ...]
>>>>>
>>>>> http://et.redhat.com/~rjones/auto-buildrequires/
>>>> There's one slightly similar one, which is several years old:
>>>>
>>>> https://www.europe.redhat.com/documentation/rhl6.2/rhl_6.2_sw_repository/rhl_6.2_powertools/InDependence-1.0-6.i386.php3
>>>>
>>>> Download it here for example:
>>>> http://www.filewatcher.com/m/InDependence-1.0-6.src.rpm.16197.0.0.html
>>> this might  be useful on conjunction with the occasional "full rawhide
>>> rebuilds using rpmbuild on a system with Everything installed" run
>>> that someone (sorry, I forget who did this) does.  That has the added
>>> benefit of picking up features that configure auto-discovers but if
>>> missing BRs, won't discover.
>>
>> It was Karsten Hopp back in March 2008.
>> https://www.redhat.com/archives/fedora-devel-list/2008-March/msg01257.html
>>
>
> I've used auto-br-rpmbuild with my latest full-install mass rebuild and grepped the
> BuildRequires from the logs.
> They are available at
> 	http://karsten.fedorapeople.org/buildrequires/

At some point I'm going to push this project into a public place, like
Fedora Hosted.  There's a series of patches that people have sent me
which need to be integrated ...

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From opensource at till.name  Thu Dec 18 12:55:09 2008
From: opensource at till.name (Till Maas)
Date: Thu, 18 Dec 2008 13:55:09 +0100
Subject: query post/postun/preun dependencies for a rpm
Message-ID: <200812181355.10028.opensource@till.name>

Hiyas,

I would like to query the post/postun/preun dependencies of an rpm.
If I run rpm --requires -q pam_mount, it is not shown which dependencies 
result e.g. from a Requires(post), but I am sure that there is at least one, 
e.g. one of the /bin/sh dependencies.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/edb17a34/attachment.sig>

From benny+usenet at amorsen.dk  Thu Dec 18 13:07:28 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 18 Dec 2008 14:07:28 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081218112937.GA3177@free.fr> (Patrice Dumas's message of "Thu\,
	18 Dec 2008 12\:29\:37 +0100")
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172045.39170.opensource@till.name>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com> <494964DB.4040808@gmail.com>
	<49496875.3090403@behdad.org>
	<alpine.LFD.2.00.0812171613270.24989@localhost.localdomain>
	<604aa7910812171342n55195d22pa19f16ce2e5c23dd@mail.gmail.com>
	<m3vdth3feq.fsf@ursa.amorsen.dk> <20081218112937.GA3177@free.fr>
Message-ID: <m3wsdxaay7.fsf@ursa.amorsen.dk>

Patrice Dumas <pertusus at free.fr> writes:

> On Thu, Dec 18, 2008 at 12:13:01PM +0100, Benny Amorsen wrote:

>> Apart from that little problem I like the idea, but IMHO anything that
>> provides /usr/sbin/sendmail should be able to actually send mail.
>
> That's the case, but cannot necessarily deliver locally (ssmtp).

ssmtp cannot (as far as I can tell) deliver to DBUS, which was Jeff
Spaleta's proposal. Both Jeff Spaleta's proposal and Seth Vidal's
proposal look good to me.


/Benny



From choeger at cs.tu-berlin.de  Thu Dec 18 13:22:21 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 18 Dec 2008 14:22:21 +0100
Subject: certificate revoked?
Message-ID: <1229606541.12194.5.camel@choeger5.umpa.netz>

Hi folks,

in the middle of rebuilding offlineimap, which I've just taken from
Till, I got an certificate revoked error. There seems to be no outage
announced and my browser cert is from today. 

Is that some kind of bug, or does koji simply not want me to build my
packages?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/8d5b3a52/attachment.sig>

From mclasen at redhat.com  Thu Dec 18 13:23:58 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 18 Dec 2008 08:23:58 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
Message-ID: <1229606638.3301.11.camel@localhost.localdomain>

On Thu, 2008-12-18 at 02:19 -0500, Yaakov Nemoy wrote:
>
> In short, the new gnome session configuration dialog is alot simpler
> and alot less confusing, but it gives us no simple way to give
> metacity the boot on a per session basis.  How do i go about doing
> this via an RPM?

The required components should just be a fallback in case the session
didn't contain a window manager, file manager, etc. At least that is my
understanding of how they're supposed to be used. So, you should just
install an autostart file for xmonad that marks it as a window manager
via

X-GNOME-Autostart-Phase=WindowManager
X-GNOME-Provides=windowmanager

then your users should be able to switch their sessions to xmonad by
turning it on in the session capplet.

(CCing Jon, who wrote most of the relevant gnome-session code).


Matthias



From tim at niemueller.de  Thu Dec 18 13:52:19 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Thu, 18 Dec 2008 14:52:19 +0100
Subject: boost rebuild status
In-Reply-To: <20081218011435.03690d24@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
Message-ID: <494A5593.9050502@niemueller.de>

Benjamin Kosnik schrieb:
> Rebuilding dependent packages for boost is progressing relatively
> smoothly. Here's an update on boost rebuilds for the second half of the
> deps list: hopefully Petr will update from the top.

[...]

> player-0:2.1.1-5.fc10.x86_64
> player-examples-0:2.1.1-5.fc10.x86_64
>   bump Release, rebuild fails:
>   
>   compile error, temporary build situation?
>   /usr/include/linux/serial.h:164: error: '__u32' does not name a type
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=1005939

I'll take care of this one. Problem has been discussed and fix is known.
Just need to find time which will probably be today night.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From devzero2000 at rpm5.org  Thu Dec 18 13:52:23 2008
From: devzero2000 at rpm5.org (devzero2000)
Date: Thu, 18 Dec 2008 14:52:23 +0100
Subject: query post/postun/preun dependencies for a rpm
In-Reply-To: <200812181355.10028.opensource@till.name>
References: <200812181355.10028.opensource@till.name>
Message-ID: <b086760e0812180552i26cadfaen9906611ee75764af@mail.gmail.com>

The Requires(post) context marker exists only for breaking loop deps at the
install package time.So it is not necessary to register them in an rpmdb
because they were needed only
for installing, not for using or erasing, a package. The %post scriptlet is
run only during install, never run after install.

Regards

2008/12/18 Till Maas <opensource at till.name>

> Hiyas,
>
> I would like to query the post/postun/preun dependencies of an rpm.
> If I run rpm --requires -q pam_mount, it is not shown which dependencies
> result e.g. from a Requires(post), but I am sure that there is at least
> one,
> e.g. one of the /bin/sh dependencies.
>
> Regards,
> Till
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/821ae1e3/attachment.htm>

From nicolas.mailhot at laposte.net  Thu Dec 18 14:00:20 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 18 Dec 2008 15:00:20 +0100 (CET)
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <gida1s$ap3$1@ger.gmane.org>
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229587671.3612.52.camel@eagle.danny.cz>
	<1229590959.3612.57.camel@eagle.danny.cz>
	<gida1s$ap3$1@ger.gmane.org>
Message-ID: <60e68f0f443fc12dde9a57a958afedd8.squirrel@arekh.dyndns.org>



Le Jeu 18 d?cembre 2008 11:52, Kevin Kofler a ?crit :

> I think we should have some guideline that such versioned Provides
> should be kept indefinitely

IMHO it is perfectly ok to clean up old cruft, or it accumulates and
the packages start to be musty.

The question is how and when.

I'd tend to reserve such spring cleanup to rawhide, in the first month
of a new cycle, to leave other packagers time to adapt.

-- 
Nicolas Mailhot



From hughsient at gmail.com  Thu Dec 18 13:59:59 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 18 Dec 2008 13:59:59 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <20081217214854.GA7105@nostromo.devel.redhat.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<20081217214854.GA7105@nostromo.devel.redhat.com>
Message-ID: <1229608799.3651.9.camel@hughsie-work.lan>

On Wed, 2008-12-17 at 16:48 -0500, Bill Nottingham wrote:
> Dumb question. All the complaints I've seen that come in are
> about word-wrapping, but your main example is about character
> escaping/transliteration. Why not just do the word-wrapping, and
> leave it at that? (Note that PK at the moment wordwraps badly,
> which causes other issues.)

Yes, I've fixed the word wrapping in the client tools now. I've also
removed all the " and ' replacement logic.

So, if you use valid markdown in your bohdi descriptions, or in your
package descriptions then gnome-packagekit will attempt to convert
elements to PangoMarkup. If it comes across anything oddball, it'll just
show the untouched line instead.

Richard.




From skvidal at fedoraproject.org  Thu Dec 18 14:06:40 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 18 Dec 2008 09:06:40 -0500 (EST)
Subject: search for BuildRequires using repoquery
In-Reply-To: <1229594337.3612.68.camel@eagle.danny.cz>
References: <1229594337.3612.68.camel@eagle.danny.cz>
Message-ID: <alpine.LFD.2.00.0812180906270.31106@localhost.localdomain>



On Thu, 18 Dec 2008, Dan Hor?k wrote:

> Hi,
>
> the manpage for repoquery says that is is possible to search for
> BuildRequires using this command:
>
> repoquery --archlist=src --whatrequires gail-devel
>
> But it gives me a traceback. Is it still supposed to work? There was
> also a thread on yum-devel about searching BuildRequires -
> http://lists.baseurl.org/pipermail/yum-devel/2006-May/002187.html
>
>

What traceback does it give you?

-sv

From hughsient at gmail.com  Thu Dec 18 14:09:55 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 18 Dec 2008 14:09:55 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <49496940.20706@gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan> <49496940.20706@gmail.com>
Message-ID: <1229609395.3651.19.camel@hughsie-work.lan>

On Wed, 2008-12-17 at 13:04 -0800, Toshio Kuratomi wrote:
> In that case, you're going to have a lot of problems with adding
> Markdown in PackageKit upstream.

http://www.packagekit.org/pk-faq.html#markup

> I doubt heavily that we'll be able to
> get people within Fedora to agree to format their %descriptions as
> markdown let alone the larger community of distributions.

I don't want people to change anything. If you use markdown syntax (or
something similar to the syntax) then everything just works. If you use
something oddball (?), then PackageKit is going to give up and just
display the text as it is, probably with incorrect wrapping.

> The problem is that Markdown and other non-intrusive formats (like
> reStructuredText) don't have enough information to tell if it's
> "invalid".  For instance, if my Bodhi comments have:
> 
> # Fix an issue with char *foobar and all void* on gcc-5
> # Fix call to __init__ in python bindings.

Then you're going to get two titles. Seriously - who does that? If you
follow what 99% of other people are doing and either do:

* lists
 * that
 - most
- people
 +   use

Then it'll just work.

> Markdown will mangle what I intended because there are three constructs
> in there that look like valid Markdown.

Right, it'll make italic the "foobar and all void" line. I really don't
think putting code in update descriptions is a good idea, for the very
point of them is to tell people if they need to do the update. A better
message would be:

* Fix compile on GCC-5

and then provide a link to the mailing list with more information. If
that's not acceptable, writing "*foobar and all void *" would prevent it
being marked italic.

> To use a non-intrusive format, we need to specify the format being used
> either in a specification or as metadata to the %description tag.  Both
> of those solutions would have to be hashed out with the rpm authors.

That's never going to happen. Most busy people struggle with good
descriptions and bodhi update text in plain text, ask them to do it in
SGML/html/some-other-markup and even less people will be bothered.

Richard.




From kevin.kofler at chello.at  Thu Dec 18 14:10:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Dec 2008 15:10:47 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229587671.3612.52.camel@eagle.danny.cz>
	<1229590959.3612.57.camel@eagle.danny.cz>
	<gida1s$ap3$1@ger.gmane.org>
	<60e68f0f443fc12dde9a57a958afedd8.squirrel@arekh.dyndns.org>
Message-ID: <gidll7$hh2$1@ger.gmane.org>

Nicolas Mailhot wrote:
> IMHO it is perfectly ok to clean up old cruft, or it accumulates and
> the packages start to be musty.

But versioned Provides are not "old cruft":
* They don't accumulate - if Qt is Qt 4, it only Provides: qt4(-devel) and
not qt3(-devel), qt2(-devel) or qt1(-devel), that's the whole point of this
system.
* They will have to be reintroduced when the migration to the next version
happens (e.g. Qt 5), so there's no point in removing them (and we don't
plan to do it in the case of Qt).

The wxGTK2 case is particular though in that the maintainer doesn't expect
another transition period to be needed when the move to GTK+ 3 happens,
because wxWidgets is supposed to abstract the difference away (see his
reply to my message). Let's see.

        Kevin Kofler



From ob.system at gmail.com  Thu Dec 18 14:13:05 2008
From: ob.system at gmail.com (Oscar Victorio Calixto Bacho)
Date: Thu, 18 Dec 2008 08:13:05 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <m3wsdxaay7.fsf@ursa.amorsen.dk>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<604aa7910812171159x7f52274bvdd93f7dc6b08c3a2@mail.gmail.com>
	<200812171438.00606.jamundso@gmail.com> <494964DB.4040808@gmail.com>
	<49496875.3090403@behdad.org>
	<alpine.LFD.2.00.0812171613270.24989@localhost.localdomain>
	<604aa7910812171342n55195d22pa19f16ce2e5c23dd@mail.gmail.com>
	<m3vdth3feq.fsf@ursa.amorsen.dk> <20081218112937.GA3177@free.fr>
	<m3wsdxaay7.fsf@ursa.amorsen.dk>
Message-ID: <6a28481b0812180613l6094bf2dj851814751590390@mail.gmail.com>

This thread is for fedora boot fast, no for MTA default.

Open new thread pleas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/29a7c3a5/attachment.htm>

From kevin.kofler at chello.at  Thu Dec 18 14:13:16 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Dec 2008 15:13:16 +0100
Subject: Forcing Gnome to start sans metacity
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
Message-ID: <gidlps$hh2$2@ger.gmane.org>

Matthias Clasen wrote:
> The required components should just be a fallback in case the session
> didn't contain a window manager, file manager, etc. At least that is my
> understanding of how they're supposed to be used. So, you should just
> install an autostart file for xmonad that marks it as a window manager
> via
> 
> X-GNOME-Autostart-Phase=WindowManager
> X-GNOME-Provides=windowmanager
> 
> then your users should be able to switch their sessions to xmonad by
> turning it on in the session capplet.

If you install an autostart file into /etc/xdg/autostart, you'll force this
for KDE users with no easy way to turn it off, KDE does not allow users to
turn off autostart entries. So that's not a good solution.

        Kevin Kofler



From dan at danny.cz  Thu Dec 18 14:25:41 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 18 Dec 2008 15:25:41 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <20081218125148.8229e119.mschwendt@gmail.com>
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229587671.3612.52.camel@eagle.danny.cz>
	<1229590959.3612.57.camel@eagle.danny.cz> <gida1s$ap3$1@ger.gmane.org>
	<1229598546.3612.88.camel@eagle.danny.cz>
	<20081218125148.8229e119.mschwendt@gmail.com>
Message-ID: <1229610341.3612.118.camel@eagle.danny.cz>

Michael Schwendt p??e v ?t 18. 12. 2008 v 12:51 +0100:
> On Thu, 18 Dec 2008 12:09:06 +0100, Dan wrote:
> 
> > > For example, in KDE SIG we're telling folks to keep using qt4-devel and
> > > kdelibs4-devel and we have no plans to drop those virtual Provides.
> > 
> > The wxWidgets API should be stable over all GUI toolkits used (GTK,
> > Cocoa, X, MSWin, ...). And there were probably some
> > differences/incompatibilities between wxWidgets build against GTK 1 and
> > wxWidgets built against GTK 2, that lead the audacity developers to
> > require the GTK 2 version.
> 
> It's the opposite.
> 
> The stable release series of Audacity, 1.2.x, is made for the GTK+ 1
> version of wxWidgets. The beta releases have closed the gap and are made
> for and tested with "wxWidgets 2", albeit for quite some time not the very
> latest. Meanwhile the requirement is wxWidgets 2.8.x.
> 
> We used to have wxGTK, wxGTK2, compat-wxGTK, compat-wxGTK2, and
> compat-wxGTK26, not just because of Audacity.

Since F-7 there is only one wxGTK package, if I read the old specs
correctly. That corresponds to the release of wxGTK 2.8.0 and the
package was (and still is) built with the wxWidgets 2.4 compatibility
compile-time option enabled.

> 
> IMO, there is no need to keep virtual package names forever.  If a package
> gets renamed after years, the BuildRequires in other packages can be
> adjusted accordingly.
> 
> What I'd like to see, however, is that this is done with an announcement
> and not for old branches. Else we offer source rpms with broken Requires.
> 

Here was the old stuff dropped only in rawhide 2 weeks ago, the
changelog lies (s/Nov/Dec/).

But I agree that an announcement must be sent.


		Dan




From sgrubb at redhat.com  Thu Dec 18 14:27:04 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 18 Dec 2008 09:27:04 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <4949501C.90003@behdad.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
Message-ID: <200812180927.05026.sgrubb@redhat.com>

On Wednesday 17 December 2008 02:24:41 pm Jeff Spaleta wrote:
> On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad at behdad.org> wrote:
> > And what are all those applications that are claimed depend on sendmail? 
> > Show it to me.
>
> Ask and you shall receive, at least for F10 with rpmfusion enabled:
> > repoquery --whatrequires --alldeps sendmail --qf "%{NAME}\n"|sort -u

We ran into a problem doing the LSPP evaluation with regards to email. Of all 
the packages listed, the only one that really mattered for security was cron. 
So, what we did was patched cron to be able to take an argument, -m, to 
define the mail delivery agent. It could be a shell script, procmail, or 
anything you wanted to take the cron output and move it into the local spool 
dir. Would using this solve the problems being debated here?  (And since cron 
can take a mail agent argument, it should not have a hard requirement for 
sendmail.)

-Steve



From dan at danny.cz  Thu Dec 18 14:27:28 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 18 Dec 2008 15:27:28 +0100
Subject: search for BuildRequires using repoquery
In-Reply-To: <alpine.LFD.2.00.0812180906270.31106@localhost.localdomain>
References: <1229594337.3612.68.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0812180906270.31106@localhost.localdomain>
Message-ID: <1229610448.3612.120.camel@eagle.danny.cz>

Seth Vidal p??e v ?t 18. 12. 2008 v 09:06 -0500:
> 
> On Thu, 18 Dec 2008, Dan Hor?k wrote:
> 
> > Hi,
> >
> > the manpage for repoquery says that is is possible to search for
> > BuildRequires using this command:
> >
> > repoquery --archlist=src --whatrequires gail-devel
> >
> > But it gives me a traceback. Is it still supposed to work? There was
> > also a thread on yum-devel about searching BuildRequires -
> > http://lists.baseurl.org/pipermail/yum-devel/2006-May/002187.html
> >
> >
> 
> What traceback does it give you?

yum-utils-1.1.18-2.fc10.noarch

[dan at eagle ~]$ repoquery --archlist=src --whatrequires wxGTK2-devel
Traceback (most recent call last):
  File "/usr/bin/repoquery", line 853, in <module>
    main(sys.argv)
  File "/usr/bin/repoquery", line 849, in main
    repoq.runQuery(regexs)
  File "/usr/bin/repoquery", line 503, in runQuery
    for p in self.doQuery(oper, prco): print p
  File "/usr/bin/repoquery", line 508, in doQuery
    return getattr(self, "fmt_%s" % method)(*args, **kw)
  File "/usr/bin/repoquery", line 545, in fmt_whatrequires
    require_recursive(name)
  File "/usr/bin/repoquery", line 540, in require_recursive
    for pkg in self.pkgSack.searchRequires(prov.split()[0]):
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 592, in
<lambda>
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 417, in
_getSacks
    if self._pkgSack and thisrepo is None:
  File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 263,
in __len__
    ret += len(sack)
ValueError: __len__() should return >= 0


Do you want a bug?


		Dan




From sgrubb at redhat.com  Thu Dec 18 14:29:19 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 18 Dec 2008 09:29:19 -0500
Subject: Whatever happened to make force-tag?
In-Reply-To: <49491AED.3070709@lfarkas.org>
References: <200812170954.09054.sgrubb@redhat.com>
	<1229527504.4052.17.camel@eagle.danny.cz>
	<49491AED.3070709@lfarkas.org>
Message-ID: <200812180929.19658.sgrubb@redhat.com>

On Wednesday 17 December 2008 10:29:49 am Farkas Levente wrote:
> Dan Hor?k wrote:
> > Steve Grubb p??e v St 17. 12. 2008 v 09:54 -0500:
> >> I remember that there were lots of discussion about this in September.
> >> We have the ability to do "force-tag" in cvs directly, why have we not
> >> taken the next step and re-enabled the make target?
> >
> > The official way is now "TAG_OPTS=-f make tag", but you can have "make
> > force-tag" too - see
> > http://www.redhat.com/archives/rhl-devel-list/2008-September/msg01689.htm
> >l
>
> it'd be useful to document it somehow...

It would be even more useful if we just decided that since we have an official 
workaround, its OK to restore the force-tag target to use it.

-Steve



From skvidal at fedoraproject.org  Thu Dec 18 14:31:07 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 18 Dec 2008 09:31:07 -0500 (EST)
Subject: search for BuildRequires using repoquery
In-Reply-To: <1229610448.3612.120.camel@eagle.danny.cz>
References: <1229594337.3612.68.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0812180906270.31106@localhost.localdomain>
	<1229610448.3612.120.camel@eagle.danny.cz>
Message-ID: <alpine.LFD.2.00.0812180930490.31106@localhost.localdomain>



On Thu, 18 Dec 2008, Dan Hor?k wrote:

> Seth Vidal p??e v ?t 18. 12. 2008 v 09:06 -0500:
>>
>> On Thu, 18 Dec 2008, Dan Hor?k wrote:
>>
>>> Hi,
>>>
>>> the manpage for repoquery says that is is possible to search for
>>> BuildRequires using this command:
>>>
>>> repoquery --archlist=src --whatrequires gail-devel
>>>
>>> But it gives me a traceback. Is it still supposed to work? There was
>>> also a thread on yum-devel about searching BuildRequires -
>>> http://lists.baseurl.org/pipermail/yum-devel/2006-May/002187.html
>>>
>>>
>>
>> What traceback does it give you?
>
> yum-utils-1.1.18-2.fc10.noarch
>
> [dan at eagle ~]$ repoquery --archlist=src --whatrequires wxGTK2-devel
> Traceback (most recent call last):
>  File "/usr/bin/repoquery", line 853, in <module>
>    main(sys.argv)
>  File "/usr/bin/repoquery", line 849, in main
>    repoq.runQuery(regexs)
>  File "/usr/bin/repoquery", line 503, in runQuery
>    for p in self.doQuery(oper, prco): print p
>  File "/usr/bin/repoquery", line 508, in doQuery
>    return getattr(self, "fmt_%s" % method)(*args, **kw)
>  File "/usr/bin/repoquery", line 545, in fmt_whatrequires
>    require_recursive(name)
>  File "/usr/bin/repoquery", line 540, in require_recursive
>    for pkg in self.pkgSack.searchRequires(prov.split()[0]):
>  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 592, in
> <lambda>
>    pkgSack = property(fget=lambda self: self._getSacks(),
>  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 417, in
> _getSacks
>    if self._pkgSack and thisrepo is None:
>  File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 263,
> in __len__
>    ret += len(sack)
> ValueError: __len__() should return >= 0
>
>
> Do you want a bug?
>

sure, but before you do, try yum-utils 1.1.19 which just hit 
updates-testing.

-sv

From limb at jcomserv.net  Thu Dec 18 14:32:08 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 08:32:08 -0600 (CST)
Subject: certificate revoked?
In-Reply-To: <1229606541.12194.5.camel@choeger5.umpa.netz>
References: <1229606541.12194.5.camel@choeger5.umpa.netz>
Message-ID: <c549477884353bbd9cff5bfd9a21509f.squirrel@mail.jcomserv.net>


> Hi folks,
>
> in the middle of rebuilding offlineimap, which I've just taken from
> Till, I got an certificate revoked error. There seems to be no outage
> announced and my browser cert is from today.
>
> Is that some kind of bug, or does koji simply not want me to build my
> packages?

If your cert is more than 1 year old, get a new one from FAS.

> regards
>
> christoph
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From choeger at cs.tu-berlin.de  Thu Dec 18 14:53:33 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 18 Dec 2008 15:53:33 +0100
Subject: certificate revoked?
In-Reply-To: <c549477884353bbd9cff5bfd9a21509f.squirrel@mail.jcomserv.net>
References: <1229606541.12194.5.camel@choeger5.umpa.netz>
	<c549477884353bbd9cff5bfd9a21509f.squirrel@mail.jcomserv.net>
Message-ID: <1229612013.12194.14.camel@choeger5.umpa.netz>

Am Donnerstag, den 18.12.2008, 08:32 -0600 schrieb Jon Ciesla:
> > Hi folks,
> >
> > in the middle of rebuilding offlineimap, which I've just taken from
> > Till, I got an certificate revoked error. There seems to be no outage
> > announced and my browser cert is from today.
> >
> > Is that some kind of bug, or does koji simply not want me to build my
> > packages?
> 
> If your cert is more than 1 year old, get a new one from FAS.
> 
> > regards
> >
> > christoph
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
> -- 
> in your fear, speak only peace
> in your fear, seek only love
> 
> -d. bowie
> 

I've just re-setup my fedora devel environment on this box. I've created
the browser cert a few hours ago, and look at this:

[choeger at choeger5 ~]$ ls -l .fed*
-rw------- 1 choeger choeger 10115 18. Dez 13:35 .fedora.cert
-rw------- 1 choeger choeger  6162  7. Nov 08:20 .fedora-server-ca.cert
-rw------- 1 choeger choeger  6162  7. Nov 08:20 .fedora-upload-ca.cert

So what i the problem? Who revoked my certs?
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/1aafb483/attachment.sig>

From rjones at redhat.com  Thu Dec 18 15:05:51 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 18 Dec 2008 15:05:51 +0000
Subject: Automatic BuildRequires
In-Reply-To: <20081218124447.GA8331@amd.home.annexia.org>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
	<20081109204946.GA12715@auslistsprd01.us.dell.com>
	<20081109210146.GA16833@auslistsprd01.us.dell.com>
	<494A44DD.2050701@redhat.com>
	<20081218124447.GA8331@amd.home.annexia.org>
Message-ID: <20081218150551.GA8957@amd.home.annexia.org>

On Thu, Dec 18, 2008 at 12:44:47PM +0000, Richard W.M. Jones wrote:
> At some point I'm going to push this project into a public place, like
> Fedora Hosted.  There's a series of patches that people have sent me
> which need to be integrated ...

https://fedorahosted.org/fedora-infrastructure/ticket/1070

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 chris.stone at gmail.com  Thu Dec 18 15:22:19 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 18 Dec 2008 07:22:19 -0800
Subject: Reboot Icons are Lame
Message-ID: <d9c612bf0812180722i68254a54u7a54816c43ab24b0@mail.gmail.com>

I woke up this morning to find two orange triangle icons with
exclamation marks in them asking me to restart my computer.  These
"restart your computer notification" icons which I assume are part of
PackgeKit or something are totally lame.  They should tell you *why*
you need to restart.  I checked my yum logs for yesterday and I don't
even see a kernel update, so I am confused as to why I have two icons
on my taskbar now requesting that I reboot...  WTF?!



From sgallagh at redhat.com  Thu Dec 18 15:24:09 2008
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Thu, 18 Dec 2008 10:24:09 -0500
Subject: Reboot Icons are Lame
In-Reply-To: <d9c612bf0812180722i68254a54u7a54816c43ab24b0@mail.gmail.com>
References: <d9c612bf0812180722i68254a54u7a54816c43ab24b0@mail.gmail.com>
Message-ID: <494A6B19.8020909@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Stone wrote:
> I woke up this morning to find two orange triangle icons with
> exclamation marks in them asking me to restart my computer.  These
> "restart your computer notification" icons which I assume are part of
> PackgeKit or something are totally lame.  They should tell you *why*
> you need to restart.  I checked my yum logs for yesterday and I don't
> even see a kernel update, so I am confused as to why I have two icons
> on my taskbar now requesting that I reboot...  WTF?!
> 

The rollback to D-BUS 1.2.4 occurred yesterday. Since practically the
entire desktop relies on the messagebus service, it's easiest to just
reboot the entire machine.

- --

- --------------------
Stephen Gallagher
RHCE 804006346421761
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKaxkACgkQeiVVYja6o6P8cQCfZThMSiRqjpdNA8ESvLQ9Uurc
SiIAniztV7k+DjUHvBZs40U4i2q7deox
=MgFH
-----END PGP SIGNATURE-----



From pmatilai at laiskiainen.org  Thu Dec 18 15:25:58 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 18 Dec 2008 17:25:58 +0200 (EET)
Subject: query post/postun/preun dependencies for a rpm
In-Reply-To: <200812181355.10028.opensource@till.name>
References: <200812181355.10028.opensource@till.name>
Message-ID: <alpine.DEB.1.10.0812181719440.13881@gotcha.dreamhost.com>

On Thu, 18 Dec 2008, Till Maas wrote:

> Hiyas,
>
> I would like to query the post/postun/preun dependencies of an rpm.
> If I run rpm --requires -q pam_mount, it is not shown which dependencies
> result e.g. from a Requires(post), but I am sure that there is at least one,
> e.g. one of the /bin/sh dependencies.

The information is stored in RPMTAG_REQUIREFLAGS of headers but there's no 
formatter to make it human readable in current rpm versions (upstream has 
:deptype now but that's not yet in rpm 4.6.0), meanwhile this'll do the 
trick: http://laiskiainen.org/rpm/scripts/depnames.py

[pmatilai at localhost ~]$ ./depnames.py pam_mount
auto R /bin/bash
post R /bin/sh
auto R /bin/sh
auto R /usr/bin/perl
manual R config(pam_mount) = 0.49-1.fc10
manual R libHX >= 1.25
...

This'll only work for installed packages, making it work for non-installed 
packages is left as an excercise to the reader...

 	- Panu -



From limb at jcomserv.net  Thu Dec 18 15:26:13 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 09:26:13 -0600 (CST)
Subject: certificate revoked?
In-Reply-To: <1229612013.12194.14.camel@choeger5.umpa.netz>
References: <1229606541.12194.5.camel@choeger5.umpa.netz>
	<c549477884353bbd9cff5bfd9a21509f.squirrel@mail.jcomserv.net>
	<1229612013.12194.14.camel@choeger5.umpa.netz>
Message-ID: <2a348b5bb919d84584a4c928fec7fc35.squirrel@mail.jcomserv.net>

> Am Donnerstag, den 18.12.2008, 08:32 -0600 schrieb Jon Ciesla:
>> > Hi folks,
>> >
>> > in the middle of rebuilding offlineimap, which I've just taken from
>> > Till, I got an certificate revoked error. There seems to be no outage
>> > announced and my browser cert is from today.
>> >
>> > Is that some kind of bug, or does koji simply not want me to build my
>> > packages?
>>
>> If your cert is more than 1 year old, get a new one from FAS.
>>
>> > regards
>> >
>> > christoph
>> > --
>> > fedora-devel-list mailing list
>> > fedora-devel-list at redhat.com
>> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>>
>> --
>> in your fear, speak only peace
>> in your fear, seek only love
>>
>> -d. bowie
>>
>
> I've just re-setup my fedora devel environment on this box. I've created
> the browser cert a few hours ago, and look at this:
>
> [choeger at choeger5 ~]$ ls -l .fed*
> -rw------- 1 choeger choeger 10115 18. Dez 13:35 .fedora.cert
> -rw------- 1 choeger choeger  6162  7. Nov 08:20 .fedora-server-ca.cert
> -rw------- 1 choeger choeger  6162  7. Nov 08:20 .fedora-upload-ca.cert
>
> So what i the problem? Who revoked my certs?
>
Not sure.  What do the expiration dates in the certs say?  Also, is your
ssh key in place?

-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie




From hughsient at gmail.com  Thu Dec 18 15:28:13 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 18 Dec 2008 15:28:13 +0000
Subject: Reboot Icons are Lame
In-Reply-To: <494A6B19.8020909@redhat.com>
References: <d9c612bf0812180722i68254a54u7a54816c43ab24b0@mail.gmail.com>
	<494A6B19.8020909@redhat.com>
Message-ID: <1229614093.3651.47.camel@hughsie-work.lan>

On Thu, 2008-12-18 at 10:24 -0500, Stephen Gallagher wrote:
> The rollback to D-BUS 1.2.4 occurred yesterday. Since practically the
> entire desktop relies on the messagebus service, it's easiest to just
> reboot the entire machine.

I've already asked Mike Langlie to draw me some better icons after
Christmas. He's busy at the moment, but when he's done I'll upload a
package with fixed icons.

I'm guessing you've got two icons as gnome-packagekit itself was
updated, and the old instance failed to exit. I guess you need to file a
bug about that.

Richard.




From pmatilai at laiskiainen.org  Thu Dec 18 15:33:26 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 18 Dec 2008 17:33:26 +0200 (EET)
Subject: query post/postun/preun dependencies for a rpm
In-Reply-To: <b086760e0812180552i26cadfaen9906611ee75764af@mail.gmail.com>
References: <200812181355.10028.opensource@till.name>
	<b086760e0812180552i26cadfaen9906611ee75764af@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0812181731350.13881@gotcha.dreamhost.com>

On Thu, 18 Dec 2008, devzero2000 wrote:

> The Requires(post) context marker exists only for breaking loop deps at
> the install package time.So it is not necessary to register them in an
> rpmdb because they were needed only
> for installing, not for using or erasing, a package. The %post scriptlet
> is run only during install, never run after install.

They're filtered out from the require *index*, not the headers stored in 
rpmdb. Very different thing.

 	- Panu -



From chris.stone at gmail.com  Thu Dec 18 15:41:44 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 18 Dec 2008 07:41:44 -0800
Subject: Reboot Icons are Lame
In-Reply-To: <1229614093.3651.47.camel@hughsie-work.lan>
References: <d9c612bf0812180722i68254a54u7a54816c43ab24b0@mail.gmail.com>
	<494A6B19.8020909@redhat.com>
	<1229614093.3651.47.camel@hughsie-work.lan>
Message-ID: <d9c612bf0812180741x16c0f3a2ha550a83ea634ee90@mail.gmail.com>

On Thu, Dec 18, 2008 at 7:28 AM, Richard Hughes <hughsient at gmail.com> wrote:
> I've already asked Mike Langlie to draw me some better icons after
> Christmas. He's busy at the moment, but when he's done I'll upload a
> package with fixed icons.

It's not that the icons look ugly, its that they do not tell you what
packages are requesting the reboot.



From loupgaroublond at gmail.com  Thu Dec 18 15:51:50 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Thu, 18 Dec 2008 10:51:50 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <1229606638.3301.11.camel@localhost.localdomain>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
Message-ID: <7f692fec0812180751o45f67bc2r599077362ed80cb8@mail.gmail.com>

2008/12/18 Matthias Clasen <mclasen at redhat.com>:
> On Thu, 2008-12-18 at 02:19 -0500, Yaakov Nemoy wrote:
>>
>> In short, the new gnome session configuration dialog is alot simpler
>> and alot less confusing, but it gives us no simple way to give
>> metacity the boot on a per session basis.  How do i go about doing
>> this via an RPM?
>
> The required components should just be a fallback in case the session
> didn't contain a window manager, file manager, etc. At least that is my
> understanding of how they're supposed to be used. So, you should just
> install an autostart file for xmonad that marks it as a window manager
> via
>
> X-GNOME-Autostart-Phase=WindowManager
> X-GNOME-Provides=windowmanager
>
> then your users should be able to switch their sessions to xmonad by
> turning it on in the session capplet.
>
> (CCing Jon, who wrote most of the relevant gnome-session code).

This doesn't explain how to give metacity the boot.  xmonad doesn't
honor --replace or most other window manager command line options, and
metacity is no longer listed in the sessions capplet. Secondly, i
found that when gnome tries to manage xmonad, it loads several
instances and lets them fight with other until they crash in a pile of
suckage.  All i'm looking to do is just get rid of metacity, and use
more unixy methods to load xmonad.

-Yaakov



From loupgaroublond at gmail.com  Thu Dec 18 15:54:48 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Thu, 18 Dec 2008 10:54:48 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <gidlps$hh2$2@ger.gmane.org>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<gidlps$hh2$2@ger.gmane.org>
Message-ID: <7f692fec0812180754x20f9b890t9f44fbadac447920@mail.gmail.com>

2008/12/18 Kevin Kofler <kevin.kofler at chello.at>:
> Matthias Clasen wrote:
>> The required components should just be a fallback in case the session
>> didn't contain a window manager, file manager, etc. At least that is my
>> understanding of how they're supposed to be used. So, you should just
>> install an autostart file for xmonad that marks it as a window manager
>> via
>>
>> X-GNOME-Autostart-Phase=WindowManager
>> X-GNOME-Provides=windowmanager
>>
>> then your users should be able to switch their sessions to xmonad by
>> turning it on in the session capplet.
>
> If you install an autostart file into /etc/xdg/autostart, you'll force this
> for KDE users with no easy way to turn it off, KDE does not allow users to
> turn off autostart entries. So that's not a good solution.

This is intended to be default behavior only if you install a special
xmonad-gnome-session package, though i'm planning on doing one for kde
too.  Presumably, if the user wants this behavior, then the package is
needed, but realistically, if /etc/xdg/autostart implies that it is
forced on the user in KDE, then you're right, it's a bad solution,
because i'm really looking to have this remain optional, via GDM or
KDM (/usr/share/xsessions/*)

-Yaakov



From james at fedoraproject.org  Thu Dec 18 15:57:07 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 18 Dec 2008 10:57:07 -0500
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229609395.3651.19.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan> <49496940.20706@gmail.com>
	<1229609395.3651.19.camel@hughsie-work.lan>
Message-ID: <1229615827.6392.109.camel@code.and.org>

On Thu, 2008-12-18 at 14:09 +0000, Richard Hughes wrote:
> On Wed, 2008-12-17 at 13:04 -0800, Toshio Kuratomi wrote:
> > In that case, you're going to have a lot of problems with adding
> > Markdown in PackageKit upstream.
> 
> http://www.packagekit.org/pk-faq.html#markup
> 
> > I doubt heavily that we'll be able to
> > get people within Fedora to agree to format their %descriptions as
> > markdown let alone the larger community of distributions.
> 
> I don't want people to change anything.

% cat ../pkg.description2markdown-html.py     
#! /usr/bin/python -tt

import os, sys, markdown2, yum

yb = yum.YumBase()
yb.conf.cache = os.geteuid() != 0

for pkg in yb.pkgSack.returnPackages(patterns=sys.argv[1:]):
  sep = "\n" + "-" * 79
  print "=" * 79
  print pkg, pkg.repoid, sep
  print pkg.description, sep
  print markdown2.markdown(pkg.description), sep

...after a quick search the following package descriptions will need to
be changed:

perl-Regexp-Shellish-0.93-4.fc9
txt2tags-2.5-4.fc9
geeqie-1.0-0.4.alpha1.fc9
tinyca2-0.7.5-3.fc7
moreutils-0.28-3.fc9
alpine-2.00-1.fc9
FEDORA-2008-5191

...the biggest problem seems to be parsing lists, for instance lists
with a "large" indent like "       * item 1" which markdown parses as a
<pre><code> block or using lists but using '-' or 'o' etc. instead of
'*', so markdown again fails to parse them as lists (I also assume it'll
fail to parse ? too).

 I'm actually somewhat impressed by how well it does, but it still
requires a change in behaviour for a known tag ... and obviously doesn't
work anywhere near as well as what we have in yum (which just does
wrapping).

> > The problem is that Markdown and other non-intrusive formats (like
> > reStructuredText) don't have enough information to tell if it's
> > "invalid".  For instance, if my Bodhi comments have:
> > 
> > # Fix an issue with char *foobar and all void* on gcc-5
> > # Fix call to __init__ in python bindings.
> 
> Then you're going to get two titles. Seriously - who does that? If you
> follow what 99% of other people are doing and either do:
> 
> * lists
>  * that
>  - most
> - people
>  +   use
>
> Then it'll just work.

 Not quite. For instance:

msg = """\
If you follow what x% of other people are doing and do:

* lists
 * that
 - most
- people
 +   use

Then it'll just work.
"""

msg = """\
If you follow what y% of other people are doing and do:
* lists
 * that
 - most
- people
 +   use

Then it'll just fail.
"""

...it also seems to pass &blah; straight through to the html output,
although maybe that's a bug in the module?

-- 
James Antill <james at fedoraproject.org>
Fedora



From ivazqueznet at gmail.com  Thu Dec 18 16:02:37 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 18 Dec 2008 11:02:37 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <7f692fec0812180751o45f67bc2r599077362ed80cb8@mail.gmail.com>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<7f692fec0812180751o45f67bc2r599077362ed80cb8@mail.gmail.com>
Message-ID: <1229616157.3741.83.camel@ignacio.lan>

On Thu, 2008-12-18 at 10:51 -0500, Yaakov Nemoy wrote:
> xmonad doesn't
> honor --replace or most other window manager command line options, and
> metacity is no longer listed in the sessions capplet.

> All i'm looking to do is just get rid of metacity, and use
> more unixy methods to load xmonad.

Then xmonad has to support these unixy methods, including --replace.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/5db3277c/attachment.sig>

From jspaleta at gmail.com  Thu Dec 18 16:05:47 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Dec 2008 07:05:47 -0900
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812180927.05026.sgrubb@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <4949501C.90003@behdad.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<200812180927.05026.sgrubb@redhat.com>
Message-ID: <604aa7910812180805k77653cc6w9d7deee887bc0ab8@mail.gmail.com>

On Thu, Dec 18, 2008 at 5:27 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> We ran into a problem doing the LSPP evaluation with regards to email. Of all
> the packages listed, the only one that really mattered for security was cron.
> So, what we did was patched cron to be able to take an argument, -m, to
> define the mail delivery agent. It could be a shell script, procmail, or
> anything you wanted to take the cron output and move it into the local spool
> dir. Would using this solve the problems being debated here?  (And since cron
> can take a mail agent argument, it should not have a hard requirement for
> sendmail.)

How would you expose the option to use the argument for a local admin?
Having them edit the service file in init.d seems inappropriate. Would
you expose it in an etc/sysconfig/  file to be parsed at service
script start?

-jef



From pertusus at free.fr  Thu Dec 18 16:14:52 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Dec 2008 17:14:52 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812180927.05026.sgrubb@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <4949501C.90003@behdad.org>
	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>
	<200812180927.05026.sgrubb@redhat.com>
Message-ID: <20081218161452.GB14758@free.fr>

On Thu, Dec 18, 2008 at 09:27:04AM -0500, Steve Grubb wrote:
> 
> We ran into a problem doing the LSPP evaluation with regards to email. Of all 
> the packages listed, the only one that really mattered for security was cron. 
> So, what we did was patched cron to be able to take an argument, -m, to 
> define the mail delivery agent. It could be a shell script, procmail, or 
> anything you wanted to take the cron output and move it into the local spool 
> dir. Would using this solve the problems being debated here?  (And since cron 
> can take a mail agent argument, it should not have a hard requirement for 
> sendmail.)

I propose a virtual provides mail(local), in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=472710
You can skip right to
https://bugzilla.redhat.com/show_bug.cgi?id=472710#c20

--
Pat



From limb at jcomserv.net  Thu Dec 18 16:17:03 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 10:17:03 -0600 (CST)
Subject: orphaning all my packages
In-Reply-To: <20081217192929.GA2364@free.fr>
References: <20081216094739.GA3877@free.fr>
	<6127d4ff49e510ce9d9f6ae31ed404c4.squirrel@mail.jcomserv.net>
	<6281b553c0ecd1705d2707b7742bbaef.squirrel@mail.jcomserv.net>
	<20081217192929.GA2364@free.fr>
Message-ID: <1383a23785081522d35378fc4081dd6d.squirrel@mail.jcomserv.net>


> On Wed, Dec 17, 2008 at 07:54:14AM -0600, Jon Ciesla wrote:
>>
>> >
>> > I'll take these.
>>
>> All branches. Sorry.
>
> Very good. I invested a lot of work in this package, it would be nice
> if it wasn't lost. And since it is old, big, fortran and imake I feared
> nobody would want it.
>
> F9 and F10 branches released.

Thanks, I'll take all branches of xbae, too.

I was looking for a challenge. :)

> --
> Pat
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From hughsient at gmail.com  Thu Dec 18 16:17:35 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 18 Dec 2008 16:17:35 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229615827.6392.109.camel@code.and.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan> <49496940.20706@gmail.com>
	<1229609395.3651.19.camel@hughsie-work.lan>
	<1229615827.6392.109.camel@code.and.org>
Message-ID: <1229617055.3651.55.camel@hughsie-work.lan>

On Thu, 2008-12-18 at 10:57 -0500, James Antill wrote:
> perl-Regexp-Shellish-0.93-4.fc9
> txt2tags-2.5-4.fc9
> geeqie-1.0-0.4.alpha1.fc9
> tinyca2-0.7.5-3.fc7
> moreutils-0.28-3.fc9
> alpine-2.00-1.fc9
> FEDORA-2008-5191

Cool, that's a much smaller list that I expected. Thanks for looking
into this.

> ...the biggest problem seems to be parsing lists, for instance lists
> with a "large" indent like "       * item 1" which markdown parses as a
> <pre><code> block or using lists but using '-' or 'o' etc. instead of
> '*', so markdown again fails to parse them as lists (I also assume it'll
> fail to parse ? too).

Yes, I think we just need to standardize. Most packages I've seen fall
into the "already work" camp.

>  I'm actually somewhat impressed by how well it does, but it still
> requires a change in behaviour for a known tag ... and obviously doesn't
> work anywhere near as well as what we have in yum (which just does
> wrapping).

Right, I too am impressed with markdown. I've written a GObject for
gnome-packagekit that decodes markdown to pango or text output in a
simple fast pass.

>  Not quite. For instance:
> 
> msg = """\
> If you follow what x% of other people are doing and do:
> 
> * lists
>  * that
>  - most
> - people
>  +   use
> 
> Then it'll just work.
> """
> 
> msg = """\
> If you follow what y% of other people are doing and do:
> * lists
>  * that
>  - most
> - people
>  +   use
> 
> Then it'll just fail.

Ahh, my simple markup parser is a bit more tolerant to this and formats
the bullets correctly.

Richard.




From karsten at redhat.com  Thu Dec 18 16:30:10 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Thu, 18 Dec 2008 17:30:10 +0100
Subject: Usage of {_libdir} or {_lib} in noarch packages
Message-ID: <494A7A92.9020404@redhat.com>

I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages
which erronously use  {_libdir} or {_lib} in their spec files. rpmdiff shows this output:

./firstaidkit-0.2.2-5.fc11.noarch.rpm
removed    /usr/lib/firstaidkit
removed    /usr/lib/firstaidkit/plugins
added      /usr/lib64/firstaidkit
added      /usr/lib64/firstaidkit/plugins

As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs

Here is the list of offending packages I've found:


Package        Owner
------------------------
ntfs-config    laxathom
firstaidkit    msivak
terminus-font  ndim
gdeskcal       pfj
libopensync-plugin-synce  awjb
cohoba         tjikkun
gnome-schedule farnold
common-lisp-controller  green
gcstar         tian
revisor-cli    jsteffan
jruby          konradm



Can we make it a policy to not use _libdir or _lib in noarch packages, please ?



        Karsten



From a.badger at gmail.com  Thu Dec 18 16:27:28 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 18 Dec 2008 08:27:28 -0800
Subject: certificate revoked?
In-Reply-To: <1229612013.12194.14.camel@choeger5.umpa.netz>
References: <1229606541.12194.5.camel@choeger5.umpa.netz>	<c549477884353bbd9cff5bfd9a21509f.squirrel@mail.jcomserv.net>
	<1229612013.12194.14.camel@choeger5.umpa.netz>
Message-ID: <494A79F0.1060509@gmail.com>

Christoph H?ger wrote:
> 
> I've just re-setup my fedora devel environment on this box. I've created
> the browser cert a few hours ago, and look at this:
> 
> [choeger at choeger5 ~]$ ls -l .fed*
> -rw------- 1 choeger choeger 10115 18. Dez 13:35 .fedora.cert
> -rw------- 1 choeger choeger  6162  7. Nov 08:20 .fedora-server-ca.cert
> -rw------- 1 choeger choeger  6162  7. Nov 08:20 .fedora-upload-ca.cert
> 
> So what i the problem? Who revoked my certs?
> 

I see this for your username in the logs:

R       090616123503Z   081218123515Z   10D1
V       090616123516Z           10D2

That means that you were issued cert 10D1 and immediately afterwards
revoked that and were issued 10D2.  I've seem other cases of this before
 so I'm wondering why this happens.  Did you double click the link?  Did
it take a while and you clicked the link a second time to take you to
the certificate?  Just trying to diagnose why this happens.

(The solution should be to simply download a new cert with only single
clicks... so far that has worked for everyone we've talked to.  But we
haven't discovered why it does this in the first place.)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/257a4d62/attachment.sig>

From rc040203 at freenet.de  Thu Dec 18 16:36:57 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 18 Dec 2008 17:36:57 +0100
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <494A7A92.9020404@redhat.com>
References: <494A7A92.9020404@redhat.com>
Message-ID: <1229618217.14090.543.camel@beck.corsepiu.local>

On Thu, 2008-12-18 at 17:30 +0100, Karsten Hopp wrote:
> I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages
> which erronously use  {_libdir} or {_lib} in their spec files. rpmdiff shows this output:
> 
> ./firstaidkit-0.2.2-5.fc11.noarch.rpm
> removed    /usr/lib/firstaidkit
> removed    /usr/lib/firstaidkit/plugins
> added      /usr/lib64/firstaidkit
> added      /usr/lib64/firstaidkit/plugins
> 
> As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs
> 
> Here is the list of offending packages I've found:
> 
> 
> Package        Owner
> ------------------------
> ntfs-config    laxathom
> firstaidkit    msivak
> terminus-font  ndim
> gdeskcal       pfj
> libopensync-plugin-synce  awjb
> cohoba         tjikkun
> gnome-schedule farnold
> common-lisp-controller  green
> gcstar         tian
> revisor-cli    jsteffan
> jruby          konradm
> 
> 
> 
> Can we make it a policy to not use _libdir or _lib in noarch packages, please ?
Wouldn't it be better to let rpm set _libdir/_lib to match noarch
package requirements?

Ralf




From lesmikesell at gmail.com  Thu Dec 18 16:21:07 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 18 Dec 2008 10:21:07 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812180805k77653cc6w9d7deee887bc0ab8@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<4949501C.90003@behdad.org>	<604aa7910812171124y5eb03206k2d74bc0f5b1d019d@mail.gmail.com>	<200812180927.05026.sgrubb@redhat.com>
	<604aa7910812180805k77653cc6w9d7deee887bc0ab8@mail.gmail.com>
Message-ID: <494A7873.6050205@gmail.com>

Jeff Spaleta wrote:
> On Thu, Dec 18, 2008 at 5:27 AM, Steve Grubb <sgrubb at redhat.com> wrote:
>> We ran into a problem doing the LSPP evaluation with regards to email. Of all
>> the packages listed, the only one that really mattered for security was cron.
>> So, what we did was patched cron to be able to take an argument, -m, to
>> define the mail delivery agent. It could be a shell script, procmail, or
>> anything you wanted to take the cron output and move it into the local spool
>> dir. Would using this solve the problems being debated here?  (And since cron
>> can take a mail agent argument, it should not have a hard requirement for
>> sendmail.)
> 
> How would you expose the option to use the argument for a local admin?
> Having them edit the service file in init.d seems inappropriate. Would
> you expose it in an etc/sysconfig/  file to be parsed at service
> script start?

That just seems like the wrong place to short-circuit an existing good 
general solution.  If you want root's mail to go somewhere else, use 
aliases or .procmailrc.  If you want to splat text onto a screen on the 
odd chance that someone who cares happens to be watching, add a program 
that takes a message on a pipe and does that, and use the existing 
mechanisms to run it.  Or add one that alerts for mailbox deliveries. 
But don't break the well-designed ability to send to multiple 
destinations, including local and non-local for the people who actually 
do want the messages.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sandeen at redhat.com  Thu Dec 18 16:43:14 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 18 Dec 2008 10:43:14 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494977E0.1000209@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>	<49467E08.2080806@redhat.com>	<49467EA4.2060909@redhat.com>	<1229546027.2882.3.camel@sb-home>	<494965FB.7030601@redhat.com>
	<494977E0.1000209@gmail.com>
Message-ID: <494A7DA2.6090902@redhat.com>

Les Mikesell wrote:

> Hasn't there always been a problem with xfs and 4k stacks?  Or are you 
> only talking about 64-bit versions here?

Well, we weren't talking about stacks :) but yeah, xfs can use more
stack than ext3, and on a complex IO path that can be a problem.  But
4kstacks are another thing taken as holy gospel (though only on x86 for
some reason) so I doubt that will change.

I'm not really serious about xfs as default, btw, but did feel it
necessary to re-educate on the whole "null files" thing.  :)

-Eric



From mw_triad at users.sourceforge.net  Thu Dec 18 16:46:42 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 18 Dec 2008 10:46:42 -0600
Subject: RFC: Description text in packages
In-Reply-To: <200812181117.34596.billcrawford1970@gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<1229456805.15451.2.camel@arekh.okg>
	<gi91p1$ssr$1@ger.gmane.org>
	<200812181117.34596.billcrawford1970@gmail.com>
Message-ID: <gidupi$lhi$1@ger.gmane.org>

Bill Crawford wrote:
> On Tuesday 16 December 2008 20:06:57 Matthew Woehlke wrote:
> 
>> What's the fourth level? Not alt, that's used for accelerators. Not
>> ctrl, shift, meta, or any combination thereof, as those are for
>> shortcuts. That leaves... menu, and combinations thereof. If
>> menu+something does something special, I sure don't know about it.
>>
>> You still haven't answered the education question.
> 
> It's usually "Alt Gr" or "AltGr" (alternative graphic) and that is (again, 
> *usually*) the "right alt" key. My keyboard has it labelled that way, so it is 
> not intended for accelerators.

I did, in fact, know that :-), and I understand that's typical of non-US 
keyboards. My US keyboard however has two keys labeled "Alt". Both of 
them do, in fact, work to activate the menu (or other accelerators).

...which is the point I was trying to make to Nicolas; when dealing with 
current US keyboards, there is no precedent for a compose key. That's a 
lot of inertia to overcome, and (to respond to Nicolas' other comment), 
there IS NO EDUCATION SYSTEM IN PLACE right now, that I am aware of.

I keep waiting for a proposal to fix that. I haven't heard one yet.

(Bill: I've sort of hijacked your post, sorry about that :-).)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
???????????????????????



From ville.skytta at iki.fi  Thu Dec 18 16:47:34 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 18 Dec 2008 18:47:34 +0200
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081218094440.3c13a7f3@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172152.30869.ville.skytta@iki.fi>
	<20081218094440.3c13a7f3@infradead.org>
Message-ID: <200812181847.35253.ville.skytta@iki.fi>

On Thursday 18 December 2008, Arjan van de Ven wrote:
> On Wed, 17 Dec 2008 21:52:30 +0200
> Ville Skytt? <ville.skytta at iki.fi> wrote:

> > - shutdown: 28 sec
> > - fresh boot: 66 sec
>
> see this is the problem; this can be 5 to 10 seconds, and should be.
> that's the point of this discussion

Well, you said earlier:

> > > I suspect you will always be able to boot faster than you can
> > > hibernate+resume.

Maybe I'm just having a problem parsing that.  Does "will" here mean that it 
will be like that in the future after $something gets done?



From tcallawa at redhat.com  Thu Dec 18 16:50:37 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 18 Dec 2008 11:50:37 -0500
Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch
 packages
In-Reply-To: <1229618217.14090.543.camel@beck.corsepiu.local>
References: <494A7A92.9020404@redhat.com>
	<1229618217.14090.543.camel@beck.corsepiu.local>
Message-ID: <1229619037.3472.26.camel@localhost.localdomain>

On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
> Wouldn't it be better to let rpm set _libdir/_lib to match noarch
> package requirements?

What should it set it to? It has no knowledge of where the noarch rpm
package will eventually be installed. Should we assume that /usr/lib is
always correct (how Debian of me to even suggest this)?

~spot



From sgrubb at redhat.com  Thu Dec 18 16:52:59 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 18 Dec 2008 11:52:59 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812180805k77653cc6w9d7deee887bc0ab8@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <200812180927.05026.sgrubb@redhat.com>
	<604aa7910812180805k77653cc6w9d7deee887bc0ab8@mail.gmail.com>
Message-ID: <200812181153.00287.sgrubb@redhat.com>

On Thursday 18 December 2008 11:05:47 am Jeff Spaleta wrote:
> On Thu, Dec 18, 2008 at 5:27 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> > We ran into a problem doing the LSPP evaluation with regards to email. Of
> > all the packages listed, the only one that really mattered for security
> > was cron. So, what we did was patched cron to be able to take an
> > argument, -m, to define the mail delivery agent. It could be a shell
> > script, procmail, or anything you wanted to take the cron output and move
> > it into the local spool dir. Would using this solve the problems being
> > debated here?  (And since cron can take a mail agent argument, it should
> > not have a hard requirement for sendmail.)
>
> How would you expose the option to use the argument for a local admin?

In /etc/sysconfig/crond, there is the CRONDARGS variable where it can be set.

-Steve



From jkeating at redhat.com  Thu Dec 18 16:53:18 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Dec 2008 08:53:18 -0800
Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch
 packages
In-Reply-To: <1229619037.3472.26.camel@localhost.localdomain>
References: <494A7A92.9020404@redhat.com>
	<1229618217.14090.543.camel@beck.corsepiu.local>
	<1229619037.3472.26.camel@localhost.localdomain>
Message-ID: <1229619198.6191.106.camel@localhost.localdomain>

On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote:
> On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
> > Wouldn't it be better to let rpm set _libdir/_lib to match noarch
> > package requirements?
> 
> What should it set it to? It has no knowledge of where the noarch rpm
> package will eventually be installed. Should we assume that /usr/lib is
> always correct (how Debian of me to even suggest this)?
> 
> ~spot

Also, how does one get this right in the age of noarch subpackages to
arch specific packages?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/3f477bb2/attachment.sig>

From devzero2000 at rpm5.org  Thu Dec 18 16:55:02 2008
From: devzero2000 at rpm5.org (devzero2000)
Date: Thu, 18 Dec 2008 17:55:02 +0100
Subject: query post/postun/preun dependencies for a rpm
In-Reply-To: <alpine.DEB.1.10.0812181731350.13881@gotcha.dreamhost.com>
References: <200812181355.10028.opensource@till.name>
	<b086760e0812180552i26cadfaen9906611ee75764af@mail.gmail.com>
	<alpine.DEB.1.10.0812181731350.13881@gotcha.dreamhost.com>
Message-ID: <b086760e0812180855q6ac67eecse9533d99498871d1@mail.gmail.com>

Yes, I know.

Do you think is it necessary o useful to store in rpmheader information on
Require(post) anyway ?  Why should be rpm or a depsolver use it after
install ? Apart query it, of course.

Elia

On Thu, Dec 18, 2008 at 4:33 PM, Panu Matilainen
<pmatilai at laiskiainen.org>wrote:

> On Thu, 18 Dec 2008, devzero2000 wrote:
>
>  The Requires(post) context marker exists only for breaking loop deps at
>> the install package time.So it is not necessary to register them in an
>> rpmdb because they were needed only
>> for installing, not for using or erasing, a package. The %post scriptlet
>> is run only during install, never run after install.
>>
>
> They're filtered out from the require *index*, not the headers stored in
> rpmdb. Very different thing.
>
>        - Panu -
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/faca4741/attachment.htm>

From james at fedoraproject.org  Thu Dec 18 16:56:07 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 18 Dec 2008 11:56:07 -0500
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229617055.3651.55.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229380985.29700.197.camel@atropine.boston.devel.redhat.com>
	<1229416413.3434.3.camel@hughsie-work.lan>
	<385866f0812160932w5d3532f5yc554fdc2dfc7b0f6@mail.gmail.com>
	<1229451449.13024.6.camel@arekh.okg>
	<20081216201640.GB8506@nostromo.devel.redhat.com>
	<1229460222.15689.53.camel@arekh.okg> <gi94q2$7eb$2@ger.gmane.org>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan> <49496940.20706@gmail.com>
	<1229609395.3651.19.camel@hughsie-work.lan>
	<1229615827.6392.109.camel@code.and.org>
	<1229617055.3651.55.camel@hughsie-work.lan>
Message-ID: <1229619367.6392.118.camel@code.and.org>

On Thu, 2008-12-18 at 16:17 +0000, Richard Hughes wrote:
> On Thu, 2008-12-18 at 10:57 -0500, James Antill wrote:
> > perl-Regexp-Shellish-0.93-4.fc9
> > txt2tags-2.5-4.fc9
> > geeqie-1.0-0.4.alpha1.fc9
> > tinyca2-0.7.5-3.fc7
> > moreutils-0.28-3.fc9
> > alpine-2.00-1.fc9
> > FEDORA-2008-5191
> 
> Cool, that's a much smaller list that I expected. Thanks for looking
> into this.

 That wasn't a canonical list (I'm not sure we can easily generate that
without just having users say XYZ looks wrong), although from my testing
there aren't "many" packages that contain "\n  " which is one of the
problems:

x = yb.pkgSack.returnPackages()
x = filter(lambda x: x.description.find('\n  ') != -1, x)
x = yum.packageSack.packagesNewestByName(x)
# F9, len(x) == 213

...my point was more that although there might not be a lot of them
there _are_ known packages which will fail. So we can't just say
"everything works, and we have new features".

> >  Not quite. For instance:
> > 
> > msg = """\
> > If you follow what x% of other people are doing and do:
> > 
> > * lists
> >  * that
> >  - most
> > - people
> >  +   use
> > 
> > Then it'll just work.
> > """
> > 
> > msg = """\
> > If you follow what y% of other people are doing and do:
> > * lists
> >  * that
> >  - most
> > - people
> >  +   use
> > 
> > Then it'll just fail.
> 
> Ahh, my simple markup parser is a bit more tolerant to this and formats
> the bullets correctly.

 So, it's not markdown then surely? Can you point to some python that
implements your version?

-- 
James Antill <james at fedoraproject.org>
Fedora



From ville.skytta at iki.fi  Thu Dec 18 16:59:12 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 18 Dec 2008 18:59:12 +0200
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <gida1s$ap3$1@ger.gmane.org>
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229590959.3612.57.camel@eagle.danny.cz>
	<gida1s$ap3$1@ger.gmane.org>
Message-ID: <200812181859.12885.ville.skytta@iki.fi>

On Thursday 18 December 2008, Kevin Kofler wrote:
> Dan Hor?k wrote:
> > I have checked all packages that link with the "base" wxGTK library and
> > no other package is affected, they all use wxGTK-devel.
>
> I think we should have some guideline that such versioned Provides should
> be kept indefinitely and packages should use them where available.

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages
(especially the last 2 paragraphs)

We encourage garbage collecting old cruft, keeping it around indefinitely 
should be a pretty rare exception for quite specific cases (or at least 
that's the way I remember it when we worked on it in FPC).

I suppose that a "should add specfile comment if some compatibility are 
intended to be kept around indefinitely" note should be added in the above 
doc though, currently it's only a "should" for the common case where stuff is 
intended to be cleaned up later.



From rc040203 at freenet.de  Thu Dec 18 17:00:01 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 18 Dec 2008 18:00:01 +0100
Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch
 packages
In-Reply-To: <1229619037.3472.26.camel@localhost.localdomain>
References: <494A7A92.9020404@redhat.com>
	<1229618217.14090.543.camel@beck.corsepiu.local>
	<1229619037.3472.26.camel@localhost.localdomain>
Message-ID: <1229619601.14090.592.camel@beck.corsepiu.local>

On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote:
> On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
> > Wouldn't it be better to let rpm set _libdir/_lib to match noarch
> > package requirements?
> 
> What should it set it to? It has no knowledge of where the noarch rpm
> package will eventually be installed.
It has. In case of noarch _lib always is the "default", which normally
is lib.

>  Should we assume that /usr/lib is
> always correct (how Debian of me to even suggest this)?
In case of noarch, yes.
 
Because an arch'aware (e.g. lib vs. lib64) _lib/_libdir qualifies a
package as "arch'ed" 

Ralf




From sgrubb at redhat.com  Thu Dec 18 17:03:30 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 18 Dec 2008 12:03:30 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494A7873.6050205@gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<604aa7910812180805k77653cc6w9d7deee887bc0ab8@mail.gmail.com>
	<494A7873.6050205@gmail.com>
Message-ID: <200812181203.30856.sgrubb@redhat.com>

On Thursday 18 December 2008 11:21:07 am Les Mikesell wrote:
> That just seems like the wrong place to short-circuit an existing good
> general solution. 

Cron is the only thing that is installed in a default setup that actually 
requires mail delivery. For most people, a shell script will do all that's 
required. Anyone needing something more sophisticated can easily add postfix 
or another MTA to do what they want. As for the other apps, they would 
obviously pull in by Requires a real MTA.

We had to make this short circuit for LSPP because there is no Open Source 
mail system that understands MLS. But what we did might solve the 99% use 
case.

-Steve



From rawhide at fedoraproject.org  Thu Dec 18 17:22:56 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 18 Dec 2008 17:22:56 +0000 (UTC)
Subject: rawhide report: 20081218 changes
Message-ID: <20081218172256.DFEB01F8250@releng2.fedora.phx.redhat.com>

Compose started at Thu Dec 18 06:08:17 UTC 2008

New package gupnp-ui
        GUPnP-UI is a collection of helpers for adding ui to upnp apps
New package ifuse
        Mount Apple iPhone and iPod touch devices
New package libspiro
        Library to simplify the drawing of beautiful curves
New package openconnect
        Open client for Cisco AnyConnect VPN
New package pdfbook
        Rearrange pages in a PDF file into signatures
New package perl-Class-Adapter
        Perl implementation of the "Adapter" Design Pattern
New package perl-Class-XSAccessor
        Generate fast XS accessors without runtime compilation
New package python-zope-filesystem
        Python-Zope Libraries Base Filesystem
New package symmetrica
        A Collection of Routines for Solving Symmetric Groups
New package terminator
        Store and run multiple GNOME terminals in one window
Removed package tk-tktreectrl
Updated Packages:

Cython-0.10.3-1.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.10.3-1
- Update to 0.10.3


GConf2-2.24.0-3.fc11
--------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.0-3
- Rebuild for pkg-config requires

* Fri Nov 21 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.0-2
- Better URL


ace-0.0.4-1.fc11
----------------

akonadi-1.0.81-1.fc11
---------------------
* Tue Dec 16 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0.81-1
- 1.0.81


andika-fonts-1.0-3.fc11
-----------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 1.0-3
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 1.0-2
? Rebuild using new ??rpm-fonts??


apanov-heuristica-fonts-20081109-3.fc11
---------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20081109-3
? ?rpm-fonts? renamed to ?fontpackages?


atlas-3.8.2-4.fc11
------------------
* Tue Dec 16 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.8.2-4
- Don't symlink the atlas libdir on i386, cause upgrade issue (BZ#476787)
- Fix options passed to gcc when making shared libs

* Tue Dec 16 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.8.2-3
- Use 'gcc -shared' to build shared libs instead of stock 'ld'

* Sat Dec 13 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.8.2-2
- Properly obsolete/provide older subpackages that are no longer packaged.

* Mon Sep  1 18:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.8.2-1
- Upgrade to ver 3.8.2 with refined build procedures.


audacity-1.3.5-0.10.beta.fc11
-----------------------------
* Wed Dec 17 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.3.5-0.9.beta
- rebuild in Rawhide for new SONAME in vamp-plugin-sdk
- BR wxGTK-devel for rename of wxGTK2-devel

* Wed Dec 17 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.3.5-0.10.beta
- patch include paths for changes in new vamp-plugin-sdk-devel


audit-1.7.10-2.fc11
-------------------
* Wed Dec 17 17:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.10-2
- Fix bz 476798 -  "auditd -n" does not work


bind-9.6.0-0.6.rc1.fc11
-----------------------
* Tue Dec 16 17:00:00 2008 Martin Nagy <mnagy redhat com> 32:9.6.0-0.6.rc1
- add patch for dynamic loading of database backends

* Tue Dec  9 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.5.1.rc1
- allow to reuse address for non-random query-source ports (#475120)


bitstream-vera-fonts-1.10-12.fc11
---------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 1.10-12
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 1.10-11
? Rebuild using new ??rpm-fonts??


boost-1.37.0-1.fc11
-------------------
* Tue Dec 16 17:00:00 2008 Benjamin Kosnik <bkoz at redhat.com> - 1.37.0-1
- Fix rpmlint rpath errors.
- Fix rpmlint warnings on tabs and spaces.
- Bump SONAME to 4

* Mon Nov 17 17:00:00 2008 Benjamin Kosnik <bkoz at redhat.com> - 1.37.0-0.1
- Rebase to 1.37.0.

* Tue Oct 21 18:00:00 2008 Benjamin Kosnik <bkoz at redhat.com> - 1.36.0-1
- Rebase to 1.36.0.


cairo-dock-2.0.0-0.2.svn1443_trunk.fc11
---------------------------------------
* Thu Dec 18 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1443

* Wed Dec 17 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Trial fix to compile motion-blur plugin on rev 1439


certmaster-0.24-1.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Adrian Likins <alikins at redhat.com> - 0.24-1
- add missing dirs as per bz#473633


charis-fonts-4.104-4.fc11
-------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 4.104-4
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 4.104-3
? Rebuild using new ??rpm-fonts??


cheese-2.25.3-1.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 2.25.3-1
- Update to 2.25.3


cherokee-0.11.2-3.fc11
----------------------
* Tue Dec 16 17:00:00 2008 Pavel Lisy <pavel.lisy at gmail.com> - 0.11.2-3
- ppc arch excluded only for el4

* Tue Dec 16 17:00:00 2008 Pavel Lisy <pavel.lisy at gmail.com> - 0.11.2-2
- ppc arch excluded

* Tue Dec 16 17:00:00 2008 Pavel Lisy <pavel.lisy at gmail.com> - 0.11.2-1
- updated to 0.11.2

* Tue Dec 16 17:00:00 2008 Pavel Lisy <pavel.lisy at gmail.com> - 0.10.0-3
- Unowned directories, Resolves bz 474634


cluster-3.0.0-1.alpha1.fc11
---------------------------
* Wed Dec 17 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 3.0.0-1.alpha1
- New upstream release.
- Fix legacy code build.
- Fix wrong conffile attribute.


control-center-2.25.2-7.fc11
----------------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-7
- Drop eel dependency


cups-1.4-0.b2.2.fc11
--------------------
* Tue Dec 16 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1:1.4-0.b2.2
- 1.4b2.
- No longer need CVE-2008-5183 patch.

* Sat Dec 13 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1:1.4-0.b1.6
- Start cupsd at priority 25: after avahi-daemon but before haldaemon
  (bug #468709).

* Tue Dec  9 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1:1.4-0.b1.5
- Applied patch to fix RSS subscription limiting (bug #473901,
  CVE-2008-5183).
- Attempt to unbreak the fix for STR #2831 (bug #474742).


dejavu-fonts-2.27-7.fc11
------------------------
* Sat Dec  6 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 2.27-7
? Add explicit conflicts to help yum

* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 2.27-5
? ?rpm-fonts? renamed to ?fontpackages?

* Wed Nov 12 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 2.27-4
? Tweak using new ??rpm-fonts??

* Mon Nov 10 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 2.26-7
? Rebuild using new ??rpm-fonts??


deluge-1.0.7-1.fc11
-------------------
* Tue Dec 16 17:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 1.0.7-1
- Update to new upstream bug-fix release (1.0.7)
- Remove CC-BY-SA license (the Tango WebUI images have been replaced by upstream).


ds9-5.4-2.fc11
--------------
* Wed Dec 17 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> - 5.4-2
- Readded dependency in tcllib (bz #476840)


dvd+rw-tools-7.1-2.fc11
-----------------------
* Wed Dec 17 17:00:00 2008 Roman Rakus <rrakus at redhat.com> - 7.1-2
- Allow burn small images on dvd-dl
  Resolves: #476154


dwdiff-1.5-2.fc11
-----------------
* Tue Dec 16 17:00:00 2008 Jakub Hrozek <jhrozek at redhat.com> 1.5-2
- Modify the localedir patch to allow build with fuzz=0 and version 1.5

* Tue Dec 16 17:00:00 2008 Jakub Hrozek <jhrozek at redhat.com> 1.5-1
- New upstream release

* Tue Dec  2 17:00:00 2008 Jakub Hrozek <jhrozek at redhat.com> 1.4-3
- Shorten summary so it's PackageKit friendly


ecolier-court-fonts-20070702-5.fc11
-----------------------------------
* Wed Dec 17 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070702-5
? Workaround RHEL5 rpm unicode bug to fix koji build

* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070702-4
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070702-3
? Rebuild using new ??rpm-fonts??


ecore-0.9.9.050-3.fc11
----------------------
* Wed Dec 17 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.050-3
- rebuilt

* Wed Dec 17 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.050-2
- Rebuilt


edrip-fonts-20081007-2.fc11
---------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20081007-2
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20081007-1
? Rebuild using new ??rpm-fonts??


eel2-2.25.1-4.fc11
------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-4
- Rebuild against new gnome-desktop


eog-2.25.3-2.fc11
-----------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-2
- Update to 2.25.3


epdfview-0.1.6-7.20081217svn.fc11
---------------------------------
* Wed Dec 17 17:00:00 2008 Michal Schmidt <mschmidt at redhat.com> - 0.1.6-7.20081217svn
- Add icon.

* Wed Dec 17 17:00:00 2008 Michal Schmidt <mschmidt at redhat.com> - 0.1.6-6.20081217svn
- Rebased to current svn snapshot.
- Fixes bz476575 "epdfview crashes on print pdf".


epiphany-2.24.2.1-2.fc11
------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2.1-2
- Rebuild against new gnome-desktop


fftw-3.2-2.fc11
---------------

firstboot-1.104-1.fc11
----------------------
* Tue Dec 16 17:00:00 2008 Chris Lumens <clumens at redhat.com> 1.104-1
- Let X tell us when it's ready to run (ajax).
- Add a Requires: for authconfig-gtk (#474733).
- Log errors changing file permissions and notify (#473191).
- Improve the dialogs around reusing a home directory (#470461).
- Fix a crash when cancelling contacting an NTP server (#475304).
- Since you have to create a user now, change the message.


fontforge-20081215-2.fc11
-------------------------
* Wed Dec 17 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 20081215-2
- Add libspiro-devel to build with spiro

* Tue Dec 16 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 20081215-1
- Upgrade to 20081215
- Build with cairo and pango


fprintd-0.1-5.git43fe72a2aa.fc11
--------------------------------
* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.1-5.git43fe72a2aa
- Add patch to stop leaking a D-Bus connection on failure


freedroidrpg-0.11.1-1.fc11
--------------------------
* Tue Dec 16 17:00:00 2008 Wart <wart at kobold.org> - 0.11.1-1
- Update to 0.11.1


freefem++-3.0-2.3.fc11
----------------------
* Mon Dec 15 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.0-2.3
- Rebuild for atlas-3.8.2

* Wed Dec 10 17:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> 3.0-2.2
- update to 3.0-2
- fix compilation
- fix installation paths and path substitution in ff-c++
- preserve timestamps in make install
- add missing BR
- disable regression tests for now

* Fri Dec  5 17:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> 3.0-1.1
- update to 3.0
- fixed build of pdf doc
- dropped obsolete patch


func-0.24-1.fc11
----------------
* Wed Dec 17 17:00:00 2008 Adrian Likins <alikins at redhat.com> - 0.24-1
- require certmaster 0.24

* Mon Dec  8 17:00:00 2008 Adrian Likins <alikins at redhat.com> - 0.24-1
- claim ownership of all dirs bz#474644
- add dep on logrotate


gajim-0.12-1.fc11
-----------------
* Thu Dec 18 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.12-1
- Version bump to 0.12.
- Added 'Requires: notify-python python-kerberos'.


gcalctool-5.25.3-1.fc11
-----------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 5.25.3-1
- Update to 5.25.3


gdm-2.25.2-2.fc11
-----------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1:2.25.2-2
- Update to 2.25.2
- Drop the xkb groups workaround to see if the issue disappeared


gfs-ambrosia-fonts-20080624-3.fc11
----------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080624-3
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080624-2
? Rebuild using new ??rpm-fonts??


gfs-artemisia-fonts-20070415-9.fc11
-----------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-9
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-8
? Rebuild using new ??rpm-fonts??


gfs-baskerville-fonts-20070327-10.fc11
--------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070327-10
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070327-9
? Rebuild using new ??rpm-fonts??


gfs-bodoni-classic-fonts-20070415-9.fc11
----------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-9
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-8
? Rebuild using new ??rpm-fonts??


gfs-bodoni-fonts-20070415-8.fc11
--------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-8
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-7
? Rebuild using new ??rpm-fonts??


gfs-complutum-fonts-20070413-10.fc11
------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070413-10
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070413-9
? Rebuild using new ??rpm-fonts??


gfs-didot-classic-fonts-20080702-4.fc11
---------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080702-4
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080702-3
? Rebuild using new ??rpm-fonts??


gfs-didot-fonts-20070616-9.fc11
-------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070616-9
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070616-8
? Rebuild using new ??rpm-fonts??


gfs-eustace-fonts-20080303-3.fc11
---------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080303-3
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080303-2
? Rebuild using new ??rpm-fonts??


gfs-fleischman-fonts-20080303-3.fc11
------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080303-3
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080303-2
? Rebuild using new ??rpm-fonts??


gfs-garaldus-fonts-20080707-3.fc11
----------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080707-3
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080707-2
? Rebuild using new ??rpm-fonts??


gfs-gazis-fonts-20080318-5.fc11
-------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080318-5
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080318-4
? Rebuild using new ??rpm-fonts??


gfs-jackson-fonts-20080303-3.fc11
---------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080303-3
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080303-2
? Rebuild using new ??rpm-fonts??


gfs-neohellenic-fonts-20070415-8.fc11
-------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
-  20070415-8
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-7
? Rebuild using new ??rpm-fonts??


gfs-nicefore-fonts-20080303-3.fc11
----------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080303-3
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080303-2
? Rebuild using new ??rpm-fonts??


gfs-olga-fonts-20060908-8.fc11
------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20060908-8
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20060908-7
? Rebuild using new ??rpm-fonts??


gfs-porson-fonts-20060908-10.fc11
---------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20060908-10
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20060908-9
? Rebuild using new ??rpm-fonts??


gfs-solomos-fonts-20071114-9.fc11
---------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20071114-9
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20071114-8
? Rebuild using new ??rpm-fonts??


gfs-theokritos-fonts-20070415-11.fc11
-------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-11
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20070415-10
? Rebuild using new ??rpm-fonts??


ghc-gtk2hs-0.9.13-7.20081108.fc11
---------------------------------
* Wed Dec 17 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.9.13-7.20081108
- turn on docs and buildrequire ghc-doc
- buildrequire dbus-devel for gconf private


gnome-commander-1.2.8-0.2.svn2361_trunk.fc11
--------------------------------------------
* Thu Dec 18 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2361


gnome-desktop-2.25.3-2.fc11
---------------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-2
- Update to 2.25.3


gnome-devel-docs-2.24.1-1.fc11
------------------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


gnome-doc-utils-0.14.1-1.fc11
-----------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.14.1-1
- Update to 0.14.1


gnome-games-2.25.3-1.fc11
-------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.3-1
- Update to 2.25.3


gnome-media-2.25.1-1.fc11
-------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com>  2.25.1-1
- Update to 2.25.1

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com>  2.24.0.1-3
- Tweak description


gnome-nettool-2.25.3-2.fc11
---------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-2
- Update to 2.25.3

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.22.1-3
- Tweak description


gnome-screensaver-2.25.2-1.fc11
-------------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2


gnome-session-2.25.3-1.fc11
---------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.3-1
- Update to 2.25.3


gnome-terminal-2.25.3-2.fc11
----------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-2
- Update to 2.25.3


gnome-themes-2.25.3-1.fc11
--------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-1
- Update to 2.25.3


gnome-user-docs-2.24.1-1.fc11
-----------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1

* Mon Sep 22 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-1
- Update to 2.24.0

* Wed Jul 23 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.22.0-2
- fix license tag


gnome-user-share-0.41-1.fc11
----------------------------
* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.41-1
- Update to 0.41


gnome-utils-2.24.1-4.fc11
-------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.1-4
- Rebuild against new gnome-desktop

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.1-3
- Improve description


gnucash-2.2.8-1.fc11
--------------------
* Tue Dec 16 17:00:00 2008 Bill Nottingham <notting at redhat.com> - 2.2.8-1
- update to 2.2.8

* Fri Dec  5 17:00:00 2008 Bill Nottingham <notting at redhat.com> - 2.2.7-2
- fix crash with glib-2.19 (#474511, <jik at kamens.brookline.ma.us>)


gtk2-2.14.6-1.fc11
------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.6-1
- Update to 2.14.6


gvfs-1.1.2-2.fc11
-----------------
* Wed Dec 17 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.1.2-2
- Update the smb-browse auth patch

* Tue Dec 16 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1.1.2-1
- Update to 1.1.2


gwibber-0.7.2-1.156bzr.fc11
---------------------------
* Wed Dec 17 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.7.2-1.156bzr
- Update upstream


harminv-1.3.1-14.fc11
---------------------
* Tue Dec 16 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 1.3-14
- It really doesn't need lapack-devel, my bad

* Tue Dec 16 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 1.3-13
- BR lapack-devel

* Mon Dec 15 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 1.3-12
- Rebuild for atlas-3.8.2

* Fri May 23 18:00:00 2008 Jon Stanley <jonstanley at gmail.com> - 1.3-11
- Fix license tag


hunspell-es-0.20081215-1.fc11
-----------------------------
* Tue Dec 16 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081215-1
- latest version


icu-4.0-5.fc11
--------------
* Tue Dec 16 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 4.0-5
- drop integrated icu.icu5557.safety.patch


iok-1.0.9-1.fc11
----------------
* Thu Dec 18 17:00:00 2008 Parag Nemade <panemade at gmail.com>- 1.0.9-1
- Update to Next release 1.0.9


itpp-4.0.0-6.fc11
-----------------
* Mon Dec 15 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 4.0.0-6
- Rebuild for atlas-3.8.2


java-1.5.0-gcj-1.5.0.0-25.fc11
------------------------------
* Wed Dec 17 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1.5.0.0-25
- Updated jgcver to 1.0.79.
- Updated release.


jd-2.1.0-0.2.svn2573_trunk.fc11
-------------------------------
* Thu Dec 18 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2573

* Tue Dec 16 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.0.3-0.2.beta081216
- 2.0.3 beta 081216


kadu-0.6.5-7.fc11
-----------------
* Tue Dec 16 17:00:00 2008 Micha? Bentkowski <mr.ecik at gmail.com> - 0.6.5-7
- Osd_hints tarball was missing in sources

* Tue Dec 16 17:00:00 2008 Micha? Bentkowski <mr.ecik at gmail.com> - 0.6.5-6
- Enable kadu-osd_hints by default

* Tue Dec 16 17:00:00 2008 Micha? Bentkowski <mr.ecik at gmail.com> - 0.6.5-5
- Fix conflicts with kadu-osd_hints and kadu-agent


kde-l10n-4.1.85-1.fc11
----------------------
* Fri Dec 12 17:00:00 2008 Than Ngo <than at redhat.com> - 4.1.85-1
- 4.2beta2

* Fri Nov 21 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-1
- 4.2 beta1


kdebase-workspace-4.1.85-3.fc11
-------------------------------
* Tue Dec 16 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 4.1.85-3
- respun tarball


kdelibs-4.1.85-5.fc11
---------------------
* Tue Dec 16 17:00:00 2008 Than Ngo <than at redhat.com> - 4.1.85-4
- add missing ENTITY systemsettings in pt, that fixes kde-l10
  build breakage

* Tue Dec 16 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.85-5
- respun tarball, integrates kde-l10n-systemsettings patch


kdepimlibs-4.1.85-2.fc11
------------------------
* Wed Dec 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 4.1.85-2
- versioned akonadi(-devel) deps


kdeplasma-addons-4.1.85-2.fc11
------------------------------
* Tue Dec 16 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.85-2
- saner versioned Obsoletes


kipi-plugins-0.2.0-0.8.beta5.fc11
---------------------------------
* Mon Dec 15 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.2.0-0.8.beta5
- kipi-plugins-0.0.2-beta5
- %description: reorder (alphabetic), simplify


libXext-1.0.4-2.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 1.0.4-2
- Rebuild for pkg-config auto-provides


libXrandr-1.2.99.4-1.fc11
-------------------------
* Wed Dec 17 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.2.99.4-1
- libXrandr 1.2.99.4


libgtop2-2.24.0-4.fc11
----------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-4
- Rebuild for pkg-config auto-provides


libgweather-2.25.3-2.fc11
-------------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.25.3-2
- Update to 2.25.3


libselinux-2.0.76-5.fc11
------------------------
* Tue Dec 16 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 2.0.76-5
- Fix segfault if seusers file does not work


libtheora-1.0-1.fc11
--------------------
* Tue Dec 16 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1:1.0-1
- 1.0 final release
- need epoch because we were not using the special pre-release
  version-release scheme used now a days in Fedora :(


libvirt-0.5.1-2.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Daniel Veillard <veillard at redhat.com> - 0.5.1-2.fc11
- fix missing read-only access checks, fixes CVE-2008-5086


libwnck-2.25.3-1.fc11
---------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-1
- Update to 2.25.3


lilypond-doc-2.11.65-1.fc11
---------------------------
* Wed Dec 17 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> 2.11.65-1
- Update to 2.11.65.


logwatch-7.3.6-38.fc11
----------------------
* Tue Dec 16 17:00:00 2008 Ivana Varekova <varekova at redhat.com> 7.3.6-38
- remove obsolete patches
- fix dovecot,named and openvpn scrpts(#476620)


mail-notification-5.4-6.fc11
----------------------------
* Wed Dec 17 17:00:00 2008 Dmitry Butskoy <Dmitry at Butskoy.name> - 5.4-6
- rebuild for dependencies


maniadrive-1.2-11.fc11
----------------------
* Wed Dec 17 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.2-11
- Rebuild for new php version


mash-0.4.7-1.fc11
-----------------
* Wed Dec 17 17:00:00 2008 Bill Nottingham <notting at redhat.com> 0.4.7-1
- Fix noarch handling

* Wed Dec 17 17:00:00 2008 Bill Nottingham <notting at redhat.com> 0.4.6-1
- Fix -p/--previous for certain repository layouts

* Tue Dec 16 17:00:00 2008 Bill Nottingham <notting at redhat.com> 0.4.5-1
- fix caching bug with respect to epochs
- work with both python createrepo API and commandline createrepo

* Tue Dec 16 17:00:00 2008 Bill Nottingham <notting at redhat.com> 0.4.4-1
- Mark gstreamer plugins as multilib (#252173)
- Some more multilib devel blacklisting, including php. (#342851)
- Add a --previous option, for copying createrepo data


maxima-5.17.1-1.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 5.17.1-1
- maxima-5.17.1


metacity-2.25.55-1.fc11
-----------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.55-1
- Update to 2.25.55

* Mon Dec 15 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.34-3
- Clean _NET_SUPPORTING_WM_CHECK on shutdown
- Fix BuildRequires


mono-2.2-12.pre3.20081217svn121664.fc11
---------------------------------------
* Wed Dec 17 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-12.pre3.20081217svn121664
- Fix libdir issue with monodoc

* Tue Dec 16 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-11.pre3.20081216svn121605
- Fixes problems with web references
- Fixes x86_64 build problems
- Added new web-devel subpackage

* Mon Dec 15 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-11.pre3.20081215svn121536
- Exclude ppc due to build problems (temporary)
- Moved to pre3 in sync with Novell releases

* Wed Dec 10 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-10.pre2.20081215svn121507
- removed the winform patch
- move to svn
- removed files no longer built
- removed vbnc manual

* Tue Dec  9 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-9.pre2
- remove the seds and just use patches

* Fri Dec  5 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-8.pre2
- Bump to 2.2 preview 2
- More sed fixes

* Thu Dec  4 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-7.pre1
- Add fix so that winforms doesn't need libgdiplus-devel
- Add fix so the sed script works correctly on x86_64

* Sun Nov 30 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-6.pre1
- missed a sed invocation

* Sun Nov 30 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-5.pre1
- new patch for winforms problems
- reorganised patches
- use sed to fix the incorrect libdir issues - experimental!!!!


mono-basic-2.2-6.pre3.20081217svn121665.fc11
--------------------------------------------
* Wed Dec 17 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-6.pre3.20081217svn121665
- Removed ppc build (problems upstream with mono-2.2)

* Wed Dec 17 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-5.pre3.20081217svn121665
- Another fix for x86_64

* Wed Dec 17 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-4.pre3.20081217svn121665
- Fix for x86_64

* Wed Dec 17 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-3.pre3.20081217svn121665
- Update

* Tue Dec 16 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-3.pre3.20081216svn121582
- Bump to preview 3 svn (as per Novell release schedule)

* Mon Dec 15 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-3.pre2.20081215svn121506
- Update 2.2 preview 2 to svn build
- Modify patch
- Added in manual file

* Fri Dec  5 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-2.pre2
- Update to 2.2 preview 2


mono-tools-2.2-7.pre3.20081217svn121681.fc11
--------------------------------------------
* Mon Dec 15 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-7.pre2.20081215svn121502
- Updated to svn

* Mon Dec 15 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-3.pre3.20081215svn121681
- Bump to preview 3
- Updated to svn

* Sat Dec  6 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-6.pre2
- Bump to preview 2
- use sed to remove the patches


nautilus-2.25.2-3.fc11
----------------------
* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.2-3
- Rebuild for new libgnome-desktop

* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-2
- Drop the eel2 Obsoletes temporarily to give people some time
  to port away

* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2
- Clean up Requires
- Obsolete eel2
- Drop hard dependency on gvfs backends. 
  These are pulled in by comps, anyway


nautilus-cd-burner-2.25.3-1.fc11
--------------------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-1
- Update to 2.25.3


nautilus-open-terminal-0.9-11.fc11
----------------------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.9-11
- Rebuild against new gnome-desktop


nautilus-search-tool-0.2.2-7.fc11
---------------------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 0.2.2-7
- Rebuild to drop eel dependency


ncl-5.0.0-17.fc11
-----------------
* Mon Dec 15 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 5.0.0-17
- Rebuild for atlas-3.8.2


net-snmp-5.4.2.1-6.fc11
-----------------------
* Wed Dec 17 17:00:00 2008 Jan Safranek <jsafranek at redhat.com> 5.4.2.1-6
- rebuilt for new python again...


numpy-1.2.0-3.fc11
------------------
* Mon Dec 15 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 1.2.0-3
- Rebuild for atlas-3.8.2


orca-2.25.3-2.fc11
------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-2
- Update to 2.25.3


pam-1.0.90-1.fc11
-----------------
* Tue Dec 16 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> 1.0.90-1
- upgrade to new upstream release
- add --disable-prelude (#466242)


pango-1.22.4-1.fc11
-------------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.22.4-1
- Update to 1.22.4


perl-Module-Info-0.31-4.fc11
----------------------------
* Wed Dec 17 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.31-4
- BR Test::Pod::Coverage.
- Filter B::Utils auto-provides.


perl-Module-Install-ExtraTests-0.006-1.fc11
-------------------------------------------
* Tue Dec 16 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.006-1
- update to 0.006


perl-Mouse-0.13-1.fc11
----------------------
* Tue Dec 16 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.13-1
- update to 0.13


perl-RPM2-0.68-1.fc11
---------------------
* Wed Dec 17 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.68-1
- New upstream release
- Drop patches


perl-Satcon-1.10-1.fc11
-----------------------
* Tue Dec 16 17:00:00 2008 Miroslav Such? <msuchy at redhat.com> 1.10-1
- remove satcon-make-rpm.pl


perl-Text-SpellChecker-0.05-1.fc11
----------------------------------
* Tue Dec 16 17:00:00 2008 Paul Howarth <paul at city-fan.org> 0.05-1
- Update to 0.05


pixman-0.13.2-1.fc11
--------------------
* Tue Dec 16 17:00:00 2008 Adam Jackson <ajax at redhat.com> 0.13.2-1
- pixman 0.13.2


plague-0.4.5.7-3.20081216cvs.fc11
---------------------------------
* Tue Dec 16 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.4.5.7-3.20081216cvs
- patch with fixes from cvs, also to make work with Python 2.6


plymouth-0.6.0-2.fc11
---------------------
* Wed Dec 17 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-2
- Add patch from drop-nash branch for jeremy


poppler-0.10.2-1.fc11
---------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.10.2-1
- Update to 0.10.2


postgis-1.3.5-1.fc11
--------------------
* Tue Dec 16 17:00:00 2008 Devrim GUNDUZ <devrim at commandprompt.com> - 1.3.5-1
- Update to 1.3.5


puppet-0.24.7-4.fc11
--------------------
* Tue Dec 16 17:00:00 2008 Todd Zullinger <tmz at pobox.com> - 0.24.7-4
- Remove redundant useradd from %pre

* Tue Dec 16 17:00:00 2008 Jeroen van Meeuwen <kanarip at kanarip.com> - 0.24.7-3
- New upstream version
- Set a static uid and gid (#472073, #471918, #471919)
- Add a conditional requirement on libselinux-ruby for Fedora >= 9
- Add a dependency on ruby-augeas


purple-facebookchat-1.44-2.fc11
-------------------------------
* Tue Dec 16 17:00:00 2008 Ismael Olea <ismael at olea.org> 1.44-2
- fixing Makefile: the  NO_ZLIB flag is needed.
- fixing Makefile: adding source files


pycairo-1.8.0-1.fc11
--------------------
* Tue Dec 16 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 1.8.0-1
- Update to 1.8.0


python-flickrapi-1.2-1.fc11
---------------------------
* Wed Dec 17 17:00:00 2008 Ian Weller <ianweller at gmail.com> 1.2-1
- 1.2
- Update URL and Source0 locations


python-mwlib-0.9.2-1.fc11
-------------------------
* Wed Dec 17 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.9.2-1
- Bump to 0.9.2


python-zope-interface-3.5.0-3.fc11
----------------------------------
* Wed Dec 17 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 3.5.0-3
- Make compatible with the new python-zope-filesystem.


rcssserver-13.0.2-2.fc11
------------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> 13.0.2-2
- Rebuild for boost-1.37.0.


referencer-1.1.5-4.fc11
-----------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 1.1.5-4
- Rebuild for boost-1.37.0.


rhpxl-1.10-1.fc11
-----------------
* Tue Dec 16 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.10-1
- rhpxl 1.10


roundcubemail-0.2-5.beta.fc11
-----------------------------
* Wed Dec 17 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> = 0.2-5.beta
- Security fix, BZ 476830.


rubygem-gruff-0.3.4-3.fc11
--------------------------
* Wed Dec 17 17:00:00 2008 Darryl Pierce <dpierce at redhat.com> - 0.3.4-3
- Added a requirement for ruby-RMagick.


scipy-0.7.0-0.2.b1.fc11
-----------------------
* Mon Dec 15 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 0.7.0-0.2.b1
- Rebuild for atlas-3.8.2


scsi-target-utils-0.9.2-1.fc11
------------------------------
* Tue Dec 16 17:00:00 2008 Jarod Wilson <jarod at redhat.com> - 0.9.2-1
- Update to 0.9.2 release


seamonkey-1.1.14-1.fc11
-----------------------
* Wed Dec 17 17:00:00 2008 Kai Engert <kengert at redhat.com> - 1.1.14-1
- Update to 1.1.14


selinux-policy-3.6.1-11.fc11
----------------------------
* Wed Dec 17 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-11
- Fixes for IBM java location


shorewall-4.2.3-1.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.3-1
- Update to version 4.2.3


source-highlight-2.10-2.fc11
----------------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 2.10-2
- Rebuild for boost-1.37.0.


stix-fonts-0.9-9.fc11
---------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 0.9-9
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 0.9-8
? Rebuild using new ??rpm-fonts??


suitesparse-3.2.0-2.fc11
------------------------
* Wed Dec 17 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.2.0-2
- Rebuild for updated atlas

* Mon Dec 15 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.2.0-1
- New upstream version


system-config-network-1.5.95-1.fc11
-----------------------------------
* Fri Dec 12 17:00:00 2008 Jiri Moskovcak <jmoskovc at redhat.com> 1.5.95-1
- New version 1.5.95
- Fixed hostname test according to latest rfc. (rhbz#473919)
- Don't write empty options to config file
- Fixed s-control-network crash when run as non-root (rhbz#470203)
- DSL: Fixed overwritting synchrounous mode to 'yes' (rhbz#475155)
- Fixed typo in NCIPsec.py. (rhbz#474988)
- Added gnome-python2-gnome to Requirements (rhbz#472154)
- Improved compatibility with NetworkManager
- Resolves: #472154, #475155, #473919, #474988, #470203

* Tue Dec  2 17:00:00 2008 Jiri Moskovcak <jmoskovc at redhat.com> 1.5.94-1
- version 1.5.94
- fixed tcp/ip gateway/netmask problem
- fixed crash when pap-secrets contains spaces
- Resolves: #469434, #465748


system-config-printer-1.0.12-5.fc11
-----------------------------------
* Wed Dec 17 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.12-5
- Added patch for pycups git changes since 1.9.44:
  - Look for test page file in new location for CUPS 1.4 (bug


tclxml-3.1-14.fc11
------------------
* Wed Dec 17 17:00:00 2008 Wart <wart at kobold.org> - 3.1-14
- Fix parsing of stylesheet entity (BZ #474766)
- Remove package name from Summary


tomboy-0.13.2-3.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.13.2-3
- Update to 0.13.2


totem-2.25.3-5.fc11
-------------------
* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-5
- Whatever

* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-4
- Add totem-tv icons, and jamendo plugin

* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-3
- Add missing, but temporary, startup-notification BR

* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-2
- Disable tracker plugin until tracker is fixed

* Mon Dec 15 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-1
- Update to 2.25.3

* Wed Dec 10 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.3-4
- Remove hal, glade, gnome-desktop and control-center BRs, not needed anymore


trousers-0.3.1-12.fc11
----------------------
* Tue Dec 16 17:00:00 2008 David Woodhouse <David.Woodhouse at intel.com> - 0.3.1-12
- Bump release to avoid wrong tag in rawhide

* Tue Dec 16 17:00:00 2008 David Woodhouse <David.Woodhouse at intel.com> - 0.3.1-11
- Work around SELinux namespace pollution (#464037)
- Use SO_REUSEADDR
- Use TPM emulator if it's available and no hardware is

* Fri Aug  8 18:00:00 2008 Emily Ratliff <ratliff at austin.ibm.com> - 0.3.1-10
- Use the uid/gid pair assigned to trousers from BZ#457593


twinkle-1.3.2-3.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 1.3.2-3
- Rebuild for boost-1.37.0.


udev-135-3.fc11
---------------
* Tue Dec 16 17:00:00 2008 Harald Hoyer <harald at redhat.com> 135-3
- added sepol patch

* Tue Dec 16 17:00:00 2008 Harald Hoyer <harald at redhat.com> 135-2
- changed udevsettle -> udevadm settle
- added doc to libudev-devel
- added more attr and defattr
- various rpmlint fixes


urlgfe-1.0.3-1.fc11
-------------------
* Wed Dec 17 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.0.3-1
- 1.0.3


vala-0.5.3-1.fc11
-----------------
* Tue Dec 16 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.5.3-1
- Update to 0.5.3

* Mon Dec 15 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.5.2-3
- Fix bug in Emacs version detection


vdr-femon-1.6.5-1.fc11
----------------------
* Wed Dec 17 17:00:00 2008 Ville Skytt? <ville.skytta at iki.fi> - 1.6.5-1
- 1.6.5.


vinagre-2.25.3-1.fc11
---------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-1
- Update to 2.25.3


vino-2.25.3-1.fc11
------------------
* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-1
- Update to 2.25.3


vte-0.19.4-2.fc11
-----------------
* Tue Dec 16 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0.19.4-2
- Update to 0.19.4


wesnoth-1.4.6-6.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 1.4.6-6
- Rebuild for boost-1.37.0.

* Sun Dec 14 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 1.4.6-5
- No longer ship Wesnoth's redundant copy of fonts.
  We now symlink to the Fedora packaged fonts that wesnoth expects.
  dejavu-fonts (Latin)
  sazanami-fonts-gothic (Japanese)
  wqy-zenhei-fonts (Chinese)
  We do not explicitly require these fonts.  Normally these fonts would be 
  already installed by your system use that language.

* Wed Dec 10 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.4.6-4
- Rediffed fuzzy gcc43 patch.


wordwarvi-0.24-1.fc11
---------------------
* Tue Dec 16 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.24-1
- New upstream release 0.24
- Drop upstreamed patches


wp_tray-0.5.3-9.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 0.5.3-9
- Rebuild for boost-1.37.0.


x86info-1.23-1.38.fc11
----------------------
* Tue Dec 16 17:00:00 2008 Dave Jones <davej at redhat.com>
- Update to new upstream 1.23

* Tue Dec 16 17:00:00 2008 Dave Jones <davej at redhat.com>
- Update to new upstream 1.22


xcb-proto-1.3-1.fc11
--------------------
* Wed Dec 17 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.3-1
- xcb-proto 1.3


xorg-x11-proto-devel-7.4-10.fc11
--------------------------------
* Thu Dec 18 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 7.4-10
- xextproto 7.0.4

* Tue Dec 16 17:00:00 2008 Adam Jackson <ajax at redhat.com> 7.4-9
- randrproto 1.2.99.3


xorg-x11-util-macros-1.2.1-1.fc11
---------------------------------
* Wed Dec 17 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.2.1-1
- util-macros 1.2.1
- BuildArch: noarch


yanone-kaffeesatz-fonts-20080723-3.fc11
---------------------------------------
* Sun Nov 23 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080723-3
? ?rpm-fonts? renamed to ?fontpackages?

* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 20080723-2
? Rebuild using new rpm-font


Summary:
Added Packages: 10
Removed Packages: 1
Modified Packages: 174
Broken deps for i386
----------------------------------------------------------
	HippoDraw-python-1.21.1-6.fc11.i386 requires libboost_python.so.3
	Miro-1.2.8-1.fc11.i386 requires libboost_thread-mt.so.3
	Miro-1.2.8-1.fc11.i386 requires libboost_date_time-mt.so.3
	Miro-1.2.8-1.fc11.i386 requires libboost_filesystem-mt.so.3
	Miro-1.2.8-1.fc11.i386 requires libboost_python.so.3
	QuantLib-test-0.9.7-3.fc11.i386 requires libboost_unit_test_framework.so.3
	aqsis-1.4.1-4.fc10.i386 requires libboost_thread-mt.so.3
	aqsis-1.4.1-4.fc10.i386 requires libboost_regex-mt.so.3
	aqsis-core-1.4.1-4.fc10.i386 requires libboost_wave-mt.so.3
	aqsis-core-1.4.1-4.fc10.i386 requires libboost_filesystem-mt.so.3
	asc-2.2.0.0-1.fc11.i386 requires libboost_regex.so.3
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	avant-window-navigator-0.2.6-13.fc11.i386 requires libgnome-desktop-2.so.10
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	balsa-2.3.26-2.fc10.i386 requires libgmime-2.0.so.2
	barry-0.14-5.fc11.i386 requires libboost_serialization.so.3
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	bmpx-0.40.14-7.fc10.i386 requires libboost_regex-mt.so.3
	bmpx-0.40.14-7.fc10.i386 requires libboost_iostreams-mt.so.3
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	chess-1.0-22.fc11.i386 requires libboost_thread-mt.so.3
	compiz-gnome-0.7.8-9.fc11.i386 requires libgnome-desktop-2.so.10
	conexus-0.5.3-4.fc9.i386 requires libboost_regex.so.3
	1:control-center-2.25.2-7.fc11.i386 requires libgnome-desktop-2.so.10
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	deluge-1.0.7-1.fc11.i386 requires libboost_thread-mt.so.3
	deluge-1.0.7-1.fc11.i386 requires libboost_python-mt.so.3
	deluge-1.0.7-1.fc11.i386 requires libboost_filesystem-mt.so.3
	deluge-1.0.7-1.fc11.i386 requires libboost_iostreams-mt.so.3
	deluge-1.0.7-1.fc11.i386 requires libboost_date_time-mt.so.3
	deskbar-applet-2.25.1-5.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	e16-0.16.8.14-1.fc10.i386 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	fbida-2.07-2.fc10.i386 requires bitstream-vera-fonts
	fuse-encfs-1.5-1.fc10.i386 requires libboost_serialization-mt.so.3
	fuse-encfs-1.5-1.fc10.i386 requires libboost_filesystem-mt.so.3
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	glob2-0.9.3-1.fc10.i386 requires libboost_thread-mt.so.3
	gnash-0.8.4-5.fc11.i386 requires libboost_thread-mt.so.3
	gnash-0.8.4-5.fc11.i386 requires libboost_date_time-mt.so.3
	gnash-cygnal-0.8.4-5.fc11.i386 requires libboost_thread-mt.so.3
	1:gnome-applets-2.25.1-4.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-launch-box-0.4-12.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-panel-2.24.1-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gnomedesktop-2.24.0-5.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-settings-daemon-2.25.2-8.fc11.i386 requires libgnome-desktop-2.so.10
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	hugin-0.7.0-1.fc10.i386 requires libboost_thread-mt.so.3
	hugin-base-0.7.0-1.fc10.i386 requires libboost_thread-mt.so.3
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.i386 requires perl(too)
	k3d-0.6.7.0-8.fc11.i386 requires libboost_date_time.so.3
	k3d-0.6.7.0-8.fc11.i386 requires libboost_regex.so.3
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	kdeedu-math-4.1.85-1.fc11.i386 requires libboost_python-mt.so.3
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	1:libtheora-devel-1.0-1.fc11.i386 requires pkgconfig(ogg) >= 0:1.1
	linkage-0.2.0-3.fc10.i386 requires libboost_thread-mt.so.3
	linkage-0.2.0-3.fc10.i386 requires libboost_date_time-mt.so.3
	linkage-0.2.0-3.fc10.i386 requires libboost_serialization-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mkvtoolnix-2.4.0-3.fc11.i386 requires libboost_regex-mt.so.3
	mono-sharpcvslib-0.35-3.fc10.i386 requires mono(nunit.framework) = 0:2.2.0.0
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	nautilus-search-tool-0.2.2-7.fc11.i386 requires libgnome-desktop-2.so.10
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openvrml-0.17.10-1.0.fc10.i386 requires libboost_thread-mt.so.3
	openvrml-xembed-0.17.10-1.0.fc10.i386 requires libboost_thread-mt.so.3
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-XML-LibXSLT-1.66-2.fc10.i386 requires perl(XML::LibXML) = 0:1.66
	pingus-0.7.2-3.fc9.i386 requires libboost_signals.so.3
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-examples-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.i386 requires python-pygame
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-tag-0.94.1-3.fc11.i386 requires libboost_python-mt.so.3
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_thread-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_filesystem-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_date_time-mt.so.3
	rb_libtorrent-python-0.13.1-5.fc11.i386 requires libboost_python-mt.so.3
	rcsslogplayer-13.0.1-1.fc11.i386 requires libboost_program_options-mt.so.3
	rcssserver3d-0.6-5.fc10.i386 requires libboost_thread-mt.so.3
	rcssserver3d-0.6-5.fc10.i386 requires libboost_regex.so.3
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-search-tool-0.6.6-4.fc11.i386 requires libgnome-desktop-2.so.10
	tsclient-2.0.1-9.fc11.i386 requires libgnome-desktop-2.so.10
	vegastrike-0.5.0-6.fc11.i386 requires libboost_python.so.3
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts
	xmms2-0.5-2.fc11.i386 requires libboost_signals.so.3



Broken deps for x86_64
----------------------------------------------------------
	HippoDraw-python-1.21.1-6.fc11.x86_64 requires libboost_python.so.3()(64bit)
	Miro-1.2.8-1.fc11.x86_64 requires libboost_python.so.3()(64bit)
	Miro-1.2.8-1.fc11.x86_64 requires libboost_thread-mt.so.3()(64bit)
	Miro-1.2.8-1.fc11.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	Miro-1.2.8-1.fc11.x86_64 requires libboost_date_time-mt.so.3()(64bit)
	QuantLib-test-0.9.7-3.fc11.x86_64 requires libboost_unit_test_framework.so.3()(64bit)
	aqsis-1.4.1-4.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	aqsis-1.4.1-4.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	aqsis-core-1.4.1-4.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	aqsis-core-1.4.1-4.fc10.x86_64 requires libboost_wave-mt.so.3()(64bit)
	asc-2.2.0.0-1.fc11.x86_64 requires libboost_regex.so.3()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	avant-window-navigator-0.2.6-13.fc11.i386 requires libgnome-desktop-2.so.10
	avant-window-navigator-0.2.6-13.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	barry-0.14-5.fc11.x86_64 requires libboost_serialization.so.3()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bmpx-0.40.14-7.fc10.x86_64 requires libboost_regex.so.3()(64bit)
	bmpx-0.40.14-7.fc10.x86_64 requires libboost_iostreams.so.3()(64bit)
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	chess-1.0-22.fc11.x86_64 requires libboost_thread-mt.so.3()(64bit)
	compiz-gnome-0.7.8-9.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	conexus-0.5.3-4.fc9.i386 requires libboost_regex.so.3
	conexus-0.5.3-4.fc9.x86_64 requires libboost_regex.so.3()(64bit)
	1:control-center-2.25.2-7.fc11.i386 requires libgnome-desktop-2.so.10
	1:control-center-2.25.2-7.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	deluge-1.0.7-1.fc11.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	deluge-1.0.7-1.fc11.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	deluge-1.0.7-1.fc11.x86_64 requires libboost_thread-mt.so.3()(64bit)
	deluge-1.0.7-1.fc11.x86_64 requires libboost_date_time-mt.so.3()(64bit)
	deluge-1.0.7-1.fc11.x86_64 requires libboost_python-mt.so.3()(64bit)
	deskbar-applet-2.25.1-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.x86_64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.i386 requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	fbida-2.07-2.fc10.x86_64 requires bitstream-vera-fonts
	fuse-encfs-1.5-1.fc10.i386 requires libboost_serialization-mt.so.3
	fuse-encfs-1.5-1.fc10.i386 requires libboost_filesystem-mt.so.3
	fuse-encfs-1.5-1.fc10.x86_64 requires libboost_serialization-mt.so.3()(64bit)
	fuse-encfs-1.5-1.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	glob2-0.9.3-1.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	gnash-0.8.4-5.fc11.x86_64 requires libboost_thread-mt.so.3()(64bit)
	gnash-0.8.4-5.fc11.x86_64 requires libboost_date_time-mt.so.3()(64bit)
	gnash-cygnal-0.8.4-5.fc11.x86_64 requires libboost_thread-mt.so.3()(64bit)
	1:gnome-applets-2.25.1-4.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-launch-box-0.4-12.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-panel-2.24.1-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-settings-daemon-2.25.2-8.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	hugin-0.7.0-1.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	hugin-base-0.7.0-1.fc10.i386 requires libboost_thread-mt.so.3
	hugin-base-0.7.0-1.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.x86_64 requires perl(too)
	k3d-0.6.7.0-8.fc11.i386 requires libboost_date_time.so.3
	k3d-0.6.7.0-8.fc11.i386 requires libboost_regex.so.3
	k3d-0.6.7.0-8.fc11.x86_64 requires libboost_regex.so.3()(64bit)
	k3d-0.6.7.0-8.fc11.x86_64 requires libboost_date_time.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	kdeedu-math-4.1.85-1.fc11.x86_64 requires libboost_python-mt.so.3()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.x86_64 requires bitstream-vera-fonts
	1:libtheora-devel-1.0-1.fc11.i386 requires pkgconfig(ogg) >= 0:1.1
	1:libtheora-devel-1.0-1.fc11.x86_64 requires pkgconfig(ogg) >= 0:1.1
	linkage-0.2.0-3.fc10.i386 requires libboost_thread-mt.so.3
	linkage-0.2.0-3.fc10.i386 requires libboost_date_time-mt.so.3
	linkage-0.2.0-3.fc10.i386 requires libboost_serialization-mt.so.3
	linkage-0.2.0-3.fc10.x86_64 requires libboost_serialization-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.x86_64 requires libboost_date_time-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mkvtoolnix-2.4.0-3.fc11.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mono-sharpcvslib-0.35-3.fc10.x86_64 requires mono(nunit.framework) = 0:2.2.0.0
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	nautilus-search-tool-0.2.2-7.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openvrml-0.17.10-1.0.fc10.i386 requires libboost_thread-mt.so.3
	openvrml-0.17.10-1.0.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	openvrml-xembed-0.17.10-1.0.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-XML-LibXSLT-1.66-2.fc10.x86_64 requires perl(XML::LibXML) = 0:1.66
	pingus-0.7.2-3.fc9.x86_64 requires libboost_signals.so.3()(64bit)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-2.1.1-5.fc10.x86_64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libboost_signals.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.x86_64 requires python-pygame
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-tag-0.94.1-3.fc11.x86_64 requires libboost_python-mt.so.3()(64bit)
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_thread-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_filesystem-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_date_time-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.x86_64 requires libboost_thread-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.x86_64 requires libboost_date_time-mt.so.3()(64bit)
	rb_libtorrent-python-0.13.1-5.fc11.x86_64 requires libboost_python-mt.so.3()(64bit)
	rcsslogplayer-13.0.1-1.fc11.i386 requires libboost_program_options-mt.so.3
	rcsslogplayer-13.0.1-1.fc11.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.i386 requires libboost_thread-mt.so.3
	rcssserver3d-0.6-5.fc10.i386 requires libboost_regex.so.3
	rcssserver3d-0.6-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.x86_64 requires libboost_regex.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	tsclient-2.0.1-9.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	vegastrike-0.5.0-6.fc11.x86_64 requires libboost_python.so.3()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts
	xmms2-0.5-2.fc11.i386 requires libboost_signals.so.3
	xmms2-0.5-2.fc11.x86_64 requires libboost_signals.so.3()(64bit)



Broken deps for ppc
----------------------------------------------------------
	HippoDraw-python-1.21.1-6.fc11.ppc requires libboost_python.so.3
	Miro-1.2.8-1.fc11.ppc requires libboost_thread-mt.so.3
	Miro-1.2.8-1.fc11.ppc requires libboost_date_time-mt.so.3
	Miro-1.2.8-1.fc11.ppc requires libboost_filesystem-mt.so.3
	Miro-1.2.8-1.fc11.ppc requires libboost_python.so.3
	QuantLib-test-0.9.7-3.fc11.ppc requires libboost_unit_test_framework.so.3
	aqsis-1.4.1-4.fc10.ppc requires libboost_thread-mt.so.3
	aqsis-1.4.1-4.fc10.ppc requires libboost_regex-mt.so.3
	aqsis-core-1.4.1-4.fc10.ppc requires libboost_wave-mt.so.3
	aqsis-core-1.4.1-4.fc10.ppc requires libboost_filesystem-mt.so.3
	asc-2.2.0.0-1.fc11.ppc requires libboost_regex.so.3
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	avahi-sharp-0.6.24-1.fc11.ppc requires mono-core >= 0:1.1.13
	avahi-sharp-0.6.24-1.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	avahi-sharp-0.6.24-1.fc11.ppc requires mono(System) = 0:1.0.5000.0
	avahi-sharp-0.6.24-1.fc11.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
	avahi-ui-sharp-0.6.24-1.fc11.ppc requires mono-core >= 0:1.1.13
	avahi-ui-sharp-0.6.24-1.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	avahi-ui-sharp-0.6.24-1.fc11.ppc requires mono(System) = 0:1.0.5000.0
	avahi-ui-sharp-0.6.24-1.fc11.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
	avant-window-navigator-0.2.6-13.fc11.ppc requires libgnome-desktop-2.so.10
	avant-window-navigator-0.2.6-13.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc requires libgmime-2.0.so.2
	banshee-1.4.1-1.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Cairo) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(ICSharpCode.SharpZipLib) = 0:2.84.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(System) = 0:2.0.0.0
	barry-0.14-5.fc11.ppc requires libboost_serialization.so.3
	beagle-0.3.8-16.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires libmono.so.0
	beagle-0.3.8-16.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires libmono.so.0(VER_1)
	beagle-0.3.8-16.fc11.ppc requires mono(Mono.Data.Sqlite) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(ICSharpCode.SharpZipLib) = 0:2.84.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(System) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(Mono.Data.Sqlite) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(System) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(Mono.Cairo) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(System) = 0:2.0.0.0
	beagle-thunderbird-0.3.8-16.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	beagle-thunderbird-0.3.8-16.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	beagle-thunderbird-0.3.8-16.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	beagle-thunderbird-0.3.8-16.fc11.ppc requires mono(System) = 0:2.0.0.0
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-4.fc10.ppc requires mono-web
	bless-0.6.0-1.fc10.ppc requires mono-core
	bmpx-0.40.14-7.fc10.ppc requires libboost_iostreams-mt.so.3
	bmpx-0.40.14-7.fc10.ppc requires libboost_regex-mt.so.3
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	cdcollect-0.6.0-6.fc10.ppc requires mono-core >= 0:1.1.17
	cdcollect-0.6.0-6.fc10.ppc requires mono-data-sqlite
	chess-1.0-22.fc11.ppc requires libboost_thread-mt.so.3
	compiz-gnome-0.7.8-9.fc11.ppc requires libgnome-desktop-2.so.10
	conexus-0.5.3-4.fc9.ppc requires libboost_regex.so.3
	conexus-0.5.3-4.fc9.ppc64 requires libboost_regex.so.3()(64bit)
	1:control-center-2.25.2-7.fc11.ppc requires libgnome-desktop-2.so.10
	1:control-center-2.25.2-7.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	cowbell-0.3-0.svn34.4.fc10.ppc requires mono-core
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(System.Drawing) = 0:2.0.0.0
	db4o-6.1-4.fc9.ppc requires mono(mscorlib) = 0:2.0.0.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	db4o-6.1-4.fc9.ppc requires mono(Mono.GetOptions) = 0:2.0.0.0
	db4o-6.1-4.fc9.ppc requires mono(System) = 0:2.0.0.0
	dbus-sharp-0.63-10.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	deluge-1.0.7-1.fc11.ppc requires libboost_thread-mt.so.3
	deluge-1.0.7-1.fc11.ppc requires libboost_python-mt.so.3
	deluge-1.0.7-1.fc11.ppc requires libboost_filesystem-mt.so.3
	deluge-1.0.7-1.fc11.ppc requires libboost_iostreams-mt.so.3
	deluge-1.0.7-1.fc11.ppc requires libboost_date_time-mt.so.3
	deskbar-applet-2.25.1-5.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.ppc requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc requires libcamel-1.2.so.14
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-sharp-0.18.1-1.fc10.ppc requires mono(System) = 0:1.0.5000.0
	evolution-sharp-0.18.1-1.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	f-spot-0.5.0.3-5.fc11.ppc requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System) = 0:1.0.5000.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(Mono.Cairo) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(ICSharpCode.SharpZipLib) = 0:2.84.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System) = 0:2.0.0.0
	fbida-2.07-2.fc10.ppc requires bitstream-vera-fonts
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	fuse-encfs-1.5-1.fc10.ppc requires libboost_serialization-mt.so.3
	fuse-encfs-1.5-1.fc10.ppc requires libboost_filesystem-mt.so.3
	fuse-encfs-1.5-1.fc10.ppc64 requires libboost_serialization-mt.so.3()(64bit)
	fuse-encfs-1.5-1.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gbrainy-1.00-3.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	gbrainy-1.00-3.fc11.ppc requires mono(Mono.Cairo) = 0:2.0.0.0
	gbrainy-1.00-3.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	gbrainy-1.00-3.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	gbrainy-1.00-3.fc11.ppc requires mono(System) = 0:2.0.0.0
	gecko-sharp2-0.13-2.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	glob2-0.9.3-1.fc10.ppc requires libboost_thread-mt.so.3
	gmime-sharp-2.4.3-2.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gnash-0.8.4-5.fc11.ppc requires libboost_thread-mt.so.3
	gnash-0.8.4-5.fc11.ppc requires libboost_date_time-mt.so.3
	gnash-cygnal-0.8.4-5.fc11.ppc requires libboost_thread-mt.so.3
	1:gnome-applets-2.25.1-4.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-desktop-sharp-2.24.0-3.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gnome-desktop-sharp-2.24.0-3.fc10.ppc requires mono(Mono.Cairo) = 0:1.0.5000.0
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-do-0.6.1.0-2.fc10.ppc requires mono-core
	gnome-do-0.6.1.0-2.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	gnome-do-0.6.1.0-2.fc10.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	gnome-do-0.6.1.0-2.fc10.ppc requires mono(System) = 0:2.0.0.0
	gnome-keyring-sharp-1.0.0-0.2.87622svn.fc10.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	gnome-keyring-sharp-1.0.0-0.2.87622svn.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	gnome-keyring-sharp-1.0.0-0.2.87622svn.fc10.ppc requires mono(System) = 0:2.0.0.0
	gnome-launch-box-0.4-12.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-panel-2.24.1-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-settings-daemon-2.25.2-8.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-sharp-2.24.0-1.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gnome-subtitles-0.8-6.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	gnome-subtitles-0.8-6.fc10.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	gnome-subtitles-0.8-6.fc10.ppc requires mono(System) = 0:2.0.0.0
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	graphviz-sharp-2.20.3-1.fc11.1.ppc requires mono-core
	gsf-sharp-0.8.1-8.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gtk-sharp2-2.12.5-2.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gtk-sharp2-2.12.5-2.fc11.ppc requires mono(Mono.Cairo) = 0:1.0.5000.0
	gtk-sharp2-2.12.5-2.fc11.ppc requires mono(System) = 0:1.0.5000.0
	gtk-sharp2-2.12.5-2.fc11.ppc requires mono(System.Drawing) = 0:1.0.5000.0
	gtksourceview2-sharp-1.0-2.svn89788.2.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	hugin-0.7.0-1.fc10.ppc requires libboost_thread-mt.so.3
	hugin-base-0.7.0-1.fc10.ppc requires libboost_thread-mt.so.3
	hugin-base-0.7.0-1.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	ice-csharp-3.3.0-9.fc11.ppc requires mono-core >= 0:1.2.2
	ice-csharp-3.3.0-9.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	ice-csharp-3.3.0-9.fc11.ppc requires mono(System) = 0:2.0.0.0
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:2.84.0.0
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(System.Xml) = 0:2.0.0.0
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(System) = 0:2.0.0.0
	jython-manual-2.2.1-2.1.fc11.ppc requires perl(too)
	k3d-0.6.7.0-8.fc11.ppc requires libboost_date_time.so.3
	k3d-0.6.7.0-8.fc11.ppc requires libboost_regex.so.3
	k3d-0.6.7.0-8.fc11.ppc64 requires libboost_regex.so.3()(64bit)
	k3d-0.6.7.0-8.fc11.ppc64 requires libboost_date_time.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	kdeedu-math-4.1.85-1.fc11.ppc requires libboost_python-mt.so.3
	lat-1.2.3-5.fc11.ppc requires mono-data
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.ppc requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	1:libtheora-devel-1.0-1.fc11.ppc requires pkgconfig(ogg) >= 0:1.1
	1:libtheora-devel-1.0-1.fc11.ppc64 requires pkgconfig(ogg) >= 0:1.1
	linkage-0.2.0-3.fc10.ppc requires libboost_thread-mt.so.3
	linkage-0.2.0-3.fc10.ppc requires libboost_date_time-mt.so.3
	linkage-0.2.0-3.fc10.ppc requires libboost_serialization-mt.so.3
	linkage-0.2.0-3.fc10.ppc64 requires libboost_serialization-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mkvtoolnix-2.4.0-3.fc11.ppc requires libboost_regex-mt.so.3
	mod_mono-2.2-1.pre1.fc11.ppc requires mono-core
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(System.Xml) = 0:1.0.5000.0
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(System) = 0:1.0.5000.0
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
	mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.9.0
	mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	mono-zeroconf-0.7.5-4.fc9.ppc requires mono(mscorlib) = 0:2.0.0.0
	mono-zeroconf-0.7.5-4.fc9.ppc requires mono(System) = 0:2.0.0.0
	monodoc-2.0-5.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
	monodoc-2.0-5.fc10.ppc requires mono(System.Web) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono-core
	monodoc-2.0-5.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono(System.Xml) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono(System) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono(System.Web.Services) = 0:1.0.5000.0
	monosim-1.3.0.2-1.fc9.1.ppc requires mono-core >= 0:1.2.3
	monosim-1.3.0.2-1.fc9.1.ppc requires mono-web >= 0:1.2.3
	monotorrent-0.50-2.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	monotorrent-0.50-2.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	monotorrent-0.50-2.fc11.ppc requires mono(System) = 0:2.0.0.0
	muine-0.8.10-3.fc11.ppc requires mono-core
	muine-0.8.10-3.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	muine-0.8.10-3.fc11.ppc requires mono-web
	muine-0.8.10-3.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	nautilus-search-tool-0.2.2-7.fc11.ppc requires libgnome-desktop-2.so.10
	ndesk-dbus-0.6.1a-2.fc9.ppc requires mono-core
	ndesk-dbus-0.6.1a-2.fc9.ppc requires mono(mscorlib) = 0:2.0.0.0
	ndesk-dbus-0.6.1a-2.fc9.ppc requires mono(System.Xml) = 0:2.0.0.0
	ndesk-dbus-0.6.1a-2.fc9.ppc requires mono(System) = 0:2.0.0.0
	ndesk-dbus-glib-0.4.1-3.fc9.ppc requires mono(mscorlib) = 0:2.0.0.0
	notify-sharp-0.4.0-0.5.20080912svn.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openvrml-0.17.10-1.0.fc10.ppc requires libboost_thread-mt.so.3
	openvrml-0.17.10-1.0.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	openvrml-xembed-0.17.10-1.0.fc10.ppc requires libboost_thread-mt.so.3
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-XML-LibXSLT-1.66-2.fc10.ppc requires perl(XML::LibXML) = 0:1.66
	pingus-0.7.2-3.fc9.ppc requires libboost_signals.so.3
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc requires libboost_signals.so.3
	player-2.1.1-5.fc10.ppc requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libboost_thread-mt.so.3
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-examples-2.1.1-5.fc10.ppc requires libboost_signals.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	podsleuth-0.6.3-1.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	podsleuth-0.6.3-1.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	podsleuth-0.6.3-1.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	podsleuth-0.6.3-1.fc11.ppc requires mono(System) = 0:2.0.0.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc requires python-pygame
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-tag-0.94.1-3.fc11.ppc requires libboost_python-mt.so.3
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc requires libboost_thread-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.ppc requires libboost_filesystem-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.ppc requires libboost_date_time-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	rb_libtorrent-python-0.13.1-5.fc11.ppc requires libboost_python-mt.so.3
	rcsslogplayer-13.0.1-1.fc11.ppc requires libboost_program_options-mt.so.3
	rcsslogplayer-13.0.1-1.fc11.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.ppc requires libboost_thread-mt.so.3
	rcssserver3d-0.6-5.fc10.ppc requires libboost_regex.so.3
	rcssserver3d-0.6-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.ppc64 requires libboost_regex.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	sublib-0.9-2.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	sublib-0.9-2.fc10.ppc requires mono(System) = 0:2.0.0.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	taglib-sharp-2.0.3.0-7.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	tasque-0.1.7-3.fc9.ppc requires mono-core
	themonospot-0.7.1.1-1.fc10.ppc requires mono-core >= 0:1.2.3
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc requires libgnome-desktop-2.so.10
	tsclient-2.0.1-9.fc11.ppc requires libgnome-desktop-2.so.10
	vegastrike-0.5.0-6.fc11.ppc requires libboost_python.so.3
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts
	xmms2-0.5-2.fc11.ppc requires libboost_signals.so.3
	xmms2-0.5-2.fc11.ppc64 requires libboost_signals.so.3()(64bit)
	xsp-2.2-1.pre1.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Security) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono-core >= 0:2.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Configuration) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Security) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Xml) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Data) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Web.Services) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Web) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Data.SqliteClient) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Web) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Xml) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(Mono.Data.SqliteClient) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Data) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Web.Services) = 0:1.0.5000.0



Broken deps for ppc64
----------------------------------------------------------
	HippoDraw-python-1.21.1-6.fc11.ppc64 requires libboost_python.so.3()(64bit)
	Miro-1.2.8-1.fc11.ppc64 requires libboost_python.so.3()(64bit)
	Miro-1.2.8-1.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	Miro-1.2.8-1.fc11.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	Miro-1.2.8-1.fc11.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	QuantLib-test-0.9.7-3.fc11.ppc64 requires libboost_unit_test_framework.so.3()(64bit)
	aqsis-1.4.1-4.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	aqsis-1.4.1-4.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	aqsis-core-1.4.1-4.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	aqsis-core-1.4.1-4.fc10.ppc64 requires libboost_wave-mt.so.3()(64bit)
	asc-2.2.0.0-1.fc11.ppc64 requires libboost_regex.so.3()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	avant-window-navigator-0.2.6-13.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	balsa-2.3.26-2.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	barry-0.14-5.fc11.ppc64 requires libboost_serialization.so.3()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bmpx-0.40.14-7.fc10.ppc64 requires libboost_regex.so.3()(64bit)
	bmpx-0.40.14-7.fc10.ppc64 requires libboost_iostreams.so.3()(64bit)
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	chess-1.0-22.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	compiz-gnome-0.7.8-9.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	conexus-0.5.3-4.fc9.ppc64 requires libboost_regex.so.3()(64bit)
	1:control-center-2.25.2-7.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	deluge-1.0.7-1.fc11.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	deluge-1.0.7-1.fc11.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	deluge-1.0.7-1.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	deluge-1.0.7-1.fc11.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	deluge-1.0.7-1.fc11.ppc64 requires libboost_python-mt.so.3()(64bit)
	deskbar-applet-2.25.1-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.ppc64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-brutus-1.2.27-2.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	fbida-2.07-2.fc10.ppc64 requires bitstream-vera-fonts
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	fuse-encfs-1.5-1.fc10.ppc64 requires libboost_serialization-mt.so.3()(64bit)
	fuse-encfs-1.5-1.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	glob2-0.9.3-1.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	gnash-0.8.4-5.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	gnash-0.8.4-5.fc11.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	gnash-cygnal-0.8.4-5.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	1:gnome-applets-2.25.1-4.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-launch-box-0.4-12.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-panel-2.24.1-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-settings-daemon-2.25.2-8.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	hugin-0.7.0-1.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	hugin-base-0.7.0-1.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	jython-manual-2.2.1-2.1.fc11.ppc64 requires perl(too)
	k3d-0.6.7.0-8.fc11.ppc64 requires libboost_regex.so.3()(64bit)
	k3d-0.6.7.0-8.fc11.ppc64 requires libboost_date_time.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	kdeedu-math-4.1.85-1.fc11.ppc64 requires libboost_python-mt.so.3()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	1:libtheora-devel-1.0-1.fc11.ppc64 requires pkgconfig(ogg) >= 0:1.1
	linkage-0.2.0-3.fc10.ppc64 requires libboost_serialization-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mkvtoolnix-2.4.0-3.fc11.ppc64 requires libboost_regex-mt.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	nautilus-search-tool-0.2.2-7.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openvrml-0.17.10-1.0.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	openvrml-xembed-0.17.10-1.0.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-XML-LibXSLT-1.66-2.fc10.ppc64 requires perl(XML::LibXML) = 0:1.66
	pingus-0.7.2-3.fc9.ppc64 requires libboost_signals.so.3()(64bit)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rabbyt-0.8.2-7.fc11.ppc64 requires python-pygame
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-tag-0.94.1-3.fc11.ppc64 requires libboost_python-mt.so.3()(64bit)
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	rb_libtorrent-python-0.13.1-5.fc11.ppc64 requires libboost_python-mt.so.3()(64bit)
	rcsslogplayer-13.0.1-1.fc11.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.ppc64 requires libboost_regex.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	snake-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	snake-server-0.11-0.9.fc10.noarch requires python(abi) = 0:2.5
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	tsclient-2.0.1-9.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	vegastrike-0.5.0-6.fc11.ppc64 requires libboost_python.so.3()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts
	xmms2-0.5-2.fc11.ppc64 requires libboost_signals.so.3()(64bit)





From mclasen at redhat.com  Thu Dec 18 17:25:54 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 18 Dec 2008 12:25:54 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <gidlps$hh2$2@ger.gmane.org>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<gidlps$hh2$2@ger.gmane.org>
Message-ID: <1229621154.3488.5.camel@matthiasc>

On Thu, 2008-12-18 at 15:13 +0100, Kevin Kofler wrote:
> Matthias Clasen wrote:
> > The required components should just be a fallback in case the session
> > didn't contain a window manager, file manager, etc. At least that is my
> > understanding of how they're supposed to be used. So, you should just
> > install an autostart file for xmonad that marks it as a window manager
> > via
> > 
> > X-GNOME-Autostart-Phase=WindowManager
> > X-GNOME-Provides=windowmanager
> > 
> > then your users should be able to switch their sessions to xmonad by
> > turning it on in the session capplet.
> 
> If you install an autostart file into /etc/xdg/autostart, you'll force this
> for KDE users with no easy way to turn it off, KDE does not allow users to
> turn off autostart entries. So that's not a good solution.
> 

Install it in /usr/share/gnome/autostart then.



From jspaleta at gmail.com  Thu Dec 18 17:36:44 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Dec 2008 08:36:44 -0900
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812181153.00287.sgrubb@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <200812180927.05026.sgrubb@redhat.com>
	<604aa7910812180805k77653cc6w9d7deee887bc0ab8@mail.gmail.com>
	<200812181153.00287.sgrubb@redhat.com>
Message-ID: <604aa7910812180936v6c6c2f2anfad63041567513b1@mail.gmail.com>

On Thu, Dec 18, 2008 at 7:52 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> In /etc/sysconfig/crond, there is the CRONDARGS variable where it can be set.

Okay that meets the baseline requirement for the desktop live image.
And obviously kickstart scripts for other spin targets can flip that
config to something else as needed. If we get a Server Spin for
example it could choose sendmail by default and explicitly install
sendmail by default in its kickstart.

But can this be handled in a more sophisticated way so we can get a
system that can handle both the desktop target usecase and the managed
system usecase that Les is trying to articulate by default without a
config file edit?

IF a real honest-to-god mta is installed, can cron grow some logic to
prefer to use the mta if available? For example can the cron service
script see if /usr/sbin/sendmail is there.. if it is..use it... if its
not..fall back to something else (the yet to be written dbus-email
broker)

 If that sounds doable, then we can start poking Behdad to write the
missing dbus-email broker as an F11 feature and we can get something
which should not disrupt Les's managed desktop usecase.

-jef



From kevin at scrye.com  Thu Dec 18 17:43:19 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Thu, 18 Dec 2008 10:43:19 -0700
Subject: Proposed PackageRenaming guideline
Message-ID: <20081218104319.75305a5b@ohm.scrye.com>

As far as I can tell we don't have a guideline for how to do package
renames. Here's my first attempt at such a guideline: 

https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages

Feel free to leave feedback in talk page for it on the wiki, or here or
in personal email to me.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/01dfb9e1/attachment.sig>

From pertusus at free.fr  Thu Dec 18 17:48:52 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Dec 2008 18:48:52 +0100
Subject: Proposed PackageRenaming guideline
In-Reply-To: <20081218104319.75305a5b@ohm.scrye.com>
References: <20081218104319.75305a5b@ohm.scrye.com>
Message-ID: <20081218174852.GB15365@free.fr>

On Thu, Dec 18, 2008 at 10:43:19AM -0700, Kevin Fenzi wrote:
> As far as I can tell we don't have a guideline for how to do package
> renames. Here's my first attempt at such a guideline: 

In fact there is one, but it was never written down (at least it
is what I was told when I asked recently). The guideline is that
a re-review is required.

--
Pat



From dennis at ausil.us  Thu Dec 18 17:58:46 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Thu, 18 Dec 2008 11:58:46 -0600
Subject: Proposed PackageRenaming guideline
In-Reply-To: <20081218174852.GB15365@free.fr>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<20081218174852.GB15365@free.fr>
Message-ID: <200812181158.47533.dennis@ausil.us>

On Thursday 18 December 2008 11:48:52 am Patrice Dumas wrote:
> On Thu, Dec 18, 2008 at 10:43:19AM -0700, Kevin Fenzi wrote:
> > As far as I can tell we don't have a guideline for how to do package
> > renames. Here's my first attempt at such a guideline:
>
> In fact there is one, but it was never written down (at least it
> is what I was told when I asked recently). The guideline is that
> a re-review is required.
from memory yes.  you need a re-review  then to EOL the old package. 

http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife and 
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages 
hint at it.  We should make it crystal clear  :)

Dennis



From Jochen at herr-schmitt.de  Thu Dec 18 17:59:52 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 18 Dec 2008 18:59:52 +0100
Subject: Proposed PackageRenaming guideline
In-Reply-To: <20081218104319.75305a5b@ohm.scrye.com>
References: <20081218104319.75305a5b@ohm.scrye.com>
Message-ID: <494A8F98.4050100@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin Fenzi schrieb:
> https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages
>
After a first look on this proposel I have some question and comments:

1.) Is the approving process the same as if I submit a new package
request.

2.) Because the CVSAdmin request need a bugzilla ticket, why we don't
doing the relating
approving process in the same ticket.

3.) If we not need a full review process, I think anyone should
approve that the right
Provides/Requires statement existing in the new package. A lightwight
approvement
process may has the advance that the maintaining process of an
existing package will not
delayed for a long time by the renaming process.

4.) Each people which has the right to done a normal package review
should be abled
to approve a renamed package.


Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKj48ACgkQT2AHK6txfgxCRgCcDKCAa6QRoAmNfbzUrz4Q2/r5
5VMAoJQvuJ2XYct9LqWLWAXY+/z8bbVX
=TzfD
-----END PGP SIGNATURE-----



From jkeating at redhat.com  Thu Dec 18 18:00:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Dec 2008 10:00:54 -0800
Subject: Proposed PackageRenaming guideline
In-Reply-To: <200812181158.47533.dennis@ausil.us>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<20081218174852.GB15365@free.fr> <200812181158.47533.dennis@ausil.us>
Message-ID: <1229623254.6191.108.camel@localhost.localdomain>

On Thu, 2008-12-18 at 11:58 -0600, Dennis Gilmore wrote:
> from memory yes.  you need a re-review  then to EOL the old package. 
> 
> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife and 
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages 
> hint at it.  We should make it crystal clear  :)

There was recent discussion (on IRC) that some felt a full re-review as
"overkill" or worse "a waste of time".  I think it's fair to re-evaluate
what we're trying to accomplish with a re-review and re-assess if a full
review is indeed what "we" (IE the Fedora community, represented by
FESCo) want.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/5903aa23/attachment.sig>

From Jochen at herr-schmitt.de  Thu Dec 18 18:04:19 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 18 Dec 2008 19:04:19 +0100
Subject: Proposed PackageRenaming guideline
In-Reply-To: <200812181158.47533.dennis@ausil.us>
References: <20081218104319.75305a5b@ohm.scrye.com>	<20081218174852.GB15365@free.fr>
	<200812181158.47533.dennis@ausil.us>
Message-ID: <494A90A3.5060702@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dennis Gilmore schrieb:
> from memory yes.  you need a re-review  then to EOL the old
> package.
>
> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife
> and
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages
>  hint at it.  We should make it crystal clear  :)

Hast this was the practice in the past. The disadvance of this process
is the fact, that a re-review
takes a long time.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKkKMACgkQT2AHK6txfgxbBACePue+re0NVyyJ2tc9d1R5UBAF
S7UAoLI3q0E0iM9QUU0+P6z4+BBIZb2X
=cytl
-----END PGP SIGNATURE-----



From tibbs at math.uh.edu  Thu Dec 18 18:07:35 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 18 Dec 2008 12:07:35 -0600
Subject: Proposed PackageRenaming guideline
In-Reply-To: <494A90A3.5060702@herr-schmitt.de>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<20081218174852.GB15365@free.fr> <200812181158.47533.dennis@ausil.us>
	<494A90A3.5060702@herr-schmitt.de>
Message-ID: <ufaej05s6fs.fsf@epithumia.math.uh.edu>

>>>>> "JS" == Jochen Schmitt <Jochen at herr-schmitt.de> writes:

JS> Hast this was the practice in the past. The disadvance of this
JS> process is the fact, that a re-review takes a long time.

I think you mean "can take a long time".  I have done re-reviews for
renames in an hour because someone asked me to.  Typically a re-review
is much quicker than the initial review.

As discussed on IRC, an important benefit of a re-review is the
insurance that the Obsoletes and Provides are done properly.  It is
easy to get this wrong, so another pair of eyes in the process is a
good idea.

 - J<



From jspaleta at gmail.com  Thu Dec 18 18:10:04 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Dec 2008 09:10:04 -0900
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229619367.6392.118.camel@code.and.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan>
	<49496940.20706@gmail.com> <1229609395.3651.19.camel@hughsie-work.lan>
	<1229615827.6392.109.camel@code.and.org>
	<1229617055.3651.55.camel@hughsie-work.lan>
	<1229619367.6392.118.camel@code.and.org>
Message-ID: <604aa7910812181010l3d43974asefab9a58e207b8df@mail.gmail.com>

On Thu, Dec 18, 2008 at 7:56 AM, James Antill <james at fedoraproject.org> wrote:
>  So, it's not markdown then surely? Can you point to some python that
> implements your version?

This still needs to go before our packaging committee methinks.

And if its approved as a Review Should or a Must, it would absolutely
be super keen if reviewers had a toolized way to check for conformance
so we can catch this for anything submitted moving forward.

-jef"deliberately going to edit his packages descriptions to break
markdown in rawhide, without it being obvious that he's doing
it"spaleta



From Jochen at herr-schmitt.de  Thu Dec 18 18:11:54 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 18 Dec 2008 19:11:54 +0100
Subject: Proposed PackageRenaming guideline
In-Reply-To: <1229623254.6191.108.camel@localhost.localdomain>
References: <20081218104319.75305a5b@ohm.scrye.com>	<20081218174852.GB15365@free.fr>
	<200812181158.47533.dennis@ausil.us>
	<1229623254.6191.108.camel@localhost.localdomain>
Message-ID: <494A926A.1030000@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Keating schrieb:
> There was recent discussion (on IRC) that some felt a full
> re-review as "overkill" or worse "a waste of time".  I think it's
> fair to re-evaluate what we're trying to accomplish with a
> re-review and re-assess if a full review is indeed what "we" (IE
> the Fedora community, represented by FESCo) want.

Be in mind, as long as you don't rename you package, you can make any
changes on your package
without you need a review for it. Question: Why you need a full
review, if you want to rename your
package?

Of course, you can say, that you want to be sure, that you don't want
to get a naming conflict due
the renaming of the package and have the right Provides/Obsoletes
statements in the renamed
package to be sure to have a proper updating path. But this is not a
full review from my pont of
view.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKkmoACgkQT2AHK6txfgyI0gCaAxM1kZEgKEnK0nJiRvBiZ+WD
OCoAoNtKHLC2qvgRtAF3WeuSOJmS6Y0b
=zrfw
-----END PGP SIGNATURE-----



From rdieter at math.unl.edu  Thu Dec 18 18:15:58 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Dec 2008 12:15:58 -0600
Subject: exiv2-0.18 coming soon to a rawhide near you
Message-ID: <494A935E.1070503@math.unl.edu>

I'll be updating to exiv2-0.18 in rawhide real soon, which includes
soname bump, and start jumping on rebuilding dependent apps asap.

-- Rex



From Jochen at herr-schmitt.de  Thu Dec 18 18:16:19 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 18 Dec 2008 19:16:19 +0100
Subject: Proposed PackageRenaming guideline
In-Reply-To: <ufaej05s6fs.fsf@epithumia.math.uh.edu>
References: <20081218104319.75305a5b@ohm.scrye.com>	<20081218174852.GB15365@free.fr>
	<200812181158.47533.dennis@ausil.us>	<494A90A3.5060702@herr-schmitt.de>
	<ufaej05s6fs.fsf@epithumia.math.uh.edu>
Message-ID: <494A9373.2090305@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason L Tibbitts III schrieb:
>>>>>> "JS" == Jochen Schmitt <Jochen at herr-schmitt.de> writes:
>
> I think you mean "can take a long time".  I have done re-reviews
> for renames in an hour because someone asked me to.  Typically a
> re-review is much quicker than the initial review.
>
My last experience was, that the re-review has taken a long time.
> As discussed on IRC, an important benefit of a re-review is the
> insurance that the Obsoletes and Provides are done properly.  It is
>  easy to get this wrong, so another pair of eyes in the process is
> a good idea.
I agree with you, I have propose a lightwight review for check this
point in
a bugzille ticket record as an insurance that this statements are right.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKk3MACgkQT2AHK6txfgwhfACgixEK2QJULUFkw/qPlX6QkHLq
WHQAoJSyBFQk/uwm0urjbsa3FIt/h8Yd
=vmke
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/afabd7aa/attachment.htm>

From rc040203 at freenet.de  Thu Dec 18 17:03:21 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 18 Dec 2008 18:03:21 +0100
Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch
 packages
In-Reply-To: <1229619198.6191.106.camel@localhost.localdomain>
References: <494A7A92.9020404@redhat.com>
	<1229618217.14090.543.camel@beck.corsepiu.local>
	<1229619037.3472.26.camel@localhost.localdomain>
	<1229619198.6191.106.camel@localhost.localdomain>
Message-ID: <1229619801.14090.601.camel@beck.corsepiu.local>

On Thu, 2008-12-18 at 08:53 -0800, Jesse Keating wrote:
> On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote:
> > On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
> > > Wouldn't it be better to let rpm set _libdir/_lib to match noarch
> > > package requirements?
> > 
> > What should it set it to? It has no knowledge of where the noarch rpm
> > package will eventually be installed. Should we assume that /usr/lib is
> > always correct (how Debian of me to even suggest this)?
> > 
> > ~spot
> 
> Also, how does one get this right in the age of noarch subpackages to
> arch specific packages?

By properly parsing and preserving contexts in rpmbuild?

Admitted, "proper", "parsing" and "contexts" don't go well along with
rpm.

Ralf






From billcrawford1970 at gmail.com  Thu Dec 18 18:18:08 2008
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Thu, 18 Dec 2008 18:18:08 +0000
Subject: RFC: Description text in packages
In-Reply-To: <gidupi$lhi$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<200812181117.34596.billcrawford1970@gmail.com>
	<gidupi$lhi$1@ger.gmane.org>
Message-ID: <200812181818.08241.billcrawford1970@gmail.com>

On Thursday 18 December 2008 16:46:42 Matthew Woehlke wrote:
> Bill Crawford wrote:
...
> > It's usually "Alt Gr" or "AltGr" (alternative graphic) and that is
> > (again, *usually*) the "right alt" key. My keyboard has it labelled that
> > way, so it is not intended for accelerators.

> I did, in fact, know that :-), and I understand that's typical of non-US
> keyboards. My US keyboard however has two keys labeled "Alt". Both of
> them do, in fact, work to activate the menu (or other accelerators).

Ah, I see what you mean (you didn't spell that out and I was a little slow of 
thinking today for some reason).

> ...which is the point I was trying to make to Nicolas; when dealing with
> current US keyboards, there is no precedent for a compose key. That's a
> lot of inertia to overcome, and (to respond to Nicolas' other comment),
> there IS NO EDUCATION SYSTEM IN PLACE right now, that I am aware of.

Ah again. The compose thing is different altogether; my preferred key for that 
is the "right windows key" (not something that's expected by keyboard design) 
and in any case the idea of "compose key" isn't really expected by most people 
coming from another (Windows) universe either, so it doesn't really qualify 
as "intuitive" [wrong word, of course!] by most people's standards.

> I keep waiting for a proposal to fix that. I haven't heard one yet.

That part isn't easily fixable (hire a truck with a loudspeaker to go around and 
tell people? reminds me of a scene from the Blues Brothers ...)

> (Bill: I've sort of hijacked your post, sorry about that :-).)

If you meant me, no problem :o) if you meant the other Bill, I think he stopped 
reading the thread already ;o)



From limb at jcomserv.net  Thu Dec 18 18:17:28 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 12:17:28 -0600 (CST)
Subject: exiv2-0.18 coming soon to a rawhide near you
In-Reply-To: <494A935E.1070503@math.unl.edu>
References: <494A935E.1070503@math.unl.edu>
Message-ID: <a64bc4311504a990d2e7e0287ee66d96.squirrel@mail.jcomserv.net>


> I'll be updating to exiv2-0.18 in rawhide real soon, which includes
> soname bump, and start jumping on rebuilding dependent apps asap.

Thanks for the heads up.  Is it a lot of packages?  Got a list and or need
a hand?

> -- Rex
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From lesmikesell at gmail.com  Thu Dec 18 18:21:25 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 18 Dec 2008 12:21:25 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <604aa7910812180936v6c6c2f2anfad63041567513b1@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812180927.05026.sgrubb@redhat.com>	<604aa7910812180805k77653cc6w9d7deee887bc0ab8@mail.gmail.com>	<200812181153.00287.sgrubb@redhat.com>
	<604aa7910812180936v6c6c2f2anfad63041567513b1@mail.gmail.com>
Message-ID: <494A94A5.50807@gmail.com>

Jeff Spaleta wrote:
> On Thu, Dec 18, 2008 at 7:52 AM, Steve Grubb <sgrubb at redhat.com> wrote:
>> In /etc/sysconfig/crond, there is the CRONDARGS variable where it can be set.
> 
> Okay that meets the baseline requirement for the desktop live image.
> And obviously kickstart scripts for other spin targets can flip that
> config to something else as needed. If we get a Server Spin for
> example it could choose sendmail by default and explicitly install
> sendmail by default in its kickstart.
> 
> But can this be handled in a more sophisticated way so we can get a
> system that can handle both the desktop target usecase and the managed
> system usecase that Les is trying to articulate by default without a
> config file edit?

I don't think I'd call wanting standard email a 'managed system'.  It is 
the system helping you manage itself, and I think people would use it if 
they were aware that it existed.

> IF a real honest-to-god mta is installed, can cron grow some logic to
> prefer to use the mta if available? For example can the cron service
> script see if /usr/sbin/sendmail is there.. if it is..use it... if its
> not..fall back to something else (the yet to be written dbus-email
> broker)

If you really want to go down the reduced-functionality road, it doesn't 
make sense to make every program that expects /usr/bin/sendmail (keeping 
in mind that not every program in the universe is installed via yum out 
of a fedora repostitory...) have to look for alternatives.

>  If that sounds doable, then we can start poking Behdad to write the
> missing dbus-email broker as an F11 feature and we can get something
> which should not disrupt Les's managed desktop usecase.

Just write the 10-line shell script version of /usr/bin/sendmail that 
discards the message in whatever creative way you like and package it as 
an alternative mailer.  But, if I can't make them come to my phone when 
I want, you've badly broken expected functionality.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From limb at jcomserv.net  Thu Dec 18 18:23:39 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 12:23:39 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <49428284.7050903@pobox.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<4936D709.5060903@cchtml.com>
	<dad4d386380cf07260734847a74ffb1d.squirrel@mail.jcomserv.net>
	<4936EF86.5020409@cchtml.com>
	<9e286154107eae77abf9d80c0818bf82.squirrel@mail.jcomserv.net>
	<20081204170029.GA5553@bludgeon.org>
	<205cfc8121bf2d45072198add1b4fcac.squirrel@mail.jcomserv.net>
	<f907da5e57526e1a1168e90188ef7798.squirrel@mail.jcomserv.net>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
Message-ID: <eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>>> "Jon Ciesla" <limb at jcomserv.net> writes:
>>>>> (Yes, I know libjpeg upstream is kinda moribund, but if you want new
>>>>> features in it you should be trying to revive upstream development,
>>>>> not strongarm the Fedora package maintainer to take over
>>>>> development.)
>>>> I agree strongly with that principle.  Two questions:
>>>> A. What has been done thusfar WTR reviving upstream development?
>>> Well, at one point I had more or less formally blessed Guido Vollbeding
>>> as the new lead maintainer, but if he's actually put out a release I
>>> haven't heard about it :-(.  You could try bugging the people
>>> associated
>>> with the sourceforge libjpeg project.
>>
>> CCing them.  libjpeg SourceForge team, what is the current status of
>> libjpeg development?
>
> Jon,
>
> I have heard nothing in some time from Guido, and I'm not aware of him
> producing any sort of libjpeg release.
>
> I find the situation somewhat frustrating.

Agreed.  So what's next?  Is there a plan for further action, a new
primary maintainer, etc?

I think WRT gallery2, I'll see about patching the -crop call out of that
plugin.

> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From rdieter at math.unl.edu  Thu Dec 18 18:31:04 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Dec 2008 12:31:04 -0600
Subject: exiv2-0.18 coming soon to a rawhide near you
References: <494A935E.1070503@math.unl.edu>
	<a64bc4311504a990d2e7e0287ee66d96.squirrel@mail.jcomserv.net>
Message-ID: <gie4rj$brc$1@ger.gmane.org>

Jon Ciesla wrote:

> 
>> I'll be updating to exiv2-0.18 in rawhide real soon, which includes
>> soname bump, and start jumping on rebuilding dependent apps asap.
> 
> Thanks for the heads up.  Is it a lot of packages?  Got a list and or need
> a hand?

The list I'll be respinning from my quick-n-dirty repoquery includes:
geeqie-0:1.0-0.8.alpha2.fc10.src
gnome-commander-0:1.2.8-0.2.svn2351_trunk.fc11.src
hugin-0:0.7.0-1.fc10.src
immix-0:1.3.2-4.fc11.src
kdegraphics-7:4.1.85-2.fc11.src
kipi-plugins-0:0.2.0-0.7.beta4.fc11.src
koffice-1:1.9.98.3-1.fc11.src
kphotoalbum-0:3.2-0.5.20081007svn.fc11.src
merkaartor-0:0.12-2.fc10.src
pyexiv2-0:0.1.2-5.fc11.src
qtpfsgui-0:1.9.2-2.fc10.src
rawstudio-0:1.1.1-1.fc10.src
strigi-0:0.5.11.1-1.fc11.src
ufraw-0:0.14.1-3.fc11.src





From hughsient at gmail.com  Thu Dec 18 18:35:25 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 18 Dec 2008 18:35:25 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <604aa7910812181010l3d43974asefab9a58e207b8df@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan> <49496940.20706@gmail.com>
	<1229609395.3651.19.camel@hughsie-work.lan>
	<1229615827.6392.109.camel@code.and.org>
	<1229617055.3651.55.camel@hughsie-work.lan>
	<1229619367.6392.118.camel@code.and.org>
	<604aa7910812181010l3d43974asefab9a58e207b8df@mail.gmail.com>
Message-ID: <1229625325.3651.75.camel@hughsie-work.lan>

On Thu, 2008-12-18 at 09:10 -0900, Jeff Spaleta wrote:
> This still needs to go before our packaging committee methinks.

Yes. I'm still talking with the other distros, and most are /okay/ with
the idea. 99% of package don't need any changes, it's only the 1% that
already look different to the others.

> And if its approved as a Review Should or a Must, it would absolutely
> be super keen if reviewers had a toolized way to check for conformance
> so we can catch this for anything submitted moving forward.

Yes, I'm going to play with rpmlint and see if I can add some simple
rules.

Richard.




From limb at jcomserv.net  Thu Dec 18 18:46:45 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 12:46:45 -0600 (CST)
Subject: exiv2-0.18 coming soon to a rawhide near you
In-Reply-To: <gie4rj$brc$1@ger.gmane.org>
References: <494A935E.1070503@math.unl.edu>
	<a64bc4311504a990d2e7e0287ee66d96.squirrel@mail.jcomserv.net>
	<gie4rj$brc$1@ger.gmane.org>
Message-ID: <cfb4530ddf5dba67ef82aaa8b482e019.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>
>>
>>> I'll be updating to exiv2-0.18 in rawhide real soon, which includes
>>> soname bump, and start jumping on rebuilding dependent apps asap.
>>
>> Thanks for the heads up.  Is it a lot of packages?  Got a list and or
>> need
>> a hand?
>
> The list I'll be respinning from my quick-n-dirty repoquery includes:
> geeqie-0:1.0-0.8.alpha2.fc10.src
> gnome-commander-0:1.2.8-0.2.svn2351_trunk.fc11.src
> hugin-0:0.7.0-1.fc10.src
> immix-0:1.3.2-4.fc11.src
> kdegraphics-7:4.1.85-2.fc11.src
> kipi-plugins-0:0.2.0-0.7.beta4.fc11.src
> koffice-1:1.9.98.3-1.fc11.src
> kphotoalbum-0:3.2-0.5.20081007svn.fc11.src
> merkaartor-0:0.12-2.fc10.src
> pyexiv2-0:0.1.2-5.fc11.src
> qtpfsgui-0:1.9.2-2.fc10.src
> rawstudio-0:1.1.1-1.fc10.src
> strigi-0:0.5.11.1-1.fc11.src
> ufraw-0:0.14.1-3.fc11.src
>
How far have you got?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From nicolas.mailhot at laposte.net  Thu Dec 18 18:52:25 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 18 Dec 2008 19:52:25 +0100
Subject: RFC: Description text in packages
In-Reply-To: <gidupi$lhi$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229456805.15451.2.camel@arekh.okg> <gi91p1$ssr$1@ger.gmane.org>
	<200812181117.34596.billcrawford1970@gmail.com>
	<gidupi$lhi$1@ger.gmane.org>
Message-ID: <1229626345.12401.21.camel@arekh.okg>

Le jeudi 18 d?cembre 2008 ? 10:46 -0600, Matthew Woehlke a ?crit :

> ...which is the point I was trying to make to Nicolas; when dealing with 
> current US keyboards, there is no precedent for a compose key. That's a 
> lot of inertia to overcome, and (to respond to Nicolas' other comment), 
> there IS NO EDUCATION SYSTEM IN PLACE right now, that I am aware of.

So is your argument that because there is inertia, trying something new
won't work, because inertia will necessarily win?

Or is your argument that takeup will be difficult in the US?

I hope you realise that Fedora is an international project, and that to
overcome inertia, you need by definition to start something new in the
first place.

Even MS has magic symbols on something similar to xkb's 3rd and 4th
levels, and I've not seen it hurting either windows or US people in the
USA.

People will be educated the way they are educated computer-side. Someone
will RTFM or discover accidently the features, other people will notice
he manages to input pretty stuff, and the tricks will spread.

So get some perspective. People manage this kind of computer novelty all
the time. The markup Richard is so enamoured of is just as hard to
educate about.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/8f699d24/attachment.sig>

From dbn.lists at gmail.com  Thu Dec 18 18:53:58 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 18 Dec 2008 10:53:58 -0800
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
References: <loom.20081203T184910-257@post.gmane.org>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
	<eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
Message-ID: <91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>

On Thu, Dec 18, 2008 at 10:23 AM, Jon Ciesla <limb at jcomserv.net> wrote:
>
>> Jon Ciesla wrote:
>>>> "Jon Ciesla" <limb at jcomserv.net> writes:
>>>>>> (Yes, I know libjpeg upstream is kinda moribund, but if you want new
>>>>>> features in it you should be trying to revive upstream development,
>>>>>> not strongarm the Fedora package maintainer to take over
>>>>>> development.)
>>>>> I agree strongly with that principle.  Two questions:
>>>>> A. What has been done thusfar WTR reviving upstream development?
>>>> Well, at one point I had more or less formally blessed Guido Vollbeding
>>>> as the new lead maintainer, but if he's actually put out a release I
>>>> haven't heard about it :-(.  You could try bugging the people
>>>> associated
>>>> with the sourceforge libjpeg project.
>>>
>>> CCing them.  libjpeg SourceForge team, what is the current status of
>>> libjpeg development?
>>
>> Jon,
>>
>> I have heard nothing in some time from Guido, and I'm not aware of him
>> producing any sort of libjpeg release.
>>
>> I find the situation somewhat frustrating.
>
> Agreed.  So what's next?  Is there a plan for further action, a new
> primary maintainer, etc?

There was a fork on freedesktop.org for a while that was eventually
removed because the new maintainers were unresponsive.

http://www.clearchain.com/blog/posts/project-libjpeg-shutdown

If you could convince them that you would actually maintain it, they
might be receptive to reviving it.

--
Dan



From thomas.moschny at gmail.com  Thu Dec 18 19:01:06 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 18 Dec 2008 20:01:06 +0100
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229617055.3651.55.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<gi94q2$7eb$2@ger.gmane.org> <1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan>
	<49496940.20706@gmail.com> <1229609395.3651.19.camel@hughsie-work.lan>
	<1229615827.6392.109.camel@code.and.org>
	<1229617055.3651.55.camel@hughsie-work.lan>
Message-ID: <a9d183c80812181101g53b56459q24e90303af13d383@mail.gmail.com>

2008/12/18 Richard Hughes <hughsient at gmail.com>:
> Ahh, my simple markup parser is a bit more tolerant to this and formats
> the bullets correctly.

What output format are you targetting at with your
parser/transformator? Note that we already have two python markdown
implementations in the distro.

- Thomas



From rdieter at math.unl.edu  Thu Dec 18 19:04:38 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Dec 2008 13:04:38 -0600
Subject: exiv2-0.18 coming soon to a rawhide near you
References: <494A935E.1070503@math.unl.edu>
	<a64bc4311504a990d2e7e0287ee66d96.squirrel@mail.jcomserv.net>
	<gie4rj$brc$1@ger.gmane.org>
	<cfb4530ddf5dba67ef82aaa8b482e019.squirrel@mail.jcomserv.net>
Message-ID: <gie6qi$ip8$1@ger.gmane.org>

Jon Ciesla wrote:

> 
>> Jon Ciesla wrote:
>>
>>>
>>>> I'll be updating to exiv2-0.18 in rawhide real soon, which includes
>>>> soname bump, and start jumping on rebuilding dependent apps asap.
>>>
>>> Thanks for the heads up.  Is it a lot of packages?  Got a list and or
>>> need
>>> a hand?
>>
>> The list I'll be respinning from my quick-n-dirty repoquery includes:
...
> How far have you got?

http://koji.fedoraproject.org/koji/taskinfo?taskID=1007293

cross your fingers.

-- Rex



From choeger at cs.tu-berlin.de  Thu Dec 18 19:20:45 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 18 Dec 2008 20:20:45 +0100
Subject: certificate revoked?
In-Reply-To: <494A79F0.1060509@gmail.com>
References: <1229606541.12194.5.camel@choeger5.umpa.netz>
	<c549477884353bbd9cff5bfd9a21509f.squirrel@mail.jcomserv.net>
	<1229612013.12194.14.camel@choeger5.umpa.netz>
	<494A79F0.1060509@gmail.com>
Message-ID: <1229628045.20341.6.camel@choeger5.umpa.netz>

I think, I can bring some clue int that:

1. I already had ~/.fedora.cert on another box, so I copied that. 

2. I had a quick look at the packager howto, where I read, I should run
fedora-packager-setup, what I did. 

3. The ~/.fedora.cert I see now is different, I assume that something
went wrong here some step (installing koji, running
fedora-packager-setup) must have downloaded a new key.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/5d73e681/attachment.sig>

From limb at jcomserv.net  Thu Dec 18 19:21:16 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 13:21:16 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
	<eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
	<91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>
Message-ID: <c36581a7b59348d68dbdecd9d018da71.squirrel@mail.jcomserv.net>


> On Thu, Dec 18, 2008 at 10:23 AM, Jon Ciesla <limb at jcomserv.net> wrote:
>>
>>> Jon Ciesla wrote:
>>>>> "Jon Ciesla" <limb at jcomserv.net> writes:
>>>>>>> (Yes, I know libjpeg upstream is kinda moribund, but if you want
>>>>>>> new
>>>>>>> features in it you should be trying to revive upstream development,
>>>>>>> not strongarm the Fedora package maintainer to take over
>>>>>>> development.)
>>>>>> I agree strongly with that principle.  Two questions:
>>>>>> A. What has been done thusfar WTR reviving upstream development?
>>>>> Well, at one point I had more or less formally blessed Guido
>>>>> Vollbeding
>>>>> as the new lead maintainer, but if he's actually put out a release I
>>>>> haven't heard about it :-(.  You could try bugging the people
>>>>> associated
>>>>> with the sourceforge libjpeg project.
>>>>
>>>> CCing them.  libjpeg SourceForge team, what is the current status of
>>>> libjpeg development?
>>>
>>> Jon,
>>>
>>> I have heard nothing in some time from Guido, and I'm not aware of him
>>> producing any sort of libjpeg release.
>>>
>>> I find the situation somewhat frustrating.
>>
>> Agreed.  So what's next?  Is there a plan for further action, a new
>> primary maintainer, etc?
>
> There was a fork on freedesktop.org for a while that was eventually
> removed because the new maintainers were unresponsive.
>
> http://www.clearchain.com/blog/posts/project-libjpeg-shutdown
>
> If you could convince them that you would actually maintain it, they
> might be receptive to reviving it.

What about simply keeping it on Sourceforge?  Don't one of you have admin
access to the project there?  I have a SF account currently.

As far as bringing libjpeg current, I'm not sure the task would be as
herculean as it sounds, activities at fd.o hotwithstanding, not sure what
that's about.

State of things as I see them:

1 libjpeg bug in RH/Fedora land.

1 libjpeg bug in Debian. CCing debian libjpeg62 maintainer.

None in Gentoo.  Not sure where OpenSUSE bugs live.  Not sure what other
distros to loop into this.

What it looks like needs to be done is an examination of the patches used
in the above distros, and a discussion over these among the distro
maintainers and $_libjpeg_upstream_designee, leading to integration of
those most commonly used in the distros.

Does this sound sane?

> --
> Dan
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From nicolas.mailhot at laposte.net  Thu Dec 18 19:40:23 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 18 Dec 2008 20:40:23 +0100
Subject: On mass renames
Message-ID: <1229629223.13577.11.camel@arekh.okg>


Sometimes, it is necessary to perform a mass rename to bring some
consistency to a class of packages.

In that case any workflow that proceeds package by package is the road
to failure, since
? either each package is done separately by different people with little
coordination (and you don't get consistency, some packagers will always
slack or fail)
? or one person goes through each package and you get burnout and again,
failure (and I won't even speak of doing a new review for each package)

I'd like to see a mode where:
? a list of consistent renames is approved collectively
? the associated cvs work is done in one shot by infra
? each individual packager gets to work on the spec changes of his
packages
? an experienced packager or a group of packagers is mandated to check
it's done correctly and eventually to substitute to the packagers who
don't do their bit at all

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/ec5949cc/attachment.sig>

From rdieter at math.unl.edu  Thu Dec 18 19:55:17 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Dec 2008 13:55:17 -0600
Subject: exiv2-0.18 coming soon to a rawhide near you
References: <494A935E.1070503@math.unl.edu>
	<a64bc4311504a990d2e7e0287ee66d96.squirrel@mail.jcomserv.net>
	<gie4rj$brc$1@ger.gmane.org>
	<cfb4530ddf5dba67ef82aaa8b482e019.squirrel@mail.jcomserv.net>
	<gie6qi$ip8$1@ger.gmane.org>
Message-ID: <gie9pg$t1f$1@ger.gmane.org>

Rex Dieter wrote:
> Jon Ciesla wrote:

>> I'll be updating to exiv2-0.18 in rawhide real soon, which includes
>> soname bump, and start jumping on rebuilding dependent apps asap.

> Thanks for the heads up.  Is it a lot of packages?  Got a list and or
> need a hand?

OK, some rebuild failures, in need of some extra love:

pyexiv2: http://koji.fedoraproject.org/koji/buildinfo?buildID=75466

geeqie: http://koji.fedoraproject.org/koji/buildinfo?buildID=75467



From limb at jcomserv.net  Thu Dec 18 20:01:46 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 14:01:46 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <494AA62E.7040304@howardsilvan.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
	<eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
	<91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>
	<c36581a7b59348d68dbdecd9d018da71.squirrel@mail.jcomserv.net>
	<494AA62E.7040304@howardsilvan.com>
Message-ID: <dbd1018eee690e3de8da996bcd17e8ec.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>> What about simply keeping it on Sourceforge?  Don't one of you have
>> admin
>> access to the project there?  I have a SF account currently.
>>
>> As far as bringing libjpeg current, I'm not sure the task would be as
>> herculean as it sounds, activities at fd.o hotwithstanding, not sure
>> what
>> that's about.
>
> libjpeg is essentially dead.
>
> The move to put libjpeg on Sourceforge was done to prevent a complete
> scattering of the developers over a looming fork.  So I think that the
> move to Sourceforge was wise as it kept everyone "together".  However,
> the project is still dead, and if it had forked it probably would still
> be dead.
>
> I think that it will take someone who is sincerely available to maintain
> the project, who has the respect of the developer community, to commit
> those patches and organize a release schedule and plan... and then move
> forward.

Doubtless.

> I truly wish that person were me.  However, I do not have the time, and
> I otherwise don't feel qualified.

Understandable.  If this person exists, then that is the logical path.  If
not, then are distro maintainers to simply soldier on, maintaining what
are, in effect, forks?  I have to think that in the absence of the
Qualified Individual we all desire, a coordinating effort of distro
maintainers would be preferable to the status quo.

> Thanks,
>
> Lee.
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From mw_triad at users.sourceforge.net  Thu Dec 18 20:15:37 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 18 Dec 2008 14:15:37 -0600
Subject: RFC: Description text in packages
In-Reply-To: <1229626345.12401.21.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>	<1229456805.15451.2.camel@arekh.okg>
	<gi91p1$ssr$1@ger.gmane.org>	<200812181117.34596.billcrawford1970@gmail.com>	<gidupi$lhi$1@ger.gmane.org>
	<1229626345.12401.21.camel@arekh.okg>
Message-ID: <gieb19$2kt$1@ger.gmane.org>

Nicolas Mailhot wrote:
> So is your argument that because there is inertia, trying something new
> won't work, because inertia will necessarily win?
> 
> Or is your argument that takeup will be difficult in the US?

I've been saying that for the last several messages, and trying to get 
you to propose a means of starting to overcome said inertia.

> I hope you realise that Fedora is an international project,

I do. I also realize that there is a certain amount of US influence on 
technology. (Some of it, alas, is from a certain Redmond company that 
doesn't care as much as they might about international users. 
Unfortunately, said company also exerts a lot of control on hardware, 
which is part of the problem.)

> Even MS has magic symbols on something similar to xkb's 3rd and 4th
> levels, and I've not seen it hurting either windows or US people in the
> USA.

Um... no, those would be the META and MENU keys. As I already pointed 
out, one of those is already generally used for shortcuts. (And I'm 
saying that not just from personal experience, but also from usability 
discussions regarding assignment of shortcut keys.)

> The markup Richard is so enamoured of is just as hard to
> educate about.

I disagree. I'm already exposed to that sort of markup, whereas I 
/don't/ have an AltGr / Compose key on my keyboard.

Perhaps in an absolute sense (i.e. starting with someone totally 
ignorant of both systems) that is true. In a practical sense, there is 
already inertia for markdown, if only because people do something 
similar to it already. While the playing field may be level for some 
people, I think that markdown is likely more wide-spread.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
???????????????????????



From opensource at till.name  Thu Dec 18 20:18:24 2008
From: opensource at till.name (Till Maas)
Date: Thu, 18 Dec 2008 21:18:24 +0100
Subject: query post/postun/preun dependencies for a rpm
In-Reply-To: <alpine.DEB.1.10.0812181719440.13881@gotcha.dreamhost.com>
References: <200812181355.10028.opensource@till.name>
	<alpine.DEB.1.10.0812181719440.13881@gotcha.dreamhost.com>
Message-ID: <200812182118.35710.opensource@till.name>

On Thu December 18 2008, Panu Matilainen wrote:

> trick: http://laiskiainen.org/rpm/scripts/depnames.py

> This'll only work for installed packages, making it work for non-installed
> packages is left as an excercise to the reader...

Thanks, luckily there was nice documentation available to get this done:
http://people.redhat.com/pnasrat/rpm-python/rpm-python-slides/foil07.html

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/09e51791/attachment.sig>

From ville.skytta at iki.fi  Thu Dec 18 20:18:58 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 18 Dec 2008 22:18:58 +0200
Subject: Recursively listing dependencies of a package?
Message-ID: <200812182218.58818.ville.skytta@iki.fi>

Hello,

Is there a tool that can list recursive dependencies (the whole dep tree) of a 
package from repodata?  And even better if it can be also told to resolve 
things like /bin/sh and libfoo.so.x to package names and output a list of 
those package names (+ EVRA) only (not files or Provides).

What I've looked into so far:

yum deplist: is not recursive, or I don't know how to tell it to be.  Also a 
bit verbose for my taste (lists all providers of deps).

repoquery -R --resolve: otherwise exactly what I'm looking for, but it's not 
recursive either.  Adding --recursive to the options does not appear to make 
any difference.



From ffesti at redhat.com  Thu Dec 18 20:25:51 2008
From: ffesti at redhat.com (Florian Festi)
Date: Thu, 18 Dec 2008 21:25:51 +0100
Subject: Recursively listing dependencies of a package?
In-Reply-To: <200812182218.58818.ville.skytta@iki.fi>
References: <200812182218.58818.ville.skytta@iki.fi>
Message-ID: <494AB1CF.2010108@redhat.com>

Ville Skytt? wrote:
> Hello,
> 
> Is there a tool that can list recursive dependencies (the whole dep tree) of a 
> package from repodata?  And even better if it can be also told to resolve 
> things like /bin/sh and libfoo.so.x to package names and output a list of 
> those package names (+ EVRA) only (not files or Provides).
> 
> What I've looked into so far:
> 
> yum deplist: is not recursive, or I don't know how to tell it to be.  Also a 
> bit verbose for my taste (lists all providers of deps).
> 
> repoquery -R --resolve: otherwise exactly what I'm looking for, but it's not 
> recursive either.  Adding --recursive to the options does not appear to make 
> any difference.
> 

Funny, I just answered exacly this question this afternoon. Attached is a 
slightly modified yummain.py and a small shell script that is suitable to 
generated package lists out of yum commands. Just virtually install the 
package you are interested in into an empty build root.

The scripts may need a little tweaking and if it breaks you keep the pieces.

Florian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yumlist
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/e1994e33/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: createpackagelist.sh
Type: application/x-shellscript
Size: 568 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/e1994e33/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exludes-F10-x86_64.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/e1994e33/attachment.txt>

From trever.adams at gmail.com  Thu Dec 18 20:25:47 2008
From: trever.adams at gmail.com (Trever L. Adams)
Date: Thu, 18 Dec 2008 13:25:47 -0700
Subject: Multiple packages from one tarball and spec file
In-Reply-To: <200811291322.11215.konrad@tylerc.org>
References: <493162FA.6030705@gmail.com> <200811291322.11215.konrad@tylerc.org>
Message-ID: <494AB1CB.2000705@gmail.com>

Conrad Meyer wrote:
> On Saturday 29 November 2008 07:42:50 am Trever L. Adams wrote:
>   
>> Additionally, I have several packages I am thinking of doing (some of
>> which I have spec files for already). However, I am displeased with a
>> few of them that come from one tarball. There are several options
>> (crm114, dspam, or mailing back-ends for example) for dovecot-antispam.
>> The problem is, you cannot build one module for dovecot that does them
>> all, so the module has to be rebuilt with slightly different options and
>> must conflict with all other dovecot-antispam RPMs. Is possible from one
>> spec file and tarball? This would require different setup, build,
>> install and package setups. This is because the same module would be
>> built for each area, need to be packaged, and then move onto the rest.
>>     
>
> Are you suggesting that in order for multiple things to Provide: 
> dovecot-antispam they need to come from the same SRPM?
>
> Regards,
>   
Sorry for not responding quickly. This email disappeared. The problem I 
have is that dovecot-antispam has to be built specifically for each of 
the three or four ways it works. (Being: crm114, dspam, mail forward and 
some signature thing.)

Instead of having four SRPMs which are identical other than just a few 
configuration lines and SPEC file changes, is it possible to build all 
four from one SRPM or at least from one tarball?

Thank you,
Trever

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/74b0c067/attachment.sig>

From nicolas.mailhot at laposte.net  Thu Dec 18 20:27:29 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 18 Dec 2008 21:27:29 +0100
Subject: RFC: Description text in packages
In-Reply-To: <gieb19$2kt$1@ger.gmane.org>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229456805.15451.2.camel@arekh.okg> <gi91p1$ssr$1@ger.gmane.org>
	<200812181117.34596.billcrawford1970@gmail.com>
	<gidupi$lhi$1@ger.gmane.org> <1229626345.12401.21.camel@arekh.okg>
	<gieb19$2kt$1@ger.gmane.org>
Message-ID: <1229632049.14258.2.camel@arekh.okg>

Le jeudi 18 d?cembre 2008 ? 14:15 -0600, Matthew Woehlke a ?crit :
> Nicolas Mailhot wrote:
> > So is your argument that because there is inertia, trying something new
> > won't work, because inertia will necessarily win?
> > 
> > Or is your argument that takeup will be difficult in the US?
> 
> I've been saying that for the last several messages, and trying to get 
> you to propose a means of starting to overcome said inertia.

The means of overcoming inertia is to ignore it and do what you wanted
to do anyway. The means of not overcoming inertia is to wait for
something to overcome inertia to do stuff.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/0ceaa383/attachment.sig>

From limb at jcomserv.net  Thu Dec 18 20:28:39 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 14:28:39 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <494AADB7.5000604@howardsilvan.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
	<eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
	<91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>
	<c36581a7b59348d68dbdecd9d018da71.squirrel@mail.jcomserv.net>
	<494AA62E.7040304@howardsilvan.com>
	<dbd1018eee690e3de8da996bcd17e8ec.squirrel@mail.jcomserv.net>
	<494AADB7.5000604@howardsilvan.com>
Message-ID: <6cfd16a6721cf4cd73a3b7d13dcbd1e3.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>> Understandable.  If this person exists, then that is the logical path.
>> If
>> not, then are distro maintainers to simply soldier on, maintaining what
>> are, in effect, forks?  I have to think that in the absence of the
>> Qualified Individual we all desire, a coordinating effort of distro
>> maintainers would be preferable to the status quo.
>
> I wholeheartedly agree.  I'm more than happy to see them all set up with
> the necessary permissions on the Sourceforge site.

Adding Tom Lane back to the thread.

So at this point we'd need you, Lee, or someone else with the sf.net
project access, to grant the access, and buy-in from interested
maintainers, which would be Brian and Tom(unless he wants to designate
someone else) so far.  I'll research who others are at other distros.

I am also willing to contribute, beyond simply meddling. :)  I have a
sf.net account(limburgher), etc.

> Thanks,
>
> Lee.
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From skvidal at fedoraproject.org  Thu Dec 18 20:27:23 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 18 Dec 2008 15:27:23 -0500 (EST)
Subject: Recursively listing dependencies of a package?
In-Reply-To: <200812182218.58818.ville.skytta@iki.fi>
References: <200812182218.58818.ville.skytta@iki.fi>
Message-ID: <alpine.LFD.2.00.0812181521260.31106@localhost.localdomain>



On Thu, 18 Dec 2008, Ville Skytt? wrote:

> Hello,
>
> Is there a tool that can list recursive dependencies (the whole dep tree) of a
> package from repodata?  And even better if it can be also told to resolve
> things like /bin/sh and libfoo.so.x to package names and output a list of
> those package names (+ EVRA) only (not files or Provides).
>
> What I've looked into so far:
>
> yum deplist: is not recursive, or I don't know how to tell it to be.  Also a
> bit verbose for my taste (lists all providers of deps).
>
> repoquery -R --resolve: otherwise exactly what I'm looking for, but it's not
> recursive either.  Adding --recursive to the options does not appear to make
> any difference.

http://people.redhat.com/jantill/yum/commands/pkg-deps-tree-view.py

for deps

http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py

for provs

-sv

From nathanael at gnat.ca  Thu Dec 18 20:41:01 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Thu, 18 Dec 2008 13:41:01 -0700
Subject: Memory/filesystem corruption
In-Reply-To: <d551e0e20812172303v355f681dx7824c5172285ce54@mail.gmail.com>
References: <4947EEDF.9000801@niemueller.de>	<d551e0e20812161604s389a2544u935204fe143453d3@mail.gmail.com>	<4949DD1E.7070504@gnat.ca>
	<d551e0e20812172303v355f681dx7824c5172285ce54@mail.gmail.com>
Message-ID: <494AB55D.3070005@gnat.ca>

Camilo Mesias wrote:
> Hi,

> http://pastebin.com/m1ff96ea5
> 
> Any use?

Unfortunately to me no, mine has corruption in it all the time. Looks 
like this, but runs fine (on a previous mobo the ps2 key/mouse would 
stop responding when the corruption happened). On the new mobo I 
replaced it with the corruption is always there. Though memtest ran for 
18 hours with 26 passes without a fail. So I'm baffled.

http://pastebin.com/m4f4956ef

-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From markg85 at gmail.com  Thu Dec 18 20:56:52 2008
From: markg85 at gmail.com (Mark)
Date: Thu, 18 Dec 2008 21:56:52 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
Message-ID: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>

Hey,

The question is simple:
Lets use the browser view of nautilus in the next fedora release.

Motivation:
A new window for each folder that i open is so painful!!
1. My taskbar fills up in notime each time i open a new folder
2. New features of nautilus: tabbed browsing! completely useless if
your not using the browser mode
3. Tabbed browsing (files/folders or web) is "hot" these days
4. It feels so.. old (windows 95? 3.11?)
just to name a few

Cross posted to the devel list because it's for the next fedora
version (currently in development thus the devel list)

Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
couldn't find an existing one for this! made one myself)

So, lets vote:

+1 from me

I hope this can be done for Fedora 11 (it's just changing one gconf value).
All vote plz

Mark.



From a.badger at gmail.com  Thu Dec 18 20:58:28 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 18 Dec 2008 12:58:28 -0800
Subject: Multiple packages from one tarball and spec file
In-Reply-To: <494AB1CB.2000705@gmail.com>
References: <493162FA.6030705@gmail.com> <200811291322.11215.konrad@tylerc.org>
	<494AB1CB.2000705@gmail.com>
Message-ID: <494AB974.1070803@gmail.com>

Trever L. Adams wrote:
> Conrad Meyer wrote:
>> On Saturday 29 November 2008 07:42:50 am Trever L. Adams wrote:
>>  
>>> Additionally, I have several packages I am thinking of doing (some of
>>> which I have spec files for already). However, I am displeased with a
>>> few of them that come from one tarball. There are several options
>>> (crm114, dspam, or mailing back-ends for example) for dovecot-antispam.
>>> The problem is, you cannot build one module for dovecot that does them
>>> all, so the module has to be rebuilt with slightly different options and
>>> must conflict with all other dovecot-antispam RPMs. Is possible from one
>>> spec file and tarball? This would require different setup, build,
>>> install and package setups. This is because the same module would be
>>> built for each area, need to be packaged, and then move onto the rest.
>>>     
>>
>> Are you suggesting that in order for multiple things to Provide:
>> dovecot-antispam they need to come from the same SRPM?
>>
>> Regards,
>>   
> Sorry for not responding quickly. This email disappeared. The problem I
> have is that dovecot-antispam has to be built specifically for each of
> the three or four ways it works. (Being: crm114, dspam, mail forward and
> some signature thing.)
> 
> Instead of having four SRPMs which are identical other than just a few
> configuration lines and SPEC file changes, is it possible to build all
> four from one SRPM or at least from one tarball?
> 
Yes.

I believe the vim package does this to generate the vim-minimal (with
/bin/vi) and vim-enhanced  (with /usr/bin/vim).

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/379e27c7/attachment.sig>

From limb at jcomserv.net  Thu Dec 18 21:02:54 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Dec 2008 15:02:54 -0600 (CST)
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <24f04553ad09f24d13f6ad6ec9bbeada.squirrel@mail.jcomserv.net>


> Hey,
>
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.
>
> Motivation:
> A new window for each folder that i open is so painful!!
> 1. My taskbar fills up in notime each time i open a new folder
> 2. New features of nautilus: tabbed browsing! completely useless if
> your not using the browser mode
> 3. Tabbed browsing (files/folders or web) is "hot" these days
> 4. It feels so.. old (windows 95? 3.11?)
> just to name a few
>
> Cross posted to the devel list because it's for the next fedora
> version (currently in development thus the devel list)
>
> Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
> couldn't find an existing one for this! made one myself)
>
> So, lets vote:
>
> +1 from me
>
> I hope this can be done for Fedora 11 (it's just changing one gconf
> value).
> All vote plz

+1

> Mark.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From dpierce at redhat.com  Thu Dec 18 21:03:23 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Thu, 18 Dec 2008 16:03:23 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <20081218210323.GE18953@mcpierce-laptop.rdu.redhat.com>

On Thu, Dec 18, 2008 at 09:56:52PM +0100, Mark wrote:
> So, lets vote:
> 
> +1 from me

+1 with me as well. I find the separate window annoying as well, and
the way it lays itself just over the parent so that I have be a
eagle eyed sniper shot to close the parent without moving windows is
a PITA.

But, can we have it be configurable to have it open a new tab *or*
just open the selected folder in the current tab? I prefer the
latter.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/1c9dec0b/attachment.sig>

From sgallagh at redhat.com  Thu Dec 18 21:04:43 2008
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Thu, 18 Dec 2008 16:04:43 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <494ABAEB.4030805@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark wrote:
> Hey,
> 
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.
> 
> Motivation:
> A new window for each folder that i open is so painful!!
> 1. My taskbar fills up in notime each time i open a new folder
> 2. New features of nautilus: tabbed browsing! completely useless if
> your not using the browser mode
> 3. Tabbed browsing (files/folders or web) is "hot" these days
> 4. It feels so.. old (windows 95? 3.11?)
> just to name a few
> 
> Cross posted to the devel list because it's for the next fedora
> version (currently in development thus the devel list)
> 
> Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
> couldn't find an existing one for this! made one myself)
> 
> So, lets vote:
> 
> +1 from me
> 
> I hope this can be done for Fedora 11 (it's just changing one gconf value).
> All vote plz
> 
> Mark.
> 

I don't really care if it's the default or not, but for crying out loud
make it easy and obvious to change. Instead of "Always open in browser
windows", it should be the more user-friendly "Open folders in the same
window".



- --

- --------------------
Stephen Gallagher
RHCE 804006346421761
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKuusACgkQeiVVYja6o6O+fACgp6Dgn84YfPqVqOzf5JmNfxW9
gFsAoJyBPAvfUJdkdzm3EN7n9N3euJ+U
=75GB
-----END PGP SIGNATURE-----



From j.w.r.degoede at hhs.nl  Thu Dec 18 21:05:21 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 18 Dec 2008 22:05:21 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <494ABB11.70901@hhs.nl>

Mark wrote:
> Hey,
> 
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.
> 
> Motivation:
> A new window for each folder that i open is so painful!!
> 1. My taskbar fills up in notime each time i open a new folder
> 2. New features of nautilus: tabbed browsing! completely useless if
> your not using the browser mode
> 3. Tabbed browsing (files/folders or web) is "hot" these days
> 4. It feels so.. old (windows 95? 3.11?)
> just to name a few
> 
> Cross posted to the devel list because it's for the next fedora
> version (currently in development thus the devel list)
> 
> Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
> couldn't find an existing one for this! made one myself)
> 
> So, lets vote:
> 
> +1 from me
> 
> I hope this can be done for Fedora 11 (it's just changing one gconf value).
> All vote plz
> 
> Mark.
> 

+1

Regards,

Hans



From mclasen at redhat.com  Thu Dec 18 21:09:26 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 18 Dec 2008 16:09:26 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <1229634566.3300.2.camel@matthiasc>

On Thu, 2008-12-18 at 21:56 +0100, Mark wrote:
> Hey,
> 
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.
> 
> Motivation:
> A new window for each folder that i open is so painful!!
> 1. My taskbar fills up in notime each time i open a new folder
> 2. New features of nautilus: tabbed browsing! completely useless if
> your not using the browser mode
> 3. Tabbed browsing (files/folders or web) is "hot" these days
> 4. It feels so.. old (windows 95? 3.11?)
> just to name a few
> 
> Cross posted to the devel list because it's for the next fedora
> version (currently in development thus the devel list)
> 
> Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
> couldn't find an existing one for this! made one myself)
> 
> So, lets vote:
> 
> +1 from me
> 
> I hope this can be done for Fedora 11 (it's just changing one gconf value).
> All vote plz

We don't do votes on things like this. But I admire your persistence.
Haven't you tried to get fesco to vote on this for F9 ?



From sundaram at fedoraproject.org  Thu Dec 18 21:10:23 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 19 Dec 2008 02:40:23 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <494ABC3F.8000700@fedoraproject.org>

Mark wrote:
> Hey,
> 
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.
> 
> I hope this can be done for Fedora 11 (it's just changing one gconf value).
> All vote plz

What's next? Voting on ssh configuration options?

Mindless +1 and =1 will yield to nothing but number pushing and not a 
serious debate.

I vote that we don't vote on configuration changes and let the upstream 
developers and package maintainers decide.  Voting on every 
configuration change, we would obvious not be getting anywhere.  The 
decision will be an upstream change or in other circumstances, the 
maintainer of the software in question. If the maintainers want to do a 
survey, they can on their own or ask for help if needed.


Rahul



From naheemzaffar at gmail.com  Thu Dec 18 21:10:56 2008
From: naheemzaffar at gmail.com (Naheem Zaffar)
Date: Thu, 18 Dec 2008 21:10:56 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494ABB11.70901@hhs.nl>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABB11.70901@hhs.nl>
Message-ID: <3adc77210812181310y15a39b43lfedf2b5f1fb04c96@mail.gmail.com>

-1

I like it as it is. However I am not power user. The occasional time I need
to traverse directories, middle-click is king.

Should Fedora try to deviate from upstream? Is there a need for a proper
debate upstream? Is there a proper poll where only those in favour will not
post?

That is an honest question - originally I even disliked that Fedora had its
own window borders (Nodoka Vs Clearlooks), but over time I have come to
accept that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/0e3c6b7b/attachment.htm>

From dpierce at redhat.com  Thu Dec 18 21:11:32 2008
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Thu, 18 Dec 2008 16:11:32 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494ABAEB.4030805@redhat.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABAEB.4030805@redhat.com>
Message-ID: <20081218211132.GF18953@mcpierce-laptop.rdu.redhat.com>

On Thu, Dec 18, 2008 at 04:04:43PM -0500, Stephen Gallagher wrote:
> I don't really care if it's the default or not, but for crying out loud
> make it easy and obvious to change. Instead of "Always open in browser
> windows", it should be the more user-friendly "Open folders in the same
> window".

+1 to this . :)

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
"What do you care what other people think, Mr. Feynman?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/e4250d11/attachment.sig>

From markg85 at gmail.com  Thu Dec 18 21:13:08 2008
From: markg85 at gmail.com (Mark)
Date: Thu, 18 Dec 2008 22:13:08 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229634566.3300.2.camel@matthiasc>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc>
Message-ID: <6e24a8e80812181313n3c07101ua4df7441bd75dc4e@mail.gmail.com>

well i tried yes but that was for the thumbnail size.

On Thu, Dec 18, 2008 at 10:09 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> On Thu, 2008-12-18 at 21:56 +0100, Mark wrote:
>> Hey,
>>
>> The question is simple:
>> Lets use the browser view of nautilus in the next fedora release.
>>
>> Motivation:
>> A new window for each folder that i open is so painful!!
>> 1. My taskbar fills up in notime each time i open a new folder
>> 2. New features of nautilus: tabbed browsing! completely useless if
>> your not using the browser mode
>> 3. Tabbed browsing (files/folders or web) is "hot" these days
>> 4. It feels so.. old (windows 95? 3.11?)
>> just to name a few
>>
>> Cross posted to the devel list because it's for the next fedora
>> version (currently in development thus the devel list)
>>
>> Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
>> couldn't find an existing one for this! made one myself)
>>
>> So, lets vote:
>>
>> +1 from me
>>
>> I hope this can be done for Fedora 11 (it's just changing one gconf value).
>> All vote plz
>
> We don't do votes on things like this. But I admire your persistence.
> Haven't you tried to get fesco to vote on this for F9 ?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From hughsient at gmail.com  Thu Dec 18 21:12:39 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 18 Dec 2008 21:12:39 +0000
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <a9d183c80812181101g53b56459q24e90303af13d383@mail.gmail.com>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<gi94q2$7eb$2@ger.gmane.org> <1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan> <49496940.20706@gmail.com>
	<1229609395.3651.19.camel@hughsie-work.lan>
	<1229615827.6392.109.camel@code.and.org>
	<1229617055.3651.55.camel@hughsie-work.lan>
	<a9d183c80812181101g53b56459q24e90303af13d383@mail.gmail.com>
Message-ID: <1229634759.3651.76.camel@hughsie-work.lan>

On Thu, 2008-12-18 at 20:01 +0100, Thomas Moschny wrote:
> What output format are you targetting at with your
> parser/transformator? Note that we already have two python markdown
> implementations in the distro.

It's in C, not python. It's also outputting to PangoMarkup rather than
HTML.

Richard.




From hughsient at gmail.com  Thu Dec 18 21:16:46 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 18 Dec 2008 21:16:46 +0000
Subject: RFC: Description text in packages
In-Reply-To: <1229632049.14258.2.camel@arekh.okg>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229456805.15451.2.camel@arekh.okg> <gi91p1$ssr$1@ger.gmane.org>
	<200812181117.34596.billcrawford1970@gmail.com>
	<gidupi$lhi$1@ger.gmane.org> <1229626345.12401.21.camel@arekh.okg>
	<gieb19$2kt$1@ger.gmane.org>  <1229632049.14258.2.camel@arekh.okg>
Message-ID: <1229635006.3651.80.camel@hughsie-work.lan>

On Thu, 2008-12-18 at 21:27 +0100, Nicolas Mailhot wrote:
> The means of overcoming inertia is to ignore it and do what you wanted
> to do anyway. The means of not overcoming inertia is to wait for
> something to overcome inertia to do stuff.

The way to get stuff done is to ask users to stick to a trivial standard
(that most people are already using) that takes no more work. If you're
asking packagers to paste random UTF-8 characters from "Character Map",
into a spec file, then we've failed, as people are not going to do that.

Richard.




From dimi at lattica.com  Thu Dec 18 21:25:19 2008
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 18 Dec 2008 16:25:19 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494ABC3F.8000700@fedoraproject.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
Message-ID: <1229635519.23410.31.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 02:40 +0530, Rahul Sundaram wrote:
> I vote that we don't vote on configuration changes and let the
> upstream 
> developers and package maintainers decide.  Voting on every 
> configuration change, we would obvious not be getting anywhere.  The 
> decision will be an upstream change or in other circumstances, the 
> maintainer of the software in question. If the maintainers want to do
> a survey, they can on their own or ask for help if needed.

This makes lots of sense -- to be consistent, I suggest we remove
all Fedora-related artwork that diverges from upstream. Including
the desktop background images too.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From markg85 at gmail.com  Thu Dec 18 21:27:50 2008
From: markg85 at gmail.com (Mark)
Date: Thu, 18 Dec 2008 22:27:50 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494ABC3F.8000700@fedoraproject.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
Message-ID: <6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>

On Thu, Dec 18, 2008 at 10:10 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Mark wrote:
>>
>> Hey,
>>
>> The question is simple:
>> Lets use the browser view of nautilus in the next fedora release.
>>
>> I hope this can be done for Fedora 11 (it's just changing one gconf
>> value).
>> All vote plz
>
> What's next? Voting on ssh configuration options?
>
> Mindless +1 and =1 will yield to nothing but number pushing and not a
> serious debate.
>
> I vote that we don't vote on configuration changes and let the upstream
> developers and package maintainers decide.  Voting on every configuration
> change, we would obvious not be getting anywhere.  The decision will be an
> upstream change or in other circumstances, the maintainer of the software in
> question. If the maintainers want to do a survey, they can on their own or
> ask for help if needed.
>
>
> Rahul
>

Sorry, Rahul, i disagree with this. I try to get through the redhat
and fedora devs that we, the users (about 5 now if i count right),
just want to see this changed!
Redhat is eager to change things when they might get in trouble if
they have it in.. like codec support. You guys are killing out more
then enough in other packages to save your own asses and you tell us
that you want to follow upstream.. i agree on that with CODE changes.
i disagree on that with config changes! config things are just the the
values set by the creators that they think are best to use. That
doesn't make them THE best settings out there. Don't be so freaking
hard on config changes! And if it must change upstream then do so!
redhad is the lead dev of both fedora and gnome so everything
regarding this config setting is in redhats hands.

Or do you want me to submit a bug report to suggest that config
changes should be allowed in fedora! but code changes shouldn't
(unless it could possibly end up in patent lawsuits)

I am just trying to get a clear signal out that there is something in
fedora that the people using fedora want to see different



From tony at bakeyournoodle.com  Thu Dec 18 21:31:46 2008
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Fri, 19 Dec 2008 08:31:46 +1100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <20081218213146.GD25985@ozlabs.org>

On Thu, Dec 18, 2008 at 09:56:52PM +0100, Mark wrote:
> Hey,
> 
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.

<snip>
 
> So, lets vote:
> 
> +1 from me

FWIW
+1
 
Yours Tony

  linux.conf.au    http://www.marchsouth.org/
  Jan 19 - 24 2009 The Australian Linux Technical Conference!



From sundaram at fedoraproject.org  Thu Dec 18 21:32:41 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 19 Dec 2008 03:02:41 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229635519.23410.31.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>
	<1229635519.23410.31.camel@dimi.lattica.com>
Message-ID: <494AC179.10303@fedoraproject.org>

Dimi Paun wrote:
> On Fri, 2008-12-19 at 02:40 +0530, Rahul Sundaram wrote:
>> I vote that we don't vote on configuration changes and let the
>> upstream 
>> developers and package maintainers decide.  Voting on every 
>> configuration change, we would obvious not be getting anywhere.  The 
>> decision will be an upstream change or in other circumstances, the 
>> maintainer of the software in question. If the maintainers want to do
>> a survey, they can on their own or ask for help if needed.
> 
> This makes lots of sense -- to be consistent, I suggest we remove
> all Fedora-related artwork that diverges from upstream. Including
> the desktop background images too.

Branding doesn't really have anything to do with configuration changes.
I suggest that you read

http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream

For artwork and branding, Fedora is essentially upstream for many things 
like Nodoka theme. To be consistent, the decision on which artwork to 
pick among the many competing proposals is left to the artwork team and 
not by a random vote in a mail cross posted to fedora-devel and 
fedora-list either. You are confusing completely different things.

Rahul



From a.badger at gmail.com  Thu Dec 18 21:35:55 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 18 Dec 2008 13:35:55 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <24f04553ad09f24d13f6ad6ec9bbeada.squirrel@mail.jcomserv.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<24f04553ad09f24d13f6ad6ec9bbeada.squirrel@mail.jcomserv.net>
Message-ID: <494AC23B.7080102@gmail.com>

>> Motivation:
>> A new window for each folder that i open is so painful!!
>> 1. My taskbar fills up in notime each time i open a new folder
>> 2. New features of nautilus: tabbed browsing! completely useless if
>> your not using the browser mode
>> 3. Tabbed browsing (files/folders or web) is "hot" these days
>> 4. It feels so.. old (windows 95? 3.11?)
>> just to name a few
>>

Having this list is nice.  Seeing things like "tabbed browsing is a new
feature not shown when in spatial" is useful information for restarting
this flamew^Wdebate.  However:

>> Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
>> couldn't find an existing one for this! made one myself)
>>
>> So, lets vote:
>>
Voting is not the way to achieve results.  Upstream defaults, package
maintainers, and desktop team all deserve more say in what the default
should be than a poll of developers of random pieces of the distribution
no matter what our personal preference is.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/c24e08b0/attachment.sig>

From jspaleta at gmail.com  Thu Dec 18 21:42:24 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Dec 2008 12:42:24 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
Message-ID: <604aa7910812181342p7a21fc0jbb0e36762385f0b1@mail.gmail.com>

On Thu, Dec 18, 2008 at 12:27 PM, Mark <markg85 at gmail.com> wrote:
> Sorry, Rahul, i disagree with this. I try to get through the redhat
> and fedora devs that we, the users (about 5 now if i count right),
> just want to see this changed!

I'm going to be very clear on this.  A mailing list vote of this sort
isn't going to get it changed unless the maintainers are willing to
change it. If the maintainers responsible for the package aren't
interested in changing it at the Fedora level, and they have gone on
record saying that it would need to be changed as an upstream
default... then you have to drive the discussion upstream. Continuing
to brow beat the maintainers who are standing behind upstream's
default config is not going to be an effective strategy. You are
burning bridges, not solving the problem.

We've no policy in place that would compel maintainers to diviate from
upstream for a config choice for a usability argument.  Take the
usability argument upstream.

> I am just trying to get a clear signal out that there is something in
> fedora that the people using fedora want to see different

Don't you mean there is a clear signal from Gnome users that there are
people using Gnome who want to see it changed?

-jef"Looking for a new drum to beat? I've got a dead horse I can sell
you"spaleta



From nicolas.mailhot at laposte.net  Thu Dec 18 21:43:21 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 18 Dec 2008 22:43:21 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
Message-ID: <1229636601.15429.2.camel@arekh.okg>

If you want to propose this I suggest you revive the usability SIG, do
enough work to gain cloud, and then get the group to ask for the change.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/15a423af/attachment.sig>

From sundaram at fedoraproject.org  Thu Dec 18 21:49:29 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 19 Dec 2008 03:19:29 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
Message-ID: <494AC569.8070401@fedoraproject.org>

Mark wrote:

> Redhat is eager to change things when they might get in trouble if
> they have it in.. like codec support.  You guys are killing out more
> then enough in other packages to save your own asses and you tell us
> that you want to follow upstream.. 

If a software is not included at all in Fedora, then there is no 
modification and upstream is preserved as it is. For many others like in 
the case of gstreamer, the extra codecs or functionality is separated 
cleanly as plugins and we don't have to modify anything but only pick 
and choose, what we can include. Only as a last resort, is something 
patched and that is because it is the only legal choice at that point. 
It is still a unfortunate divergence and adds a ongoing  maintenance 
overhead for the package maintainers. Adding more pain to the problem 
doesn't make sense.

Refer
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream

i agree on that with CODE changes.
> i disagree on that with config changes! config things are just the the
> values set by the creators that they think are best to use. That
> doesn't make them THE best settings out there. Don't be so freaking
> hard on config changes! 

Code and configuration cannot be easily separated like this and changes 
always have a associated cost. Atleast in one package I maintain, a very 
small and simple configuration change resulted in a potential security 
hole (only in rawhide for a short while but still ..)

> I am just trying to get a clear signal out that there is something in
> fedora that the people using fedora want to see different

It doesn't seem the right path to doing that, to me.

Rahul




From cmadams at hiwaay.net  Thu Dec 18 21:51:07 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 18 Dec 2008 15:51:07 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
Message-ID: <20081218215107.GB1366434@hiwaay.net>

Once upon a time, Mark <markg85 at gmail.com> said:
> Sorry, Rahul, i disagree with this. I try to get through the redhat
> and fedora devs that we, the users (about 5 now if i count right),
> just want to see this changed!

I vote we change the default browser to "vi" (none of that sissy "vim"
crap) and the default web browser to "telnet <host> 80".

Web and/or mailing list votes, petitions, etc., are not in any way a
true representation of any user base, so don't count 5 whole votes as
"the users".
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From alsadi at gmail.com  Thu Dec 18 21:52:47 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 18 Dec 2008 23:52:47 +0200
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229636601.15429.2.camel@arekh.okg>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<1229636601.15429.2.camel@arekh.okg>
Message-ID: <385866f0812181352i4b0755f7pe5bb15a4b78c11f1@mail.gmail.com>

if shift key is pressed it will be opened in same window

so if this can be reversed in browser mode
ie. if one double clicks a folder in browser mode it should open in a new window
and one can drag and drop and benefit from the the worlds

+1 for browser mode
+2 if the shift thing is implemented

can I add +3 ?
:-)



From rda at rincon.com  Thu Dec 18 21:57:15 2008
From: rda at rincon.com (Robert Arendt)
Date: Thu, 18 Dec 2008 14:57:15 -0700
Subject: Memory/filesystem corruption
In-Reply-To: <d551e0e20812172303v355f681dx7824c5172285ce54@mail.gmail.com>
References: <4947EEDF.9000801@niemueller.de>	<d551e0e20812161604s389a2544u935204fe143453d3@mail.gmail.com>	<4949DD1E.7070504@gnat.ca>
	<d551e0e20812172303v355f681dx7824c5172285ce54@mail.gmail.com>
Message-ID: <494AC73B.4050007@rincon.com>

>> Camilo Mesias wrote:
> [...]
>>> I'm seeing messages like these:
>>>
>>> Uhhuh. NMI received for unknown reason b0 on CPU 0.
>>> You have some hardware problem, likely on the PCI bus.
>>> Dazed and confused, but trying to continue
>>>

This message comes from the kernel, from reading cpu port 61H.
It can have different meanings for different motherboards
and vendors, and is rarely adequately documented.  Interesting
discussion here: http://www.gossamer-threads.com/lists/linux/kernel/969550

For us this error turned out to be the interaction of a pair
of PCI cards.  We regressed a prom on the card, and the problem
vanished.  Basically, the kernel messages won't tell you much.
Assuming the board's OK, it's probably a board - card interaction.

Good luck
-Bob



From dr.diesel at gmail.com  Thu Dec 18 22:08:14 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Thu, 18 Dec 2008 17:08:14 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <385866f0812181352i4b0755f7pe5bb15a4b78c11f1@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<1229636601.15429.2.camel@arekh.okg>
	<385866f0812181352i4b0755f7pe5bb15a4b78c11f1@mail.gmail.com>
Message-ID: <2a28d2ab0812181408m1ff794b2gdbf2898056cd10e1@mail.gmail.com>

On Thu, Dec 18, 2008 at 4:52 PM, Muayyad AlSadi <alsadi at gmail.com> wrote:

> if shift key is pressed it will be opened in same window
>
> so if this can be reversed in browser mode
> ie. if one double clicks a folder in browser mode it should open in a new
> window
> and one can drag and drop and benefit from the the worlds
>
> +1 for browser mode
> +2 if the shift thing is implemented
>
> can I add +3 ?
> :-)
>

-1 for browser mode, but don't really care as-long-as I can change it back!





-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/56a5beb6/attachment.htm>

From dennis at ausil.us  Thu Dec 18 22:26:29 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Thu, 18 Dec 2008 16:26:29 -0600
Subject: certificate revoked?
In-Reply-To: <1229612013.12194.14.camel@choeger5.umpa.netz>
References: <1229606541.12194.5.camel@choeger5.umpa.netz>
	<c549477884353bbd9cff5bfd9a21509f.squirrel@mail.jcomserv.net>
	<1229612013.12194.14.camel@choeger5.umpa.netz>
Message-ID: <200812181626.34137.dennis@ausil.us>

On Thursday 18 December 2008 08:53:33 am Christoph H?ger wrote:
> Am Donnerstag, den 18.12.2008, 08:32 -0600 schrieb Jon Ciesla:
> > > Hi folks,
> > >
> > > in the middle of rebuilding offlineimap, which I've just taken from
> > > Till, I got an certificate revoked error. There seems to be no outage
> > > announced and my browser cert is from today.
> > >
> > > Is that some kind of bug, or does koji simply not want me to build my
> > > packages?
> >
> > If your cert is more than 1 year old, get a new one from FAS.
Certs now expire every 6 months


> > > regards
> > >
> > > christoph
> > > --
> > > fedora-devel-list mailing list
> > > fedora-devel-list at redhat.com
> > > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> > --
> > in your fear, speak only peace
> > in your fear, seek only love
> >
> > -d. bowie
>
> I've just re-setup my fedora devel environment on this box. I've created
> the browser cert a few hours ago, and look at this:
>
> [choeger at choeger5 ~]$ ls -l .fed*
> -rw------- 1 choeger choeger 10115 18. Dez 13:35 .fedora.cert
> -rw------- 1 choeger choeger  6162  7. Nov 08:20 .fedora-server-ca.cert
> -rw------- 1 choeger choeger  6162  7. Nov 08:20 .fedora-upload-ca.cert
>
> So what i the problem? Who revoked my certs?
FAS automatically revokes old certs when you download a new one. koji updates 
the crl hourly. if you continue to have troubles please drop by #fedora-admin 
on freenode and we can help you.

Dennis





From alsadi at gmail.com  Thu Dec 18 22:30:04 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 19 Dec 2008 00:30:04 +0200
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <2a28d2ab0812181408m1ff794b2gdbf2898056cd10e1@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<1229636601.15429.2.camel@arekh.okg>
	<385866f0812181352i4b0755f7pe5bb15a4b78c11f1@mail.gmail.com>
	<2a28d2ab0812181408m1ff794b2gdbf2898056cd10e1@mail.gmail.com>
Message-ID: <385866f0812181430q3a6623c9gd1b36756bc03fb72@mail.gmail.com>

I meant to say
if one double clicks a folder while holding shift in browser mode it
should open in a new
window
and one can drag and drop and benefit from the the worlds



From dbn.lists at gmail.com  Thu Dec 18 22:36:22 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 18 Dec 2008 14:36:22 -0800
Subject: RPATH vs. libtool 2.2
In-Reply-To: <494A2729.3090109@redhat.com>
References: <494A2729.3090109@redhat.com>
Message-ID: <91705d080812181436q79f46689q940d22f8506882a@mail.gmail.com>

On Thu, Dec 18, 2008 at 2:34 AM, Michal Hlavinka <mhlavink at redhat.com> wrote:
> Hi,
>
> I've just tried to fix some bug in rawhide, but I've ended up with
> libtool/rpath error (again).
>
> without autoreconf OR with autoreconf -f -i -v
>> error: ... contains a standard rpath '/usr/lib64' in [/usr/lib64]
>
> with just autoreconf
>> ../libtool: line 763: X--tag=CC: command not found

It shouldn't be this way, but running bare autoconf is destined to
fail if you use libtool. "autoreconf -iv" is usually the best thing to
do if you need to rebuild the autotools.

> In F-10 autoreconf was working fine, but in rawhide we have now new libtool
> 2.2 and rpath patch was removed.
>
> I've heard some rumours that it's not required with this new shiny libtool
> 2.2 and everything (rpaths) should just work. So my question is: Am I
> missing something? Is there some parameter for configure (or something)
> required?

In my testing, it doesn't seem to work with multilib on newer libtool.
For linux, it guesses that the runtime default search path is /lib and
/usr/lib and then adds stuff it finds in /etc/ld.so.conf. For the
fedora libtool-1.5* packages, there is a patch to handle this:

http://cvs.fedoraproject.org/viewvc/rpms/libtool/F-10/libtool-1.5.24-multilib.patch?view=markup

However, it's not applied for libtool-2.2*, and I don't see it being
handled upstream.

--
Dan



From surenkarapetyan at gmail.com  Thu Dec 18 22:36:37 2008
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Fri, 19 Dec 2008 02:36:37 +0400
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081218215107.GB1366434@hiwaay.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<20081218215107.GB1366434@hiwaay.net>
Message-ID: <494AD075.7080105@gmail.com>

Chris Adams wrote:
> Once upon a time, Mark <markg85 at gmail.com> said:
>   
>> Sorry, Rahul, i disagree with this. I try to get through the redhat
>> and fedora devs that we, the users (about 5 now if i count right),
>> just want to see this changed!
>>     
>
> I vote we change the default browser to "vi" (none of that sissy "vim"
> crap) and the default web browser to "telnet <host> 80".
>
> Web and/or mailing list votes, petitions, etc., are not in any way a
> true representation of any user base, so don't count 5 whole votes as
> "the users".
>   
I would be very pleased if You told what IS.



From surenkarapetyan at gmail.com  Thu Dec 18 22:38:54 2008
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Fri, 19 Dec 2008 02:38:54 +0400
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494AC569.8070401@fedoraproject.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org>
Message-ID: <494AD0FE.70202@gmail.com>

Rahul Sundaram wrote:
> Mark wrote:
>
>> Redhat is eager to change things when they might get in trouble if
>> they have it in.. like codec support.  You guys are killing out more
>> then enough in other packages to save your own asses and you tell us
>> that you want to follow upstream.. 
>
> If a software is not included at all in Fedora, then there is no 
> modification and upstream is preserved as it is. For many others like 
> in the case of gstreamer, the extra codecs or functionality is 
> separated cleanly as plugins and we don't have to modify anything but 
> only pick and choose, what we can include. Only as a last resort, is 
> something patched and that is because it is the only legal choice at 
> that point. It is still a unfortunate divergence and adds a ongoing  
> maintenance overhead for the package maintainers. Adding more pain to 
> the problem doesn't make sense.
>
> Refer
> http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
>
> i agree on that with CODE changes.
>> i disagree on that with config changes! config things are just the the
>> values set by the creators that they think are best to use. That
>> doesn't make them THE best settings out there. Don't be so freaking
>> hard on config changes! 
>
> Code and configuration cannot be easily separated like this and 
> changes always have a associated cost. Atleast in one package I 
> maintain, a very small and simple configuration change resulted in a 
> potential security hole (only in rawhide for a short while but still ..)
Not in this case.
Here we can easily separate a default checkbox from code change.
>
>> I am just trying to get a clear signal out that there is something in
>> fedora that the people using fedora want to see different
>
> It doesn't seem the right path to doing that, to me.
>
> Rahul
>
>



From ivazqueznet at gmail.com  Thu Dec 18 22:57:51 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 18 Dec 2008 17:57:51 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <1229641071.3741.102.camel@ignacio.lan>

On Thu, 2008-12-18 at 21:56 +0100, Mark wrote:
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.

-1

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/e7338a5e/attachment.sig>

From kevin.kofler at chello.at  Thu Dec 18 23:03:39 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 00:03:39 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<1229590959.3612.57.camel@eagle.danny.cz>
	<gida1s$ap3$1@ger.gmane.org>
	<200812181859.12885.ville.skytta@iki.fi>
Message-ID: <gieksb$2ph$1@ger.gmane.org>

Ville Skytt? wrote:
> We encourage garbage collecting old cruft, keeping it around indefinitely
> should be a pretty rare exception for quite specific cases (or at least
> that's the way I remember it when we worked on it in FPC).

Once again, a Provides with a version number attached is *not* old cruft,
it's both backwards and *forwards* thinking, because another new major
version will inevitably happen.

        Kevin Kofler



From sundaram at fedoraproject.org  Thu Dec 18 23:06:16 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 19 Dec 2008 04:36:16 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494AD0FE.70202@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<494AD0FE.70202@gmail.com>
Message-ID: <494AD768.4030907@fedoraproject.org>

Suren Karapetyan wrote:

> Not in this case.
> Here we can easily separate a default checkbox from code change.

Nothing is as easy as it looks. You have to patch software,  patch 
documentation, patch translations and test them. All deviations from 
upstream carry risks. Then there would be differences between upstream 
and some distributions. Users who have to deal with multiple 
distributions have to deal with these differences.

If there is a change required, talk within the upstream community or 
have a real discussion with the package maintainers and try to convince 
them instead of pointless voting in the development mailing list (which 
is far from representative of a regular user base, would make them feel 
forced). If the maintainers have agreed to a vote, then fine. If not, it 
makes no difference and just wastes time.  Don't do it. It just provides 
false hope and leads to more disappointment. Not worth it, for a easily 
changed setting.

Rahul



From markg85 at gmail.com  Thu Dec 18 23:14:21 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 00:14:21 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494AC569.8070401@fedoraproject.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org>
Message-ID: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>

On Thu, Dec 18, 2008 at 10:49 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Mark wrote:
>
>> Redhat is eager to change things when they might get in trouble if
>> they have it in.. like codec support.  You guys are killing out more
>> then enough in other packages to save your own asses and you tell us
>> that you want to follow upstream..
>
> If a software is not included at all in Fedora, then there is no
> modification and upstream is preserved as it is. For many others like in the
> case of gstreamer, the extra codecs or functionality is separated cleanly as
> plugins and we don't have to modify anything but only pick and choose, what
> we can include. Only as a last resort, is something patched and that is
> because it is the only legal choice at that point. It is still a unfortunate
> divergence and adds a ongoing  maintenance overhead for the package
> maintainers. Adding more pain to the problem doesn't make sense.
>
> Refer
> http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
>
> i agree on that with CODE changes.
>>
>> i disagree on that with config changes! config things are just the the
>> values set by the creators that they think are best to use. That
>> doesn't make them THE best settings out there. Don't be so freaking
>> hard on config changes!
>
> Code and configuration cannot be easily separated like this and changes
> always have a associated cost. Atleast in one package I maintain, a very
> small and simple configuration change resulted in a potential security hole
> (only in rawhide for a short while but still ..)
>
>> I am just trying to get a clear signal out that there is something in
>> fedora that the people using fedora want to see different
>
> It doesn't seem the right path to doing that, to me.
>
> Rahul

I just can't resist to comment on you just to BREAK your arguments
that settings have to be made upstream as well.

Oke. I browsed through the fedora cvs for a few minutes looking for
firefox because i know a setting got in there a while ago to "fix"
something.
That something was that the scrolling was going slow in firefox when
compositing was enabled. which is especially notable in gmail in long
messages.

Now that firefox issue never got resolved on fedora but the value:
general.smoothScroll was set to true while the upstream was false!
and that setting just lets firefox scroll with less lines per scroll.
the issue that firefox scrolls slow when compositing is enabled is
still valid.. still not fixed..
and that conf value is still set to true! while upstream is still
FALSE! that setting got through relatively fast (mather of hours or
days.. don't remember exactly) and the proof is here:
http://cvs.fedoraproject.org/viewvc/devel/firefox/firefox-redhat-default-prefs.js?view=markup

Now that's just one thing you guys changed in firefox. there is a lot
more that got changed in firefox and isn't changed upstream! just go
through the firefox files on the fedora CVS.
So your argument that confis settings will have to be applied upstream
is hereby smashed to the ground because other packages don't keep that
same "deal".
Other packages get config setting changes so WHY are you making such a
hard deal of nautilus?

O and don't believe that you guys don't patch the hell out of
packages? look at apache, look at php, look at mysql, look at kde...
look at nearly EVERY package that is in fedora.
And those patches are the hard ones!

Then for the fedora bookmarks in firefox.. those are relatively easy
to add but to we want them? are those requested by the users? NO! are
those done anyway? YES!
are those upstream? NO! are those in fedora? YES!

And to your latest post here:
On Fri, Dec 19, 2008 at 12:06 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Suren Karapetyan wrote:
>
>> Not in this case.
>> Here we can easily separate a default checkbox from code change.
>
> Nothing is as easy as it looks. You have to patch software,  patch
> documentation, patch translations and test them. All deviations from
> upstream carry risks. Then there would be differences between upstream and
> some distributions. Users who have to deal with multiple distributions have
> to deal with these differences.
>
> If there is a change required, talk within the upstream community or have a
> real discussion with the package maintainers and try to convince them
> instead of pointless voting in the development mailing list (which is far
> from representative of a regular user base, would make them feel forced). If
> the maintainers have agreed to a vote, then fine. If not, it makes no
> difference and just wastes time.  Don't do it. It just provides false hope
> and leads to more disappointment. Not worth it, for a easily changed
> setting.
>
> Rahul

Oh men, i'm so starting to hate you.
your reasons are broken and smashed to the ground by what i said
above! get fedora in line with what you say or don't say a thing!

So.. you want us/me to contact the maintainers of nautilus. So be it!
Will do so in my next post

Sorry for the mad post but i'm just getting kinda frustrated by one person here.



From kevin.kofler at chello.at  Thu Dec 18 23:14:57 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 00:14:57 +0100
Subject: Forcing Gnome to start sans metacity
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<gidlps$hh2$2@ger.gmane.org>
	<7f692fec0812180754x20f9b890t9f44fbadac447920@mail.gmail.com>
Message-ID: <gielhh$6n2$1@ger.gmane.org>

Yaakov Nemoy wrote:
> This is intended to be default behavior only if you install a special
> xmonad-gnome-session package, though i'm planning on doing one for kde
> too.  Presumably, if the user wants this behavior, then the package is
> needed, but realistically, if /etc/xdg/autostart implies that it is
> forced on the user in KDE, then you're right, it's a bad solution,
> because i'm really looking to have this remain optional, via GDM or
> KDM (/usr/share/xsessions/*)

KDE allows setting the preferred WM in systemsettings under Advanced /
Session management. I'm not sure where it gets its list of WMs from though,
at least KWin and Metacity are detected.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Dec 18 23:22:35 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 00:22:35 +0100
Subject: RPATH vs. libtool 2.2
References: <494A2729.3090109@redhat.com>
	<91705d080812181436q79f46689q940d22f8506882a@mail.gmail.com>
Message-ID: <gielvr$6n2$2@ger.gmane.org>

Dan Nicholson wrote:
> In my testing, it doesn't seem to work with multilib on newer libtool.
> For linux, it guesses that the runtime default search path is /lib and
> /usr/lib and then adds stuff it finds in /etc/ld.so.conf. For the
> fedora libtool-1.5* packages, there is a patch to handle this:
> 
>http://cvs.fedoraproject.org/viewvc/rpms/libtool/F-10/libtool-1.5.24-multilib.patch?view=markup
> 
> However, it's not applied for libtool-2.2*, and I don't see it being
> handled upstream.

I guess it's not being applied because the upstream libtool authors loudly
claimed it's no longer necessary. :-(

Please file a high-priority bug against libtool in Fedora to get the patch
reapplied, and also complain loudly to upstream about them *still* failing
to support multilib.

        Kevin Kofler



From mike at cchtml.com  Thu Dec 18 23:20:02 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 18 Dec 2008 17:20:02 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
Message-ID: <494ADAA2.1030608@cchtml.com>

-------- Original Message --------
Subject: Re: Call for vote: Nautilus use Browser view for fedora 11
From: Mark <markg85 at gmail.com>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
CC: "Community assistance, encouragement, and advice for using Fedora." 
<fedora-list at redhat.com>
Date: 12/18/2008 05:14 PM


> 
> Sorry for the mad post but i'm just getting kinda frustrated by one person here.
> 


The traditional, top two trouble makers in both lists are Rahul and Les. 
I'm surprised Les hasn't shown up in this thread yet. He must have not 
checked his email yet.



From mw_triad at users.sourceforge.net  Thu Dec 18 23:36:33 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 18 Dec 2008 17:36:33 -0600
Subject: patching fedora kernel for eeepc
In-Reply-To: <a36b7e2a0812171904x60cf5716oaebf8d676c725e13@mail.gmail.com>
References: <a36b7e2a0812171904x60cf5716oaebf8d676c725e13@mail.gmail.com>
Message-ID: <giemq1$94f$1@ger.gmane.org>

Justin Conover wrote:
> This might be a stupid question.... but....
> 
> How to I use these in a patch?
> 
> http://lkml.org/lkml/2008/11/20/265
> 
> http://lkml.org/lkml/2008/11/20/266
> 
> http://lkml.org/lkml/2008/11/20/267
> 
> I understand this one because its in a patch file, but these are just
> e-mails.

Omit the file name and let patch read stdin, paste the patch portion of 
the mails, and ctrl-D (twice)?

(For some reason, patch - and only patch - seems to eat the first ctrl-D.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
???????????????????????



From markg85 at gmail.com  Thu Dec 18 23:21:49 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 00:21:49 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494AD768.4030907@fedoraproject.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
Message-ID: <6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>

On Fri, Dec 19, 2008 at 12:06 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Suren Karapetyan wrote:
>
>> Not in this case.
>> Here we can easily separate a default checkbox from code change.
>
> If there is a change required, talk within the upstream community or have a
> real discussion with the package maintainers and try to convince them
> instead of pointless voting in the development mailing list (which is far
> from representative of a regular user base, would make them feel forced). If
> the maintainers have agreed to a vote, then fine. If not, it makes no
> difference and just wastes time.  Don't do it. It just provides false hope
> and leads to more disappointment. Not worth it, for a easily changed
> setting.
>
> Rahul

On Rahul's request i invite a bunch of poeple to read this thread in
the hope to get this in fedora.
Note the list i cc'ed to.. all @redhat.com mail addresses.. i hope i
can get a objective opinion from them.

Also cc'ed to the nautilus list.. though it probably should be
somewhere else but that's what you get when you make a list for
everything.. you lose sight.
"So many trees that i can't see the forest any more"

Also if this isn't the way to get this in fedora then what is? this
change will affect everyone and should not rely on one person but
should have a solid base behind it.
In this thread there are just a few -1 posts and the rest seems to be
+1 so the solid base is building up here.



From surenkarapetyan at gmail.com  Thu Dec 18 23:41:12 2008
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Fri, 19 Dec 2008 03:41:12 +0400
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
Message-ID: <494ADF98.6000001@gmail.com>

Mark wrote:
> On Thu, Dec 18, 2008 at 10:49 PM, Rahul Sundaram
> <sundaram at fedoraproject.org> wrote:
>   
>> Mark wrote:
>>
>>     
>>> Redhat is eager to change things when they might get in trouble if
>>> they have it in.. like codec support.  You guys are killing out more
>>> then enough in other packages to save your own asses and you tell us
>>> that you want to follow upstream..
>>>       
>> If a software is not included at all in Fedora, then there is no
>> modification and upstream is preserved as it is. For many others like in the
>> case of gstreamer, the extra codecs or functionality is separated cleanly as
>> plugins and we don't have to modify anything but only pick and choose, what
>> we can include. Only as a last resort, is something patched and that is
>> because it is the only legal choice at that point. It is still a unfortunate
>> divergence and adds a ongoing  maintenance overhead for the package
>> maintainers. Adding more pain to the problem doesn't make sense.
>>
>> Refer
>> http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
>>
>> i agree on that with CODE changes.
>>     
>>> i disagree on that with config changes! config things are just the the
>>> values set by the creators that they think are best to use. That
>>> doesn't make them THE best settings out there. Don't be so freaking
>>> hard on config changes!
>>>       
>> Code and configuration cannot be easily separated like this and changes
>> always have a associated cost. Atleast in one package I maintain, a very
>> small and simple configuration change resulted in a potential security hole
>> (only in rawhide for a short while but still ..)
>>
>>     
>>> I am just trying to get a clear signal out that there is something in
>>> fedora that the people using fedora want to see different
>>>       
>> It doesn't seem the right path to doing that, to me.
>>
>> Rahul
>>     
>
> I just can't resist to comment on you just to BREAK your arguments
> that settings have to be made upstream as well.
>
> Oke. I browsed through the fedora cvs for a few minutes looking for
> firefox because i know a setting got in there a while ago to "fix"
> something.
> That something was that the scrolling was going slow in firefox when
> compositing was enabled. which is especially notable in gmail in long
> messages.
>
> Now that firefox issue never got resolved on fedora but the value:
> general.smoothScroll was set to true while the upstream was false!
> and that setting just lets firefox scroll with less lines per scroll.
> the issue that firefox scrolls slow when compositing is enabled is
> still valid.. still not fixed..
> and that conf value is still set to true! while upstream is still
> FALSE! that setting got through relatively fast (mather of hours or
> days.. don't remember exactly) and the proof is here:
> http://cvs.fedoraproject.org/viewvc/devel/firefox/firefox-redhat-default-prefs.js?view=markup
>
> Now that's just one thing you guys changed in firefox. there is a lot
> more that got changed in firefox and isn't changed upstream! just go
> through the firefox files on the fedora CVS.
> So your argument that confis settings will have to be applied upstream
> is hereby smashed to the ground because other packages don't keep that
> same "deal".
> Other packages get config setting changes so WHY are you making such a
> hard deal of nautilus?
>
> O and don't believe that you guys don't patch the hell out of
> packages? look at apache, look at php, look at mysql, look at kde...
> look at nearly EVERY package that is in fedora.
> And those patches are the hard ones!
>
> Then for the fedora bookmarks in firefox.. those are relatively easy
> to add but to we want them? are those requested by the users? NO! are
> those done anyway? YES!
> are those upstream? NO! are those in fedora? YES!
>
> And to your latest post here:
> On Fri, Dec 19, 2008 at 12:06 AM, Rahul Sundaram
> <sundaram at fedoraproject.org> wrote:
>   
>> Suren Karapetyan wrote:
>>
>>     
>>> Not in this case.
>>> Here we can easily separate a default checkbox from code change.
>>>       
>> Nothing is as easy as it looks. You have to patch software,  patch
>> documentation, patch translations and test them. All deviations from
>> upstream carry risks. Then there would be differences between upstream and
>> some distributions. Users who have to deal with multiple distributions have
>> to deal with these differences.
>>
>> If there is a change required, talk within the upstream community or have a
>> real discussion with the package maintainers and try to convince them
>> instead of pointless voting in the development mailing list (which is far
>> from representative of a regular user base, would make them feel forced). If
>> the maintainers have agreed to a vote, then fine. If not, it makes no
>> difference and just wastes time.  Don't do it. It just provides false hope
>> and leads to more disappointment. Not worth it, for a easily changed
>> setting.
>>
>> Rahul
>>     
>
> Oh men, i'm so starting to hate you.
> your reasons are broken and smashed to the ground by what i said
> above! get fedora in line with what you say or don't say a thing!
>
> So.. you want us/me to contact the maintainers of nautilus. So be it!
> Will do so in my next post
>
> Sorry for the mad post but i'm just getting kinda frustrated by one person here.
>
>   
No need to get frustrated, but I agree with Your points.
Expecting configuration changes to happen upstream is sometimes crazy.
Let's take the kernel as an example.
Here upstream default config is the one in Linus'es tree's .config file.
It's very easy to understand that everybody isn't going to use that 
config file.
And we don't... in fact nobody does, cause there is only one default 
upstream config and it WON'T fit everyone.
So we do change the config, even more we add our own patches (in fact a 
hundred of them).
If we weren't going to do config changes (and not only them) we wouldn't 
need and Usability/Friendliness experts.
In fact we wouldn't need ant developers/maintainers too.
A build-system would be the only thing we need.

And now about this particular case.
I think it's quite easy: if in some way we find out that most people 
want/use browser mode we MUST switch to it.
It's called democracy (not that I believe in it much :) but it can work 
sometimes).
If majority of users changes that setting to "true" every time they 
install fedora, then it should be the default.



From mike at cchtml.com  Thu Dec 18 23:20:02 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 18 Dec 2008 17:20:02 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
Message-ID: <494ADAA2.1030608@cchtml.com>

-------- Original Message --------
Subject: Re: Call for vote: Nautilus use Browser view for fedora 11
From: Mark <markg85 at gmail.com>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
CC: "Community assistance, encouragement, and advice for using Fedora." 
<fedora-list at redhat.com>
Date: 12/18/2008 05:14 PM


> 
> Sorry for the mad post but i'm just getting kinda frustrated by one person here.
> 


The traditional, top two trouble makers in both lists are Rahul and Les. 
I'm surprised Les hasn't shown up in this thread yet. He must have not 
checked his email yet.



From bob at fedoraunity.org  Thu Dec 18 23:29:17 2008
From: bob at fedoraunity.org (Robert 'Bob' Jensen)
Date: Thu, 18 Dec 2008 23:29:17 +0000 (UTC)
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
Message-ID: <29424585.4771229642957194.JavaMail.root@zimbra.cbccgroup.com>

Mark,

Remember these items if nothing else from this experience.
 1. Rahul is an abrasive boob who makes things sound like he is the be all and end all, the total authority, the "Omega" if you will.
 2. Don't ask for a "vote" ask for a poll to gauge interest in the topic, it will keep gentlemen like Rahul off your ass.
 3. Don't cross post to the -devel list, the Developers (really mostly packagers) are not users, they are power users or more. 

Robert 'EvilBob' Jensen

P.S. I vote next time Rahul shows up at a public event we paint him purple and make like a pinata. +100

P.S.S. BTW the first setting I change on every new install is "Always open in browser windows" even before running "yum update"


----- Original Me ssage -----
From: "Mark" <markg85 at gmail.com>
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Cc: "Community assistance, encouragement, and advice for using Fedora." <fedora-list at redhat.com>
Sent: Thursday, December 18, 2008 5:14:21 PM GMT -06:00 US/Canada Central
Subject: Re: Call for vote: Nautilus use Browser view for fedora 11

On Thu, Dec 18, 2008 at 10:49 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Mark wrote:
>
>> Redhat is eager to change things when they might get in trouble if
>> they have it in.. like codec support.  You guys are killing out more
>> then enough in other packages to save your own asses and you tell us
>> that you want to follow upstream..
>
> If a software is not included at all in Fedora, then there is no
> modification and upstream is preserved as it is. For many others like in the
> case of gstreamer, the extra codecs or functionality is separated cleanly as
> plugins and we don't have to modify anything but only pick and choose, what
> we can include. Only as a last resort, is something patched and that is
> because it is the only legal choice at that point. It is still a unfortunate
> divergence and adds a ongoing  maintenance overhead for the package
> maintainers. Adding more pain to the problem doesn't make sense.
>
> Refer
> http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
>
> i agree on that with CODE changes.
>>
>> i disagree on that with config changes! config things are just the the
>> values set by the creators that they think are best to use. That
>> doesn't make them THE best settings out there. Don't be so freaking
>> hard on config changes!
>
> Code and configuration cannot be easily separated like this and changes
> always have a associated cost. Atleast in one package I maintain, a very
> small and simple configuration change resulted in a potential security hole
> (only in rawhide for a short while but still ..)
>
>> I am just trying to get a clear signal out that there is something in
>> fedora that the people using fedora want to see different
>
> It doesn't seem the right path to doing that, to me.
>
> Rahul

I just can't resist to comment on you just to BREAK your arguments
that settings have to be made upstream as well.

Oke. I browsed through the fedora cvs for a few minutes looking for
firefox because i know a setting got in there a while ago to "fix"
something.
That something was that the scrolling was going slow in firefox when
compositing was enabled. which is especially notable in gmail in long
messages.

Now that firefox issue never got resolved on fedora but the value:
general.smoothScroll was set to true while the upstream was false!
and that setting just lets firefox scroll with less lines per scroll.
the issue that firefox scrolls slow when compositing is enabled is
still valid.. still not fixed..
and that conf value is still set to true! while upstream is still
FALSE! that setting got through relatively fast (mather of hours or
days.. don't remember exactly) and the proof is here:
http://cvs.fedoraproject.org/viewvc/devel/firefox/firefox-redhat-default-prefs.js?view=markup

Now that's just one thing you guys changed in firefox. there is a lot
more that got changed in firefox and isn't changed upstream! just go
through the firefox files on the fedora CVS.
So your argument that confis settings will have to be applied upstream
is hereby smashed to the ground because other packages don't keep that
same "deal".
Other packages get config setting changes so WHY are you making such a
hard deal of nautilus?

O and don't believe that you guys don't patch the hell out of
packages? look at apache, look at php, look at mysql, look at kde...
look at nearly EVERY package that is in fedora.
And those patches are the hard ones!

Then for the fedora bookmarks in firefox.. those are relatively easy
to add but to we want them? are those requested by the users? NO! are
those done anyway? YES!
are those upstream? NO! are those in fedora? YES!

And to your latest post here:
On Fri, Dec 19, 2008 at 12:06 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Suren Karapetyan wrote:
>
>> Not in this case.
>> Here we can easily separate a default checkbox from code change.
>
> Nothing is as easy as it looks. You have to patch software,  patch
> documentation, patch translations and test them. All deviations from
> upstream carry risks. Then there would be differences between upstream and
> some distributions. Users who have to deal with multiple distributions have
> to deal with these differences.
>
> If there is a change required, talk within the upstream community or have a
> real discussion with the package maintainers and try to convince them
> instead of pointless voting in the development mailing list (which is far
> from representative of a regular user base, would make them feel forced). If
> the maintainers have agreed to a vote, then fine. If not, it makes no
> difference and just wastes time.  Don't do it. It just provides false hope
> and leads to more disappointment. Not worth it, for a easily changed
> setting.
>
> Rahul

Oh men, i'm so starting to hate you.
your reasons are broken and smashed to the ground by what i said
above! get fedora in line with what you say or don't say a thing!

So.. you want us/me to contact the maintainers of nautilus. So be it!
Will do so in my next post

Sorry for the mad post but i'm just getting kinda frustrated by one person here.

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list



From jkeating at redhat.com  Thu Dec 18 23:45:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Dec 2008 15:45:54 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
Message-ID: <1229643954.6191.116.camel@localhost.localdomain>

On Fri, 2008-12-19 at 00:21 +0100, Mark wrote:
> Also if this isn't the way to get this in fedora then what is? this
> change will affect everyone and should not rely on one person but
> should have a solid base behind it.
> In this thread there are just a few -1 posts and the rest seems to be
> +1 so the solid base is building up here.

-1, just to keep the numbers fun.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/4f9d3ea9/attachment.sig>

From kevin.kofler at chello.at  Thu Dec 18 23:53:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 00:53:59 +0100
Subject: Proposed PackageRenaming guideline
References: <20081218104319.75305a5b@ohm.scrye.com>
Message-ID: <gienqn$cg4$1@ger.gmane.org>

Kevin Fenzi wrote:
> As far as I can tell we don't have a guideline for how to do package
> renames. Here's my first attempt at such a guideline:
> 
> https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages
> 
> Feel free to leave feedback in talk page for it on the wiki, or here or
> in personal email to me.

Somewhere in the distant past, we had a rule that to rename a package, all
that's needed is a CVS Request. I'd like that to be reintroduced. I don't
think dropping that rule was ever really discussed, it just vanished some
day. It doesn't make sense to require a rereview just for a name change
when any other updates (including things like adding subpackages and
Obsoletes - and no, I'm not suggesting to force rereviews for all that
stuff, it wouldn't scale!) are allowed. IMHO even a quick review on the ML
is too much overhead for something as trivial as a name change.

        Kevin Kofler



From dbn.lists at gmail.com  Thu Dec 18 23:55:08 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 18 Dec 2008 15:55:08 -0800
Subject: RPATH vs. libtool 2.2
In-Reply-To: <gielvr$6n2$2@ger.gmane.org>
References: <494A2729.3090109@redhat.com>
	<91705d080812181436q79f46689q940d22f8506882a@mail.gmail.com>
	<gielvr$6n2$2@ger.gmane.org>
Message-ID: <91705d080812181555r236d3fe9ge637346014f8d425@mail.gmail.com>

On Thu, Dec 18, 2008 at 3:22 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Dan Nicholson wrote:
>> In my testing, it doesn't seem to work with multilib on newer libtool.
>> For linux, it guesses that the runtime default search path is /lib and
>> /usr/lib and then adds stuff it finds in /etc/ld.so.conf. For the
>> fedora libtool-1.5* packages, there is a patch to handle this:
>>
>>http://cvs.fedoraproject.org/viewvc/rpms/libtool/F-10/libtool-1.5.24-multilib.patch?view=markup
>>
>> However, it's not applied for libtool-2.2*, and I don't see it being
>> handled upstream.
>
> I guess it's not being applied because the upstream libtool authors loudly
> claimed it's no longer necessary. :-(
>
> Please file a high-priority bug against libtool in Fedora to get the patch
> reapplied, and also complain loudly to upstream about them *still* failing
> to support multilib.

I'll see what I can do. What is handled is that adding -L/usr/lib64
should not happen when linking. This is because libtool checks where
the compiler will look for libraries on it's own and avoid those.

--
Dan



From markg85 at gmail.com  Thu Dec 18 23:58:46 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 00:58:46 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <29424585.4771229642957194.JavaMail.root@zimbra.cbccgroup.com>
References: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
	<29424585.4771229642957194.JavaMail.root@zimbra.cbccgroup.com>
Message-ID: <6e24a8e80812181558t3741b70cgcbab7d47fb2a918d@mail.gmail.com>

On Fri, Dec 19, 2008 at 12:29 AM, Robert 'Bob' Jensen
<bob at fedoraunity.org> wrote:
> Mark,
>
> Remember these items if nothing else from this experience.
>  1. Rahul is an abrasive boob who makes things sound like he is the be all and end all, the total authority, the "Omega" if you will.
>  2. Don't ask for a "vote" ask for a poll to gauge interest in the topic, it will keep gentlemen like Rahul off your ass.
>  3. Don't cross post to the -devel list, the Developers (really mostly packagers) are not users, they are power users or more.
>
> Robert 'EvilBob' Jensen
>
> P.S. I vote next time Rahul shows up at a public event we paint him purple and make like a pinata. +100

Where is that event ^_^
>
> P.S.S. BTW the first setting I change on every new install is "Always open in browser windows" even before running "yum update"

The very first thing i do is open a console and install gconf-editor
then i adjust some config settings of nautilus followed by a updates
and more config changing... (like all fonts to 8 instead of 10)



From adamwill at shaw.ca  Fri Dec 19 00:03:45 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Thu, 18 Dec 2008 16:03:45 -0800
Subject: boost rebuild status
In-Reply-To: <20081218011435.03690d24@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
Message-ID: <1229645025.24419.623.camel@lenovo.local.net>

On Thu, 2008-12-18 at 01:14 -0800, Benjamin Kosnik wrote:
> rb_libtorrent-0:0.13.1-3.fc10.x86_64
> rb_libtorrent-python-0:0.13.1-3.fc10.x86_64
>   bump Release, failed:
>   configuration error with boost system library
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=1005216&name=build.log
> 
>   add --with-boost-system=mt to %configure, still compile fail:
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=1006006
> 
> In file included from disk_io_thread.cpp:35:
> ../include/libtorrent/disk_io_thread.hpp:135: error: 'condition' in
> namespace 'boost' does not name a type
> disk_io_thread.cpp: In member function 'void
> libtorrent::disk_io_thread::join()':
> disk_io_thread.cpp:97: error: 'm_signal' was not declared in this
> scope
> disk_io_thread.cpp: In member function 'void
> libtorrent::disk_io_thread::stop(boost::intrusive_ptr<libtorrent::piece_manager>)':
> disk_io_thread.cpp:124: error: 'm_signal' was not declared in this
> scope
> disk_io_thread.cpp: In member function 'void
> libtorrent::disk_io_thread::add_job(const libtorrent::disk_io_job&,
> const boost::function<void ()(int, const
> libtorrent::disk_io_job&)>&)':
> disk_io_thread.cpp:209: error: 'm_signal' was not declared in this
> scope
> disk_io_thread.cpp: In member function 'void
> libtorrent::disk_io_thread::operator()()':
> disk_io_thread.cpp:243: error: 'm_signal' was not declared in this
> scope

There is a later version of this library, 0.14.1. It may build where
this older version doesn't, I don't know for sure.

I have verified and tested that the three things in Mandriva which use
rasterbar libtorrent - deluge, miro, and springlobby - can build and
work with this version of libtorrent (there's trivial patches for deluge
and springlobby in Mandriva SVN if needed). I don't know if Fedora has
any other rasterbar libtorrent-dependent apps which may work with 0.13
and not with 0.14.
-- 
adamw



From kevin.kofler at chello.at  Fri Dec 19 00:05:23 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 01:05:23 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
	<29424585.4771229642957194.JavaMail.root@zimbra.cbccgroup.com>
Message-ID: <gieog3$cg4$2@ger.gmane.org>

Robert 'Bob' Jensen wrote:
> P.S.S. BTW the first setting I change on every new install is "Always open
> in browser windows" even before running "yum update"

Even before disabling SELinux? ;-)

        Kevin Kofler



From jkeating at redhat.com  Fri Dec 19 00:18:45 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Dec 2008 16:18:45 -0800
Subject: Proposed PackageRenaming guideline
In-Reply-To: <gienqn$cg4$1@ger.gmane.org>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<gienqn$cg4$1@ger.gmane.org>
Message-ID: <1229645925.6191.117.camel@localhost.localdomain>

On Fri, 2008-12-19 at 00:53 +0100, Kevin Kofler wrote:
> something as trivial as a name change.

Sadly, name changes aren't trivial.  They involve Obsoletes/Provides,
and these are frequently done wrong.  When done wrong, you can get to a
point where a package obsoletes itself which has resulted in some fun
yum output.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/a0cd3c0d/attachment.sig>

From fedora at matbooth.co.uk  Fri Dec 19 00:19:07 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Fri, 19 Dec 2008 00:19:07 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <gieog3$cg4$2@ger.gmane.org>
References: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
	<29424585.4771229642957194.JavaMail.root@zimbra.cbccgroup.com>
	<gieog3$cg4$2@ger.gmane.org>
Message-ID: <9497e9990812181619g1540de55tce86fa3e0b4197fa@mail.gmail.com>

On Fri, Dec 19, 2008 at 12:05 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Robert 'Bob' Jensen wrote:
>> P.S.S. BTW the first setting I change on every new install is "Always open
>> in browser windows" even before running "yum update"
>
> Even before disabling SELinux? ;-)
>
>        Kevin Kofler
>

The *three* things he does are... Set "Always open in browser
windows," a yum update, disable SELinux and have an almost fanatical
devotion to the colour of the bikeshed. The *four* things he... Erm,
*amongst* the things he does are... Tell you what, I'll start again...

I always change that setting too, but I don't mind the fact that I
have to change it. After all, it is something I do only once.

-- 
Mat Booth
www.matbooth.co.uk



From kevin.kofler at chello.at  Fri Dec 19 00:21:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 01:21:55 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc>
Message-ID: <giepf5$i12$1@ger.gmane.org>

Matthias Clasen wrote:
> We don't do votes on things like this.

If only there was a GNOME SIG with community involvement, where all the
maintainers of GNOME and closely-related packages (also implying: if GNOME
packages actually _had_ community comaintainers...) were represented, with
public meetings also followed by triagers, documentation writers and
interested users, that would be a good place to hold a vote (among the
maintainers), also showing some transparency and providing an incentive to
get involved. Now where did I get this idea from? ;-)

        Kevin Kofler



From ianweller at gmail.com  Fri Dec 19 00:28:38 2008
From: ianweller at gmail.com (Ian Weller)
Date: Thu, 18 Dec 2008 18:28:38 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <20081219002838.GA12405@gmail.com>

On Thu, Dec 18, 2008 at 09:56:52PM +0100, Mark wrote:
> So, lets vote:
> 
Fedora is not a democracy, it is a meritocracy. The more you do for the
project, the more clout you have. Seeing as you don't have a FAS account
under this email address, sure, you can make recommendations, but even
if you get all of 6 votes (whoa! the Fedora user base is made up of
*only 11 people*), it's not going to change unless the maintainer wants
it to.

This is how Fedora has been forever. From a usability standpoint, this
is stupid, because you don't change something people are used to.

(In case you didn't notice, -1)

-- 
Ian Weller <ianweller at gmail.com>                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/e57160ae/attachment.sig>

From kevin.kofler at chello.at  Fri Dec 19 00:27:52 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 01:27:52 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<494AD0FE.70202@gmail.com> <494AD768.4030907@fedoraproject.org>
Message-ID: <giepq8$i12$3@ger.gmane.org>

Rahul Sundaram wrote:

> Suren Karapetyan wrote:
> 
>> Not in this case.
>> Here we can easily separate a default checkbox from code change.
> 
> Nothing is as easy as it looks. You have to patch software,  patch
> documentation, patch translations and test them.

Well, then that's a problem in how GNOME handles configuration.

If we want to change a setting like this in KDE, all we need to do is to
change one line in kde-settings, no code changes needed at all.

And I don't see why translations and documentation would need to be patched
at all.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 19 00:25:39 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 01:25:39 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
Message-ID: <giepm3$i12$2@ger.gmane.org>

Mark wrote:
> i agree on that with CODE changes. i disagree on that with config changes!
> config things are just the the values set by the creators that they think
> are best to use. That doesn't make them THE best settings out there. Don't
> be so freaking hard on config changes!

+1, customizing configuration is really not a big deal at all. Many of our
default configurations are customized in some way.

> Or do you want me to submit a bug report to suggest that config
> changes should be allowed in fedora! but code changes shouldn't
> (unless it could possibly end up in patent lawsuits)

-1, code changes are allowed and should remain so. We already have the
WhyUpstream page providing some guidance on what kind of changes are
reasonable. How to actually handle this should be the maintainer's call, it
really depends on the package, and also on the nature of the individual
change (e.g. making some program work with PulseAudio is definitely worth
patching).

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 19 00:40:52 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 01:40:52 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<20081219002838.GA12405@gmail.com>
Message-ID: <gieqik$i12$5@ger.gmane.org>

Ian Weller wrote:
> This is how Fedora has been forever. From a usability standpoint, this
> is stupid, because you don't change something people are used to.

Yet this is exactly what they did when they changed that setting in the
first place. The default used to be browser view in the distant past.

        Kevin Kofler



From kanarip at kanarip.com  Fri Dec 19 00:45:30 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Fri, 19 Dec 2008 01:45:30 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <494AEEAA.3090608@kanarip.com>

Mark wrote:
> Hey,
> 
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.
> 

Wasn't the non-browser nautilus mode chosen as a default for 
accessibility purposes, either upstream or in Fedora or wherever?

I'm sorry, but I don't remember where I ever got that from... if at all 
it is true, even :/

Kind regards,

Jeroen van Meeuwen
-kanarip



From markg85 at gmail.com  Fri Dec 19 00:57:16 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 01:57:16 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494AEEAA.3090608@kanarip.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
Message-ID: <6e24a8e80812181657p70bf98cala176e7b9a40abb44@mail.gmail.com>

On Fri, Dec 19, 2008 at 1:45 AM, Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
> Mark wrote:
>>
>> Hey,
>>
>> The question is simple:
>> Lets use the browser view of nautilus in the next fedora release.
>>
>
> Wasn't the non-browser nautilus mode chosen as a default for accessibility
> purposes, either upstream or in Fedora or wherever?
>
> I'm sorry, but I don't remember where I ever got that from... if at all it
> is true, even :/
>
> Kind regards,
>
> Jeroen van Meeuwen
> -kanarip

If that's true then gnome is a final goner for me.
I already disagree with there gnome usability idea to scratch features
for usability.
but is this is true for whatever reason then i'm really gonna:
- Switch to another wm (sadly kde is still not the "d.e." for me)
- Make a fedora derivative with my settings in and fedora's settings out

gonna look into this stuff.



From mclasen at redhat.com  Fri Dec 19 00:59:42 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 18 Dec 2008 19:59:42 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <giepf5$i12$1@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc>  <giepf5$i12$1@ger.gmane.org>
Message-ID: <1229648382.3300.9.camel@matthiasc>

On Fri, 2008-12-19 at 01:21 +0100, Kevin Kofler wrote:
> Matthias Clasen wrote:
> > We don't do votes on things like this.
> 
> If only there was a GNOME SIG with community involvement, where all the
> maintainers of GNOME and closely-related packages (also implying: if GNOME
> packages actually _had_ community comaintainers...) were represented, with
> public meetings also followed by triagers, documentation writers and
> interested users, that would be a good place to hold a vote (among the
> maintainers), also showing some transparency and providing an incentive to
> get involved. Now where did I get this idea from? ;-)

Nice try, Kevin. 

Now that we've made clear who the bad guys in this story are, maybe we
should all install kde and move on ? :-)



From joshuacov at googlemail.com  Fri Dec 19 01:11:28 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Fri, 19 Dec 2008 02:11:28 +0100
Subject: Amarok 2 on F9
Message-ID: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>

I recompiled amarok-2.0.2.fc10 for f9 just to try it. Before this i
had to recompile mysql-embedded for f9 (source is in koji for f10)
because in f9 there is no mysql-embedded. I also needed to recompile
libmtp-0.3.4 for f9. So far it is working fine. Since the kde versions
in f10 and  f9 are identical can the maintainer officially publich it
for f9?



From loupgaroublond at gmail.com  Fri Dec 19 01:14:56 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Thu, 18 Dec 2008 20:14:56 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <gielhh$6n2$1@ger.gmane.org>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<gidlps$hh2$2@ger.gmane.org>
	<7f692fec0812180754x20f9b890t9f44fbadac447920@mail.gmail.com>
	<gielhh$6n2$1@ger.gmane.org>
Message-ID: <7f692fec0812181714i40b405dfl58b43baf2581051b@mail.gmail.com>

2008/12/18 Kevin Kofler <kevin.kofler at chello.at>:
> Yaakov Nemoy wrote:
>> This is intended to be default behavior only if you install a special
>> xmonad-gnome-session package, though i'm planning on doing one for kde
>> too.  Presumably, if the user wants this behavior, then the package is
>> needed, but realistically, if /etc/xdg/autostart implies that it is
>> forced on the user in KDE, then you're right, it's a bad solution,
>> because i'm really looking to have this remain optional, via GDM or
>> KDM (/usr/share/xsessions/*)
>
> KDE allows setting the preferred WM in systemsettings under Advanced /
> Session management. I'm not sure where it gets its list of WMs from though,
> at least KWin and Metacity are detected.

KDE's very easy to configure, thankfully.  A package called
xmonad-gnome-session that starts up KDE probably wouldn't be very
welcome though ;).

-Yaakov



From vonbrand at inf.utfsm.cl  Fri Dec 19 01:05:30 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 18 Dec 2008 22:05:30 -0300
Subject: What I'm going to do: Was: RFC: Description text in packages
In-Reply-To: <1229625325.3651.75.camel@hughsie-work.lan>
References: <1229355476.3432.89.camel@hughsie-work.lan>
	<1229466653.6392.38.camel@code.and.org>
	<1229507380.1951.15.camel@hughsie-work.lan>
	<4949378E.9030209@gmail.com>
	<1229540361.1951.100.camel@hughsie-work.lan>
	<49496940.20706@gmail.com>
	<1229609395.3651.19.camel@hughsie-work.lan>
	<1229615827.6392.109.camel@code.and.org>
	<1229617055.3651.55.camel@hughsie-work.lan>
	<1229619367.6392.118.camel@code.and.org>
	<604aa7910812181010l3d43974asefab9a58e207b8df@mail.gmail.com>
	<1229625325.3651.75.camel@hughsie-work.lan>
Message-ID: <200812190105.mBJ15Ux8007240@laptop14.inf.utfsm.cl>

Richard Hughes <hughsient at gmail.com> wrote:
> On Thu, 2008-12-18 at 09:10 -0900, Jeff Spaleta wrote:
> > This still needs to go before our packaging committee methinks.

> Yes. I'm still talking with the other distros, and most are /okay/ with
> the idea. 99% of package don't need any changes, it's only the 1% that
> already look different to the others.

I.e., 99% of packages are just fine with normal text, and you want to futz
around for the sake of the remaining 1%, thus risking breakage in the vast
amjority that works dandy today?

Doesn't sound very reasonable to 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 2340000       Fax:  +56 32 2797513



From mjs at clemson.edu  Fri Dec 19 01:31:37 2008
From: mjs at clemson.edu (Matthew Saltzman)
Date: Thu, 18 Dec 2008 20:31:37 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494ADAA2.1030608@cchtml.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org>
	<6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
	<494ADAA2.1030608@cchtml.com>
Message-ID: <1229650297.4159.1.camel@valkyrie.localdomain>

On Thu, 2008-12-18 at 17:20 -0600, Michael Cronenworth wrote:
> -------- Original Message --------
> Subject: Re: Call for vote: Nautilus use Browser view for fedora 11
> From: Mark <markg85 at gmail.com>
> To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
> CC: "Community assistance, encouragement, and advice for using Fedora." 
> <fedora-list at redhat.com>
> Date: 12/18/2008 05:14 PM
> 
> 
> > 
> > Sorry for the mad post but i'm just getting kinda frustrated by one person here.
> > 
> 
> 
> The traditional, top two trouble makers in both lists are Rahul and Les. 
> I'm surprised Les hasn't shown up in this thread yet. He must have not 
> checked his email yet.

The traditional top *three* troublemakers are...

Oh, never mind...

> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From rdieter at math.unl.edu  Fri Dec 19 01:48:07 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Dec 2008 19:48:07 -0600
Subject: Amarok 2 on F9
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
Message-ID: <gieuf2$uok$1@ger.gmane.org>

Joshua C. wrote:

>. Since the kde versions
> in f10 and  f9 are identical can the maintainer officially publich it
> for f9?

I'd tend to be against that  A major upgrade like that in the middle of a release cycle is unwise.

(Besides, the deps aren't *entirely* identical, F-9's libmtp is too old)

-- Rex




From markg85 at gmail.com  Fri Dec 19 02:16:47 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 03:16:47 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494AEEAA.3090608@kanarip.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
Message-ID: <6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>

On Fri, Dec 19, 2008 at 1:45 AM, Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
> Mark wrote:
>>
>> Hey,
>>
>> The question is simple:
>> Lets use the browser view of nautilus in the next fedora release.
>>
>
> Wasn't the non-browser nautilus mode chosen as a default for accessibility
> purposes, either upstream or in Fedora or wherever?
>
> I'm sorry, but I don't remember where I ever got that from... if at all it
> is true, even :/
>
> Kind regards,
>
> Jeroen van Meeuwen
> -kanarip

in case your interested in more details.
The gnome devs decided for Gnome 2.6 that they needed a new nautilus
browser mode: "Spatial" and make that default. I haven't found the
reasons why they needed it and why they made it but it's clear to me
now that they did it intentionally and probably don't intend to revert
it: http://library.gnome.org/misc/release-notes/2.6/ it was one of the
biggest features (aka failures) in gnome 2.6

There was also a person who didn't agree at it at that time along with
a range of other gnome decisions and forked gnome into: "genome" which
is dead at this moment. What i could find about genome is:
http://www.akcaagac.com/index_goneme.html I agree with most of his
opinions about gnome. I have those same opinions since i use it. Sad
that i stepped in the linux world in about 2005. Fedora was the first
linux os i could use although i mainly used windows back then.. just
fedora a few hours a month!

I also found a post from alexander larson with: "The future direction
of the Nautilus UI" where he probably didn't made a line of the
spatial mode yet but he is clearly talking about something like that.
If you want to read it:
http://mail.gnome.org/archives/nautilus-list/2002-September/msg00093.html
So it's unlikely that we will ever see a +1 vote from that nautilus
dev which is also a package maintainer for nautilus. His opinion is
just the law regarding nautilus (so far for democracy! it more like
the lonely tiran that rules it all).

So in short. as long as the nautilus creator is also the maintainer
and the inventor of spatial we probably won't see this default
behaviour change. very sad but true!

I'm gonna quit gnome with all that i know now. i don't want to use it
anymore and be treated like an idiotic user (that's how gnome thinks,
not me). i don't want to be a part of gnome anymore and i'm wondering
what i should do with fedora. I want to keep RPM's but not fedora
(mainly because of codecs but this thread play a part in it as
well)... kinda hard. I'm gonna try to make my own file browser in QT
(gtk sucks)



From jkeating at redhat.com  Fri Dec 19 02:19:16 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Dec 2008 18:19:16 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
Message-ID: <1229653156.6191.119.camel@localhost.localdomain>

On Fri, 2008-12-19 at 03:16 +0100, Mark wrote:
> so far for democracy!

Nobody said it was a democracy, in fact, we've explicitly said it
wasn't.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/b94e10f5/attachment.sig>

From markg85 at gmail.com  Fri Dec 19 02:25:32 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 03:25:32 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229653156.6191.119.camel@localhost.localdomain>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229653156.6191.119.camel@localhost.localdomain>
Message-ID: <6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>

2008/12/19 Jesse Keating <jkeating at redhat.com>:
> On Fri, 2008-12-19 at 03:16 +0100, Mark wrote:
>> so far for democracy!
>
> Nobody said it was a democracy, in fact, we've explicitly said it
> wasn't.
>
> --
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating
>

Then what is it? Meritocracy?



From mike at cchtml.com  Fri Dec 19 02:30:16 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 18 Dec 2008 20:30:16 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494AEEAA.3090608@kanarip.com>	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>	<1229653156.6191.119.camel@localhost.localdomain>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
Message-ID: <494B0738.1040409@cchtml.com>

Mark wrote:
> Then what is it? Meritocracy?
>
>   


You know, you could package nautilus into RPM Fusion and get people to 
use it over the Fedora package. Maybe then, the maintainer will wise up 
and realize what a farce his ideology is.



From jkeating at redhat.com  Fri Dec 19 02:30:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Dec 2008 18:30:32 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229653156.6191.119.camel@localhost.localdomain>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
Message-ID: <1229653832.6191.120.camel@localhost.localdomain>

On Fri, 2008-12-19 at 03:25 +0100, Mark wrote:
> Then what is it? Meritocracy?

That's exactly right.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/3cb19f7a/attachment.sig>

From markg85 at gmail.com  Fri Dec 19 02:41:40 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 03:41:40 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494B0738.1040409@cchtml.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229653156.6191.119.camel@localhost.localdomain>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com>
Message-ID: <6e24a8e80812181841qc7e1fd4o1f87310c8025ce18@mail.gmail.com>

On Fri, Dec 19, 2008 at 3:30 AM, Michael Cronenworth <mike at cchtml.com> wrote:
> Mark wrote:
>>
>> Then what is it? Meritocracy?
>>
>>
>
>
> You know, you could package nautilus into RPM Fusion and get people to use
> it over the Fedora package. Maybe then, the maintainer will wise up and
> realize what a farce his ideology is.

Possible, yes, but i don't want to waste more time on a desktop
environment that a don't agree on for the biggest part.
And besides those gnome heads are so damn hard that you won't get
through. I tried with the thumbnail size stuff and failed.

So thanx but i pass.

2008/12/19 Jesse Keating <jkeating at redhat.com>:
> On Fri, 2008-12-19 at 03:25 +0100, Mark wrote:
>> Then what is it? Meritocracy?
>
> That's exactly right.
>
> --
> Jesse Keating

funny. then you should change your signature.
freedom is a feature for you but a limited feature for me. it's
enclosed freedom for me.



From jkeating at redhat.com  Fri Dec 19 02:49:10 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Dec 2008 18:49:10 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181841qc7e1fd4o1f87310c8025ce18@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229653156.6191.119.camel@localhost.localdomain>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com>
	<6e24a8e80812181841qc7e1fd4o1f87310c8025ce18@mail.gmail.com>
Message-ID: <1229654950.6191.121.camel@localhost.localdomain>

On Fri, 2008-12-19 at 03:41 +0100, Mark wrote:
> funny. then you should change your signature.
> freedom is a feature for you but a limited feature for me. it's
> enclosed freedom for me.

Incorrect sir.  We allow you to take the bits we produce, change them in
any way you like (within confines of the license) and ship it as your
own OS just the way you like it.  Your freedom is intact.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/2876c1a4/attachment.sig>

From konrad at tylerc.org  Fri Dec 19 03:15:13 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 18 Dec 2008 19:15:13 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494B0738.1040409@cchtml.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com>
Message-ID: <200812181915.13192.konrad@tylerc.org>

On Thursday 18 December 2008 06:30:16 pm Michael Cronenworth wrote:
> Mark wrote:
> > Then what is it? Meritocracy?
>
> You know, you could package nautilus into RPM Fusion and get people to
> use it over the Fedora package. Maybe then, the maintainer will wise up
> and realize what a farce his ideology is.

No, that's definitely unacceptable for RPM Fusion.

-- 
Conrad Meyer <konrad at tylerc.org>




From tony at bakeyournoodle.com  Fri Dec 19 03:19:58 2008
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Fri, 19 Dec 2008 14:19:58 +1100
Subject: PPC netboot on F-10?
In-Reply-To: <494892BD.6060603@redhat.com>
References: <494892BD.6060603@redhat.com>
Message-ID: <20081219031958.GF25985@ozlabs.org>

On Wed, Dec 17, 2008 at 12:48:45AM -0500, Warren Togami wrote:
> http://wtogami.livejournal.com/29574.html
> Has anyone successfully netbooted any PPC Mac with F-10?  I tried a G3  
> iMac and G5 tower today with only failure.

For what's it's worth I'll dig up a couple of these machines and see if any
light can be shed on this.  There have been a few problmes with netbooting
"large" (>12Mb) kernels on ppc64.  It seems reasonable that the same problems
could be affecting older machines.

One thing you may like to try is moving open-formware

0 > setenv real-base 2000000
0 > reset-all

Then try the netboot.

But you're right at least a few of the problems are firmware bugs.

Yours Tony

  linux.conf.au    http://www.marchsouth.org/
  Jan 19 - 24 2009 The Australian Linux Technical Conference!



From jspaleta at gmail.com  Fri Dec 19 03:26:25 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Dec 2008 18:26:25 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <200812181915.13192.konrad@tylerc.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
Message-ID: <604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>

On Thu, Dec 18, 2008 at 6:15 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> On Thursday 18 December 2008 06:30:16 pm Michael Cronenworth wrote:
>> Mark wrote:
>> > Then what is it? Meritocracy?
>>
>> You know, you could package nautilus into RPM Fusion and get people to
>> use it over the Fedora package. Maybe then, the maintainer will wise up
>> and realize what a farce his ideology is.
>
> No, that's definitely unacceptable for RPM Fusion.


There is another option to drive feedback. Find a way to have gnome
users submit application environment settings such as gconf keys, into
a a gnome project datadump in a way that shows what settings users are
changing from the system defaults.   I think you could do that as part
of a larger usability study which focuses on trying to understand why
people are making those changes.

-jef



From sokerlp at gmail.com  Fri Dec 19 04:26:20 2008
From: sokerlp at gmail.com (Oscar<Soker>)
Date: Thu, 18 Dec 2008 22:26:20 -0600
Subject: Amarok 2 on F9
In-Reply-To: <gieuf2$uok$1@ger.gmane.org>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gieuf2$uok$1@ger.gmane.org>
Message-ID: <8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>

Plz don't do that, Amarok 2 is not as goog as Amarok 1.4 it loose a lot of
functionality

Atentamente Oscar:



On Thu, Dec 18, 2008 at 7:48 PM, Rex Dieter <rdieter at math.unl.edu> wrote:

> Joshua C. wrote:
>
> >. Since the kde versions
> > in f10 and  f9 are identical can the maintainer officially publich it
> > for f9?
>
> I'd tend to be against that  A major upgrade like that in the middle of a
> release cycle is unwise.
>
> (Besides, the deps aren't *entirely* identical, F-9's libmtp is too old)
>
> -- Rex
>
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081218/570bae49/attachment.htm>

From bkoz at redhat.com  Fri Dec 19 04:42:49 2008
From: bkoz at redhat.com (Benjamin Kosnik)
Date: Thu, 18 Dec 2008 20:42:49 -0800
Subject: boost rebuild status
In-Reply-To: <20081218011435.03690d24@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
Message-ID: <20081218204249.33a3adeb@balbo.artheist.org>


Current status:

aqsis-0:1.4.1-4.fc10.x86_64
aqsis-core-0:1.4.1-4.fc10.x86_64
  bump Release, rebuilt Nicolas Chauvet (kwizart)

asc-0:2.1.0.0-2.fc10.x86_64
  bump Release, rebuilt by Petr Machata

barry-0:0.14-4.fc10.x86_64
  bump Release, rebuilt by Petr Machata

bmpx-0:0.40.14-7.fc10.x86_64
  bump Release, rebuild fails on libtool. 
  Petr Machata fix offered, running autoreconf -i -f in %build, build passes.
  Ask maintainer.

chess-0:1.0-20.fc10.x86_64
  bump Release, rebuilt by Petr Machata

conexus-0:0.5.3-4.fc9.i386
conexus-0:0.5.3-4.fc9.x86_64
  bump Release, rebuilt by Petr Machata

deluge-0:1.0.5-1.fc10.x86_64
  bump Release, rebuilt by Petr Machata

fuse-encfs-0:1.5-1.fc10.x86_64
  bump Release, rebuilt by Petr Machata

glob2-0:0.9.3-1.fc10.x86_64
  bump Release, rebuilt by Petr Machata

gnash-0:0.8.4-3.fc10.x86_64
gnash-cygnal-0:0.8.4-3.fc10.x86_64
  bump Release, rebuilt by Kevin Kofler

HippoDraw-python-0:1.21.1-4.fc9.x86_64
  bump Release, rebuild fails:
  config fails boost, python debug?
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1008532

hugin-0:0.7.0-1.fc10.x86_64
hugin-base-0:0.7.0-1.fc10.i386
  bump Release, rebuilt by Petr Machata

k3d-0:0.6.7.0-7.fc10.i386
  bump Release, rebuilt by Petr Machata

kdeedu-0:4.1.2-2.fc10.x86_64
  bump Release, rebuilt by Kevin Kofler

linkage-0:0.2.0-3.fc10.i386
  bump Release, rebuild fails
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1008400

  rb_libtorrent deps fail?

mapnik-0:0.5.2-0.7.svn738.fc10.i386
mapnik-python-0:0.5.2-0.7.svn738.fc10.x86_64
mapnik-utils-0:0.5.2-0.7.svn738.fc10.x86_64
  bump Release, build fails:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1008473
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1008570

  python/icuuc issues? 
  Could not find header or shared library for icuuc, exiting!

Miro-0:1.2.7-2.fc10.x86_64
  bump Release, rebuilt by Alex Lancaster (alexlan)

mkvtoolnix-0:2.4.0-1.fc10.x86_64
  bump Release, rebuilt.

openvrml-0:0.17.10-1.0.fc10.i386
openvrml-xembed-0:0.17.10-1.0.fc10.x86_64
  bump Release, scratch builds ok, rebuild fails only on ppc64, g++ killed ICE?:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1006133

pingus-0:0.7.2-3.fc9.x86_64
  bump Release, rebuilt.

player-0:2.1.1-5.fc10.x86_64
player-examples-0:2.1.1-5.fc10.x86_64
  bump Release, rebuild fails:
  
  compile error, temporary build situation?
  /usr/include/linux/serial.h:164: error: '__u32' does not name a type
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1007777
  
  Tim Niemueller on it.

pyexiv2-0:0.1.2-4.fc10.x86_64
  rebuild fails:
  http://koji.fedoraproject.org/koji/getfile?taskID=1007372

  boost_python? 
  g++ -o build/libpyexiv2.os -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC -I/usr/include/python2.6 src/libpyexiv2.cpp
src/libpyexiv2.cpp: In member function 'boost::python::tuple LibPyExiv2::Image::getThumbnailData()':
src/libpyexiv2.cpp:312: error: 'Exiv2::Thumbnail' has not been declared
src/libpyexiv2.cpp:312: error: expected `;' before 'thumbnail'
src/libpyexiv2.cpp:313: error: 'thumbnail' was not declared in this scope

python-tag-0:0.94.1-1.fc10.x86_64
  bump Release, rebuilt.

qmf-0:0.3.705289-1.fc10.x86_64
qpidc-0:0.3.705289-1.fc10.i386
qpidc-perftest-0:0.3.705289-1.fc10.x86_64
qpidc-rdma-0:0.3.705289-1.fc10.i386
qpidd-0:0.3.722557-1.fc10.x86_64
qpidd-cluster-0:0.3.705289-1.fc10.x86_64
qpidd-rdma-0:0.3.705289-1.fc10.x86_64
  bump Release, rebuild fails, not consistent.

  libtool issue?
  http://koji.fedoraproject.org/koji/getfile?taskID=1006101&name=build.log

libtool: install: invalid libtool wrapper script `perftest'
error: Bad exit status from /var/tmp/rpm-tmp.dOuDVz (%install)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.dOuDVz (%install)
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/qpidc.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.4/site-packages/mock/util.py", line 316, in do
    raise mock.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/qpidc.spec']
LEAVE do --> EXCEPTION RAISED

QuantLib-test-0:0.9.0-5.fc10.x86_64
  bump Release, rebuilt
  Note no boost libs in Requires in binary files.

rb_libtorrent-0:0.13.1-3.fc10.x86_64
rb_libtorrent-python-0:0.13.1-3.fc10.x86_64
  bump Release, failed:
  configuration error with boost system library
  http://koji.fedoraproject.org/koji/getfile?taskID=1005216&name=build.log

  add --with-boost-system=mt to %configure, still compile fail:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1006006

In file included from disk_io_thread.cpp:35:
../include/libtorrent/disk_io_thread.hpp:135: error: 'condition' in namespace 'boost' does not name a type
disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::join()':
disk_io_thread.cpp:97: error: 'm_signal' was not declared in this scope
disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::stop(boost::intrusive_ptr<libtorrent::piece_manager>)':
disk_io_thread.cpp:124: error: 'm_signal' was not declared in this scope
disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::add_job(const libtorrent::disk_io_job&, const boost::function<void ()(int, const libtorrent::disk_io_job&)>&)':
disk_io_thread.cpp:209: error: 'm_signal' was not declared in this scope
disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::operator()()':
disk_io_thread.cpp:243: error: 'm_signal' was not declared in this scope

  bump base sources to 0.14.1, configure ok, compile ok, link fails, 
  boost_system vs zlib.
  Ask maintainer.

rcsslogplayer-13.1.0-2.fc11.src.rpm
  bump Release, rebuilt

rcssbase-0:12.1.2-1.fc10.x86_64
rcssserver-0:12.1.4-1.fc10.i386
  bump Release, rebuilt

rcssserver3d-0:0.6-5.fc10.i386
  bump Release, rebuild fails:
  compile error  
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1008370
  
In file included from corecontext.cpp:25:
node.h: In member function 'boost::weak_ptr<T> zeitgeist::Leaf::FindParentSupportingClass() const':
node.h:135: error: there are no arguments to 'make_shared' that depend on a template parameter, so a declaration of 'make_shared' must be available
node.h:135: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
class.cpp: In member function 'boost::shared_ptr<zeitgeist::Object> zeitgeist::Class::Create()':
class.cpp:65: error: 'make_shared' was not declared in this scope
class.cpp: In member function 'boost::shared_ptr<zeitgeist::Core> zeitgeist::Class::GetCore() const':
class.cpp:88: error: 'make_shared' was not declared in this scope
In file included from core.cpp:26:
node.h: In member function 'boost::weak_ptr<T> zeitgeist::Leaf::FindParentSupportingClass() const':
node.h:135: error: there are no arguments to 'make_shared' that depend on a template parameter, so a declaration of 'make_shared' must be available
node.h:135: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
make[3]: *** [libzeitgeist_la-corecontext.lo] Error 1

referencer-0:1.1.4-1.fc10.x86_64
  bump Release, rebuilt

smc-0:1.5-3.fc10.x86_64
  no devel package?

source-highlight-0:2.10-1.fc10.x86_64
  bump Release, rebuilt

twinkle-0:1.3.2-1.fc10.x86_64
  bump Release, rebuilt

vegastrike-0:0.5.0-5.fc10.x86_64
  bump Release, rebuild fails:
  http://koji.fedoraproject.org/koji/getfile?taskID=1005464&name=build.log

  boost_python compile error
/usr/include/boost/python/detail/caller.hpp:102: error: 'struct boost::python::detail::caller_arity<1u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<Vector, int>]::result_converter' has no member named 'get_pytype'

wesnoth-0:1.4.5-1.fc10.x86_64
wesnoth-server-0:1.4.5-1.fc10.x86_64
wesnoth-tools-0:1.4.5-1.fc10.x86_64
  bump Release, rebuilt

wp_tray-0:0.5.3-8.fc10.x86_64
  bump Release, rebuilt

xmms2-0:0.5-2.fc10.x86_64
  bump Release, rebuilt



From rda at rincon.com  Fri Dec 19 06:27:24 2008
From: rda at rincon.com (Bob Arendt)
Date: Thu, 18 Dec 2008 23:27:24 -0700
Subject: Amarok 2 on F9
In-Reply-To: <8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>	<gieuf2$uok$1@ger.gmane.org>
	<8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
Message-ID: <494B3ECC.6090404@rincon.com>

Oscar<Soker> wrote:
> Plz don't do that, Amarok 2 is not as goog as Amarok 1.4 it loose a lot 
> of functionality
> 
+1
Amarok 2 is missing some this 1.4 has:
   doesn't have UMS media player support.  Bug 473807
   doesn't ship documentation. Bug 473522
*Please* do not "upgrade" f9 to Amarok2



From sundaram at fedoraproject.org  Fri Dec 19 06:56:53 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 19 Dec 2008 12:26:53 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <29424585.4771229642957194.JavaMail.root@zimbra.cbccgroup.com>
References: <29424585.4771229642957194.JavaMail.root@zimbra.cbccgroup.com>
Message-ID: <494B45B5.1090507@fedoraproject.org>

Robert 'Bob' Jensen wrote:
> Mark,
> 
> Remember these items if nothing else from this experience.
>  1. Rahul is an abrasive boob who makes things sound like he is the be all and end all, the total authority, the "Omega" if you will.
>  2. Don't ask for a "vote" ask for a poll to gauge interest in the topic, it will keep gentlemen like Rahul off your ass.
>  3. Don't cross post to the -devel list, the Developers (really mostly packagers) are not users, they are power users or more. 
> 
> Robert 'EvilBob' Jensen
> 
> P.S. I vote next time Rahul shows up at a public event we paint him purple and make like a pinata. +100
> 
> P.S.S. BTW the first setting I change on every new install is "Always open in browser windows" even before running "yum update"

Hurray for cheap personal attacks to derail a technical discussion. 
Especially if it comes from people who you have been supportive of, all 
along. Well done.

Rahul



From bob at fedoraunity.org  Fri Dec 19 06:59:43 2008
From: bob at fedoraunity.org (Robert 'Bob' Jensen)
Date: Fri, 19 Dec 2008 06:59:43 +0000 (UTC)
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181558t3741b70cgcbab7d47fb2a918d@mail.gmail.com>
Message-ID: <12963637.4841229669983494.JavaMail.root@zimbra.cbccgroup.com>

Mark, 

I sure hope you and everyone else knows that I was not seriously suggesting violence on another community member. My intent was to simply poke fun at the whole mailing list "+1, +10, +1000" habit of some people. 

Rahul if you were offended I am sorry.

Robert 'EvilBob' Jensen


----- Original Message -----
From: "Mark" <markg85 at gmail.com>
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Sent: Thursday, December 18, 2008 5:58:46 PM GMT -06:00 US/Canada Central
Subject: Re: Call for vote: Nautilus use Browser view for fedora 11

On Fri, Dec 19, 2008 at 12:29 AM, Robert 'Bob' Jensen
<bob at fedoraunity.org> wrote:
> Mark,
>
> Remember these items if nothing else from this experience.
>  1. Rahul is an abrasive boob who makes things sound like he is the be all and end all, the total authority, the "Omega" if you will.
>  2. Don't ask for a "vote" ask for a poll to gauge interest in the topic, it will keep gentlemen like Rahul off your ass.
>  3. Don't cross post to the -devel list, the Developers (really mostly packagers) are not users, they are power users or more.
>
> Robert 'EvilBob' Jensen
>
> P.S. I vote next time Rahul shows up at a public event we paint him purple and make like a pinata. +100

Where is that event ^_^
>
> P.S.S. BTW the first setting I change on every new install is "Always open in browser windows" even before running "yum update"

The very first thing i do is open a console and install gconf-editor
then i adjust some config settings of nautilus followed by a updates
and more config changing... (like all fonts to 8 instead of 10)

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list



From db at zigo.dhs.org  Fri Dec 19 07:26:45 2008
From: db at zigo.dhs.org (Dennis =?utf-8?Q?Bj=C3=B6rklund?=)
Date: Fri, 19 Dec 2008 08:26:45 +0100 (CET)
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <b2517dc251accd55e78603c47e6176f5.squirrel@zigo.org>

> Lets use the browser view of nautilus in the next fedora release.

-1

I love the way nautilus work now and I don't like the browser mode.

-1 on voting in mailinglists. But I like the spatial nautilus so much that
I couldn't resist this time.

/Dennis



From sundaram at fedoraproject.org  Fri Dec 19 07:37:46 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 19 Dec 2008 13:07:46 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<6e24a8e80812181514o5e424250q5799afc96a8793fc@mail.gmail.com>
Message-ID: <494B4F4A.70408@fedoraproject.org>

Mark wrote:
> Now that's just one thing you guys changed in firefox. there is a lot
> more that got changed in firefox and isn't changed upstream! just go
> through the firefox files on the fedora CVS.
> So your argument that confis settings will have to be applied upstream
> is hereby smashed to the ground because other packages don't keep that
> same "deal".

The question isn't really a simple matter of whether there is a change 
or not but whether it is going to be in the upstream project or is it a 
patch forever?  Pointing out deviations isn't a justification for making 
more such changes. It is a good motivation for avoiding them.

Some of my packages have some patches as well. In one case, upstream 
said they aren't doing any more releases even though they didn't 
disagree with the patch. In another case, the software doesn't even 
build without a patch in recent distributions and upstream isn't active 
either. There are more, which is why the guidelines have a list of 
exceptions as examples.

> Oh men, i'm so starting to hate you.
> your reasons are broken and smashed to the ground by what i said
> above! get fedora in line with what you say or don't say a thing!

Hate? You need to get less emotional. Fedora is getting better at 
pushing things upstream (including configuration changes) than before 
and I don't think it is a black and white thing and we shouldn't be 
dismissive of configuration changes.


Rahul



From nicu_fedora at nicubunu.ro  Fri Dec 19 08:14:07 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 19 Dec 2008 10:14:07 +0200
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229635519.23410.31.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>
	<1229635519.23410.31.camel@dimi.lattica.com>
Message-ID: <494B57CF.2090501@nicubunu.ro>

Dimi Paun wrote:
> On Fri, 2008-12-19 at 02:40 +0530, Rahul Sundaram wrote:
>> I vote that we don't vote on configuration changes and let the
>> upstream 
>> developers and package maintainers decide.  Voting on every 
>> configuration change, we would obvious not be getting anywhere.  The 
>> decision will be an upstream change or in other circumstances, the 
>> maintainer of the software in question. If the maintainers want to do
>> a survey, they can on their own or ask for help if needed.
> 
> This makes lots of sense -- to be consistent, I suggest we remove
> all Fedora-related artwork that diverges from upstream. Including
> the desktop background images too.

You may be sarcastic Dimi, but you may be surprised to learn how close 
is this to the truth and how strong is the initiative to remove our 
custom artwork.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com



From thomas.moschny at gmail.com  Fri Dec 19 08:25:48 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Fri, 19 Dec 2008 09:25:48 +0100
Subject: boost rebuild status
In-Reply-To: <20081218011435.03690d24@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
Message-ID: <a9d183c80812190025w27c81bb4hf2d543b4a3fbf375@mail.gmail.com>

2008/12/18 Benjamin Kosnik <bkoz at redhat.com>:
> Rebuilding dependent packages for boost is progressing relatively
> smoothly. Here's an update on boost rebuilds for the second half of the
> deps list: hopefully Petr will update from the top.
>
> Here's a list of some of the deps with status:

How did you get that list - it seems to me that some packages are
missing, maybe because they need boost at build time only.

Here's a list of src rpms that depend on boost-devel. Some of these
packages are on your list, others are not.

abiword-1:2.6.5-9.fc11.src
agave-0:0.4.2-8.fc10.src
akonadi-0:1.0.81-1.fc11.src
aqsis-0:1.4.1-4.fc10.src
ardour-0:2.7-1.fc11.src
asc-0:2.2.0.0-1.fc11.src
asio-0:1.0.0-2.fc9.src
barry-0:0.14-5.fc11.src
bmpx-0:0.40.14-7.fc10.src
CGAL-0:3.3.1-11.fc9.src
chess-0:1.0-22.fc11.src
clipsmm-0:0.0.7-4.fc9.src
conexus-0:0.5.3-4.fc9.src
deluge-0:1.0.7-1.fc11.src
enblend-0:3.2-2.fc10.src
exempi-0:2.0.1-1.fc10.src
fuse-encfs-0:1.5-1.fc10.src
glob2-0:0.9.3-1.fc10.src
gnash-0:0.8.4-5.fc11.src
gnuradio-0:3.1.2-3.fc11.src
HippoDraw-0:1.21.1-6.fc11.src
hugin-0:0.7.0-1.fc10.src
inkscape-0:0.46-8.fc11.src
k3d-0:0.6.7.0-8.fc11.src
kdeedu-0:3.5.10-1.src
kdeedu-0:3.5.9-1.src
kdeedu-0:4.1.85-1.fc11.src
kdenetwork-7:4.1.85-1.fc11.src
kdepim-6:4.1.85-1.fc11.src
kdepimlibs-0:4.1.85-2.fc11.src
kdeplasma-addons-0:4.1.85-2.fc11.src
kdesdk-0:4.1.85-1.fc11.src
koffice-1:1.9.98.3-1.fc11.src
libopenraw-0:0.0.5-1.fc9.src
linkage-0:0.2.0-3.fc10.src
lordsawar-0:0.1.3-3.fc11.src
mapnik-0:0.5.2-0.7.svn738.fc10.src
Miro-0:1.2.8-1.fc11.src
mkvtoolnix-0:2.4.0-3.fc11.src
monotone-0:0.41-1.fc10.src
MyPasswordSafe-0:0.6.7-6.20061216.fc10.src
nemiver-0:0.6.3-1.fc10.src
openoffice.org-1:3.0.1-13.2.fc11.src
openvrml-0:0.17.10-1.0.fc10.src
oyranos-0:0.1.7-12.fc10.src
papyrus-0:0.7.1-3.fc9.src
pdfedit-0:0.4.1-2.fc10.src
pdns-0:2.9.22-1.rc2.fc11.src
pdns-recursor-0:3.1.7-2.fc10.src
pingus-0:0.7.2-3.fc9.src
pinot-0:0.89-1.fc10.src
player-0:2.1.1-5.fc10.src
pyexiv2-0:0.1.2-5.fc11.src
python-tag-0:0.94.1-3.fc11.src
qpidc-0:0.3.722557-1.fc10.src
QuantLib-0:0.9.7-3.fc11.src
quickfix-0:1.12.4-6.fc11.src
rb_libtorrent-0:0.13.1-5.fc11.src
rcsslogplayer-0:13.0.1-1.fc11.src
rcssmonitor-0:13.0.0-2.fc10.src
rcssserver-0:13.0.2-2.fc11.src
rcssserver3d-0:0.6-5.fc10.src
referencer-0:1.1.5-4.fc11.src
sim-0:0.9.5-0.14.20080923svn2261rev.fc10.src
source-highlight-0:2.10-2.fc11.src
srecord-0:1.45-1.fc11.src
stellarium-0:0.10.0-1.fc10.src
subcommander-0:1.9.94-3.fc10.src
TnL-0:071111-8.fc11.src
twinkle-0:1.3.2-3.fc11.src
vegastrike-0:0.5.0-6.fc11.src
wesnoth-0:1.4.6-6.fc11.src
widelands-0:0-0.13.Build13.fc11.src
wp_tray-0:0.5.3-9.fc11.src
xmlcopyeditor-0:1.1.0.6-4.fc9.src
xmms2-0:0.5-2.fc11.src

- Thomas



From kevin.kofler at chello.at  Fri Dec 19 08:26:06 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 09:26:06 +0100
Subject: Forcing Gnome to start sans metacity
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<gidlps$hh2$2@ger.gmane.org>
	<7f692fec0812180754x20f9b890t9f44fbadac447920@mail.gmail.com>
	<gielhh$6n2$1@ger.gmane.org>
	<7f692fec0812181714i40b405dfl58b43baf2581051b@mail.gmail.com>
Message-ID: <giflqu$kb3$1@ger.gmane.org>

Yaakov Nemoy wrote:
> KDE's very easy to configure, thankfully.  A package called
> xmonad-gnome-session that starts up KDE probably wouldn't be very
> welcome though ;).

Just call it xmonad-desktop-session and make it silently use KDE. ;-)

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 19 08:33:49 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 09:33:49 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
Message-ID: <gifm9d$kb3$2@ger.gmane.org>

Mark wrote:
> I'm gonna quit gnome with all that i know now. i don't want to use it
> anymore and be treated like an idiotic user (that's how gnome thinks,
> not me). i don't want to be a part of gnome anymore and i'm wondering
> what i should do with fedora. I want to keep RPM's but not fedora
> (mainly because of codecs but this thread play a part in it as
> well)... kinda hard. I'm gonna try to make my own file browser in QT
> (gtk sucks)

Why make your own? Try Dolphin. :-) Nothing keeps you from using Dolphin
under GNOME or any other WM or DE if you don't like KDE 4.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 19 08:35:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 09:35:37 +0100
Subject: boost rebuild status
References: <20081218011435.03690d24@balbo.artheist.org>
	<a9d183c80812190025w27c81bb4hf2d543b4a3fbf375@mail.gmail.com>
Message-ID: <gifmcp$kb3$3@ger.gmane.org>

Thomas Moschny wrote:
> How did you get that list - it seems to me that some packages are
> missing, maybe because they need boost at build time only.

Well, those don't have broken deps, so they don't actually _have_ to be
rebuilt now. (Still, they should get rebuilt to check that they still
build.)

        Kevin Kofler



From kevin.kofler at chello.at  Fri Dec 19 08:37:25 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 09:37:25 +0100
Subject: Amarok 2 on F9
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gieuf2$uok$1@ger.gmane.org>
Message-ID: <gifmg5$kb3$4@ger.gmane.org>

Rex Dieter wrote:

> Joshua C. wrote:
> 
>>. Since the kde versions
>> in f10 and  f9 are identical can the maintainer officially publich it
>> for f9?
> 
> I'd tend to be against that  A major upgrade like that in the middle of a
> release cycle is unwise.

+1

You should advertise the F9 build in kde-redhat unstable though. :-)

        Kevin Kofler



From fedora at ml.shredzone.de  Fri Dec 19 09:32:55 2008
From: fedora at ml.shredzone.de (Richard =?iso-8859-1?Q?K=F6rber?=)
Date: Fri, 19 Dec 2008 10:32:55 +0100 (CET)
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <28c555e2af7bce3d43b2c4c9e99958af.squirrel@mail.shredzone.net>


> A new window for each folder that i open is so painful!!
> 1. My taskbar fills up in notime each time i open a new folder

Just double-click a folder with the middle mouse button.

> 2. New features of nautilus: tabbed browsing! completely useless if
> your not using the browser mode
> 3. Tabbed browsing (files/folders or web) is "hot" these days

The browser already clutters its window with a lot toolbars, buttons and
gadgets. With tabs it clutters the window even more.

> 4. It feels so.. old (windows 95? 3.11?)

The browser view feels so... Windows XP.

But seriously, who cares? If you dislike the folder/browser view, just
configure it the way you like it. How often do you need to reconfigure
your Gnome? My Gnome settings are a couple of years old now.

Regards
-- 
Richard "Shred" K?rber



From bnocera at redhat.com  Fri Dec 19 10:05:13 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 19 Dec 2008 10:05:13 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
Message-ID: <1229681113.3159.13863.camel@cookie.hadess.net>

On Fri, 2008-12-19 at 00:21 +0100, Mark wrote:
<snip>
> Also if this isn't the way to get this in fedora then what is? this
> change will affect everyone and should not rely on one person but
> should have a solid base behind it.

Get the defaults changed upstream.

> In this thread there are just a few -1 posts and the rest seems to be
> +1 so the solid base is building up here.

That's called a vocal minority, and is the reason why we don't have
votes on mailing-lists for this sort of thing.

And if you think it's a matter of patching the package, note that for
any GNOME packages you'll find in Fedora for which there are patches,
you'll find those same patches/functionality being upstreamed.



From pm at datasphere.ch  Fri Dec 19 10:24:10 2008
From: pm at datasphere.ch (Patrick MONNERAT)
Date: Fri, 19 Dec 2008 11:24:10 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229681113.3159.13863.camel@cookie.hadess.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
	<1229681113.3159.13863.camel@cookie.hadess.net>
Message-ID: <1229682250.6483.0.camel@linuxdev.datasphere.ch>

+1 for me
Cheers,
Patrick



From pm at datasphere.ch  Fri Dec 19 10:24:10 2008
From: pm at datasphere.ch (Patrick MONNERAT)
Date: Fri, 19 Dec 2008 11:24:10 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229681113.3159.13863.camel@cookie.hadess.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
	<1229681113.3159.13863.camel@cookie.hadess.net>
Message-ID: <1229682250.6483.0.camel@linuxdev.datasphere.ch>

+1 for me
Cheers,
Patrick



From mcepl at redhat.com  Fri Dec 19 10:16:37 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 19 Dec 2008 11:16:37 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
Message-ID: <5t8s16xl8o.ln2@ppp1053.in.ipex.cz>

On 2008-12-19, 02:16 GMT, Mark wrote:
>so far for democracy!

Nobody ever claimed that open software development (or any 
software development for that matter) should be controlled by 
unwashed masses aka democratically.

Moreover, you can save your time for writing all this rant, if 
you just configured nautilus as you like it.

Mat?j



From hughsient at gmail.com  Fri Dec 19 10:34:16 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 19 Dec 2008 10:34:16 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <1229682856.3971.18.camel@hughsie-work.lan>

On Thu, 2008-12-18 at 21:56 +0100, Mark wrote:
> Cross posted to the devel list because it's for the next fedora
> version (currently in development thus the devel list)

Please don't cross post like this. Decisions like this don't come from
people doing +1 or -1 on mailing lists, sorry.

Richard.




From mcepl at redhat.com  Fri Dec 19 10:17:29 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 19 Dec 2008 11:17:29 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229653156.6191.119.camel@localhost.localdomain>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<1229653832.6191.120.camel@localhost.localdomain>
Message-ID: <pu8s16xl8o.ln2@ppp1053.in.ipex.cz>

On 2008-12-19, 02:30 GMT, Jesse Keating wrote:
>> Then what is it? Meritocracy?
>
> That's exactly right.

Or I would be even more blunt -- "Who makes patches decides."

Mat?j



From mcepl at redhat.com  Fri Dec 19 10:27:35 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 19 Dec 2008 11:27:35 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
Message-ID: <nh9s16xl8o.ln2@ppp1053.in.ipex.cz>

["Followup-To:" header set to gmane.linux.redhat.fedora.devel.]
> Lets use the browser view of nautilus in the next fedora 
> release.

Read http://slashdot.org/features/98/10/13/1423253.shtml three 
times and only then continue in writing messages to this thread.  
:)

Mat?j



From mschwendt at gmail.com  Fri Dec 19 10:47:53 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 19 Dec 2008 11:47:53 +0100
Subject: GNOME menu ugliness - Name/GenericName
Message-ID: <20081219114753.e9588d0b.mschwendt@gmail.com>

What is the "correct usage" of Name/GenericName in Fedora Land?

[...]

https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files

| Installed .desktop files MUST follow the desktop-entry-spec , paying
| particular attention to validating correct usage of Name, GenericName,
| [...] entries.

Raises the question: What is "correct usage" of those entries?


http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html

| Name	: Specific name of the application,
| for example "Mozilla". (REQUIRED)

| GenericName	: Generic name of the application,
| for example "Web Browser". (OPTIONAL)

Raises the questions: Why don't packages adhere to this standard?


https://fedoraproject.org/wiki/Special:Search?search=GenericName&go=Go

Tells me that this has been discussed several times in early 2007.


https://fedoraproject.org/wiki/FWN/Issue90#What_Should_X-Chat_Be_Called_In_The_Menu.3F
(May 2007)
https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02153.html

| Kevin also wondered why GNOME didn't support GenericNames in .desktop
| yet, which Matthias answered by saying no one had got around to it yet.

Is this still the case? - Seems so. GNOME here only shows the Name= entries.
How does KDE handle this?

Why do we have a policy on "correct usage" of Name/GenericName that would
make the menus look ugly. It's not just the mix of Name/GenericName in there,
it confuses users, who are not familiar with application names. I would
like to violate the guidelines and put GenericName as Name to escape from
this.

To repeat the question from the beginning:
What is the "correct usage" of Name/GenericName in Fedora Land?



From alsadi at gmail.com  Fri Dec 19 10:48:17 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 19 Dec 2008 12:48:17 +0200
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <pu8s16xl8o.ln2@ppp1053.in.ipex.cz>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229653156.6191.119.camel@localhost.localdomain>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<1229653832.6191.120.camel@localhost.localdomain>
	<pu8s16xl8o.ln2@ppp1053.in.ipex.cz>
Message-ID: <385866f0812190248g69e58d9ar911f47ae5759a9ec@mail.gmail.com>

> Wasn't the non-browser nautilus mode chosen as a default for accessibility purposes, either upstream or in Fedora or wherever?


yes and I pointed out why
the other mode was made so that one can drag and drop things easily
and if you have 10000000000s windows on your desktop
then you use shift double click

my suggestion was in the first place that solves both is
1. provide a patch that make shift-double click opens in a new window
2. upstream the patch
3. make browser mode to be the default because the usability issue is solved



From rawhide at fedoraproject.org  Fri Dec 19 10:48:38 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 19 Dec 2008 10:48:38 +0000 (UTC)
Subject: rawhide report: 20081219 changes
Message-ID: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>

Compose started at Fri Dec 19 06:01:07 UTC 2008

New package entertrack
        Web-based artifact tracking/management system written in PHP
New package nekovm
        Neko embedded scripting language and virtual machine
New package perl-AnyEvent-AIO
        Truly asynchronous file and directrory I/O
New package perl-AnyEvent-BDB
        Truly asynchronous Berkeley DB access
New package skinlf
        Skin look and feel Skinning library for java
New package tcping
        Check of TCP connection to a given IP/Port
New package trytond
        Server for the Tryton application framework
New package usbmon
        A basic front-end to usbmon
Removed package frysk
Removed package kmobiletools
Removed package knetworkmanager
Removed package kpowersave
Updated Packages:

Miro-1.2.8-3.fc11
-----------------
* Thu Dec 18 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.2.8-3
- Enable patch for new boost 1.37 for F-11+

* Thu Dec 18 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.2.8-2
- Rebuild against new boost


QuantLib-0.9.7-4.fc11
---------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 0.9.7-4
- Rebuild for boost-1.37.0.


anaconda-11.5.0.1-1
-------------------
* Thu Dec 18 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.5.0.1-1
- Remove plural forms from po/tg.mo (katzj)

* Thu Dec 18 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.5.0.0-1
- Reduce direct D-Bus calls in isys/iface.c. (dcantrell)
- Allow 'ks' to function as it once did (#471812) (dcantrell)
- Fix telnet install support (#471082) (dcantrell)
- Call 'udevadm settle' instead of 'udevsettle'. (dcantrell)
- When using anaconda with kickstart file with UI mode - do not show the VNC
  question (#476548) (msivak)
- Check error from asprintf() correctly for dhcpclass handling. (dcantrell)
- Use libnm_glib in net.c:get_connection() (dcantrell)
- Add libnm_glib CFLAGS and LIBS to loader's Makefile. (dcantrell)
- BR NetworkManager-glib-devel. (dcantrell)
- Only write the short hostname to the localhost line (#474086) (dcantrell)
- Updated Tajik Translation - Victor Ibragimov (victor.ibragimov)
- Copy /etc/dhclient-DEV.conf file to target system (#476364) (dcantrell)
- Use macros for D-Bus paths (dcantrell)
- Let X tell us when it's launched rather than just sleeping. (ajax)
- When there's no baseurl, set a default of [] instead of [''] (#476208).
  (clumens)
- cracklib now raises exceptions on bad passwords (rzhou, #476312). (clumens)
- Make sure ssh doesn't get duplicated in the open port list (#474937).
  (clumens)
- mdraid1: default to putting grub on partition instead of mbr (#217176)
  (hdegoede)
- Don't install the games group as part of office/productivity (#472324).
  (clumens)
- Don't dump encryption passphrases. (dlehman)
- Write anacdump.txt upon receipt of SIGUSR2 (from clumens). (dlehman)
- Use stacks instead of tracebacks in traceback handlers. (dlehman)
- Unmount swap devices when migrating filesystems, then reactivate
  (#473260). (clumens)
- Handle both /dev/sr0 and sr0, since that's what cdromList gives (#475083).
  (clumens)
- In iface_ip2str(), make sure to advance to next item before continue.
  (dcantrell)
- We already have _GNU_SOURCE defined in Makefile.inc (dcantrell)
- Remove XXX comment in net.c about GATEWAY (dcantrell)
- Use strverscmp() from glibc in place of rpmvercmp() (dcantrell)
- Remove readLine() function from loader/loadermisc.c (dcantrell)
- Do not write SEARCH line to ifcfg-DEVICE file (#474858) (dcantrell)
- Preserve existing network configuration files during install (#461550)
  (dcantrell)
- Send unique vendor class identifier unless user specifies one. (dcantrell)
- Avoid tracebacks when filling in static network config fields (#474275)
  (dcantrell)
- Prevent network install when no network devices are found (#470144)
  (dcantrell)
- Remove markup from text before printing it in cmdline mode (#470253).
  (clumens)
- Move strip_markup() into iutil. (clumens)
- Fix up plural forms header so that python doesn't blow up for us (katzj)
- Change text to reflect Jesse's comments (katzj)
- Add support for the Tajik language (#455963). (clumens)
- Add a button to the UI to ignore all missing packages. (clumens)
- First small eu.po transtation, just to be sure that the system is set up
  OK. (mikel.paskual)
- mini-wm: Turn on automatic window redirection. (ajax)
- Better naming for LVM volume groups and logical volumes (#461682)
  (dcantrell)
- Partition requests can be None when populating the tree. (#474284)
  (dlehman)
- Say we are unable to configure the network interface (#467960) (dcantrell)
- Match textw/network_text.py strings to iw/network_gui.py (#470145)
  (dcantrell)
- In addSnap(), check snapshots for data key before continuing (#433824)
  (dcantrell)
- Load FCP modules early for CD/DVD install (#184648) (dcantrell)
- Update mk-s390-cdboot.c to work with large kernel images (#184648)
  (dcantrell)
- Make sure fstype exists before we try to test it (#473498). (clumens)
- Updated a small correction in kn locale (svenkate)
- Use modules.* files for finding modules of a type rather than modinfo
  (katzj)
- Make complete text mention updates (#244431) (katzj)
- Make text for autopartitioning types clearer (#441350) (katzj)
- Allow installing grub on the MBR if /boot is on mdraid (#217176) (hdegoede)
- Fix some spelling errors in German translation (fabian)
- Make the required media dialog less wordy (#469557). (clumens)
- returnNewestByName now raises an error instead of returning [] (#472462).
  (clumens)
- Fix death on login of an OLPC on a live image (katzj)
- Fix ld-*.so globbing for glibc-2.9 . (pjones)
- Do not bring up network for non-remote kickstart locations (#471658)
  (dcantrell)
- Resolve dm-X devices returned by pvdisplay. (#448129) (dlehman)
- More shell script syntax fixing (katzj)
- Only bring up the network dialog on package failures if required
  (#471502). (clumens)


aqsis-1.4.1-5.fc11
------------------
* Thu Dec 18 17:00:00 2008 kwizart < kwizart at gmail.com > - 1.4.1-5
- Rebuild for boost


asc-2.2.0.0-2.fc11
------------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 2.2.0.0-2
- Rebuild for new boost


balsa-2.3.26-3.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Pawel Salek <pawsa at theochem.kth.se> - 2.3.26-3
- Port to gmime-2.4 using http://bugzilla.gnome.org/537507


barry-0.14-6.fc11
-----------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.14-6
- rebuild for new boost


bind-9.6.0-0.7.rc2.fc11
-----------------------
* Thu Dec 18 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.7.rc2
- 9.6.0rc2 release
- bind-96-rh475120.patch merged


bmpx-0.40.14-8.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.40.14-8
- rebuild for new boost


bochs-2.3.7-2.fc11
------------------
* Thu Dec 18 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.3.7-2
- Remove dlxlinux sub package, we cannot build this from source (rh 476878)


chess-1.0-23.fc11
-----------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 1.0-23
- Rebuild for new boost


compiz-0.7.8-10.fc11
--------------------
* Thu Dec 18 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.7.8-10
- Rebuild against new gnome-desktop


conexus-0.5.3-6.fc11
--------------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.5.3-6
- Rebuild for new boost

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.5.3-5
- Fix Patch0:/%patch mismatch.


control-center-2.25.3-1.fc11
----------------------------
* Thu Dec 18 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-1
- Update to 2.25.3
- Drop upstreamed patches

* Thu Dec 18 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.2-9
- Remove the sound capplet by hand, will be gone in the next upstream version

* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-8
- Rebuild against new gnome-desktop


cpl-4.2.0-1.fc11
----------------
* Thu Dec 18 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> 4.2.0-1
- New upstream source


deluge-1.0.7-2.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 1.0.7-2
- Rebuild for new boost.


dhcp-4.0.0-33.fc11
------------------
* Thu Dec 18 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 12:4.0.0-33
- Remove unnecessary success/failure lines in init scripts (#476846)


drupal-views-6.x.2.2-1.fc11
---------------------------
* Thu Dec 18 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 6.x.2.2-1
- New upstream, fixes SA-2008-075.


enlightenment-0.16.999.050-1.fc11
---------------------------------
* Sun Nov 30 17:00:00 2008 Pavel "Stalwart" Shevchuk - 0.16.999.050-1
- New upstream snapshot

* Sun Nov 23 17:00:00 2008 Pavel "Stalwart" Shevchuk - 0.16.999.043-4
- Changed summary to be more descriptive


evolution-brutus-1.2.34-1.fc11
------------------------------
* Thu Dec 18 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.2.34-1
- Update to latest upstream (1.2.34). 
- Build against new e-d-s: 2.26.


exiv2-0.18-1.fc11
-----------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.18-1
- exiv2-0.18


ext3grep-0.10.1-1.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.10.1-1
- Upstream version 0.10.1


fbida-2.07-3.fc11
-----------------
* Thu Dec 18 17:00:00 2008 Adrian Reber <adrian at lisas.de> - 2.07-3
- removed bitstream-vera dependency to fix (#473559)
  "Replace bitstream-vera dependencies with dejavu dependencies"
- changed BR libungif-devel to giflib-devel


florence-0.3.1-1.fc11
---------------------
* Thu Dec 18 17:00:00 2008 Simon Wesp <cassmodiah at fedoraproject.org> - 0.3.1-1
- New upstream release
- Move installation of icon from highcolortheme to DATADIR/pixmaps


fop-0.95-1
----------
* Thu Dec 18 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.95-1
- New upstream release


fuse-encfs-1.5-2.fc11
---------------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 1.5-2
- Rebuild with new boost


gallery2-2.3-2.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 2.3-2
- Correct removal of bundled Smarty and usage of system Smarty.


ganyremote-5.5-1.fc11
---------------------
* Sun Dec 14 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.5-1
- Handle GuiAppVersion parameter in configuration files. Add possibility
  to download java client from Web. Small Ubuntu-specific fixes.


geeqie-1.0-0.11.alpha2.1299svn.fc11
-----------------------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0-0.9.alpha2
- respin (exiv2)

* Thu Dec 18 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.0-0.11.alpha2.1299svn
- drop desktop file Exec= invocation patch (no longer necessary)

* Thu Dec 18 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.0-0.10.alpha2.1299svn
- update to svn 1299 for new exiv2
- disable LIRC support which is broken


glade3-3.5.4-1.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 3.5.4-1
- Version bump to 3.5.4.


glob2-0.9.3-2.fc11
------------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.9.3-2
- rebuild for new boost


gnash-0.8.4-6.fc11
------------------
* Thu Dec 18 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.8.4-6
- rebuild for new boost


gnome-commander-1.2.8-0.3.svn2361_trunk.fc11
--------------------------------------------

gnome-panel-2.25.3-3.fc11
-------------------------
* Thu Dec 18 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-3
- Remove the mixer from the default panel config as well
- Update search and preferred apps patches

* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-2
- Update to 2.25.3
- Drop mixer from default config


gnome-settings-daemon-2.25.3-2.fc11
-----------------------------------
* Thu Dec 18 17:00:00 2008 - Ray Strode <rstrode at redhat.com> - 2.25.3-2
- Drop touchpad patch for now

* Thu Dec 18 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-1
- Update to 2.25.3

* Thu Dec 18 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.2-11
- Fix touchpad patches

* Wed Dec 17 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.2-10
- Rebuild against new gnome-desktop


gssdp-0.6.3-3.fc11
------------------
* Thu Dec 18 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.6.3-3
- Add gtk-doc build req


gupnp-0.12.4-3.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.12.4-3
- Add gtk-doc build req


gupnp-av-0.2.1-7.fc11
---------------------
* Thu Dec 18 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.2.1-7
- Add gtk-doc build req


gypsy-0.6-6.fc11
----------------
* Thu Dec 18 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.6-6
- Add gtk-doc build req


hotssh-0.2.6-1.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Colin Walters <walters at redhat.com> - 0.2.6-1
- New upstream


hotwire-0.721-3.fc11
--------------------
* Thu Dec 18 17:00:00 2008 Colin Walters <walters at redhat.com> - 0.721-3
- Bug 445109 - fix desktop file installation
  Patch from Christian Krause (chkr at plauener.de)


httpd-2.2.11-3
--------------
* Thu Dec 18 17:00:00 2008 Joe Orton <jorton at redhat.com> 2.2.11-3
- update to 2.2.11
- package new /var/run/httpd directory, and move default pidfile
  location inside there


hugin-0.7.0-3.fc11
------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.7.0-3
- respin (eviv2)

* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.7.0-2
- rebuild for new boost


hunspell-en-0.20081216-1.fc11
-----------------------------
* Thu Dec 18 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081216-1
- latest version


hunspell-sk-0.20080525-1.fc11
-----------------------------
* Wed Dec  3 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1:0.20080525-1
- latest version

* Fri Aug  3 18:00:00 2007 Caolan McNamara <caolanm at redhat.com> - 1:0.5.6-2
- clarify that tri-licensed


immix-1.3.2-5.fc11
------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.3.2-5
- respin (exiv2)


inksmoto-0.5.0-1.rc1.fc11
-------------------------
* Thu Dec 18 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 0.5.0-1.rc1
- New upstream, fixes BZ 476815.

* Mon Nov 24 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 0.4.1-3
- Cleaned up summary.


jd-2.1.0-0.2.svn2575_trunk.fc11
-------------------------------
* Fri Dec 19 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2575


jython-2.2.1-2.2.fc11
---------------------
* Thu Dec 18 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 2.2.1-2.2
- Rebuild


k3d-0.6.7.0-9.fc11
------------------
* Thu Dec 18 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.6.7.0-9
- Rebuild for new boost


kanyremote-5.5-1.fc11
---------------------
* Sun Dec 14 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.5-1
- Handle GuiAppVersion parameter in configuration files. Add possibility
  to download java client from Web. Small Ubuntu-specific fixes.


kdebase-workspace-4.1.85-4.fc11
-------------------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 4.1.85-4
- BR: edje-devel
- BR: google-gadgets-devel


kdeedu-4.1.85-5.fc11
--------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.85-4
- respin (upstreamable) cfitsio patch

* Thu Dec 18 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.85-5
- and fix cfitsio detection yet again (upstream revision 898747)

* Thu Dec 18 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.85-3
- fix cfitsio detection yet again

* Thu Dec 18 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.85-2
- rebuild for new boost


kdegraphics-4.1.85-3.fc11
-------------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 4.1.85-3
- respin (eviv2)


kdelibs-4.1.85-6.fc11
---------------------
* Fri Dec 19 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.85-6
- add plasma-default-wallpaper libplasma patch from kdebase-workspace-4.1


kdevelop-3.5.4-1.fc11
---------------------
* Thu Dec 18 17:00:00 2008 Than Ngo <than at redhat.com> - 3.5.4-1
- 3.5.4


kernel-2.6.28-0.131.rc8.git4.fc11
---------------------------------
* Wed Dec 17 17:00:00 2008 John W. Linville <linville at redhat.com>
- iwlwifi: use GFP_KERNEL to allocate Rx SKB memory

* Tue Dec 16 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc8-git4

* Mon Dec 15 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc8-git3


kipi-plugins-0.2.0-0.9.beta5.fc11
---------------------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.2.0-0.9.beta5
- respin (eviv2)


kphotoalbum-3.2-0.6.20081007svn.fc11
------------------------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.2-0.5.20081007svn
- respin (eviv2)


libX11-1.1.99.2-2.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.1.99.2-2
- BR: util-macros

* Thu Dec 18 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.1.99.2-1
- libX11 1.1.99.2


libogg-1.1.3-10.fc11
--------------------
* Thu Dec 18 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2:1.1.3-10
- Rebuild for pkgconfig provides


libxcb-1.1.93-2.fc11
--------------------
* Thu Dec 18 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.1.93-2
- Egregious hack to make the next libX11 build work.  Hands... won't come
  clean...

* Wed Dec 17 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.1.93-1
- libxcb 1.1.93


lordsawar-0.1.4-2.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.1.4-2
- Bump because I screwed up my CVS checkin

* Sun Dec  7 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.1.4-1
- 0.1.4
- Add BuildRequires: intltool >= 0.35.0


man-pages-cs-0.17.20080113-6.fc11
---------------------------------
* Thu Dec 18 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 0.17.20080113-6
- update another part of coreutils man-pages (patches are from Kamil Dudka)


mash-0.4.8-1.fc11
-----------------
* Thu Dec 18 17:00:00 2008 Bill Nottingham <notting at redhat.com> 0.4.8-1
- Fix debuginfo exclusion
- Fix --skip-stat with old createrepo
- Use update_from, if it's available


merkaartor-0.12-3.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.12-3
- respin (eviv2)


mingw32-filesystem-41-1.fc11
----------------------------
* Wed Dec 17 17:00:00 2008 Levente Farkas <lfarkas at lfarkas.org> - 41-1
- Re-add mingw32-make


mkinitrd-6.0.73-7.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 6.0.73-7
- Split grubby/new-kernel-pkg into their own package

* Wed Dec 10 17:00:00 2008 Adam Jackson <ajax at redhat.com> 6.0.73-6
- Fix description.


mkvtoolnix-2.4.0-4.fc11
-----------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> 2.4.0-4
- Rebuild for boost-1.37.0.


mono-zeroconf-0.7.6-6.fc11
--------------------------
* Thu Dec 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.7.6-6
- Another fix for x86_64

* Thu Dec 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.7.6-5
- Remove patch file (use sed)
- Additional BRs and Rs

* Thu Dec 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.7.6-4
- remove ppc build for now

* Thu Dec 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.7.6-3
- rebuild (0.8.0 is buggy)

* Thu Aug 14 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.7.6-2
- bump to new version
- libdir clean now


monodevelop-1.9.1-6.pre1.20081218svn121699.fc11
-----------------------------------------------
* Thu Dec 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-6.pre1.20081217svn121699
- Actually use the svn version!

* Wed Dec 17 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-5.pre1.20081217svn121653
- Update

* Tue Dec 16 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-4.pre1.20081216svn121578
- Update

* Sat Nov 29 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-3.pre1
- missed a libdir...

* Sat Nov 29 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-2.pre1
- remove libdir patch, now using sed

* Sun Nov 23 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-1.pre1
- Update to 1.9.1 preview 1
- Removed R mono-basic and vala

* Sat Oct 18 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9-7
- Fix dependancies of R (BZ 467544)


monotorrent-0.62-2.fc11
-----------------------

moodle-1.9.3-4.fc11
-------------------
* Wed Dec 17 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.9.3-4
- Texed fix, BZ 476709.


nautilus-2.25.2-5.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.2-5
- Fix spec

* Thu Dec 18 17:00:00 2008 - Ray Strode <rstrode at redhat.com> - 2.25.2-4
- Add eel crossfade patch


nut-2.2.2-5.fc11
----------------
* Thu Dec 18 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> 2.2.2-5
- remove rpath, fix libtool

* Wed Dec 17 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> 2.2.2-4
- fix #476850 - tripplite_usb driver segfaults when UPS on battery


ochusha-0.5.99.70-0.4.cvs20081218T1500.fc11
-------------------------------------------
* Thu Dec 18 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


perl-IO-AIO-3.17-1.fc11
-----------------------
* Thu Dec 18 17:00:00 2008 Nicolas Chauvet <kwizart at gmail.com> 3.17-1
- Update to 3.17


perl-Padre-0.20-1.fc11
----------------------
* Wed Dec 17 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 0.20-1
- update to 0.20, switch off check of Wx, because unset DISPLAY
     in rpmbuild. V0.21 wasn't package because same problem
     somewhere else in code.


phpPgAdmin-4.2.2-1.fc11
-----------------------
* Fri Dec 19 17:00:00 2008 Devrim Gunduz <devrim at commandprompt.com> 4.2.2-1
- Update to 4.2.2


pingus-0.7.2-4.fc11
-------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 0.7.2-4
- Rebuild for boost-1.37.0.


python-jinja2-2.1-1.fc11
------------------------
* Thu Dec 18 17:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 2.1-1
- Update to 2.1, which fixes a number of bugs.
  See http://jinja.pocoo.org/2/documentation/changelog#version-2-1.


python-rabbyt-0.8.2-8.fc11
--------------------------
* Thu Dec 18 17:00:00 2008 Simon Wesp <cassmodiah at fedoraproject.org> - 0.8.2-8
- Clean specfile
- Correct Requirement(s)
- Remove tests


python-tag-0.94.1-4.fc11
------------------------
* Thu Dec 18 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 0.94.1-4
- Rebuild for boost-1.37.0.


python-transaction-1.0-0.3.a1.fc11
----------------------------------
* Thu Dec 18 17:00:00 2008 Luke Macken <lmacken at redhat.com> - 1.0-0.3.a1
- Fix the license tag


qtpfsgui-1.9.2-3.fc11
---------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.9.2-3
- respin (eviv2)


rawstudio-1.1.1-2.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.1.1-2
- respin (eviv2)


rcsslogplayer-13.1.0-2.fc11
---------------------------
* Thu Dec 18 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.1.0-1
- Updated to the new released version (13.1.0)

* Thu Dec 18 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> 13.1.0-2
- Rebuild for boost-1.37.0.


rcssserver-13.1.0-1.fc11
------------------------
* Thu Dec 18 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.1.0-1
- Bump to 13.1.0 version.


rogue-5.4.5-3.fc11
------------------
* Thu Dec 18 17:00:00 2008 Wart <wart at kobold.org> 5.4.5-3
- Add coreutils requirement for rpm post scripts (BZ #475924)


scons-1.1.0-2.fc11
------------------
* Thu Dec 18 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 1.1.0-1
- new release 1.1.0


setup-2.7.5-3.fc11
------------------
* Thu Dec 18 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2.7.5-3
- add pkiuser (17:17) to uidgid
- temporarily create video/audio group in post section
  (#476886)


snake-0.11-0.11.fc11
--------------------
* Thu Dec 18 17:00:00 2008 James Laska <jlaska at redhat.com> 0.11-0.11
- ticket#64 - only parse kickstarts when requested during snake-ks generate
  (jlaska)

* Fri Aug 29 18:00:00 2008 James Laska <jlaska at redhat.com> 0.11-0.10
- ticket#54 - correct for older grubby that can't handle --title that contains
  spaces (jlaska)
- handle version parsing problems by falling back to "devel" (wwoods)


strigi-0.5.11.1-2.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.5.11.1-2
- respin (eviv2)


sugar-jukebox-6-1.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Sebastian Dziallas <sebastian at when.com> - 6-1
- update to version 6


texlive-texmf-errata-2007-5.fc11
--------------------------------
* Thu Dec 18 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 2007-5
- do own directories properly(#474028)


ularn-1.5p4-12.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Wart <wart at kobold.org> 1.5p4-12
- Add coreutils requirement for rpm post scripts (BZ #475915)


ushare-1.1a-4.fc11
------------------
* Thu Dec 18 17:00:00 2008 Dave Jones <davej at redhat.com>
- Don't trash the ircd pid file when shutting down ushare.


xcb-util-0.3.2-1.fc11
---------------------
* Thu Dec 18 17:00:00 2008 Michal Nowak <mnowak at redhat.com> - 0.3.2-1
- 0.3.2
- remove rpath (x86-64)
- xcb_keysyms: remove xcb_lookup_t
- Revert "keysyms: use xcb_key_lookup_t type for col paramter"
- temporary disabled %check due to RPATH regression


xen-3.3.0-2.fc11
----------------
* Wed Dec 17 17:00:00 2008 Gerd Hoffmann <kraxel at redhat.com> - 3.3.0-2
- build and package stub domains (pvgrub, ioemu).
- backport unstable fixes for pv_ops dom0.


xenwatch-0.5.4-1.fc11
---------------------

xmms2-0.5-3.fc11
----------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 0.5-3
- Rebuild for boost-1.37.0.


xorg-x11-proto-devel-7.4-11.fc11
--------------------------------

yum-3.2.20-8.fc11
-----------------
* Thu Dec 18 17:00:00 2008 James Antill <james at fedoraproject.org> - 3.2.20-8
- merge latest from upstream
- move to 6hr metadata


yum-utils-1.1.19-1.fc11
-----------------------
* Wed Dec 17 17:00:00 2008 Tim Lauridsen <timlau at fedoraproject.org>
- mark as 1.1.19

* Wed Dec 10 17:00:00 2008 Seth Vidal <skvidal at fedoraproject.org>
- add find-repos-of-install from James' stash of misc stuff


Summary:
Added Packages: 8
Removed Packages: 4
Modified Packages: 104
Broken deps for i386
----------------------------------------------------------
	HippoDraw-python-1.21.1-6.fc11.i386 requires libboost_python.so.3
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	avant-window-navigator-0.2.6-13.fc11.i386 requires libgnome-desktop-2.so.10
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	deskbar-applet-2.25.1-5.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	e16-0.16.8.14-1.fc10.i386 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	1:gnome-applets-2.25.1-4.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-launch-box-0.4-12.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gnomedesktop-2.24.0-5.fc11.i386 requires libgnome-desktop-2.so.10
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.i386 requires python(abi) = 0:2.5
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	linkage-0.2.0-3.fc10.i386 requires libboost_thread-mt.so.3
	linkage-0.2.0-3.fc10.i386 requires libboost_date_time-mt.so.3
	linkage-0.2.0-3.fc10.i386 requires libboost_serialization-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mono-sharpcvslib-0.35-3.fc10.i386 requires mono(nunit.framework) = 0:2.2.0.0
	nautilus-python-0.5.1-1.fc10.i386 requires libpython2.5.so.1.0
	nautilus-search-tool-0.2.2-7.fc11.i386 requires libgnome-desktop-2.so.10
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	opencv-python-1.0.0-8.fc10.i386 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.i386 requires libpython2.5.so.1.0
	openvrml-0.17.10-1.0.fc10.i386 requires libboost_thread-mt.so.3
	openvrml-xembed-0.17.10-1.0.fc10.i386 requires libboost_thread-mt.so.3
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	perl-XML-LibXSLT-1.66-2.fc10.i386 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-examples-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_thread-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_filesystem-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_date_time-mt.so.3
	rb_libtorrent-python-0.13.1-5.fc11.i386 requires libboost_python-mt.so.3
	rcssserver3d-0.6-5.fc10.i386 requires libboost_thread-mt.so.3
	rcssserver3d-0.6-5.fc10.i386 requires libboost_regex.so.3
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-search-tool-0.6.6-4.fc11.i386 requires libgnome-desktop-2.so.10
	tsclient-2.0.1-9.fc11.i386 requires libgnome-desktop-2.so.10
	ufraw-0.14.1-3.fc11.i386 requires libexiv2.so.4
	ufraw-cinepaint-0.14.1-3.fc11.i386 requires libexiv2.so.4
	ufraw-gimp-0.14.1-3.fc11.i386 requires libexiv2.so.4
	vegastrike-0.5.0-6.fc11.i386 requires libboost_python.so.3
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	HippoDraw-python-1.21.1-6.fc11.x86_64 requires libboost_python.so.3()(64bit)
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	avant-window-navigator-0.2.6-13.fc11.i386 requires libgnome-desktop-2.so.10
	avant-window-navigator-0.2.6-13.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	banshee-1.4.1-1.fc11.x86_64 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	deskbar-applet-2.25.1-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.x86_64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.i386 requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.x86_64 requires pkgconfig(hal-storage)
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:gnome-applets-2.25.1-4.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-launch-box-0.4-12.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.x86_64 requires python(abi) = 0:2.5
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.x86_64 requires bitstream-vera-fonts
	linkage-0.2.0-3.fc10.i386 requires libboost_thread-mt.so.3
	linkage-0.2.0-3.fc10.i386 requires libboost_date_time-mt.so.3
	linkage-0.2.0-3.fc10.i386 requires libboost_serialization-mt.so.3
	linkage-0.2.0-3.fc10.x86_64 requires libboost_serialization-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.x86_64 requires libboost_date_time-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mono-sharpcvslib-0.35-3.fc10.x86_64 requires mono(nunit.framework) = 0:2.2.0.0
	nautilus-python-0.5.1-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	nautilus-search-tool-0.2.2-7.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	opencv-python-1.0.0-8.fc10.x86_64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	openvrml-0.17.10-1.0.fc10.i386 requires libboost_thread-mt.so.3
	openvrml-0.17.10-1.0.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	openvrml-xembed-0.17.10-1.0.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	perl-XML-LibXSLT-1.66-2.fc10.x86_64 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-2.1.1-5.fc10.x86_64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libboost_signals.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_thread-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_filesystem-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.i386 requires libboost_date_time-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.x86_64 requires libboost_thread-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.x86_64 requires libboost_date_time-mt.so.3()(64bit)
	rb_libtorrent-python-0.13.1-5.fc11.x86_64 requires libboost_python-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.i386 requires libboost_thread-mt.so.3
	rcssserver3d-0.6-5.fc10.i386 requires libboost_regex.so.3
	rcssserver3d-0.6-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.x86_64 requires libboost_regex.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	tsclient-2.0.1-9.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	ufraw-0.14.1-3.fc11.x86_64 requires libexiv2.so.4()(64bit)
	ufraw-cinepaint-0.14.1-3.fc11.x86_64 requires libexiv2.so.4()(64bit)
	ufraw-gimp-0.14.1-3.fc11.x86_64 requires libexiv2.so.4()(64bit)
	vegastrike-0.5.0-6.fc11.x86_64 requires libboost_python.so.3()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	HippoDraw-python-1.21.1-6.fc11.ppc requires libboost_python.so.3
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	avahi-sharp-0.6.24-1.fc11.ppc requires mono-core >= 0:1.1.13
	avahi-sharp-0.6.24-1.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	avahi-sharp-0.6.24-1.fc11.ppc requires mono(System) = 0:1.0.5000.0
	avahi-sharp-0.6.24-1.fc11.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
	avahi-ui-sharp-0.6.24-1.fc11.ppc requires mono-core >= 0:1.1.13
	avahi-ui-sharp-0.6.24-1.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	avahi-ui-sharp-0.6.24-1.fc11.ppc requires mono(System) = 0:1.0.5000.0
	avahi-ui-sharp-0.6.24-1.fc11.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
	avant-window-navigator-0.2.6-13.fc11.ppc requires libgnome-desktop-2.so.10
	avant-window-navigator-0.2.6-13.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Zeroconf) = 0:1.0.0.75
	banshee-1.4.1-1.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Cairo) = 0:2.0.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(ICSharpCode.SharpZipLib) = 0:2.84.0.0
	banshee-1.4.1-1.fc11.ppc requires mono(System) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires libmono.so.0
	beagle-0.3.8-16.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires libmono.so.0(VER_1)
	beagle-0.3.8-16.fc11.ppc requires mono(Mono.Data.Sqlite) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(ICSharpCode.SharpZipLib) = 0:2.84.0.0
	beagle-0.3.8-16.fc11.ppc requires mono(System) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(Mono.Data.Sqlite) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	beagle-evolution-0.3.8-16.fc11.ppc requires mono(System) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(Mono.Cairo) = 0:2.0.0.0
	beagle-gnome-0.3.8-16.fc11.ppc requires mono(System) = 0:2.0.0.0
	beagle-thunderbird-0.3.8-16.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	beagle-thunderbird-0.3.8-16.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	beagle-thunderbird-0.3.8-16.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	beagle-thunderbird-0.3.8-16.fc11.ppc requires mono(System) = 0:2.0.0.0
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-4.fc10.ppc requires mono-web
	bless-0.6.0-1.fc10.ppc requires mono-core
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	cdcollect-0.6.0-6.fc10.ppc requires mono-core >= 0:1.1.17
	cdcollect-0.6.0-6.fc10.ppc requires mono-data-sqlite
	cowbell-0.3-0.svn34.4.fc10.ppc requires mono-core
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(System.Drawing) = 0:2.0.0.0
	db4o-6.1-4.fc9.ppc requires mono(mscorlib) = 0:2.0.0.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	db4o-6.1-4.fc9.ppc requires mono(Mono.GetOptions) = 0:2.0.0.0
	db4o-6.1-4.fc9.ppc requires mono(System) = 0:2.0.0.0
	dbus-sharp-0.63-10.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	deskbar-applet-2.25.1-5.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.ppc requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	evolution-sharp-0.18.1-1.fc10.ppc requires mono(System) = 0:1.0.5000.0
	evolution-sharp-0.18.1-1.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc requires pkgconfig(hal-storage)
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	f-spot-0.5.0.3-5.fc11.ppc requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System) = 0:1.0.5000.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(Mono.Cairo) = 0:2.0.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(ICSharpCode.SharpZipLib) = 0:2.84.0.0
	f-spot-0.5.0.3-5.fc11.ppc requires mono(System) = 0:2.0.0.0
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gbrainy-1.00-3.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	gbrainy-1.00-3.fc11.ppc requires mono(Mono.Cairo) = 0:2.0.0.0
	gbrainy-1.00-3.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	gbrainy-1.00-3.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	gbrainy-1.00-3.fc11.ppc requires mono(System) = 0:2.0.0.0
	gecko-sharp2-0.13-2.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gmime-sharp-2.4.3-2.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	1:gnome-applets-2.25.1-4.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-desktop-sharp-2.24.0-3.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gnome-desktop-sharp-2.24.0-3.fc10.ppc requires mono(Mono.Cairo) = 0:1.0.5000.0
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-do-0.6.1.0-2.fc10.ppc requires mono-core
	gnome-do-0.6.1.0-2.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	gnome-do-0.6.1.0-2.fc10.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	gnome-do-0.6.1.0-2.fc10.ppc requires mono(System) = 0:2.0.0.0
	gnome-keyring-sharp-1.0.0-0.2.87622svn.fc10.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	gnome-keyring-sharp-1.0.0-0.2.87622svn.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	gnome-keyring-sharp-1.0.0-0.2.87622svn.fc10.ppc requires mono(System) = 0:2.0.0.0
	gnome-launch-box-0.4-12.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-sharp-2.24.0-1.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gnome-subtitles-0.8-6.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	gnome-subtitles-0.8-6.fc10.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	gnome-subtitles-0.8-6.fc10.ppc requires mono(System) = 0:2.0.0.0
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	graphviz-sharp-2.20.3-1.fc11.1.ppc requires mono-core
	gsf-sharp-0.8.1-8.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gtk-sharp2-2.12.5-2.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	gtk-sharp2-2.12.5-2.fc11.ppc requires mono(Mono.Cairo) = 0:1.0.5000.0
	gtk-sharp2-2.12.5-2.fc11.ppc requires mono(System) = 0:1.0.5000.0
	gtk-sharp2-2.12.5-2.fc11.ppc requires mono(System.Drawing) = 0:1.0.5000.0
	gtksourceview2-sharp-1.0-2.svn89788.2.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	ice-csharp-3.3.0-9.fc11.ppc requires mono-core >= 0:1.2.2
	ice-csharp-3.3.0-9.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	ice-csharp-3.3.0-9.fc11.ppc requires mono(System) = 0:2.0.0.0
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	ipa-client-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc requires python(abi) = 0:2.5
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:2.84.0.0
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(System.Xml) = 0:2.0.0.0
	ipod-sharp-0.8.1-1.fc10.ppc requires mono(System) = 0:2.0.0.0
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	lat-1.2.3-5.fc11.ppc requires mono-data
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.ppc requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	linkage-0.2.0-3.fc10.ppc requires libboost_thread-mt.so.3
	linkage-0.2.0-3.fc10.ppc requires libboost_date_time-mt.so.3
	linkage-0.2.0-3.fc10.ppc requires libboost_serialization-mt.so.3
	linkage-0.2.0-3.fc10.ppc64 requires libboost_serialization-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mod_mono-2.2-1.pre1.fc11.ppc requires mono-core
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(System.Xml) = 0:1.0.5000.0
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(System) = 0:1.0.5000.0
	mono-addins-0.3.1-2.2.fc10.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
	mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.9.0
	mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
	monodoc-2.0-5.fc10.ppc requires mono(System.Web) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono-core
	monodoc-2.0-5.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono(System.Xml) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono(System) = 0:1.0.5000.0
	monodoc-2.0-5.fc10.ppc requires mono(System.Web.Services) = 0:1.0.5000.0
	monosim-1.3.0.2-1.fc9.1.ppc requires mono-core >= 0:1.2.3
	monosim-1.3.0.2-1.fc9.1.ppc requires mono-web >= 0:1.2.3
	muine-0.8.10-3.fc11.ppc requires mono-core
	muine-0.8.10-3.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	muine-0.8.10-3.fc11.ppc requires mono-web
	muine-0.8.10-3.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	nautilus-python-0.5.1-1.fc10.ppc requires libpython2.5.so.1.0
	nautilus-search-tool-0.2.2-7.fc11.ppc requires libgnome-desktop-2.so.10
	ndesk-dbus-0.6.1a-2.fc9.ppc requires mono-core
	ndesk-dbus-0.6.1a-2.fc9.ppc requires mono(mscorlib) = 0:2.0.0.0
	ndesk-dbus-0.6.1a-2.fc9.ppc requires mono(System.Xml) = 0:2.0.0.0
	ndesk-dbus-0.6.1a-2.fc9.ppc requires mono(System) = 0:2.0.0.0
	ndesk-dbus-glib-0.4.1-3.fc9.ppc requires mono(mscorlib) = 0:2.0.0.0
	notify-sharp-0.4.0-0.5.20080912svn.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	opencv-python-1.0.0-8.fc10.ppc requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc requires libpython2.5.so.1.0
	openvrml-0.17.10-1.0.fc10.ppc requires libboost_thread-mt.so.3
	openvrml-0.17.10-1.0.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	openvrml-xembed-0.17.10-1.0.fc10.ppc requires libboost_thread-mt.so.3
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	perl-XML-LibXSLT-1.66-2.fc10.ppc requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc requires libboost_signals.so.3
	player-2.1.1-5.fc10.ppc requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libboost_thread-mt.so.3
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-examples-2.1.1-5.fc10.ppc requires libboost_signals.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	podsleuth-0.6.3-1.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	podsleuth-0.6.3-1.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	podsleuth-0.6.3-1.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	podsleuth-0.6.3-1.fc11.ppc requires mono(System) = 0:2.0.0.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc requires libboost_thread-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.ppc requires libboost_filesystem-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.ppc requires libboost_date_time-mt.so.3
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	rb_libtorrent-python-0.13.1-5.fc11.ppc requires libboost_python-mt.so.3
	rcssserver3d-0.6-5.fc10.ppc requires libboost_thread-mt.so.3
	rcssserver3d-0.6-5.fc10.ppc requires libboost_regex.so.3
	rcssserver3d-0.6-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.ppc64 requires libboost_regex.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	sublib-0.9-2.fc10.ppc requires mono(mscorlib) = 0:2.0.0.0
	sublib-0.9-2.fc10.ppc requires mono(System) = 0:2.0.0.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	taglib-sharp-2.0.3.0-7.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	tasque-0.1.7-3.fc9.ppc requires mono-core
	themonospot-0.7.1.1-1.fc10.ppc requires mono-core >= 0:1.2.3
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc requires libgnome-desktop-2.so.10
	tsclient-2.0.1-9.fc11.ppc requires libgnome-desktop-2.so.10
	ufraw-0.14.1-3.fc11.ppc requires libexiv2.so.4
	ufraw-cinepaint-0.14.1-3.fc11.ppc requires libexiv2.so.4
	ufraw-gimp-0.14.1-3.fc11.ppc requires libexiv2.so.4
	vegastrike-0.5.0-6.fc11.ppc requires libboost_python.so.3
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts
	xsp-2.2-1.pre1.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Security) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono-core >= 0:2.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Configuration) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Security) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Posix) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Xml) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Data) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Xml) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Web.Services) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System.Web) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(Mono.Data.SqliteClient) = 0:1.0.5000.0
	xsp-2.2-1.pre1.fc11.ppc requires mono(System) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Data) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Web) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Web) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(mscorlib) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Xml) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(Mono.Data.SqliteClient) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Data) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System) = 0:1.0.5000.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System) = 0:2.0.0.0
	xsp-tests-2.2-1.pre1.fc11.ppc requires mono(System.Web.Services) = 0:1.0.5000.0



Broken deps for ppc64
----------------------------------------------------------
	HippoDraw-python-1.21.1-6.fc11.ppc64 requires libboost_python.so.3()(64bit)
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	avant-window-navigator-0.2.6-13.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	deskbar-applet-2.25.1-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.ppc64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	exo-devel-0.3.4-4.fc11.ppc64 requires pkgconfig(hal-storage)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:gnome-applets-2.25.1-4.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-launch-box-0.4-12.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	ipa-client-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-python-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	ipa-server-1.2.0-3.fc11.ppc64 requires python(abi) = 0:2.5
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	linkage-0.2.0-3.fc10.ppc64 requires libboost_serialization-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	linkage-0.2.0-3.fc10.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	nautilus-python-0.5.1-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	nautilus-search-tool-0.2.2-7.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires python(abi) = 0:2.5
	opencv-python-1.0.0-8.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	openvrml-0.17.10-1.0.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	openvrml-xembed-0.17.10-1.0.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Data-TreeDumper-Renderer-GTK-0.02-3.fc11.noarch requires perl(Gtk2::TreeView)
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	perl-XML-LibXSLT-1.66-2.fc10.ppc64 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_thread-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	rb_libtorrent-0.13.1-5.fc11.ppc64 requires libboost_date_time-mt.so.3()(64bit)
	rb_libtorrent-python-0.13.1-5.fc11.ppc64 requires libboost_python-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	rcssserver3d-0.6-5.fc10.ppc64 requires libboost_regex.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	tsclient-2.0.1-9.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	ufraw-0.14.1-3.fc11.ppc64 requires libexiv2.so.4()(64bit)
	ufraw-cinepaint-0.14.1-3.fc11.ppc64 requires libexiv2.so.4()(64bit)
	ufraw-gimp-0.14.1-3.fc11.ppc64 requires libexiv2.so.4()(64bit)
	vegastrike-0.5.0-6.fc11.ppc64 requires libboost_python.so.3()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts





From debarshi.ray at gmail.com  Fri Dec 19 11:06:16 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 19 Dec 2008 16:36:16 +0530
Subject: rawhide report: 20081219 changes
In-Reply-To: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
Message-ID: <3170f42f0812190306ub740cf8x2998b8577e69c4f1@mail.gmail.com>

The Anjuta breakage was caused by the new Glade 3.5.4 that was built
yesterday. Both packages are owned by me, and I will take care of
Anjuta.

Cheers,
Debarshi



From paul at all-the-johnsons.co.uk  Fri Dec 19 11:06:37 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 19 Dec 2008 11:06:37 +0000
Subject: Strange mono problem with ppc
Message-ID: <1229684798.10450.47.camel@PB3.Linux>

Hi,

I've just checked the development part for ppc and there is nothing
there for the main mono parts (such as mono-core etc) which means it's
impossible to build anything for mono on ppc.

Shouldn't they have been moved over from f10 to devel when we branched?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/bebb207a/attachment.sig>

From opensource at till.name  Fri Dec 19 11:06:38 2008
From: opensource at till.name (Till Maas)
Date: Fri, 19 Dec 2008 12:06:38 +0100
Subject: GNOME menu ugliness - Name/GenericName
In-Reply-To: <20081219114753.e9588d0b.mschwendt@gmail.com>
References: <20081219114753.e9588d0b.mschwendt@gmail.com>
Message-ID: <200812191206.53541.opensource@till.name>

On Fri December 19 2008, Michael Schwendt wrote:

> Is this still the case? - Seems so. GNOME here only shows the Name=
> entries. How does KDE handle this?

KDE 4 shows the GenericName in big letters and when the mouse pointer is above 
one entry, the Name is also shown in smaller letters below the GenericName. 
Imho it is very convinient and not ugly.

> Why do we have a policy on "correct usage" of Name/GenericName that would
> make the menus look ugly. It's not just the mix of Name/GenericName in

A screenshot may help to understand, how ugly it looks in Gnome. Here is a 
Screenshot from KDE:

http://till.fedorapeople.org/tmp/KDE-GenericName.png

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/d6269ac3/attachment.sig>

From dr.diesel at gmail.com  Fri Dec 19 11:09:24 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Fri, 19 Dec 2008 06:09:24 -0500
Subject: Amarok 2 on F9
In-Reply-To: <8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gieuf2$uok$1@ger.gmane.org>
	<8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
Message-ID: <2a28d2ab0812190309t54ccd219i49a16ea73f2dca25@mail.gmail.com>

2008/12/18 Oscar<Soker> <sokerlp at gmail.com>

> Plz don't do that, Amarok 2 is not as goog as Amarok 1.4 it loose a lot of
> functionality
>
> Atentamente Oscar:



We really need both until the issues with 2.0 are sorted out.



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/a1a3d7f6/attachment.htm>

From paul at all-the-johnsons.co.uk  Fri Dec 19 11:12:13 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 19 Dec 2008 11:12:13 +0000
Subject: rawhide report: 20081219 changes
In-Reply-To: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
Message-ID: <1229685133.10450.49.camel@PB3.Linux>

Hi,

> 	mod_mono-2.2-1.pre1.fc11.ppc requires mono-core
> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(System.Xml) = 0:1.0.5000.0
> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(System) = 0:1.0.5000.0
> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
> 	mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.9.0
> 	mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
> 	monodoc-2.0-5.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
> 	monodoc-2.0-5.fc10.ppc requires mono(System.Web) = 0:1.0.5000.0
> 	monodoc-2.0-5.fc10.ppc requires mono-core
> 	monodoc-2.0-5.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
> 	monodoc-2.0-5.fc10.ppc requires mono(System.Xml) = 0:1.0.5000.0
> 	monodoc-2.0-5.fc10.ppc requires mono(System) = 0:1.0.5000.0
> 	monodoc-2.0-5.fc10.ppc requires mono(System.Web.Services) = 0:1.0.5000.0

I've committed a fix which means I should be able to get these fixed
today, however the ppc buildroot doesn't seem to have mono in it!

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/a1833088/attachment.sig>

From alexl at redhat.com  Fri Dec 19 11:12:56 2008
From: alexl at redhat.com (Alexander Larsson)
Date: Fri, 19 Dec 2008 12:12:56 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
Message-ID: <1229685176.1599.35.camel@fatty>

On Fri, 2008-12-19 at 03:16 +0100, Mark wrote:

> So in short. as long as the nautilus creator is also the maintainer
> and the inventor of spatial we probably won't see this default
> behaviour change. very sad but true!

I don't understand this harsh reaction. Yes, I am the maintainer of
natilus, yes I am the primary developer of nautilus for at least the
last 5 years. Yes, I am the packager of nautilus in fedora. Yes, I
implemented (not invented!) spatial mode in nautilus, for the reason
that I think its a good UI model for a file manager, especially one
targeted towards non-computer-experts like nautilus.

However, I don't think spatial mode is always what you want, so nautilus
also has the browser, always availible in the spatial window menus and
in the panel menu, if you want to do something where it is more in line
with what you want. Its not an afterthought either, we maintain it and
add features to it. And, we also have a UI preference to totally turn
off spatial mode for those that don't like it. 

The question is, why are you so persistant about pushing your
preferences on everyone. You think I'm a fucking nuthole to have picked
spatial as the default, yet you think you should decide what the default
should be. Thats as much a decision as what I've done and the people who
dislike it will write long tirades about how you're a fucking nuthole,
how they are gonna leave/fork gnome/fedora etc. Yes, it is possible to
have a discussion of what the defaults should be, but it should be a
sane one with less emotions, no namecalling, a realization that someone
else (who spent many many years working on the piece of software) may
have a valid opinion, and a genuine interest in finding out the
reasoning behind the various options.

I have been convinced to change my mind by such discussions before, so
I'm not just blocking other peoples ideas. Of course, your random
rantings and namecallings don't exactly make me interested in having a
discussion with you.




From kevin.kofler at chello.at  Fri Dec 19 11:23:23 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 12:23:23 +0100
Subject: GNOME menu ugliness - Name/GenericName
References: <20081219114753.e9588d0b.mschwendt@gmail.com>
Message-ID: <gig07b$iu4$1@ger.gmane.org>

Michael Schwendt wrote:
> Is this still the case? - Seems so. GNOME here only shows the Name=
> entries. How does KDE handle this?

It shows both, in different styles depending on whether you use Kickoff or
the classic menu. (Kickoff defaults to showing mainly the GenericName and
the Name on mouseover, classic defaults to showing both next to each other.
Of course if there's only Name, only Name will be displayed (which means
that if you fill in the generic name as "Name", the real name will be
missing).)

> Why do we have a policy on "correct usage" of Name/GenericName that would
> make the menus look ugly.

Because the "incorrect" usage (which is sadly still used in quite a few
GNOME apps) makes the KDE menus look ugly. Not all the world uses GNOME.

> It's not just the mix of Name/GenericName in there, it confuses users, who
> are not familiar with application names.

Filling in only a generic name confuses the users who _are_ familiar with
application names. The proper solution is to fix GNOME to do something
useful with GenericName.

> I would like to violate the guidelines and put GenericName as Name to
> escape from this.

Please don't. You'll break things for KDE users if you do (and yes, we're
still fighting to get the remaining offenders fixed - please don't add to
the problem).

        Kevin Kofler



From pbrobinson at gmail.com  Fri Dec 19 11:36:41 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 19 Dec 2008 12:36:41 +0100
Subject: GNOME menu ugliness - Name/GenericName
In-Reply-To: <20081219114753.e9588d0b.mschwendt@gmail.com>
References: <20081219114753.e9588d0b.mschwendt@gmail.com>
Message-ID: <5256d0b0812190336l6870f0cehc37194f39eb86a85@mail.gmail.com>

On Fri, Dec 19, 2008 at 11:47 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
> What is the "correct usage" of Name/GenericName in Fedora Land?

There was a discussion about this September last year, not sure what
the resolution is though.

Peter



From mmaslano at redhat.com  Fri Dec 19 11:40:55 2008
From: mmaslano at redhat.com (Marcela Maslanova)
Date: Fri, 19 Dec 2008 12:40:55 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229685176.1599.35.camel@fatty>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494AEEAA.3090608@kanarip.com>	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
Message-ID: <494B8847.7040209@redhat.com>

Alexander Larsson wrote:
> On Fri, 2008-12-19 at 03:16 +0100, Mark wrote:
> 
>> So in short. as long as the nautilus creator is also the maintainer
>> and the inventor of spatial we probably won't see this default
>> behaviour change. very sad but true!
> 
> I don't understand this harsh reaction. Yes, I am the maintainer of
Exactly. I'm surprised about all those harsh words. This is development
discussion so please stay calm and polite. Telling of to a maintainer
even before discussing issue with him is quite rude.

-- 
Marcela Ma?l??ov?
BaseOS team Brno



From mschwendt at gmail.com  Fri Dec 19 11:40:34 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 19 Dec 2008 12:40:34 +0100
Subject: rawhide report: 20081219 changes
In-Reply-To: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
Message-ID: <20081219124034.49c5cd5c.mschwendt@gmail.com>

On Fri, 19 Dec 2008 10:48:38 +0000 (UTC), Rawhide wrote:

> geeqie-1.0-0.11.alpha2.1299svn.fc11
> -----------------------------------
> * Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0-0.9.alpha2
> - respin (exiv2)
> 
> * Thu Dec 18 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.0-0.11.alpha2.1299svn
> - drop desktop file Exec= invocation patch (no longer necessary)
> 
> * Thu Dec 18 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.0-0.10.alpha2.1299svn
> - update to svn 1299 for new exiv2
> - disable LIRC support which is broken

The incorrect sorting is a bug in createrepo. The changelog entries need to stay
in order, as they cannot be sorted by timestamp. The timestamps refer to full days
lacking hours/mins/secs details.

repodiff can't fix this. I've had a look. It sorts the changelog entries
by timestamp, which is another bug (= probably an attempt at trying
to work around the createrepo bug).

Printing only the date can be done with attached patch, however.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repodiff-date.patch
Type: application/octet-stream
Size: 1219 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/8f92641f/attachment.obj>

From paul at city-fan.org  Fri Dec 19 11:51:24 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 19 Dec 2008 11:51:24 +0000
Subject: rawhide report: 20081219 changes
In-Reply-To: <1229685133.10450.49.camel@PB3.Linux>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
	<1229685133.10450.49.camel@PB3.Linux>
Message-ID: <494B8ABC.2000709@city-fan.org>

Paul wrote:
> Hi,
> 
>> 	mod_mono-2.2-1.pre1.fc11.ppc requires mono-core
>> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
>> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
>> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(System.Xml) = 0:1.0.5000.0
>> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(System) = 0:1.0.5000.0
>> 	mono-addins-0.3.1-2.2.fc10.ppc requires mono(Mono.Posix) = 0:1.0.5000.0
>> 	mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.9.0
>> 	mono-cecil-flowanalysis-0.1-0.7.20080409svn100264.fc11.ppc requires mono(mscorlib) = 0:1.0.5000.0
>> 	monodoc-2.0-5.fc10.ppc requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
>> 	monodoc-2.0-5.fc10.ppc requires mono(System.Web) = 0:1.0.5000.0
>> 	monodoc-2.0-5.fc10.ppc requires mono-core
>> 	monodoc-2.0-5.fc10.ppc requires mono(mscorlib) = 0:1.0.5000.0
>> 	monodoc-2.0-5.fc10.ppc requires mono(System.Xml) = 0:1.0.5000.0
>> 	monodoc-2.0-5.fc10.ppc requires mono(System) = 0:1.0.5000.0
>> 	monodoc-2.0-5.fc10.ppc requires mono(System.Web.Services) = 0:1.0.5000.0
> 
> I've committed a fix which means I should be able to get these fixed
> today, however the ppc buildroot doesn't seem to have mono in it!

It would appear that the last update of the main mono package didn't 
build successfully in koji and/or make it into rawhide:

%changelog
* Fri Dec 19 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 
2.2-13.pre3.20081219svn121833
- Lots more fixes
- New patch for ppc archs
- Re-enable ppc build

* Wed Dec 17 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 
2.2-12.pre3.20081217svn121664
- Fix libdir issue with monodoc

* Tue Dec 16 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 
2.2-11.pre3.20081216svn121605
- Fixes problems with web references
- Fixes x86_64 build problems
- Added new web-devel subpackage

$ koji latest-pkg dist-f11 mono
Build                                     Tag                   Built by
----------------------------------------  -------------------- 
----------------
mono-2.2-12.pre3.20081217svn121664.fc11   dist-f11              pfj

So the build that would have re-enabled ppc support didn't make it.

Paul.



From paul at all-the-johnsons.co.uk  Fri Dec 19 11:58:09 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 19 Dec 2008 11:58:09 +0000
Subject: rawhide report: 20081219 changes
In-Reply-To: <494B8ABC.2000709@city-fan.org>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
	<1229685133.10450.49.camel@PB3.Linux> <494B8ABC.2000709@city-fan.org>
Message-ID: <1229687889.10450.55.camel@PB3.Linux>

Hi,

> > I've committed a fix which means I should be able to get these fixed
> > today, however the ppc buildroot doesn't seem to have mono in it!
> 
> It would appear that the last update of the main mono package didn't 
> build successfully in koji and/or make it into rawhide:
> 
> %changelog
> * Fri Dec 19 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 
> 2.2-13.pre3.20081219svn121833

True, however, until there is a successful build, the last version
should remain there. There isn't even an f10 version in the rawhide
buildroot.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/0c6506b8/attachment.sig>

From dex.mbox at googlemail.com  Fri Dec 19 12:24:43 2008
From: dex.mbox at googlemail.com (dexter)
Date: Fri, 19 Dec 2008 12:24:43 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <giepf5$i12$1@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc> <giepf5$i12$1@ger.gmane.org>
Message-ID: <a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>

2008/12/19 Kevin Kofler <kevin.kofler at chello.at>:
> Matthias Clasen wrote:
>> We don't do votes on things like this.
>
> If only there was a GNOME SIG with community involvement, where all the
> maintainers of GNOME and closely-related packages (also implying: if GNOME
> packages actually _had_ community comaintainers...) were represented, with
> public meetings also followed by triagers, documentation writers and
> interested users, that would be a good place to hold a vote (among the
> maintainers), also showing some transparency and providing an incentive to
> get involved. Now where did I get this idea from? ;-)
>
>        Kevin Kofler

SILENCE! lest the people rise up and take back what is rightfully theirs.

Hey mark build it how you want it put it in a repo and the people will
come, then start a UNLEASH GNOME CAMPAIGN

...dex



From ml at bendler-net.de  Fri Dec 19 12:29:22 2008
From: ml at bendler-net.de (Thomas Bendler)
Date: Fri, 19 Dec 2008 13:29:22 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081218215107.GB1366434@hiwaay.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<20081218215107.GB1366434@hiwaay.net>
Message-ID: <e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>

On Thu, Dec 18, 2008 at 10:51 PM, Chris Adams <cmadams at hiwaay.net> wrote:

> Once upon a time, Mark <markg85 at gmail.com> said:
> [...]
>
Web and/or mailing list votes, petitions, etc., are not in any way a
> true representation of any user base, so don't count 5 whole votes as
> "the users".


Sorry, but this is nonsens. If a lot of people (and it is almost a lot more
than five) think that it is a good idea to switch to browser mode, what
indeed it is, there should be a process of thinking as a result if might be
smart to change. Saying that the form of the request as a voting is crap is
useless. The current behavior is far away from modern design and should be
changed quickly. If you like a different way of requesting features like
this, make a proposal on how to do it or point to the correct location in
the documentation but replies like this are only showing ignorance.

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/9bd455b4/attachment.htm>

From paul at city-fan.org  Fri Dec 19 12:39:08 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 19 Dec 2008 12:39:08 +0000
Subject: rawhide report: 20081219 changes
In-Reply-To: <1229687889.10450.55.camel@PB3.Linux>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>	<1229685133.10450.49.camel@PB3.Linux>
	<494B8ABC.2000709@city-fan.org>
	<1229687889.10450.55.camel@PB3.Linux>
Message-ID: <494B95EC.5000601@city-fan.org>

Paul wrote:
> Hi,
> 
>>> I've committed a fix which means I should be able to get these fixed
>>> today, however the ppc buildroot doesn't seem to have mono in it!
>> It would appear that the last update of the main mono package didn't 
>> build successfully in koji and/or make it into rawhide:
>>
>> %changelog
>> * Fri Dec 19 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 
>> 2.2-13.pre3.20081219svn121833
> 
> True, however, until there is a successful build, the last version
> should remain there. There isn't even an f10 version in the rawhide
> buildroot.

The last successful build of mono was 
2.2-12.pre3.20081217svn121664.fc11, which excluded ppc, hence there is 
no mono in the ppc buildroot.

I guess it'll need bootstrapping again now. Or maybe rel-eng can use an 
override to put an old one back in?

Paul.



From alsadi at gmail.com  Fri Dec 19 12:38:33 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 19 Dec 2008 14:38:33 +0200
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<20081218215107.GB1366434@hiwaay.net>
	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>
Message-ID: <385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>

I said
> 1. provide a patch that make shift-double click opens in a new window
> 2. upstream the patch
> 3. make browser mode to be the default because the usability issue is solved

it seems that I was sleeping

1 and 2 are already done
so the usability issue is fixed in browser mode

document shift+double click to open in a new window with more emphasis
and make it the default

why spatial mode was introduced ?
to make drag and drop easy

the question now does people drag and drop more than they browse [open
folder to see them] ?



From markg85 at gmail.com  Fri Dec 19 12:42:48 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 13:42:48 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <28c555e2af7bce3d43b2c4c9e99958af.squirrel@mail.shredzone.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<28c555e2af7bce3d43b2c4c9e99958af.squirrel@mail.shredzone.net>
Message-ID: <6e24a8e80812190442i3c9ad67cw50ee0eb501b875b2@mail.gmail.com>

On Fri, Dec 19, 2008 at 10:32 AM, Richard K?rber <fedora at ml.shredzone.de> wrote:
>
>> A new window for each folder that i open is so painful!!
>> 1. My taskbar fills up in notime each time i open a new folder
>
> Just double-click a folder with the middle mouse button.
>
>> 2. New features of nautilus: tabbed browsing! completely useless if
>> your not using the browser mode
>> 3. Tabbed browsing (files/folders or web) is "hot" these days
>
> The browser already clutters its window with a lot toolbars, buttons and
> gadgets. With tabs it clutters the window even more.
>
>> 4. It feels so.. old (windows 95? 3.11?)
>
> The browser view feels so... Windows XP.
>
> But seriously, who cares? If you dislike the folder/browser view, just
> configure it the way you like it. How often do you need to reconfigure
> your Gnome? My Gnome settings are a couple of years old now.
>
then you keep your dist long. i mostly install (or re-install) my
linux once every 2 months on several pc's and that's to try out new
releases of various distributions.
then changing the same things all over again (going that way for years
now) is getting irritating.

> Regards

Mark



From mschwendt at gmail.com  Fri Dec 19 12:48:34 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 19 Dec 2008 13:48:34 +0100
Subject: GNOME menu ugliness - Name/GenericName
In-Reply-To: <gig07b$iu4$1@ger.gmane.org>
References: <20081219114753.e9588d0b.mschwendt@gmail.com>
	<gig07b$iu4$1@ger.gmane.org>
Message-ID: <20081219134834.6f95fcb2.mschwendt@gmail.com>

On Fri, 19 Dec 2008 12:23:23 +0100, Kevin wrote:

> (and yes, we're
> still fighting to get the remaining offenders fixed - please don't add to
> the problem).

This is just dull. :(


The pop-up help in GNOME panel is affected, too, because it prints the
"Comment" entry under the "Name" entry:

---------------------
Firefox Web Browser
Browse the Web
---------------------

---------------------
Emacs Text Editor
Edit text
---------------------

---------------------
DDD Debugger
Data Display Debugger
---------------------

to give a few examples.



From hughsient at gmail.com  Fri Dec 19 12:49:12 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 19 Dec 2008 12:49:12 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812190442i3c9ad67cw50ee0eb501b875b2@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<28c555e2af7bce3d43b2c4c9e99958af.squirrel@mail.shredzone.net>
	<6e24a8e80812190442i3c9ad67cw50ee0eb501b875b2@mail.gmail.com>
Message-ID: <1229690952.3971.36.camel@hughsie-work.lan>

On Fri, 2008-12-19 at 13:42 +0100, Mark wrote:
> then you keep your dist long. i mostly install (or re-install) my
> linux once every 2 months on several pc's and that's to try out new
> releases of various distributions.

You can keep your home directory on another partition. You just
nuke /boot and / and just point the installer at /home (but don't format
it). I've been doing that for years.

Richard.




From fedora at ml.shredzone.de  Fri Dec 19 12:51:41 2008
From: fedora at ml.shredzone.de (Richard =?iso-8859-1?Q?K=F6rber?=)
Date: Fri, 19 Dec 2008 13:51:41 +0100 (CET)
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812190442i3c9ad67cw50ee0eb501b875b2@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<28c555e2af7bce3d43b2c4c9e99958af.squirrel@mail.shredzone.net>
	<6e24a8e80812190442i3c9ad67cw50ee0eb501b875b2@mail.gmail.com>
Message-ID: <e319a0f3ea18156856d255a1e0a53ffb.squirrel@mail.shredzone.net>


> then you keep your dist long.

Nope. I just keep my /home partition. :-)

Regards
-- 
Richard K?rber



From ml at bendler-net.de  Fri Dec 19 12:52:54 2008
From: ml at bendler-net.de (Thomas Bendler)
Date: Fri, 19 Dec 2008 13:52:54 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229685176.1599.35.camel@fatty>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
Message-ID: <e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>

Hi Alex,

On Fri, Dec 19, 2008 at 12:12 PM, Alexander Larsson <alexl at redhat.com>wrote:
>
> [...]
> I don't understand this harsh reaction. Yes, I am the maintainer of
> natilus, yes I am the primary developer of nautilus for at least the
> last 5 years. Yes, I am the packager of nautilus in fedora. Yes, I
> implemented (not invented!) spatial mode in nautilus, for the reason
> that I think its a good UI model for a file manager, especially one
> targeted towards non-computer-experts like nautilus.


that's as you said your opinion but there might be a reason from a UI design
point of view why nearly no other distribution nor other operating systems
(like our friends from Redmond and they've done back in 3.11) use the
spatial mode. Please don't understand this personal, I simply think ...

[...]
> The question is, why are you so persistant about pushing your
> preferences on everyone. You think I'm a fucking nuthole to have picked


... that the majority of people don't use this mode. Again, this not
personal and no one think that you are "nuthole" (at least I think that no
one think this :)). It's just looking at other distributions and operating
systems which all don't use this mode, so I think there is at least the need
of a discussion about it. Maybe we have UI experts on this list who can
provide us with details about the UI research and what they think might be a
smart approach.

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/42007e77/attachment.htm>

From paul at all-the-johnsons.co.uk  Fri Dec 19 12:55:23 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 19 Dec 2008 12:55:23 +0000
Subject: rawhide report: 20081219 changes
In-Reply-To: <494B95EC.5000601@city-fan.org>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
	<1229685133.10450.49.camel@PB3.Linux> <494B8ABC.2000709@city-fan.org>
	<1229687889.10450.55.camel@PB3.Linux> <494B95EC.5000601@city-fan.org>
Message-ID: <1229691323.10450.58.camel@PB3.Linux>

Hi,

> > True, however, until there is a successful build, the last version
> > should remain there. There isn't even an f10 version in the rawhide
> > buildroot.
> 
> The last successful build of mono was 
> 2.2-12.pre3.20081217svn121664.fc11, which excluded ppc, hence there is 
> no mono in the ppc buildroot.

Surely though if something is excluded, the version in the excluded arch
should not be touched?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/caf9ec07/attachment.sig>

From alexl at users.sourceforge.net  Fri Dec 19 12:59:16 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Fri, 19 Dec 2008 05:59:16 -0700
Subject: boost rebuild status
In-Reply-To: <20081218011435.03690d24@balbo.artheist.org> (Benjamin Kosnik's
	message of "Thu\, 18 Dec 2008 01\:14\:35 -0800")
References: <20081218011435.03690d24@balbo.artheist.org>
Message-ID: <y68wqcb9sr.fsf@allele2.eebweb.arizona.edu>


> Rebuilding dependent packages for boost is progressing relatively
> smoothly. Here's an update on boost rebuilds for the second half of the
> deps list: hopefully Petr will update from the top.

> Here's a list of some of the deps with status:

[...]

> Miro-0:1.2.7-2.fc10.x86_64

Miro rebuilt:

https://koji.fedoraproject.org/koji/buildinfo?buildID=75544

Alex



From paul at city-fan.org  Fri Dec 19 13:02:01 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 19 Dec 2008 13:02:01 +0000
Subject: rawhide report: 20081219 changes
In-Reply-To: <1229691323.10450.58.camel@PB3.Linux>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>	<1229685133.10450.49.camel@PB3.Linux>
	<494B8ABC.2000709@city-fan.org>	<1229687889.10450.55.camel@PB3.Linux>
	<494B95EC.5000601@city-fan.org>
	<1229691323.10450.58.camel@PB3.Linux>
Message-ID: <494B9B49.3050202@city-fan.org>

Paul wrote:
> Hi,
> 
>>> True, however, until there is a successful build, the last version
>>> should remain there. There isn't even an f10 version in the rawhide
>>> buildroot.
>> The last successful build of mono was 
>> 2.2-12.pre3.20081217svn121664.fc11, which excluded ppc, hence there is 
>> no mono in the ppc buildroot.
> 
> Surely though if something is excluded, the version in the excluded arch
> should not be touched?

No, the same builds are used in all primary architectures, so if a 
package is excluded from an arch, the whole package is excluded from 
that arch, not just that particular build.

Paul.



From alsadi at gmail.com  Fri Dec 19 13:03:10 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 19 Dec 2008 15:03:10 +0200
Subject: GNOME menu ugliness - Name/GenericName
In-Reply-To: <20081219134834.6f95fcb2.mschwendt@gmail.com>
References: <20081219114753.e9588d0b.mschwendt@gmail.com>
	<gig07b$iu4$1@ger.gmane.org>
	<20081219134834.6f95fcb2.mschwendt@gmail.com>
Message-ID: <385866f0812190503o7806a4e5sa930ebdb9b9b28f6@mail.gmail.com>

> KDE 4 shows the GenericName in big letters and when the mouse pointer is above

I thought that is the comment



From markg85 at gmail.com  Fri Dec 19 13:09:31 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 14:09:31 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229685176.1599.35.camel@fatty>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
Message-ID: <6e24a8e80812190509h50a49256pe44ab6da53eb4e3c@mail.gmail.com>

On Fri, Dec 19, 2008 at 12:12 PM, Alexander Larsson <alexl at redhat.com> wrote:
> On Fri, 2008-12-19 at 03:16 +0100, Mark wrote:
>
>> So in short. as long as the nautilus creator is also the maintainer
>> and the inventor of spatial we probably won't see this default
>> behaviour change. very sad but true!
>
> I don't understand this harsh reaction. Yes, I am the maintainer of
> natilus, yes I am the primary developer of nautilus for at least the
> last 5 years. Yes, I am the packager of nautilus in fedora. Yes, I
> implemented (not invented!) spatial mode in nautilus, for the reason
> that I think its a good UI model for a file manager, especially one
> targeted towards non-computer-experts like nautilus.

fine if you target the code to "noobs" (that's what you say nicer
words) but most of the computer users that use linux know just a
little more then the average starting computer user.
>
> However, I don't think spatial mode is always what you want, so nautilus
> also has the browser, always availible in the spatial window menus and
> in the panel menu, if you want to do something where it is more in line
> with what you want. Its not an afterthought either, we maintain it and
> add features to it. And, we also have a UI preference to totally turn
> off spatial mode for those that don't like it.
>
> The question is, why are you so persistant about pushing your
> preferences on everyone. You think I'm a fucking nuthole to have picked
> spatial as the default, yet you think you should decide what the default
> should be. Thats as much a decision as what I've done and the people who
> dislike it will write long tirades about how you're a fucking nuthole,
> how they are gonna leave/fork gnome/fedora etc. Yes, it is possible to
> have a discussion of what the defaults should be, but it should be a
> sane one with less emotions, no namecalling, a realization that someone
> else (who spent many many years working on the piece of software) may
> have a valid opinion, and a genuine interest in finding out the
> reasoning behind the various options.

Why am i so persistent.. well because i don't like the default
behaviour! and there are thousands if not millions of linux users that
agree with me. just do a google search on "gnome nautilus spatial
2004" and browse through all the comments that you find. the huge
majority didn't like it back then and still doesn't like it now. Now
there is just one big difference. UBUNTU listens to them and uses the
browser mode along with most other distributions. Fedora somehow has
to be different and i suspect that's because your the package
maintainer and dev of nautilus.

Also i don't intend to FORK fedora! nor gnome. to be honest, i like
c++ not c and definitely not python (fedora over uses it) so forking
any of it would be waste for me.
>
> I have been convinced to change my mind by such discussions before, so
> I'm not just blocking other peoples ideas. Of course, your random
> rantings and namecallings don't exactly make me interested in having a
> discussion with you.

your now well aware of my opinion about this and you know as good as
me that most people using linux and gnome and nautilus use the browser
mode. Just a fact not made up. I don't see a point in a discussion
with your simply well aware of the facts and how i stand. It's
entirely up to you to change this for fedora.

Also note that i'm just "harsh", hard and to the point in this
question. I'm not rude (yet). you on the other hand are starting to do
so: "fucking nuthole". Skip the rude part next time plz. I didn't
insult anyone yet (oke, perhaps Rahul a bit).



From markg85 at gmail.com  Fri Dec 19 13:13:11 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 14:13:11 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc> <giepf5$i12$1@ger.gmane.org>
	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
Message-ID: <6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>

On Fri, Dec 19, 2008 at 1:24 PM, dexter <dex.mbox at googlemail.com> wrote:
> 2008/12/19 Kevin Kofler <kevin.kofler at chello.at>:
>> Matthias Clasen wrote:
>>> We don't do votes on things like this.
>>
>> If only there was a GNOME SIG with community involvement, where all the
>> maintainers of GNOME and closely-related packages (also implying: if GNOME
>> packages actually _had_ community comaintainers...) were represented, with
>> public meetings also followed by triagers, documentation writers and
>> interested users, that would be a good place to hold a vote (among the
>> maintainers), also showing some transparency and providing an incentive to
>> get involved. Now where did I get this idea from? ;-)
>>
>>        Kevin Kofler
>
> SILENCE! lest the people rise up and take back what is rightfully theirs.
>
> Hey mark build it how you want it put it in a repo and the people will
> come, then start a UNLEASH GNOME CAMPAIGN
>
> ...dex

I probably could but that would need a lot of patching ^_^
and i don't see why i would waste my time on that, a system where i disagree on.

btw. i never understood why Linus Torvalds was so opposed to Gnome.
i'm beginning to understand why.



From rc040203 at freenet.de  Fri Dec 19 13:19:35 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 19 Dec 2008 14:19:35 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<20081218215107.GB1366434@hiwaay.net>
	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>
	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>
Message-ID: <1229692775.3209.670.camel@beck.corsepiu.local>

On Fri, 2008-12-19 at 14:38 +0200, Muayyad AlSadi wrote:
> I said
> > 1. provide a patch that make shift-double click opens in a new window
> > 2. upstream the patch
> > 3. make browser mode to be the default because the usability issue is solved
> 
> it seems that I was sleeping
> 
> 1 and 2 are already done
> so the usability issue is fixed in browser mode
> 
> document shift+double click to open in a new window with more emphasis
> and make it the default
> 
> why spatial mode was introduced ?
> to make drag and drop easy
Q: Does it? 

Yes, on big displays, with very few windows open.

No, on small displays or when having many windows open and when using
virtual screen 

Background:
* On my "big desktop" with the "big display", I find spatial mode nice.
Unless excessively opening windows, windows are being place nicely.

* On my netbook, I find "spatial mode" to be "unusable".
Stacks of windows are the norm, wading through them is a nuissance.
Drag'n'Drop is hardly applicable => browser mode.

> the question now does people drag and drop more than they browse [open
> folder to see them] ?
When observing myself: First browsing, then "opening" is the
overwhelming use-case. Drag and Drop is much seldom use-case.

Ralf




From alexl at users.sourceforge.net  Fri Dec 19 13:25:08 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Fri, 19 Dec 2008 06:25:08 -0700
Subject: exiv2-0.18 coming soon to a rawhide near you
In-Reply-To: <494A935E.1070503@math.unl.edu> (Rex Dieter's message of "Thu\,
	18 Dec 2008 12\:15\:58 -0600")
References: <494A935E.1070503@math.unl.edu>
Message-ID: <ry4p10b8ln.fsf@allele2.eebweb.arizona.edu>

>>>>> "RD" == Rex Dieter  writes:

RD> I'll be updating to exiv2-0.18 in rawhide real soon, which
RD> includes soname bump, and start jumping on rebuilding dependent
RD> apps asap.

Could these kind of soname bump e-mails be sent to
fedora-devel-announce as well? (having package ABI changes being
widely announced was the original intention of having a low-volume
announce list in the first place and it seems that very few
announcements are being made there).

fedora-devel-list is getting too high volume and occasionally noisy
for me (and I suspect many other maintainers) to follow it daily and
soname bumps are the kind of thing all maintainers should be aware of.

Thanks,
Alex



From muepsj at gmail.com  Fri Dec 19 13:26:45 2008
From: muepsj at gmail.com (=?UTF-8?Q?Joonas_Saraj=C3=A4rvi?=)
Date: Fri, 19 Dec 2008 15:26:45 +0200
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812190509h50a49256pe44ab6da53eb4e3c@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<6e24a8e80812190509h50a49256pe44ab6da53eb4e3c@mail.gmail.com>
Message-ID: <66ec675b0812190526h45227352w513a0862adea609d@mail.gmail.com>

2008/12/19 Mark <markg85 at gmail.com>:
> On Fri, Dec 19, 2008 at 12:12 PM, Alexander Larsson <alexl at redhat.com> wrote:
>>
>> I don't understand this harsh reaction. Yes, I am the maintainer of
>> natilus, yes I am the primary developer of nautilus for at least the
>> last 5 years. Yes, I am the packager of nautilus in fedora. Yes, I
>> implemented (not invented!) spatial mode in nautilus, for the reason
>> that I think its a good UI model for a file manager, especially one
>> targeted towards non-computer-experts like nautilus.
>
> fine if you target the code to "noobs" (that's what you say nicer
> words) but most of the computer users that use linux know just a
> little more then the average starting computer user.
>>

I prefer the spatial mode of Nautilus to the browser mode, even though
I don't consider myself a noob.


>> The question is, why are you so persistant about pushing your
>> preferences on everyone. You think I'm a fucking nuthole to have picked
>> spatial as the default, yet you think you should decide what the default
>> should be. Thats as much a decision as what I've done and the people who
>> dislike it will write long tirades about how you're a fucking nuthole,
>> how they are gonna leave/fork gnome/fedora etc. Yes, it is possible to
>> have a discussion of what the defaults should be, but it should be a
>> sane one with less emotions, no namecalling, a realization that someone
>> else (who spent many many years working on the piece of software) may
>> have a valid opinion, and a genuine interest in finding out the
>> reasoning behind the various options.
>
> Why am i so persistent.. well because i don't like the default
> behaviour!

Well, I do like the default behaviour! I haven't measured the number
of people doing so, but there certainly are many of those, too.

> and there are thousands if not millions of linux users that
> agree with me. just do a google search on "gnome nautilus spatial
> 2004" and browse through all the comments that you find. the huge
> majority didn't like it back then and still doesn't like it now.

I think there are many users who dislike the spatial mode just because
they have got accustomed to something else. I didn't like it either at
first, but later on wanted to know if there actually was any point in
using it. After all, the designer of the software had set the spatial
mode as the default mode, so there had to be something good in it,
wouldn't it?

There are a lot more things special in spatial mode than just the fact
that opening a folder opens a new window. I like the fact that the
state of each folder is persistent. Every window opens in the same
view that it had when I reopen them. I can have appropriate zoom
levels and views for every directory I commonly use.

There is the downside of a few unneeded windows opening when I happen
to navigate to a previously unvisited part of the filesystem
hierarchy, but I need to do that quite rarely. A few well-placed
bookmarks can also greatly reduce unneeded hierarchy navigation.

> Now
> there is just one big difference. UBUNTU listens to them and uses the
> browser mode along with most other distributions. Fedora somehow has
> to be different and i suspect that's because your the package
> maintainer and dev of nautilus.
>

Ubuntu does many things that diverge from upstream.

> Also i don't intend to FORK fedora! nor gnome. to be honest, i like
> c++ not c and definitely not python (fedora over uses it) so forking
> any of it would be waste for me.
>>
>> I have been convinced to change my mind by such discussions before, so
>> I'm not just blocking other peoples ideas. Of course, your random
>> rantings and namecallings don't exactly make me interested in having a
>> discussion with you.
>
> your now well aware of my opinion about this and you know as good as
> me that most people using linux and gnome and nautilus use the browser
> mode. Just a fact not made up. I don't see a point in a discussion
> with your simply well aware of the facts and how i stand. It's
> entirely up to you to change this for fedora.





-- 
Joonas Saraj?rvi
muepsj at gmail.com



From karsten at redhat.com  Fri Dec 19 13:41:20 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Fri, 19 Dec 2008 14:41:20 +0100
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <1229618217.14090.543.camel@beck.corsepiu.local>
References: <494A7A92.9020404@redhat.com>
	<1229618217.14090.543.camel@beck.corsepiu.local>
Message-ID: <494BA480.4020108@redhat.com>

Ralf Corsepius schrieb:
> On Thu, 2008-12-18 at 17:30 +0100, Karsten Hopp wrote:
>> I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages
>> which erronously use  {_libdir} or {_lib} in their spec files. rpmdiff shows this output:
>>
>> ./firstaidkit-0.2.2-5.fc11.noarch.rpm
>> removed    /usr/lib/firstaidkit
>> removed    /usr/lib/firstaidkit/plugins
>> added      /usr/lib64/firstaidkit
>> added      /usr/lib64/firstaidkit/plugins
>>
>> As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs
>>
>> Here is the list of offending packages I've found:
>>
>>
>> Package        Owner
>> ------------------------
>> ntfs-config    laxathom
>> firstaidkit    msivak
>> terminus-font  ndim
>> gdeskcal       pfj
>> libopensync-plugin-synce  awjb
>> cohoba         tjikkun
>> gnome-schedule farnold
>> common-lisp-controller  green
>> gcstar         tian
>> revisor-cli    jsteffan
>> jruby          konradm
>>
>>
>>
>> Can we make it a policy to not use _libdir or _lib in noarch packages, please ?
> Wouldn't it be better to let rpm set _libdir/_lib to match noarch
> package requirements?
> 
> Ralf
> 
> 



I don't have any preferences on how we solve it, I'll leave that for FPC to decide.
But I think it needs to be solved or we'll run out of luck and build one of those packages
on 64bit anytime soon.

    Karsten



From konrad at tylerc.org  Fri Dec 19 14:01:09 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 19 Dec 2008 06:01:09 -0800
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <494BA480.4020108@redhat.com>
References: <494A7A92.9020404@redhat.com>
	<1229618217.14090.543.camel@beck.corsepiu.local>
	<494BA480.4020108@redhat.com>
Message-ID: <200812190601.09387.konrad@tylerc.org>

On Friday 19 December 2008 05:41:20 am Karsten Hopp wrote:
> Ralf Corsepius schrieb:
> > On Thu, 2008-12-18 at 17:30 +0100, Karsten Hopp wrote:
> >> I've run a x86_64 mass rebuild of all our Fedora packages and found
> >> several noarch packages which erronously use  {_libdir} or {_lib} in
> >> their spec files. rpmdiff shows this output:
> >>
> >> ./firstaidkit-0.2.2-5.fc11.noarch.rpm
> >> removed    /usr/lib/firstaidkit
> >> removed    /usr/lib/firstaidkit/plugins
> >> added      /usr/lib64/firstaidkit
> >> added      /usr/lib64/firstaidkit/plugins
> >>
> >> As noarch packages can be built on any machine/architecture in koji,
> >> we'd end up with lib64 directories on 32bit archs
> >>
> >> Here is the list of offending packages I've found:
> >>
> >>
> >> Package        Owner
> >> ------------------------
> >> ntfs-config    laxathom
> >> firstaidkit    msivak
> >> terminus-font  ndim
> >> gdeskcal       pfj
> >> libopensync-plugin-synce  awjb
> >> cohoba         tjikkun
> >> gnome-schedule farnold
> >> common-lisp-controller  green
> >> gcstar         tian
> >> revisor-cli    jsteffan
> >> jruby          konradm
> >>
> >>
> >>
> >> Can we make it a policy to not use _libdir or _lib in noarch packages,
> >> please ?
> >
> > Wouldn't it be better to let rpm set _libdir/_lib to match noarch
> > package requirements?
> >
> > Ralf
>
> I don't have any preferences on how we solve it, I'll leave that for FPC to
> decide. But I think it needs to be solved or we'll run out of luck and
> build one of those packages on 64bit anytime soon.
>
>     Karsten

Note that the version of jruby in CVS *isn't* tagged or built... it's in 
progress of being bumped to 1.1.6, I've just been waiting on some new 
dependencies for a *long* time.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From kevin.kofler at chello.at  Fri Dec 19 14:04:09 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Dec 2008 15:04:09 +0100
Subject: GNOME menu ugliness - Name/GenericName
References: <20081219114753.e9588d0b.mschwendt@gmail.com>
	<gig07b$iu4$1@ger.gmane.org>
	<20081219134834.6f95fcb2.mschwendt@gmail.com>
	<385866f0812190503o7806a4e5sa930ebdb9b9b28f6@mail.gmail.com>
Message-ID: <gig9kp$ioe$1@ger.gmane.org>

Muayyad AlSadi wrote:
> I thought that is the comment

No, it's not, KDE ignores the comment entirely (which is also bad, IMHO it
should show it as a tooltip like GNOME does).

        Kevin Kofler



From ndbecker2 at gmail.com  Fri Dec 19 14:11:01 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 19 Dec 2008 09:11:01 -0500
Subject: Recursively listing dependencies of a package?
References: <200812182218.58818.ville.skytta@iki.fi>
	<alpine.LFD.2.00.0812181521260.31106@localhost.localdomain>
Message-ID: <giga1m$jh8$1@ger.gmane.org>

Seth Vidal wrote:

> 
> 
> On Thu, 18 Dec 2008, Ville Skytt? wrote:
> 
>> Hello,
>>
>> Is there a tool that can list recursive dependencies (the whole dep tree)
>> of a
>> package from repodata?  And even better if it can be also told to resolve
>> things like /bin/sh and libfoo.so.x to package names and output a list of
>> those package names (+ EVRA) only (not files or Provides).
>>
>> What I've looked into so far:
>>
>> yum deplist: is not recursive, or I don't know how to tell it to be. 
>> Also a bit verbose for my taste (lists all providers of deps).
>>
>> repoquery -R --resolve: otherwise exactly what I'm looking for, but it's
>> not
>> recursive either.  Adding --recursive to the options does not appear to
>> make any difference.
> 
> http://people.redhat.com/jantill/yum/commands/pkg-deps-tree-view.py
> 
> for deps
> 
> http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py
> 
> for provs
> 

These look pretty useful.  Is there a yum wiki or something where we could find such answers?




From joshuacov at googlemail.com  Fri Dec 19 14:37:06 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Fri, 19 Dec 2008 15:37:06 +0100
Subject: Amarok 2 on F9
In-Reply-To: <2a28d2ab0812190309t54ccd219i49a16ea73f2dca25@mail.gmail.com>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gieuf2$uok$1@ger.gmane.org>
	<8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
	<2a28d2ab0812190309t54ccd219i49a16ea73f2dca25@mail.gmail.com>
Message-ID: <5f6f8c5f0812190637h34c75e6ew546995fc7d87edd2@mail.gmail.com>

2008/12/19 Dr. Diesel <dr.diesel at gmail.com>:
> 2008/12/18 Oscar<Soker> <sokerlp at gmail.com>
>>
>> Plz don't do that, Amarok 2 is not as goog as Amarok 1.4 it loose a lot of
>> functionality
>>
>> Atentamente Oscar:
>
>
> We really need both until the issues with 2.0 are sorted out.
>
>
>
> --
> 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
>

ok I can understand it. I saw that some functionality is lost in
version 2 but there are also some useful changes (the same happened
with kde3.5.9->kde4.0). libmtp for f10 needs to be recompiled for f9,
though.

maybe we can wait untill the bugs are fixed, but this should be
reconsidered before f9 life-cycle ends.



From limb at jcomserv.net  Fri Dec 19 14:50:21 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 19 Dec 2008 08:50:21 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <494AB8A7.5010404@howardsilvan.com>
References: <loom.20081203T184910-257@post.gmane.org>
	<20081210132140.25e402bc@ohm.scrye.com>
	<baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
	<eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
	<91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>
	<c36581a7b59348d68dbdecd9d018da71.squirrel@mail.jcomserv.net>
	<494AA62E.7040304@howardsilvan.com>
	<dbd1018eee690e3de8da996bcd17e8ec.squirrel@mail.jcomserv.net>
	<494AADB7.5000604@howardsilvan.com>
	<6cfd16a6721cf4cd73a3b7d13dcbd1e3.squirrel@mail.jcomserv.net>
	<494AB8A7.5010404@howardsilvan.com>
Message-ID: <82a106d658e2ea4347ffe83ac801fc32.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>>> Jon Ciesla wrote:
>>>
>>>> Understandable.  If this person exists, then that is the logical path.
>>>> If
>>>> not, then are distro maintainers to simply soldier on, maintaining
>>>> what
>>>> are, in effect, forks?  I have to think that in the absence of the
>>>> Qualified Individual we all desire, a coordinating effort of distro
>>>> maintainers would be preferable to the status quo.
>>>>
>>> I wholeheartedly agree.  I'm more than happy to see them all set up
>>> with
>>> the necessary permissions on the Sourceforge site.
>>>
>>
>> Adding Tom Lane back to the thread.
>>
>> So at this point we'd need you, Lee, or someone else with the sf.net
>> project access, to grant the access, and buy-in from interested
>> maintainers, which would be Brian and Tom(unless he wants to designate
>> someone else) so far.  I'll research who others are at other distros.
>>
>> I am also willing to contribute, beyond simply meddling. :)  I have a
>> sf.net account(limburgher), etc.
>
> John,
>
> I've added you to the Sourceforge project.  You should have rights to
> add other project admins.
>
> If you need me to add others please compile and send to me a list of
> sourceforge account names which should be added to the project, and I
> will add them.

Thanks.  I should be able to handle that.  I'll work out a plan, and a
list of maintainers at other distros, and send something out.  I'll be AFK
next week, so this'll probably go out 12/29.

> Thanks,
>
> Lee.
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From dbn.lists at gmail.com  Fri Dec 19 14:53:59 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 19 Dec 2008 06:53:59 -0800
Subject: patching fedora kernel for eeepc
In-Reply-To: <giemq1$94f$1@ger.gmane.org>
References: <a36b7e2a0812171904x60cf5716oaebf8d676c725e13@mail.gmail.com>
	<giemq1$94f$1@ger.gmane.org>
Message-ID: <91705d080812190653p17b6787du195034b83e67e39d@mail.gmail.com>

On Thu, Dec 18, 2008 at 3:36 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Justin Conover wrote:
>>
>> This might be a stupid question.... but....
>>
>> How to I use these in a patch?
>>
>> http://lkml.org/lkml/2008/11/20/265
>>
>> http://lkml.org/lkml/2008/11/20/266
>>
>> http://lkml.org/lkml/2008/11/20/267
>>
>> I understand this one because its in a patch file, but these are just
>> e-mails.
>
> Omit the file name and let patch read stdin, paste the patch portion of the
> mails, and ctrl-D (twice)?
>
> (For some reason, patch - and only patch - seems to eat the first ctrl-D.)

Since those mails were formatted by 'git format-patch' and have no
intrusive characters, you could probably just feed the whole mail to
patch.

patch -p1 < the_mail

--
Dan



From bpepple at fedoraproject.org  Fri Dec 19 14:55:19 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Fri, 19 Dec 2008 09:55:19 -0500
Subject: FESCo Meeting Summary for 2008-12-17
Message-ID: <1229698519.9194.3.camel@localhost.localdomain>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Karsten Hopp          (kick_)
* Kevin Fenzi           (nirik)
* Josh Boyer            (jwb)
* Bill Nottingham       (notting)
* David Woodhouse       (dwmw2)

=== Absent ===
* Dennis Gilmore        (dgilmore)
* Jon Stanley           (jds2001)

== Summary ==
=== Fedora Packaging Committee Proposals ===
      * FESCo had no objections to the FPC proposals passed during their
        meeting on Dec. 9th.
        http://fedoraproject.org/wiki/Packaging/Minutes/20081209

=== Features ===
      * FESCo approved the following feature for Fedora 11:
              * https://fedoraproject.org/wiki/Features/20SecondStartup

=== FESCo meetings ===
      * The FESCo meetings for Dec. 24th and Dec. 31st have been
        cancelled due to the upcoming holidays.  The next FESCo meeting
        will occur on January 7th.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-12-17.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/092e4ab2/attachment.sig>

From james at fedoraproject.org  Fri Dec 19 15:35:33 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 19 Dec 2008 10:35:33 -0500
Subject: Recursively listing dependencies of a package?
In-Reply-To: <giga1m$jh8$1@ger.gmane.org>
References: <200812182218.58818.ville.skytta@iki.fi>
	<alpine.LFD.2.00.0812181521260.31106@localhost.localdomain>
	<giga1m$jh8$1@ger.gmane.org>
Message-ID: <1229700933.6392.263.camel@code.and.org>

On Fri, 2008-12-19 at 09:11 -0500, Neal Becker wrote:
> Seth Vidal wrote:
> > 
> > http://people.redhat.com/jantill/yum/commands/pkg-deps-tree-view.py
> > 
> > for deps
> > 
> > http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py
> > 
> > for provs
> > 
> 
> These look pretty useful.  Is there a yum wiki or something where we could find such answers?

 http://yum.baseurl.org/

-- 
James Antill <james at fedoraproject.org>
Fedora



From dimi at lattica.com  Fri Dec 19 15:42:08 2008
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 19 Dec 2008 10:42:08 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229685176.1599.35.camel@fatty>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
Message-ID: <1229701328.23410.50.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 12:12 +0100, Alexander Larsson wrote:
> I don't understand this harsh reaction. Yes, I am the maintainer of
> natilus, yes I am the primary developer of nautilus for at least the
> last 5 years. Yes, I am the packager of nautilus in fedora. Yes, I
> implemented (not invented!) spatial mode in nautilus, for the reason
> that I think its a good UI model for a file manager, especially one
> targeted towards non-computer-experts like nautilus.

But this your opinion vs, other opinions. And yes, your opinion weighs a
lot more because you are the maintainer, but it may not be any better in
terms of UI design.

If you guys were so "conservative" when this feature was forced on
people (initially you couldn't even turn it off easily!), it would never
have been set as default. The initial rationale was that it's great, and
people will get used to it. AFAICT, that didn't pan out (in fact, of the
10 or so people that I directly know using Linux, techie or not, none
use the spacial mode).

Also, please realize this is not just any regular feature -- it's one of
the most visible behavioral differences in a desktop. And it's so
removed from what people are used to that it's bound to cause confusion
to non-experts.

Do you truly think it's all that better compared to the regular mode
that it's worth the risk and confusion associated to changing well
understood behavior?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From ivazqueznet at gmail.com  Fri Dec 19 15:52:33 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 19 Dec 2008 10:52:33 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
Message-ID: <1229701953.3741.131.camel@ignacio.lan>

On Fri, 2008-12-19 at 13:52 +0100, Thomas Bendler wrote:
> ... that the majority of people don't use this mode.

Do you have actual numbers or is that a complete guess?

> ...I simply think ...

Oh, never mind.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/860f1a95/attachment.sig>

From dimi at lattica.com  Fri Dec 19 16:19:56 2008
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 19 Dec 2008 11:19:56 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229701953.3741.131.camel@ignacio.lan>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
	<1229701953.3741.131.camel@ignacio.lan>
Message-ID: <1229703596.23410.56.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 10:52 -0500, Ignacio Vazquez-Abrams wrote:
> > ... that the majority of people don't use this mode.
> 
> Do you have actual numbers or is that a complete guess?

Do you have any numbers to even suggest the current behavior
is preferred? Better yet, were there any numbers when this
has been set as default?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From ml at bendler-net.de  Fri Dec 19 16:31:43 2008
From: ml at bendler-net.de (Thomas Bendler)
Date: Fri, 19 Dec 2008 17:31:43 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229701953.3741.131.camel@ignacio.lan>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
	<1229701953.3741.131.camel@ignacio.lan>
Message-ID: <e5f36bc70812190831g67f8561alcad08138f29ec72f@mail.gmail.com>

2008/12/19 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

> On Fri, 2008-12-19 at 13:52 +0100, Thomas Bendler wrote:
> > ... that the majority of people don't use this mode.
> Do you have actual numbers or is that a complete guess?


How would you like to count without a vote were the relevant people say, no
we don't want a vote. Just take a look into this thread or take a look at
Google, the majority of user don't like spatial. How would you argue that
the majority of user like spatial?

Regards, Thomas
-- 
thomas bendler      (systemadministration/network/SAP)
cimt consulting ag             fon: +49 (163) 6081 302
burchardstrasse 17            fax: +49 (40) 5 33 02-22
20095 hamburg                   http://www.cimt-ag.de/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/16f91497/attachment.htm>

From langel at redhat.com  Fri Dec 19 16:38:14 2008
From: langel at redhat.com (Lillian Angel)
Date: Fri, 19 Dec 2008 11:38:14 -0500
Subject: Orphaning azureus
In-Reply-To: <200811260048.49879.konrad@tylerc.org>
References: <20081024190916.A41D98E0003@hormel.redhat.com>	<200811252018.15095.konrad@tylerc.org>
	<492D0AD0.5070408@gmail.com> <200811260048.49879.konrad@tylerc.org>
Message-ID: <494BCDF6.4000008@redhat.com>

Conrad Meyer wrote:
> On Wednesday 26 November 2008 12:37:36 am Alphonse Van Assche wrote:
>   
>> Conrad Meyer a ?crit :
>>     
>>> Do you still want this? If so please take it in pkgdb. If not I have an
>>> interest.
>>>       
>> Yes, but if you will we can maintain it together.
>>
>> ps: Once I can reset my fas account I will add me as (co)maintainer of
>> azureus, I'm not at home and don't know my pwd from head.
>>
>> Alphonse
>>     
>
> I'd be glad to take comaintainership here. Thanks!
>
>   

The package is still an orphan for F-9, F-10 and devel. Please feel free 
to take it:
https://admin.fedoraproject.org/pkgdb/packages/name/azureus


Lillian



From mclasen at redhat.com  Fri Dec 19 16:40:28 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 19 Dec 2008 11:40:28 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <1229606638.3301.11.camel@localhost.localdomain>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
Message-ID: <1229704828.24417.0.camel@matthiasc>

On Thu, 2008-12-18 at 08:23 -0500, Matthias Clasen wrote:
> On Thu, 2008-12-18 at 02:19 -0500, Yaakov Nemoy wrote:
> >
> > In short, the new gnome session configuration dialog is alot simpler
> > and alot less confusing, but it gives us no simple way to give
> > metacity the boot on a per session basis.  How do i go about doing
> > this via an RPM?
> 
> The required components should just be a fallback in case the session
> didn't contain a window manager, file manager, etc. At least that is my
> understanding of how they're supposed to be used. So, you should just
> install an autostart file for xmonad that marks it as a window manager
> via
> 
> X-GNOME-Autostart-Phase=WindowManager
> X-GNOME-Provides=windowmanager
> 
> then your users should be able to switch their sessions to xmonad by
> turning it on in the session capplet.

Just tried this with openbox, and it works fine.



From loupgaroublond at gmail.com  Fri Dec 19 16:48:00 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 19 Dec 2008 11:48:00 -0500
Subject: Amarok 2 on F9
In-Reply-To: <494B3ECC.6090404@rincon.com>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gieuf2$uok$1@ger.gmane.org>
	<8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
	<494B3ECC.6090404@rincon.com>
Message-ID: <7f692fec0812190848o26980f92wd76d9eee9dabc7f7@mail.gmail.com>

2008/12/19 Bob Arendt <rda at rincon.com>:
> Oscar<Soker> wrote:
>>
>> Plz don't do that, Amarok 2 is not as goog as Amarok 1.4 it loose a lot of
>> functionality
>>
> +1
> Amarok 2 is missing some this 1.4 has:
>  doesn't have UMS media player support.  Bug 473807
>  doesn't ship documentation. Bug 473522
> *Please* do not "upgrade" f9 to Amarok2

We don't vote on mailing lists.  If you would like to use a particular
package version though, we do have alternatives:

Installed Packages
Name       : yum-versionlock
Arch       : noarch
Version    : 1.1.18
Release    : 2.fc10
Size       : 5.1 k
Repo       : installed
Summary    : Yum plugin to lock specified packages from being updated
URL        : http://yum.baseurl.org/download/yum-utils/
License    : GPLv2+
Description: This plugin takes a set of name/versions for packages and
excludes all other versions of those packages (including optionally
following obsoletes). This allows you to protect
           : packages from being updated by newer versions, for example.


-Yaakov



From cmadams at hiwaay.net  Fri Dec 19 16:54:34 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 19 Dec 2008 10:54:34 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <e5f36bc70812190831g67f8561alcad08138f29ec72f@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
	<1229701953.3741.131.camel@ignacio.lan>
	<e5f36bc70812190831g67f8561alcad08138f29ec72f@mail.gmail.com>
Message-ID: <20081219165434.GC595724@hiwaay.net>

Once upon a time, Thomas Bendler <ml at bendler-net.de> said:
> How would you like to count without a vote were the relevant people say, no
> we don't want a vote. Just take a look into this thread or take a look at
> Google, the majority of user don't like spatial. How would you argue that
> the majority of user like spatial?

How many pages have you found in Google where somebody arbitrarily posts
"I like this" about something?  The complaints about _anything_ will
outweigh the positives, because happy people don't flood mailing lists
with "This is okay" messages on a regular basis.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From james at fedoraproject.org  Fri Dec 19 16:55:06 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 19 Dec 2008 11:55:06 -0500
Subject: rawhide report: 20081219 changes
In-Reply-To: <20081219124034.49c5cd5c.mschwendt@gmail.com>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
	<20081219124034.49c5cd5c.mschwendt@gmail.com>
Message-ID: <1229705706.6392.274.camel@code.and.org>

On Fri, 2008-12-19 at 12:40 +0100, Michael Schwendt wrote:
> On Fri, 19 Dec 2008 10:48:38 +0000 (UTC), Rawhide wrote:
> 
> > geeqie-1.0-0.11.alpha2.1299svn.fc11
> > -----------------------------------
> > * Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0-0.9.alpha2
> > - respin (exiv2)
> > 
> > * Thu Dec 18 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.0-0.11.alpha2.1299svn
> > - drop desktop file Exec= invocation patch (no longer necessary)
> > 
> > * Thu Dec 18 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.0-0.10.alpha2.1299svn
> > - update to svn 1299 for new exiv2
> > - disable LIRC support which is broken
> 
> The incorrect sorting is a bug in createrepo. The changelog entries need to stay
> in order, as they cannot be sorted by timestamp. The timestamps refer to full days
> lacking hours/mins/secs details.

 Actually it's in yum itself now, I think this is the fix:

diff --git a/yum/packages.py b/yum/packages.py
index acfb9f0..da4d0d8 100644
--- a/yum/packages.py
+++ b/yum/packages.py
@@ -928,7 +928,7 @@ class YumAvailablePackage(PackageObject, RpmBase):
             return ""
         msg = "\n"
         clog_count = 0
-        for (ts, author, content) in reversed(sorted(self.changelog)):
+        for (ts, author, content) in reversed(self.changelog):
             if clog_limit and clog_count >= clog_limit:
                 break
             clog_count += 1

...while I'm 99% sure the above is good, I'm not going to apply that
upstream/rawhide atm. ... due to the current real world date/time thing.

> repodiff can't fix this. I've had a look. It sorts the changelog entries
> by timestamp, which is another bug (= probably an attempt at trying
> to work around the createrepo bug).

 The sort is useless, yes ... but it's not sorting what is output, so
it's not doing any harm either.

> Printing only the date can be done with attached patch, however.

 Applied.

-- 
James Antill <james at fedoraproject.org>
Fedora



From dennis at ausil.us  Fri Dec 19 16:54:51 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Fri, 19 Dec 2008 10:54:51 -0600
Subject: rawhide report: 20081219 changes
In-Reply-To: <1229691323.10450.58.camel@PB3.Linux>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
	<494B95EC.5000601@city-fan.org>
	<1229691323.10450.58.camel@PB3.Linux>
Message-ID: <200812191059.26315.dennis@ausil.us>

On Friday 19 December 2008 06:55:23 am Paul wrote:
> Hi,
>
> > > True, however, until there is a successful build, the last version
> > > should remain there. There isn't even an f10 version in the rawhide
> > > buildroot.
> >
> > The last successful build of mono was
> > 2.2-12.pre3.20081217svn121664.fc11, which excluded ppc, hence there is
> > no mono in the ppc buildroot.
>
> Surely though if something is excluded, the version in the excluded arch
> should not be touched?
No, the most current version is always used on all arches.  there is no magic 
to have different version on different arches.

Dennis



From mcepl at redhat.com  Fri Dec 19 16:53:30 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 19 Dec 2008 17:53:30 +0100
Subject: exiv2-0.18 coming soon to a rawhide near you
References: <494A935E.1070503@math.unl.edu>
	<a64bc4311504a990d2e7e0287ee66d96.squirrel@mail.jcomserv.net>
	<gie4rj$brc$1@ger.gmane.org>
	<cfb4530ddf5dba67ef82aaa8b482e019.squirrel@mail.jcomserv.net>
	<gie6qi$ip8$1@ger.gmane.org> <gie9pg$t1f$1@ger.gmane.org>
Message-ID: <a50t16xoeq.ln2@ppp1053.in.ipex.cz>

On 2008-12-18, 19:55 GMT, Rex Dieter wrote:
> pyexiv2: 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=75466

I am trying to understand it, but more and more I look into it, 
more it looks like there is something wrong with your package:

[matej at hubmaier exiv2]$ pwd
/usr/include/exiv2
[matej at hubmaier exiv2]$ grep -r Thumbnail *
exif.hpp:        void setJpegThumbnail(
exif.hpp:        void setJpegThumbnail(
exif.hpp:        void setJpegThumbnail(const std::string& path);
exif.hpp:        void setJpegThumbnail(const byte* buf, long 
size);
exif.hpp:                 Exif.%Thumbnail.*, i.e., Exif IFD1 
tags.
xmp.hpp:            includeThumbnailPad = 0x0100UL,  //!< Include 
a padding allowance for a thumbnail image.
[matej at hubmaier exiv2]$ 

What happened to Exiv2::Thumbnail?

Mat?j



From jkeating at redhat.com  Fri Dec 19 17:06:46 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Dec 2008 09:06:46 -0800
Subject: Strange mono problem with ppc
In-Reply-To: <1229684798.10450.47.camel@PB3.Linux>
References: <1229684798.10450.47.camel@PB3.Linux>
Message-ID: <1229706406.5263.0.camel@localhost.localdomain>

On Fri, 2008-12-19 at 11:06 +0000, Paul wrote:
> Shouldn't they have been moved over from f10 to devel when we
> branched?

As noted in the other thread, a build of mono that excludes ppc was
done, thus removing mono from ppc.  Probably not the best thing to do
outside of scratch builds.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/abc03840/attachment.sig>

From dr.diesel at gmail.com  Fri Dec 19 17:12:58 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Fri, 19 Dec 2008 12:12:58 -0500
Subject: Amarok 2 on F9
In-Reply-To: <7f692fec0812190848o26980f92wd76d9eee9dabc7f7@mail.gmail.com>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gieuf2$uok$1@ger.gmane.org>
	<8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
	<494B3ECC.6090404@rincon.com>
	<7f692fec0812190848o26980f92wd76d9eee9dabc7f7@mail.gmail.com>
Message-ID: <2a28d2ab0812190912p64d392a1i956341afbf0ee1d4@mail.gmail.com>

On Fri, Dec 19, 2008 at 11:48 AM, Yaakov Nemoy <loupgaroublond at gmail.com>wrote:

> 2008/12/19 Bob Arendt <rda at rincon.com>:
> > Oscar<Soker> wrote:
> >>
> >> Plz don't do that, Amarok 2 is not as goog as Amarok 1.4 it loose a lot
> of
> >> functionality
> >>
> > +1
> > Amarok 2 is missing some this 1.4 has:
> >  doesn't have UMS media player support.  Bug 473807
> >  doesn't ship documentation. Bug 473522
> > *Please* do not "upgrade" f9 to Amarok2
>
> We don't vote on mailing lists.  If you would like to use a particular
> package version though, we do have alternatives:



Have you been sleeping the past few days?  How about the call/vote from the
Fedora group on Nautilus?


-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/c2f5e6bd/attachment.htm>

From itamar at ispbrasil.com.br  Fri Dec 19 17:14:53 2008
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Fri, 19 Dec 2008 15:14:53 -0200
Subject: Orphaning azureus
In-Reply-To: <494BCDF6.4000008@redhat.com>
References: <20081024190916.A41D98E0003@hormel.redhat.com>
	<200811252018.15095.konrad@tylerc.org> <492D0AD0.5070408@gmail.com>
	<200811260048.49879.konrad@tylerc.org> <494BCDF6.4000008@redhat.com>
Message-ID: <d3ceea380812190914o369d6970le475ffa2b544ead8@mail.gmail.com>

http://azureus.sourceforge.net/


azureus is now called Vuze


what you think about letting azureus orphaned and submiting  Vuze for review ?



On Fri, Dec 19, 2008 at 2:38 PM, Lillian Angel <langel at redhat.com> wrote:
> Conrad Meyer wrote:
>>
>> On Wednesday 26 November 2008 12:37:36 am Alphonse Van Assche wrote:
>>
>>>
>>> Conrad Meyer a ?crit :
>>>
>>>>
>>>> Do you still want this? If so please take it in pkgdb. If not I have an
>>>> interest.
>>>>
>>>
>>> Yes, but if you will we can maintain it together.
>>>
>>> ps: Once I can reset my fas account I will add me as (co)maintainer of
>>> azureus, I'm not at home and don't know my pwd from head.
>>>
>>> Alphonse
>>>
>>
>> I'd be glad to take comaintainership here. Thanks!
>>
>>
>
> The package is still an orphan for F-9, F-10 and devel. Please feel free to
> take it:
> https://admin.fedoraproject.org/pkgdb/packages/name/azureus
>
>
> Lillian
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From ml at bendler-net.de  Fri Dec 19 17:15:44 2008
From: ml at bendler-net.de (Thomas Bendler)
Date: Fri, 19 Dec 2008 18:15:44 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081219165434.GC595724@hiwaay.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
	<1229701953.3741.131.camel@ignacio.lan>
	<e5f36bc70812190831g67f8561alcad08138f29ec72f@mail.gmail.com>
	<20081219165434.GC595724@hiwaay.net>
Message-ID: <e5f36bc70812190915j2e366a95h99bb5d6b31ccec54@mail.gmail.com>

On Fri, Dec 19, 2008 at 5:54 PM, Chris Adams <cmadams at hiwaay.net> wrote:

> Once upon a time, Thomas Bendler <ml at bendler-net.de> said:
> > How would you like to count without a vote were the relevant people say,
> no
> > we don't want a vote. Just take a look into this thread or take a look at
> > Google, the majority of user don't like spatial. How would you argue that
> > the majority of user like spatial?
>
> How many pages have you found in Google where somebody arbitrarily posts
> "I like this" about something?  The complaints about _anything_ will
> outweigh the positives, because happy people don't flood mailing lists
> with "This is okay" messages on a regular basis.


This is not an answer to my question, how would you argue that the current
solution is less annoying to the majority of users? Simply saying lucky
users don't complain would mean that every user who don't officially
complain is a happy user. I don't think that you can say it like this, there
are enough users which might complain but don't know where (regardless which
problem or operating system).

The only thing that might help is some kind of vote or poll. Nothing else
would be representative. But poll or vote is not wanted, so how can you
argue for spatial or against?

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/c19fb24e/attachment.htm>

From adamwill at shaw.ca  Fri Dec 19 17:20:40 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Fri, 19 Dec 2008 09:20:40 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
Message-ID: <1229707240.24419.636.camel@lenovo.local.net>

On Thu, 2008-12-18 at 18:26 -0900, Jeff Spaleta wrote:

> There is another option to drive feedback. Find a way to have gnome
> users submit application environment settings such as gconf keys, into
> a a gnome project datadump in a way that shows what settings users are
> changing from the system defaults.   I think you could do that as part
> of a larger usability study which focuses on trying to understand why
> people are making those changes.

This is an insanely awesome idea, and I just wanted to reply so people
will see it twice, and remember it, and maybe something positive will
come out of the fiftieth incarnation of this silly argument. :)
-- 
adamw



From limb at jcomserv.net  Fri Dec 19 17:26:28 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 19 Dec 2008 11:26:28 -0600
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <20081219143900.GG14821@yellowpig>
References: <5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
	<eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
	<91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>
	<c36581a7b59348d68dbdecd9d018da71.squirrel@mail.jcomserv.net>
	<494AA62E.7040304@howardsilvan.com>
	<20081219143900.GG14821@yellowpig>
Message-ID: <494BD944.8080403@jcomserv.net>

Bill Allombert wrote:
> On Thu, Dec 18, 2008 at 11:36:14AM -0800, Lee Howard wrote:
>   
>> Jon Ciesla wrote:
>>     
>>> What about simply keeping it on Sourceforge?  Don't one of you have admin
>>> access to the project there?  I have a SF account currently.
>>>
>>> As far as bringing libjpeg current, I'm not sure the task would be as
>>> herculean as it sounds, activities at fd.o hotwithstanding, not sure what
>>> that's about.
>>>       
>> libjpeg is essentially dead.
>>     
>
> I disagree with this statement. Upstream is very responsive. However
> he is not inclined to put out new release currently, bu thti sdoes not
> qualify libjpeg as essentially dead as far as I am concerned.
>
>   
Who is 'he' in this case?
> Cheers,
> Bill Allombert,
> Debian libjpeg6b maintainer.
>   



From paul at all-the-johnsons.co.uk  Fri Dec 19 17:29:14 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 19 Dec 2008 17:29:14 +0000
Subject: rawhide report: 20081219 changes
In-Reply-To: <200812191059.26315.dennis@ausil.us>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
	<494B95EC.5000601@city-fan.org> <1229691323.10450.58.camel@PB3.Linux>
	<200812191059.26315.dennis@ausil.us>
Message-ID: <1229707754.10450.59.camel@PB3.Linux>

Hi,

> > Surely though if something is excluded, the version in the excluded arch
> > should not be touched?
> No, the most current version is always used on all arches.  there is no magic 
> to have different version on different arches.

Ah, I'll have to change the spec file so that mono self builds on PPC...

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/3890c382/attachment.sig>

From mcepl at redhat.com  Fri Dec 19 17:04:38 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 19 Dec 2008 18:04:38 +0100
Subject: exiv2-0.18 coming soon to a rawhide near you
References: <494A935E.1070503@math.unl.edu>
	<a64bc4311504a990d2e7e0287ee66d96.squirrel@mail.jcomserv.net>
	<gie4rj$brc$1@ger.gmane.org>
	<cfb4530ddf5dba67ef82aaa8b482e019.squirrel@mail.jcomserv.net>
	<gie6qi$ip8$1@ger.gmane.org> <gie9pg$t1f$1@ger.gmane.org>
Message-ID: <6q0t16xg5r.ln2@ppp1053.in.ipex.cz>

On 2008-12-18, 19:55 GMT, Rex Dieter wrote:
> pyexiv2: 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=75466

BTW, I have filed a question on the upstream (I just cannot find 
the link now -- Yahoo! Groups seem kind of slow).

Mat?j



From dimi at lattica.com  Fri Dec 19 17:32:09 2008
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 19 Dec 2008 12:32:09 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229707240.24419.636.camel@lenovo.local.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
Message-ID: <1229707929.23410.63.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 09:20 -0800, Adam Williamson wrote:
> This is an insanely awesome idea, and I just wanted to reply so people
> will see it twice, and remember it, and maybe something positive will
> come out of the fiftieth incarnation of this silly argument. :)

Unfortunately even this will not be representative -- it's fairly well
known that the vast majority of users will NOT bother to change the
defaults, they will only like or dislike them.

If you are of the opinion that "who cares, you can flip a setting" you
have no idea how users function.

If we want to be successful (especially with non-technical users
migrating from other OSes), the most important point is to not change
from expected behavior unless we have OVERWHELMING reason to do so.

Otherwise we confuse users and make them feel stupid. Nobody likes that,
and they will resent us for it.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From adamwill at shaw.ca  Fri Dec 19 17:34:39 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Fri, 19 Dec 2008 09:34:39 -0800
Subject: boost rebuild status
In-Reply-To: <y68wqcb9sr.fsf@allele2.eebweb.arizona.edu>
References: <20081218011435.03690d24@balbo.artheist.org>
	<y68wqcb9sr.fsf@allele2.eebweb.arizona.edu>
Message-ID: <1229708079.24419.640.camel@lenovo.local.net>

On Fri, 2008-12-19 at 05:59 -0700, Alex Lancaster wrote:
> > Rebuilding dependent packages for boost is progressing relatively
> > smoothly. Here's an update on boost rebuilds for the second half of the
> > deps list: hopefully Petr will update from the top.
> 
> > Here's a list of some of the deps with status:
> 
> [...]
> 
> > Miro-0:1.2.7-2.fc10.x86_64
> 
> Miro rebuilt:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=75544

Note that Miro only depends on Boost because it has an internal copy of
rasterbar libtorrent.

This means:

a) there is obviously a patch to make rasterbar libtorrent build and
work with Boost 1.37.0, since you made Miro work.

b) Miro should stop using its own copy of libtorrent and use the system
one.

I knocked up a patch to make Miro 1.28 use system libtorrent (they added
this to upstream SVN post-1.28, but it required a bit of re-diffing).
You can find it here:

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/miro/current/SOURCES/miro-1.2.8-system_libtorrent.patch?view=markup

you also need this one for libtorrent 0.14+ to work:

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/miro/current/SOURCES/miro-1.2.8-libtorrent14.patch?view=markup
-- 
adamw




From mjc at avtechpulse.com  Fri Dec 19 17:40:21 2008
From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak)
Date: Fri, 19 Dec 2008 12:40:21 -0500
Subject: exiv2-0.18 coming soon to a rawhide near you
In-Reply-To: <a50t16xoeq.ln2@ppp1053.in.ipex.cz>
References: <494A935E.1070503@math.unl.edu>	<a64bc4311504a990d2e7e0287ee66d96.squirrel@mail.jcomserv.net>	<gie4rj$brc$1@ger.gmane.org>	<cfb4530ddf5dba67ef82aaa8b482e019.squirrel@mail.jcomserv.net>	<gie6qi$ip8$1@ger.gmane.org>
	<gie9pg$t1f$1@ger.gmane.org> <a50t16xoeq.ln2@ppp1053.in.ipex.cz>
Message-ID: <494BDC85.2060707@avtechpulse.com>

Matej Cepl wrote:
> On 2008-12-18, 19:55 GMT, Rex Dieter wrote:
>> pyexiv2: 
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=75466
> 
> I am trying to understand it, but more and more I look into it, 
> more it looks like there is something wrong with your package:
...
> What happened to Exiv2::Thumbnail?

The API changed a lot. See 
http://uk.groups.yahoo.com/group/exiv2/message/1335 for example.

- Mike



From adamwill at shaw.ca  Fri Dec 19 17:49:44 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Fri, 19 Dec 2008 09:49:44 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229707929.23410.63.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
Message-ID: <1229708984.24419.641.camel@lenovo.local.net>

On Fri, 2008-12-19 at 12:32 -0500, Dimi Paun wrote:
> On Fri, 2008-12-19 at 09:20 -0800, Adam Williamson wrote:
> > This is an insanely awesome idea, and I just wanted to reply so people
> > will see it twice, and remember it, and maybe something positive will
> > come out of the fiftieth incarnation of this silly argument. :)
> 
> Unfortunately even this will not be representative -- it's fairly well
> known that the vast majority of users will NOT bother to change the
> defaults, they will only like or dislike them.
> 
> If you are of the opinion that "who cares, you can flip a setting" you
> have no idea how users function.
> 
> If we want to be successful (especially with non-technical users
> migrating from other OSes), the most important point is to not change
> from expected behavior unless we have OVERWHELMING reason to do so.
> 
> Otherwise we confuse users and make them feel stupid. Nobody likes that,
> and they will resent us for it.

I still think it would be valuable data to have. Knowing what
preferences people actively dislike enough to change is a useful piece
of information, surely.
-- 
adamw



From wwoods at redhat.com  Fri Dec 19 17:57:38 2008
From: wwoods at redhat.com (Will Woods)
Date: Fri, 19 Dec 2008 12:57:38 -0500
Subject: A way out of the update trap
In-Reply-To: <1229379987.3388.25.camel@metroid.rdu.redhat.com>
References: <604aa7910812121044g4c6e32f4h99dbf5b74e94dc3d@mail.gmail.com>
	<20081212195950.GA2866@free.fr>
	<604aa7910812121240q46058b61g98d329e250194797@mail.gmail.com>
	<6d06ce20812141000q60b74d1ehc1379aeedbd9b2ca@mail.gmail.com>
	<1229379987.3388.25.camel@metroid.rdu.redhat.com>
Message-ID: <1229709458.3403.30.camel@metroid.rdu.redhat.com>

On Mon, 2008-12-15 at 17:26 -0500, Will Woods wrote:
> On Sun, 2008-12-14 at 12:00 -0600, Jerry Amundson wrote:
> > On Fri, Dec 12, 2008 at 2:40 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> > > On Fri, Dec 12, 2008 at 10:59 AM, Patrice Dumas <pertusus at free.fr> wrote:
> > >> I'd propose, more largely @code, @base and dependencies.
> > >
> > > I think that's too broad a target to start with and you don't have the
> > > QA resourses in place to support a policy that broad.
> 
> Definitely too large.. but not by a lot.
> 
> > > Right now. I am asking us as a project to suck it up and identify a
> > > top functionality priority and to live within our means as it comes to
> > > existing QA expectations.
> 
> The informal Critical Path for current QA testing is: yum and its deps.
> 
> No matter how bad *other* things are broken, as long as yum works you
> can 'yum update' and download fixes. But if yum breaks, you have a
> Severity CFF issue [1].
> 
> Note that by "yum and its deps" I don't mean the actual "Requires:" on
> the 'yum' package, I mean "everything required to have yum run
> properly". So this includes stuff like - duh - networking. 
> 
> So, throw in NetworkManager and its deps. Like it or not, NetworkManager
> is the default network management system, and if it doesn't work, we are
> once again registering Severity CFF issues.
> 
> Since this discussion is about defining a *formal* critical path, I
> propose the following:
> 
> Bootloader: grub (yaboot on ppc), kernel, and all dependent packages.
> Networking: NetworkManager and all dependent packages.
> Update system: yum and all dependent packages.

A followup: here is the complete list of (source) packages in that set,
at least for F10-i386:

acl attr audit avahi basesystem bash bzip2 ca-certificates chkconfig
compat-db ConsoleKit coreutils cpio cracklib crontabs cryptsetup-luks
curl cyrus-sasl db4 dbus dbus-glib device-mapper-multipath dhcp dhcpv6
diffutils dirmngr dmidecode dmraid dnsmasq e2fsprogs elfutils ethtool
eventlog expat fedora-logos fedora-release fedora-release-notes file
filesystem findutils gamin gawk gcc gdbm glib2 glibc gnupg2 gpgme grep
grub gzip hal hal-info hdparm initscripts iproute iputils isomd5sum kbd
kernel keyutils krb5 less libcap libdaemon libdhcp libgcrypt
libgpg-error libidn libksba libnl libpcap libpng libselinux libsepol
libsmbios libssh2 libusb libx86 libxml2 linux-atm logrotate lua lvm2
MAKEDEV mdadm mingetty mkinitrd module-init-tools ncurses net-tools
NetworkManager nspr nss openldap openssl pam parted pciutils pcre
pinentry pm-utils PolicyKit popt ppp procps psmisc pth pygpgme python
python-iniparse python-urlgrabber radeontool readline rpm rsyslog sed
setup shadow-utils sqlite sysvinit tar tcp_wrappers texinfo tzdata udev
upstart util-linux-ng vbetool wpa_supplicant yum-metadata-parser zlib

No real surprises here, although there's a couple things that I hadn't
really thought about before: gamin, for instance. And lua? Oh yeah, RPM
has an embedded lua interpreter, doesn't it.

So that would be the proposed list of Really Important Packages.

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3153 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/09b0895e/attachment.bin>

From jkeating at redhat.com  Fri Dec 19 18:11:02 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Dec 2008 10:11:02 -0800
Subject: [Fedora Update] [stable] rcsslogplayer-13.1.0-1.fc8
In-Reply-To: <20081219134916.970A020876A@bastion.fedora.phx.redhat.com>
References: <20081219134916.970A020876A@bastion.fedora.phx.redhat.com>
Message-ID: <1229710262.5263.5.camel@localhost.localdomain>

On Fri, 2008-12-19 at 13:49 +0000, updates at fedoraproject.org wrote:
> hedayat has requested the pushing of the following update stable:
> 
> ================================================================================
>      rcsslogplayer-13.1.0-1.fc8
> ================================================================================
>     Release: Fedora 8
>      Status: pending
>        Type: enhancement
>       Karma: 0
>     Request: stable
>       Notes: New upstream version (13.1.0)
>   Submitter: hedayat
>   Submitted: 2008-12-19 13:49:16
>    Comments: hedayat - 2008-12-19 13:49:16 (karma 0)
>              This update has been submitted for stable
> 
>   http://admin.fedoraproject.org/updates/rcsslogplayer-13.1.0-1.fc8
> 

What is this update for?  What should the user expect from it, or what
should they test in it?  Please fill in some details so that users will
be informed.

Also, seriously, why is this being submitted to go directly to stable,
on F8, a platform that is in it's last weeks of life?

The same question goes for the rcssserver update.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/654610f0/attachment.sig>

From mschwendt at gmail.com  Fri Dec 19 18:35:59 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 19 Dec 2008 19:35:59 +0100
Subject: rawhide report: 20081219 changes
In-Reply-To: <1229705706.6392.274.camel@code.and.org>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
	<20081219124034.49c5cd5c.mschwendt@gmail.com>
	<1229705706.6392.274.camel@code.and.org>
Message-ID: <20081219193559.ff47002a.mschwendt@gmail.com>

On Fri, 19 Dec 2008 11:55:06 -0500, James wrote:

>  Actually it's in yum itself now, I think this is the fix:

My full fix proposal is in upstream trac, #6.
One patch for yum, a 2nd one for yum-utils.



From john5342 at googlemail.com  Fri Dec 19 18:38:38 2008
From: john5342 at googlemail.com (John5342)
Date: Fri, 19 Dec 2008 18:38:38 +0000
Subject: Amarok 2 on F9
In-Reply-To: <2a28d2ab0812190912p64d392a1i956341afbf0ee1d4@mail.gmail.com>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gieuf2$uok$1@ger.gmane.org>
	<8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
	<494B3ECC.6090404@rincon.com>
	<7f692fec0812190848o26980f92wd76d9eee9dabc7f7@mail.gmail.com>
	<2a28d2ab0812190912p64d392a1i956341afbf0ee1d4@mail.gmail.com>
Message-ID: <6dc6523c0812191038y2c99a826h650ad197a406577d@mail.gmail.com>

2008/12/19 Dr. Diesel <dr.diesel at gmail.com>

>
>
> On Fri, Dec 19, 2008 at 11:48 AM, Yaakov Nemoy <loupgaroublond at gmail.com>wrote:
>
>> 2008/12/19 Bob Arendt <rda at rincon.com>:
>> > Oscar<Soker> wrote:
>> >>
>> >> Plz don't do that, Amarok 2 is not as goog as Amarok 1.4 it loose a lot
>> of
>> >> functionality
>> >>
>> > +1
>> > Amarok 2 is missing some this 1.4 has:
>> >  doesn't have UMS media player support.  Bug 473807
>> >  doesn't ship documentation. Bug 473522
>> > *Please* do not "upgrade" f9 to Amarok2
>>
>> We don't vote on mailing lists.  If you would like to use a particular
>> package version though, we do have alternatives:
>
>
>
> Have you been sleeping the past few days?  How about the call/vote from the
> Fedora group on Nautilus?
>

And that thread is a prime example of _why_ we don't vote on mailing lists.

-- 
There are 10 kinds of people in the world: Those who understand binary and
those who don't...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/dce371c0/attachment.htm>

From limb at jcomserv.net  Fri Dec 19 18:57:16 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 19 Dec 2008 12:57:16 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <20081219180021.GK14821@yellowpig>
References: <a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
	<eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
	<91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>
	<c36581a7b59348d68dbdecd9d018da71.squirrel@mail.jcomserv.net>
	<494AA62E.7040304@howardsilvan.com> <20081219143900.GG14821@yellowpig>
	<494BD944.8080403@jcomserv.net> <20081219180021.GK14821@yellowpig>
Message-ID: <9681e0e44e3ccec6ce3f1a7e084e2b44.squirrel@mail.jcomserv.net>


> On Fri, Dec 19, 2008 at 11:26:28AM -0600, Jon Ciesla wrote:
>> Bill Allombert wrote:
>> >On Thu, Dec 18, 2008 at 11:36:14AM -0800, Lee Howard wrote:
>> >
>> >>Jon Ciesla wrote:
>> >>
>> >>>What about simply keeping it on Sourceforge?  Don't one of you have
>> admin
>> >>>access to the project there?  I have a SF account currently.
>> >>>
>> >>>As far as bringing libjpeg current, I'm not sure the task would be as
>> >>>herculean as it sounds, activities at fd.o hotwithstanding, not sure
>> what
>> >>>that's about.
>> >>>
>> >>libjpeg is essentially dead.
>> >>
>> >
>> >I disagree with this statement. Upstream is very responsive. However
>> >he is not inclined to put out new release currently, bu thti sdoes not
>> >qualify libjpeg as essentially dead as far as I am concerned.
>> >
>> >
>> Who is 'he' in this case?
>
> Sorry, I meant Guido Vollbeding.

Who's been CCd on this entire thread, spanning many days, and has yet to
reply?  !responsive.

> Cheers,
> --
> Bill. <ballombe at debian.org>
>
> Imagine a large red swirl here.
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From hedayat at grad.com  Fri Dec 19 19:06:15 2008
From: hedayat at grad.com (Hedayat Vatnakhah)
Date: Fri, 19 Dec 2008 22:36:15 +0330
Subject: [Fedora Update] [stable] rcsslogplayer-13.1.0-1.fc8
In-Reply-To: <1229710262.5263.5.camel@localhost.localdomain>
References: <20081219134916.970A020876A@bastion.fedora.phx.redhat.com>
	<1229710262.5263.5.camel@localhost.localdomain>
Message-ID: <494BF0A7.8030302@grad.com>

Hi,

/*Jesse Keating <jkeating at redhat.com>*/ wrote on ??/??/?? 09:41:02:
> On Fri, 2008-12-19 at 13:49 +0000, updates at fedoraproject.org wrote:
>   
>> hedayat has requested the pushing of the following update stable:
>>
>> ================================================================================
>>      rcsslogplayer-13.1.0-1.fc8
>> ================================================================================
>>     Release: Fedora 8
>>      Status: pending
>>        Type: enhancement
>>       Karma: 0
>>     Request: stable
>>       Notes: New upstream version (13.1.0)
>>   Submitter: hedayat
>>   Submitted: 2008-12-19 13:49:16
>>    Comments: hedayat - 2008-12-19 13:49:16 (karma 0)
>>              This update has been submitted for stable
>>
>>   http://admin.fedoraproject.org/updates/rcsslogplayer-13.1.0-1.fc8
>>
>>     
>
> What is this update for?  What should the user expect from it, or what
> should they test in it?  Please fill in some details so that users will
> be informed.
>   
OK, done.

> Also, seriously, why is this being submitted to go directly to stable,
> on F8, a platform that is in it's last weeks of life?
>   
Sine these updates do not come with many changes, and these packages
were stable enough during latest releases, I think these packages will not
show any unexpected behavior.
But anyway, if you think that it's not appropriate, I will submit them 
for testing.

Thanks

> The same question goes for the rcssserver update.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/ae10ef71/attachment.htm>

From chitlesh.goorah at gmail.com  Fri Dec 19 19:25:18 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Fri, 19 Dec 2008 20:25:18 +0100
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <20081215202939.GE23506@nostromo.devel.redhat.com>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>
	<4943D18E.60107@BitWagon.com>
	<20081215202939.GE23506@nostromo.devel.redhat.com>
Message-ID: <50baabb30812191125ga621fc5o426e0a46fa832564@mail.gmail.com>

On Mon, Dec 15, 2008 at 9:29 PM, Bill Nottingham < email hidden from
spam > wrote:
> Also, 'Electronics' seems vague ... 'Electronic Design'? 'EDA'?

I haven't yet updated the somps.xml since I'm waiting for more feedbacks.

I prefer "EDA".
however "EDA" on kpackagekit will confuse people how are not familiar
with the abbreviation EDA.
Thereby Electronic Design can be easily understood by both
non-electronic friendly and electronic amateurs.

Any other suggestions ?

Chitlesh



From rayvd at bludgeon.org  Fri Dec 19 19:20:58 2008
From: rayvd at bludgeon.org (Ray Van Dolson)
Date: Fri, 19 Dec 2008 11:20:58 -0800
Subject: Becoming a co-maintainer.  How? (proftpd)
Message-ID: <20081219192058.GA15838@bludgeon.org>

This is specifically in regards to the 'proftpd' package maintained by
Matthias Saou.  Anyone know if he's around?

I'm interested in becoming a co-maintainer for this package.  I haven't
tried recently to contact Matthias (I will), but past attempts have not
been answered and quite a few proftpd bugs are sitting open[1] -- there
hasn't been an update to the package for a long time.  I don't
necessarily want to become the sole maintainer (although maybe), but
have the following questions I wasn't able to easily find the answers
to on the wiki:

  - How can I see who currently are maintainers and comaintainers for a
    package?
  - Is there a process to become a co-maintainer of a package when the
    primary maintainer is absent?
  - As a 'provenpackager' would it be acceptable for me to push a new
    release of proftpd if I have commit access even though I'm not
    officially a maintainer?

Thanks,
Ray

[1] https://admin.fedoraproject.org/pkgdb/packages/bugs/proftpd



From bkoz at redhat.com  Fri Dec 19 19:35:28 2008
From: bkoz at redhat.com (Benjamin Kosnik)
Date: Fri, 19 Dec 2008 11:35:28 -0800
Subject: boost rebuild status
In-Reply-To: <gifmcp$kb3$3@ger.gmane.org>
References: <20081218011435.03690d24@balbo.artheist.org>
	<a9d183c80812190025w27c81bb4hf2d543b4a3fbf375@mail.gmail.com>
	<gifmcp$kb3$3@ger.gmane.org>
Message-ID: <20081219113528.7bfaddb5@balbo.artheist.org>

 
> Well, those don't have broken deps, so they don't actually _have_ to
> be rebuilt now. (Still, they should get rebuilt to check that they
> still build.)

Exactly. We are just trying to do an initial triage at the moment, so
that the update to boost-1.37.0 does not leave all these deps
broken over the holiday break.

We're almost there!

I did the initial list with repoquery. I see now that there are python
scripts to do this more accurately. (Will use these in the future,
would be great to have this functionality directly with the basic
tools.)

-benjamin



From pertusus at free.fr  Fri Dec 19 19:38:53 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 19 Dec 2008 20:38:53 +0100
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <20081219192058.GA15838@bludgeon.org>
References: <20081219192058.GA15838@bludgeon.org>
Message-ID: <20081219193853.GC2283@free.fr>

On Fri, Dec 19, 2008 at 11:20:58AM -0800, Ray Van Dolson wrote:
> This is specifically in regards to the 'proftpd' package maintained by
> Matthias Saou.  Anyone know if he's around?

I hope that he's still around... In any case he doesn't seems to be very 
active.
 
>   - How can I see who currently are maintainers and comaintainers for a
>     package?

This one is easy, just go to 
https://admin.fedoraproject.org/pkgdb/
and search for proftpd. Or directly use the package url explained
on
http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb#What.27s_the_fastest_way_to_find_a_package.3F

>   - Is there a process to become a co-maintainer of a package when the
>     primary maintainer is absent?

If the primary maintainer is absent there is a policy:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

>   - As a 'provenpackager' would it be acceptable for me to push a new
>     release of proftpd if I have commit access even though I'm not
>     officially a maintainer?

This is also covered by a policy:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages

--
Pat



From jspaleta at gmail.com  Fri Dec 19 19:43:00 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 19 Dec 2008 10:43:00 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229690952.3971.36.camel@hughsie-work.lan>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<28c555e2af7bce3d43b2c4c9e99958af.squirrel@mail.shredzone.net>
	<6e24a8e80812190442i3c9ad67cw50ee0eb501b875b2@mail.gmail.com>
	<1229690952.3971.36.camel@hughsie-work.lan>
Message-ID: <604aa7910812191143m135976fk1c3d44e04e097fb2@mail.gmail.com>

On Fri, Dec 19, 2008 at 3:49 AM, Richard Hughes <hughsient at gmail.com> wrote:
> You can keep your home directory on another partition. You just
> nuke /boot and / and just point the installer at /home (but don't format
> it). I've been doing that for years.

Does this mean we get to start a new flamewar over the default
partitioning scheme now?

-jef"how do we chart a course between passion and civility? Perhaps if
we enforced a rule that all posts to must be in a form of poetic
meter. Poetic markdown if you will. Maybe the rhythmic flow of Jazz
poetry would provide the swinging chill of rationed thought to heated
speech."spaleta



From pemboa at gmail.com  Fri Dec 19 19:43:29 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 19 Dec 2008 13:43:29 -0600
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <50baabb30812191125ga621fc5o426e0a46fa832564@mail.gmail.com>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>
	<4943D18E.60107@BitWagon.com>
	<20081215202939.GE23506@nostromo.devel.redhat.com>
	<50baabb30812191125ga621fc5o426e0a46fa832564@mail.gmail.com>
Message-ID: <16de708d0812191143s788304e6o8bbb1e1a53b1ad53@mail.gmail.com>

On Fri, Dec 19, 2008 at 1:25 PM, Chitlesh GOORAH
<chitlesh.goorah at gmail.com> wrote:
> On Mon, Dec 15, 2008 at 9:29 PM, Bill Nottingham < email hidden from
> spam > wrote:
>> Also, 'Electronics' seems vague ... 'Electronic Design'? 'EDA'?
>
> I haven't yet updated the somps.xml since I'm waiting for more feedbacks.
>
> I prefer "EDA".
> however "EDA" on kpackagekit will confuse people how are not familiar
> with the abbreviation EDA.
> Thereby Electronic Design can be easily understood by both
> non-electronic friendly and electronic amateurs.
>
> Any other suggestions ?

Just that I wouldn't have guesses Electronics anything from the abbreviation EDA

Do individual comps groups have descriptions by the way?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mw_triad at users.sourceforge.net  Fri Dec 19 19:44:31 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 19 Dec 2008 13:44:31 -0600
Subject: Amarok 2 on F9
In-Reply-To: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
Message-ID: <gigtj0$pkc$1@ger.gmane.org>

Joshua C. wrote:
> I recompiled amarok-2.0.2.fc10 for f9 just to try it. Before this i
> had to recompile mysql-embedded for f9 (source is in koji for f10)
> because in f9 there is no mysql-embedded. I also needed to recompile
> libmtp-0.3.4 for f9. So far it is working fine. Since the kde versions
> in f10 and  f9 are identical can the maintainer officially publich it
> for f9?

Why? If we were three months from a release, and talking about the 
current release (i.e. f10), and there was a compelling reason to upgrade 
(e.g. I really hope KDE 4.2 can get pushed to f10 :-) ), that would be 
one thing. In this case, users that want amarok2 can, and IMO should, 
use f10. I don't see the reason to push a major update to a non-current 
release.

(Put another way, would you support pushing OOo3 to f9?)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while 
in a KDE session. And nothing bad happened whatsoever. Try THAT on 
Windows :-D.



From dan at danny.cz  Fri Dec 19 19:44:43 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Fri, 19 Dec 2008 20:44:43 +0100
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <20081219192058.GA15838@bludgeon.org>
References: <20081219192058.GA15838@bludgeon.org>
Message-ID: <1229715883.4043.17.camel@eagle.danny.cz>

Ray Van Dolson p??e v P? 19. 12. 2008 v 11:20 -0800: 
> This is specifically in regards to the 'proftpd' package maintained by
> Matthias Saou.  Anyone know if he's around?
> 

He is, but only sporadically.

> I'm interested in becoming a co-maintainer for this package.  I haven't
> tried recently to contact Matthias (I will), but past attempts have not

Try it with a personal e-mail, I got in contact with him that way.

> been answered and quite a few proftpd bugs are sitting open[1] -- there
> hasn't been an update to the package for a long time.  I don't
> necessarily want to become the sole maintainer (although maybe), but
> have the following questions I wasn't able to easily find the answers
> to on the wiki:
> 
>   - How can I see who currently are maintainers and comaintainers for a
>     package?

all info is in pkgdb  - https://admin.fedoraproject.org/pkgdb/
e.g. https://admin.fedoraproject.org/pkgdb/packages/name/proftpd


		Dan




From vonbrand at inf.utfsm.cl  Fri Dec 19 19:46:48 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 19 Dec 2008 16:46:48 -0300
Subject: Distribuion hopping [Was: Re: Call for vote: Nautilus use Browser
	view for fedora 11]
In-Reply-To: <6e24a8e80812190442i3c9ad67cw50ee0eb501b875b2@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<28c555e2af7bce3d43b2c4c9e99958af.squirrel@mail.shredzone.net>
	<6e24a8e80812190442i3c9ad67cw50ee0eb501b875b2@mail.gmail.com>
Message-ID: <200812191946.mBJJkmru001290@laptop14.inf.utfsm.cl>

Mark <markg85 at gmail.com> wrote:
> On Fri, Dec 19, 2008 at 10:32 AM, Richard K??rber <fedora at ml.shredzone.de>
> wrote:

[...]

> > But seriously, who cares? If you dislike the folder/browser view, just
> > configure it the way you like it. How often do you need to reconfigure
> > your Gnome? My Gnome settings are a couple of years old now.

> then you keep your dist long. i mostly install (or re-install) my
> linux once every 2 months on several pc's and that's to try out new
> releases of various distributions.

Don't worry, that normally goes away soon.

[Trying out every new distribution under the sun means  you never get to
 really know any one (and thus you won't be able to use it fully). Plus you
 lose lots of time in relearning/redoing stuff (you note that above).
 Thankfully, all distributions are built out of more or less the same
 packages, so it isn't that any one is spectacularly better (or worse) than
 the rest, which one you pick is not worth agonizing over...]

> then changing the same things all over again (going that way for years
> now) is getting irritating.

Years... then yours is a specially complex case...

I'd suggest you try staying put for at least one full Fedora lifetime (here
or somewhere else, but stay put).

Good luck!
-- 
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 rayvd at bludgeon.org  Fri Dec 19 19:48:25 2008
From: rayvd at bludgeon.org (Ray Van Dolson)
Date: Fri, 19 Dec 2008 11:48:25 -0800
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <20081219193853.GC2283@free.fr>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
Message-ID: <20081219194825.GA16284@bludgeon.org>

On Fri, Dec 19, 2008 at 08:38:53PM +0100, Patrice Dumas wrote:
> On Fri, Dec 19, 2008 at 11:20:58AM -0800, Ray Van Dolson wrote:
> > This is specifically in regards to the 'proftpd' package maintained by
> > Matthias Saou.  Anyone know if he's around?
> 
> I hope that he's still around... In any case he doesn't seems to be very 
> active.
>  
> >   - How can I see who currently are maintainers and comaintainers for a
> >     package?
> 
> This one is easy, just go to 
> https://admin.fedoraproject.org/pkgdb/
> and search for proftpd. Or directly use the package url explained
> on
> http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb#What.27s_the_fastest_way_to_find_a_package.3F

>From https://admin.fedoraproject.org/pkgdb/packages/name/proftpd I only
see the Owner columns set to 'thias'.  Does this mean there are no
co-maintainers defined?

> >   - Is there a process to become a co-maintainer of a package when the
> >     primary maintainer is absent?
> 
> If the primary maintainer is absent there is a policy:
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

This would be a procedure to become the primary maintainer.  I am just
wanting to be added as a co-maintainer, not necessarily to supplant
Matthias... though I guess I will initiate this process nonetheless.

I guess I'm just wondering if someone out there could add me as a co
maintainer for the package -- thus saving some time over the non
responsive procedure and letting Matthias stay the owner if he returns.

> >   - As a 'provenpackager' would it be acceptable for me to push a new
> >     release of proftpd if I have commit access even though I'm not
> >     officially a maintainer?
> 
> This is also covered by a policy:
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages

Thanks!

Ray



From jkeating at redhat.com  Fri Dec 19 19:48:58 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Dec 2008 11:48:58 -0800
Subject: [Fedora Update] [stable] rcsslogplayer-13.1.0-1.fc8
In-Reply-To: <494BF0A7.8030302@grad.com>
References: <20081219134916.970A020876A@bastion.fedora.phx.redhat.com>
	<1229710262.5263.5.camel@localhost.localdomain>
	<494BF0A7.8030302@grad.com>
Message-ID: <1229716138.5263.7.camel@localhost.localdomain>

On Fri, 2008-12-19 at 22:36 +0330, Hedayat Vatnakhah wrote:
> Sine these updates do not come with many changes, and these packages
> were stable enough during latest releases, I think these packages will not
> show any unexpected behavior.
> But anyway, if you think that it's not appropriate, I will submit them 
> for testing.

It's up to you to use your best judgment, but you should share that
judgment with your users in the form of the bodhi notes, so that they
can understand why you made that decision.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/0dd769bd/attachment.sig>

From langel at redhat.com  Fri Dec 19 20:03:42 2008
From: langel at redhat.com (Lillian Angel)
Date: Fri, 19 Dec 2008 15:03:42 -0500
Subject: Orphaning azureus
In-Reply-To: <d3ceea380812190914o369d6970le475ffa2b544ead8@mail.gmail.com>
References: <20081024190916.A41D98E0003@hormel.redhat.com>	<200811252018.15095.konrad@tylerc.org>
	<492D0AD0.5070408@gmail.com>	<200811260048.49879.konrad@tylerc.org>
	<494BCDF6.4000008@redhat.com>
	<d3ceea380812190914o369d6970le475ffa2b544ead8@mail.gmail.com>
Message-ID: <494BFE1E.6010702@redhat.com>

Itamar Reis Peixoto wrote:
> http://azureus.sourceforge.net/
>
>
> azureus is now called Vuze
>
>
> what you think about letting azureus orphaned and submiting  Vuze for review ?
>   

That is fine, but someone will have to re-adapt the azureus spec file 
accordingly and submit it for review.


Lillian

>
>
> On Fri, Dec 19, 2008 at 2:38 PM, Lillian Angel <langel at redhat.com> wrote:
>   
>> Conrad Meyer wrote:
>>     
>>> On Wednesday 26 November 2008 12:37:36 am Alphonse Van Assche wrote:
>>>
>>>       
>>>> Conrad Meyer a ?crit :
>>>>
>>>>         
>>>>> Do you still want this? If so please take it in pkgdb. If not I have an
>>>>> interest.
>>>>>
>>>>>           
>>>> Yes, but if you will we can maintain it together.
>>>>
>>>> ps: Once I can reset my fas account I will add me as (co)maintainer of
>>>> azureus, I'm not at home and don't know my pwd from head.
>>>>
>>>> Alphonse
>>>>
>>>>         
>>> I'd be glad to take comaintainership here. Thanks!
>>>
>>>
>>>       
>> The package is still an orphan for F-9, F-10 and devel. Please feel free to
>> take it:
>> https://admin.fedoraproject.org/pkgdb/packages/name/azureus
>>
>>
>> Lillian
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>>     
>
>
>
>   



From a.badger at gmail.com  Fri Dec 19 20:06:38 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 19 Dec 2008 12:06:38 -0800
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <20081219194825.GA16284@bludgeon.org>
References: <20081219192058.GA15838@bludgeon.org>	<20081219193853.GC2283@free.fr>
	<20081219194825.GA16284@bludgeon.org>
Message-ID: <494BFECE.4050003@gmail.com>

Ray Van Dolson wrote:
> On Fri, Dec 19, 2008 at 08:38:53PM +0100, Patrice Dumas wrote:
>> On Fri, Dec 19, 2008 at 11:20:58AM -0800, Ray Van Dolson wrote:
>>> This is specifically in regards to the 'proftpd' package maintained by
>>> Matthias Saou.  Anyone know if he's around?
>> I hope that he's still around... In any case he doesn't seems to be very 
>> active.
>>  
>>>   - How can I see who currently are maintainers and comaintainers for a
>>>     package?
>> This one is easy, just go to 
>> https://admin.fedoraproject.org/pkgdb/
>> and search for proftpd. Or directly use the package url explained
>> on
>> http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb#What.27s_the_fastest_way_to_find_a_package.3F
> 
>>From https://admin.fedoraproject.org/pkgdb/packages/name/proftpd I only
> see the Owner columns set to 'thias'.  Does this mean there are no
> co-maintainers defined?
> 
Correct.

>>>   - Is there a process to become a co-maintainer of a package when the
>>>     primary maintainer is absent?
>> If the primary maintainer is absent there is a policy:
>> http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
> 
> This would be a procedure to become the primary maintainer.  I am just
> wanting to be added as a co-maintainer, not necessarily to supplant
> Matthias... though I guess I will initiate this process nonetheless.
> 
> I guess I'm just wondering if someone out there could add me as a co
> maintainer for the package -- thus saving some time over the non
> responsive procedure and letting Matthias stay the owner if he returns.
> 
There isn't but there should be.  Rahul started to put together a policy
for that that would have modified the NonResponsiveMaintainers policy.
It was not approved by FESCo but I don't remember what the sticking
points were.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/e37f0304/attachment.sig>

From jspaleta at gmail.com  Fri Dec 19 20:10:54 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 19 Dec 2008 11:10:54 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229708984.24419.641.camel@lenovo.local.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<1229708984.24419.641.camel@lenovo.local.net>
Message-ID: <604aa7910812191210sc97ec62rd6e39e3c4771d31f@mail.gmail.com>

On Fri, Dec 19, 2008 at 8:49 AM, Adam Williamson <adamwill at shaw.ca> wrote:
> I still think it would be valuable data to have. Knowing what
> preferences people actively dislike enough to change is a useful piece
> of information, surely.

"dislike" is a value judgement and an assumption.  "change" is what
you can record.... you have to then follow up and figure out "why" it
changed.  Don't assume you know why. First find out what people are
changing.  Then you have to try to profile real world users who
represent the design categories you were design for.  Then you have to
see of those people who correlate well with the target use cases are
making changes to the defaults and ask them "why".

It does not matter if 90% of the users who flip the default settings
to something else are distinctly NOT the design target.  It does not
matter if 90% of the people who are currently using GNOME flip the
default settings.  What matters is if the use cases you are targeting
with the defaults use the defaults.

You can not design for everyone.  You can not design for a majority of
people. All good design choices serve some minority of existing
preferences, and the rest of us adapt. You design for a set of usage
cases and you narrowly focus design adjustments based on feedback from
people who closely align with the usage case you are targetting.

The other valid question that people are not asking themselves is
this. Are you part of GNOME's target? If not why are you using GNOME?

Let me take a second and do what I love doing best, talking about me.
I know with great certainty that my usage patterns are not a use case
that any existing modern desktop relevant tools is going to design
for.  I am absolutely unrepresentative of the target audience that
GNOME is designing for.  Does it matter if I use spatial or not as a
design choice? Not a bit. Not one iota.  Like pretty much every other
computer tool or physical object I have to manipulate on a day to day
basis... none of them are designed for my breath-takingly large
intellect.  Everything I do is done inefficiently because of design
choices made to accommodate some aspect of the see of mediocrity in
which I swim.  Its a singular burden that I must bare.

So why do I use GNOME? Because I am equally sure that every other
desktop environment is going to suck for me in some other way.  Every
bikeshed serves equally well as shelter for my junk. I've no need to
haul my gear around to different bikesheds looking for the one I think
smells slightly better or has the freshest coat of paint.  But I do
like the smell of fresh paint. Don't you?

-jef"do you know where I put my car keys?"spaleta



From adamwill at shaw.ca  Fri Dec 19 20:15:40 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Fri, 19 Dec 2008 12:15:40 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812191210sc97ec62rd6e39e3c4771d31f@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<1229708984.24419.641.camel@lenovo.local.net>
	<604aa7910812191210sc97ec62rd6e39e3c4771d31f@mail.gmail.com>
Message-ID: <1229717740.24419.660.camel@lenovo.local.net>

On Fri, 2008-12-19 at 11:10 -0900, Jeff Spaleta wrote:
> On Fri, Dec 19, 2008 at 8:49 AM, Adam Williamson <adamwill at shaw.ca> wrote:
> > I still think it would be valuable data to have. Knowing what
> > preferences people actively dislike enough to change is a useful piece
> > of information, surely.
> 
> "dislike" is a value judgement and an assumption.

You're right, of course. Sorry for the shorthand. At all events, I like
your proposal. :) And all this discussion is making it more visible,
which was my goal in replying to your post. Yay!
-- 
adamw



From vonbrand at inf.utfsm.cl  Fri Dec 19 20:17:31 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 19 Dec 2008 17:17:31 -0300
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <e5f36bc70812190831g67f8561alcad08138f29ec72f@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
	<1229701953.3741.131.camel@ignacio.lan>
	<e5f36bc70812190831g67f8561alcad08138f29ec72f@mail.gmail.com>
Message-ID: <200812192017.mBJKHVW7002019@laptop14.inf.utfsm.cl>

Thomas Bendler <ml at bendler-net.de> wrote:

> [Wants a vote here, as otherwise it is "designing without
>  numbers". Claims Google shows majority don't like spatial]

A vote here (where just the ones who feel strongly about the matter) is not
a way to find out what "the users" want/like.

And you surely realize that what Google finds is just the complaints of
those who _don't_ like it, those who like it won't go around commenting on
the feature. Besides, if Google shows a few hundred complaints, that is
still a tiny minority of Gnome users.
-- 
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 jspaleta at gmail.com  Fri Dec 19 20:20:13 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 19 Dec 2008 11:20:13 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229717740.24419.660.camel@lenovo.local.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<1229708984.24419.641.camel@lenovo.local.net>
	<604aa7910812191210sc97ec62rd6e39e3c4771d31f@mail.gmail.com>
	<1229717740.24419.660.camel@lenovo.local.net>
Message-ID: <604aa7910812191220y7fd1e645vacadba97ce339937@mail.gmail.com>

On Fri, Dec 19, 2008 at 11:15 AM, Adam Williamson <adamwill at shaw.ca> wrote:
> You're right, of course. Sorry for the shorthand. At all events, I like
> your proposal. :) And all this discussion is making it more visible,
> which was my goal in replying to your post. Yay!

I will say that the existence of the netbook as a new usage case may
bring some new focus to a number of established GNOME design choices.
If upstream GNOME wants to be relevant for these crammed interface
devices... new design choices will need to be made. And we as
distributors will have to adapt accordingly as well.

-jef



From loupgaroublond at gmail.com  Fri Dec 19 20:20:46 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 19 Dec 2008 15:20:46 -0500
Subject: Amarok 2 on F9
In-Reply-To: <gigtj0$pkc$1@ger.gmane.org>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gigtj0$pkc$1@ger.gmane.org>
Message-ID: <7f692fec0812191220u5f513089ie01e0495da85d78e@mail.gmail.com>

2008/12/19 Matthew Woehlke <mw_triad at users.sourceforge.net>:
> Joshua C. wrote:
>>
>> I recompiled amarok-2.0.2.fc10 for f9 just to try it. Before this i
>> had to recompile mysql-embedded for f9 (source is in koji for f10)
>> because in f9 there is no mysql-embedded. I also needed to recompile
>> libmtp-0.3.4 for f9. So far it is working fine. Since the kde versions
>> in f10 and  f9 are identical can the maintainer officially publich it
>> for f9?
>
> Why? If we were three months from a release, and talking about the current
> release (i.e. f10), and there was a compelling reason to upgrade (e.g. I
> really hope KDE 4.2 can get pushed to f10 :-) ), that would be one thing. In
> this case, users that want amarok2 can, and IMO should, use f10. I don't see
> the reason to push a major update to a non-current release.

Fedora 9 is a current release.

> (Put another way, would you support pushing OOo3 to f9?)

If the OOo maintainer did not want to support security fixes for two
branches of OOo, then by all means.  If the maintainer decided to
support two branches on two Fedora versions, that might be
questionable, but if he could support both side by side, that would be
much nicer.  Even so, that's really up for the maintainer to decide.

This is the definition of a meritocracy. If this bothers you, you have
several options, most of which petitioning this mailing list isn't
desirable or optimal.  The other thread going around is a perfect
example of why we don't want this.  The phrase "the inmates are
running the asylum" come to mind.

-Yaakov
>
> --
> Matthew
> Please do not quote my e-mail address unobfuscated in message bodies.
> --
> I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in
> a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From loupgaroublond at gmail.com  Fri Dec 19 20:23:38 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 19 Dec 2008 15:23:38 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <1229704828.24417.0.camel@matthiasc>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<1229704828.24417.0.camel@matthiasc>
Message-ID: <7f692fec0812191223o524eb1b3ub0b3178f8bd788ca@mail.gmail.com>

2008/12/19 Matthias Clasen <mclasen at redhat.com>:
> On Thu, 2008-12-18 at 08:23 -0500, Matthias Clasen wrote:
>> On Thu, 2008-12-18 at 02:19 -0500, Yaakov Nemoy wrote:
>> >
>> > In short, the new gnome session configuration dialog is alot simpler
>> > and alot less confusing, but it gives us no simple way to give
>> > metacity the boot on a per session basis.  How do i go about doing
>> > this via an RPM?
>>
>> The required components should just be a fallback in case the session
>> didn't contain a window manager, file manager, etc. At least that is my
>> understanding of how they're supposed to be used. So, you should just
>> install an autostart file for xmonad that marks it as a window manager
>> via
>>
>> X-GNOME-Autostart-Phase=WindowManager
>> X-GNOME-Provides=windowmanager
>>
>> then your users should be able to switch their sessions to xmonad by
>> turning it on in the session capplet.
>
> Just tried this with openbox, and it works fine.

At this point, i don't care about openbox.  Openbox complies with
certain standards that the xmonad devs decided are a waste of lines of
code.  All i'm looking to do is convince gnome that it doesn't need a
window manager at all.  In the older versions of gnome, metacity
showed up as just yet another app in the sessions-capplet.  Not
anymore.

-Yaakov



From lesmikesell at gmail.com  Fri Dec 19 20:35:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 19 Dec 2008 14:35:51 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229707929.23410.63.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>	<494B0738.1040409@cchtml.com>
	<200812181915.13192.konrad@tylerc.org>	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
Message-ID: <494C05A7.6070102@gmail.com>

Dimi Paun wrote:
> 
> If we want to be successful (especially with non-technical users
> migrating from other OSes), the most important point is to not change
> from expected behavior unless we have OVERWHELMING reason to do so.

What's expected behavior?  The way Fedora 1 worked?  The way MS windows 
works?  The way a Mac works?  I can't say that I've ever expected 
something to leave dozens of windows open trailing behind my navigation 
in places I don't want to be any more.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From martin.langhoff at gmail.com  Fri Dec 19 20:42:34 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 19 Dec 2008 18:42:34 -0200
Subject: rpm %post - check for version being upgraded
Message-ID: <46a038f90812191242s1d877989od13a6da7d682fbe2@mail.gmail.com>

This is a bit of advanced rpm trickery that probably falls in the
"don't do that" category. :-/

Short version:

   How do I query in %post, when executed during an upgrade,
   for the version we are upgrading from?

Long version:

A custom rpm (that OLPC's XS uses to manage configuration) needs to
nuke a dynamically generated config file -
/etc/udev/rules.d/70-persistent-net.rules - _only once_. Before
version 0.5 of the pkg, the script that drove the device naming was
subtly wrong.

The problem is: bad data is almost indistinguishable from good data.
So I can't make the condition just on the bad data, I want to also
check that we're upgrading from a known-bad version.

Users will face a small disruption - any manual tweaks of device
assignation will be lost, but we don't have many users. This will
change soon, so better break it now than later... :-)

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From mclasen at redhat.com  Fri Dec 19 20:43:28 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 19 Dec 2008 15:43:28 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <7f692fec0812191223o524eb1b3ub0b3178f8bd788ca@mail.gmail.com>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<1229704828.24417.0.camel@matthiasc>
	<7f692fec0812191223o524eb1b3ub0b3178f8bd788ca@mail.gmail.com>
Message-ID: <1229719408.24417.8.camel@matthiasc>

On Fri, 2008-12-19 at 15:23 -0500, Yaakov Nemoy wrote:
> 2008/12/19 Matthias Clasen <mclasen at redhat.com>:
> > On Thu, 2008-12-18 at 08:23 -0500, Matthias Clasen wrote:
> >> On Thu, 2008-12-18 at 02:19 -0500, Yaakov Nemoy wrote:
> >> >
> >> > In short, the new gnome session configuration dialog is alot simpler
> >> > and alot less confusing, but it gives us no simple way to give
> >> > metacity the boot on a per session basis.  How do i go about doing
> >> > this via an RPM?
> >>
> >> The required components should just be a fallback in case the session
> >> didn't contain a window manager, file manager, etc. At least that is my
> >> understanding of how they're supposed to be used. So, you should just
> >> install an autostart file for xmonad that marks it as a window manager
> >> via
> >>
> >> X-GNOME-Autostart-Phase=WindowManager
> >> X-GNOME-Provides=windowmanager
> >>
> >> then your users should be able to switch their sessions to xmonad by
> >> turning it on in the session capplet.
> >
> > Just tried this with openbox, and it works fine.
> 
> At this point, i don't care about openbox.  Openbox complies with
> certain standards that the xmonad devs decided are a waste of lines of
> code.  All i'm looking to do is convince gnome that it doesn't need a
> window manager at all.  In the older versions of gnome, metacity
> showed up as just yet another app in the sessions-capplet.  Not
> anymore.

I just tried it with openbox. If you do the same with xnomad, it will
work too. metacity doesn't show up in the session-capplet because it
doesn't install an autostart file, because gnome-session runs it as the
fallback to ensure that the required component 'windowmanager' is
present in the session.



From lesmikesell at gmail.com  Fri Dec 19 20:45:42 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 19 Dec 2008 14:45:42 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229692775.3209.670.camel@beck.corsepiu.local>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>
	<1229692775.3209.670.camel@beck.corsepiu.local>
Message-ID: <494C07F6.7050302@gmail.com>

Ralf Corsepius wrote:
> >>
>> why spatial mode was introduced ?
>> to make drag and drop easy
> Q: Does it? 
> 
> Yes, on big displays, with very few windows open.

Or for people who don't realize you can open _exactly_ two windows for 
this in browser mode whenever you need them...

>> the question now does people drag and drop more than they browse [open
>> folder to see them] ?
> When observing myself: First browsing, then "opening" is the
> overwhelming use-case. Drag and Drop is much seldom use-case.

This isn't an either/or issue.  If you want 2 windows to drag/drop in 
browser mode, just open 2 windows.  Works the same across 
Windows/Mac/KDE/Gnome.

If you have a decent multitasking OS and window system that lets you 
open as many instances as you want of whatever you want, why do people 
still think that apps need to deal with that stuff themselves?


-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Fri Dec 19 20:48:55 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 19 Dec 2008 14:48:55 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229634566.3300.2.camel@matthiasc>
	<giepf5$i12$1@ger.gmane.org>	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
	<6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>
Message-ID: <494C08B7.5010903@gmail.com>

Mark wrote:
> 
> btw. i never understood why Linus Torvalds was so opposed to Gnome.
> i'm beginning to understand why.

How much less RAM would your system need if everything shared one window 
toolkit?  And how much better could it be if all development had focused 
on just one?

-- 
   Les Miksell
    lesmikesell at gmail.com




From markg85 at gmail.com  Fri Dec 19 20:49:51 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 21:49:51 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <200812192017.mBJKHVW7002019@laptop14.inf.utfsm.cl>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
	<1229701953.3741.131.camel@ignacio.lan>
	<e5f36bc70812190831g67f8561alcad08138f29ec72f@mail.gmail.com>
	<200812192017.mBJKHVW7002019@laptop14.inf.utfsm.cl>
Message-ID: <6e24a8e80812191249h4191f5e4re7adb0ddaa47b418@mail.gmail.com>

On Fri, Dec 19, 2008 at 9:17 PM, Horst H. von Brand
<vonbrand at inf.utfsm.cl> wrote:
> Thomas Bendler <ml at bendler-net.de> wrote:
>
>> [Wants a vote here, as otherwise it is "designing without
>>  numbers". Claims Google shows majority don't like spatial]
>
> A vote here (where just the ones who feel strongly about the matter) is not
> a way to find out what "the users" want/like.
>
> And you surely realize that what Google finds is just the complaints of
> those who _don't_ like it, those who like it won't go around commenting on
> the feature. Besides, if Google shows a few hundred complaints, that is
> still a tiny minority of Gnome users.

What kind of crap is this reasoning?
According to you and various others there is no way to determine is a
feature is good or bad because only the ones that dislike it will post
messages (like me with this thread) and that minority is always just a
tiny fraction of the entire gnome community. That's what you said and
a few others only in my words.

So then how can you find out that a feature is bad? I would say you
can by looking at the number of criticism on a certain feature. If you
can find a lot of it it must be something that is carried by the
majority of the gnome community. Bug if you for example just find a
handful of criticism, for example look at the thumbnail size and how
many people you find for that begging to change it, then there is a
valid point in saying that there is just no majority to be found for
it.

In this case (spatial mode) you can find so much criticism on the
subject and so many people that don't want that as the default that
you can fairly easy say that the majority of the gnome users doesn't
like it and prefers the browser mode.

Just a few numbers as an example (all made up but to give the idea)
Imagine there are 20 million people worldwide using gnome (this is a
reasonable guess! both ubuntu and fedora have around 9 million users
all using gnome by default)
of those 20 million there is probably just between 1 and 0.1 percent
that is reading mailing lists and actively asking for support or
asking for a change.
And to write those numbers out. 1% = 200.000 ppl, 0.1% = 20.000 ppl
So. the maximum feedback that you can expect that would represent the
entire gnome community is between 20k ppl and 200k ppl. divide that by
2 to get the average nr of ppl that could post here if they read it
then you get a number of: 100.000 ppl. And those are divided over:
ubuntu, fedora, bla bla and bla.. to much distros to name. but lets
just take the biggest 2 and expect that the gnome community is only in
fedora and ubuntu. then you have a max number of ppl that could vote
and represent the gnome community of just 50.000 ppl. So fedora had a
theoretical chance (in this scenario) of getting 50.000 votes for
anything gnome related. and there will never be 50.000 ppl here on
this list. more like 1000. And that is getting close to the reality.
Then we have a 1/10 vote already (way more then 100 posts om this
subject but that with multiple posts included) And i frankly don't
think it's gonna get higher then 1/10. and i tent to believe that 1/10
in this case is indeed representing the majority of gnome in which
case this default setting has to change to browser mode.

Oke. i nearly lost myself in those numbers ^_^

This will also clear up that there is simply no way to see is there is
a majority for this or not. simply because the exact numbers of linux
users is not clear let alone the number of gnome users.
To me the best way to see if there is a mojority to change this
feature into the browser mode remains just by googling and see how
easy you can find discussion f it.



From jburgess777 at googlemail.com  Fri Dec 19 20:50:37 2008
From: jburgess777 at googlemail.com (Jon Burgess)
Date: Fri, 19 Dec 2008 20:50:37 +0000
Subject: boost rebuild status
In-Reply-To: <20081218204249.33a3adeb@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
	<20081218204249.33a3adeb@balbo.artheist.org>
Message-ID: <1229719837.28509.4.camel@localhost.localdomain>

On Thu, 2008-12-18 at 20:42 -0800, Benjamin Kosnik wrote:
> mapnik-0:0.5.2-0.7.svn738.fc10.i386
> mapnik-python-0:0.5.2-0.7.svn738.fc10.x86_64
> mapnik-utils-0:0.5.2-0.7.svn738.fc10.x86_64
>   bump Release, build fails:
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=1008473
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=1008570
> 
>   python/icuuc issues? 
>   Could not find header or shared library for icuuc, exiting!
> 

I took a look at rebuilding Mapnik last week and found that the failure
appeared to be due to a problem with scons and python-2.6. It looks like
there is a new scons-1.2 release imminent which should fix this.

For more details see:
https://bugzilla.redhat.com/show_bug.cgi?id=475903

	Jon




From markg85 at gmail.com  Fri Dec 19 20:55:06 2008
From: markg85 at gmail.com (Mark)
Date: Fri, 19 Dec 2008 21:55:06 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494C08B7.5010903@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc> <giepf5$i12$1@ger.gmane.org>
	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
	<6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>
	<494C08B7.5010903@gmail.com>
Message-ID: <6e24a8e80812191255m189b4032ta5991a2ca84ade88@mail.gmail.com>

On Fri, Dec 19, 2008 at 9:48 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Mark wrote:
>>
>> btw. i never understood why Linus Torvalds was so opposed to Gnome.
>> i'm beginning to understand why.
>
> How much less RAM would your system need if everything shared one window
> toolkit?  And how much better could it be if all development had focused on
> just one?
>
> --
>  Les Miksell
>   lesmikesell at gmail.com
>

Multiple toolkits is horrible but some desire it. there is no stopping
in that unless all but one change to a license that simply isn't for
linux (or closed source).
And the biggest ram eaters and cpu eaters are all those python scripts
that keep being pushed in more and more distros (you get the point)



From mw_triad at users.sourceforge.net  Fri Dec 19 20:55:27 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 19 Dec 2008 14:55:27 -0600
Subject: Amarok 2 on F9
In-Reply-To: <7f692fec0812191220u5f513089ie01e0495da85d78e@mail.gmail.com>
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>	<gigtj0$pkc$1@ger.gmane.org>
	<7f692fec0812191220u5f513089ie01e0495da85d78e@mail.gmail.com>
Message-ID: <gih1nv$73c$1@ger.gmane.org>

Yaakov Nemoy wrote:
> 2008/12/19 Matthew Woehlke <mw_triad at users.sourceforge.net>:
>> Joshua C. wrote:
>>> I recompiled amarok-2.0.2.fc10 for f9 just to try it. Before this i
>>> had to recompile mysql-embedded for f9 (source is in koji for f10)
>>> because in f9 there is no mysql-embedded. I also needed to recompile
>>> libmtp-0.3.4 for f9. So far it is working fine. Since the kde versions
>>> in f10 and  f9 are identical can the maintainer officially publich it
>>> for f9?
>> Why? If we were three months from a release, and talking about the current
>> release (i.e. f10), and there was a compelling reason to upgrade (e.g. I
>> really hope KDE 4.2 can get pushed to f10 :-) ), that would be one thing. In
>> this case, users that want amarok2 can, and IMO should, use f10. I don't see
>> the reason to push a major update to a non-current release.
> 
> Fedora 9 is a current release.

Sorry, s/current/latest/.

>> (Put another way, would you support pushing OOo3 to f9?)
> 
> If the OOo maintainer did not want to support security fixes for two
> branches of OOo, then by all means.

Who said anything about not supporting security fixes?

> This is the definition of a meritocracy.

I don't follow? This is about pushing a .0 package representing a major 
upgrade (among other things, a change of toolkit!) in the middle of a 
stable release.

To quote Rex Dieter, "I'd tend to be against that. A major upgrade like 
that in the middle of a release cycle is unwise." All I was saying is 
that I agree with this.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while 
in a KDE session. And nothing bad happened whatsoever. Try THAT on 
Windows :-D.



From dimi at lattica.com  Fri Dec 19 20:45:50 2008
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 19 Dec 2008 15:45:50 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494C05A7.6070102@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
Message-ID: <1229719550.23410.79.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 14:35 -0600, Les Mikesell wrote:
> What's expected behavior?  The way Fedora 1 worked?  The way MS
> windows works?  The way a Mac works? 

That's not a hard question to answer: 95%+ of users are used to a browse
mode, not a "spacial" mode. Like it or not, this is what people use, and
from what I've seen most users are very upset when forced to change.

> I can't say that I've ever expected something to leave dozens of
> windows open trailing behind my navigation in places I don't want to
> be any more.

Of course not, this is the point of the entire debate: it is not a
reasonable default, and should be changed.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From jos at xos.nl  Fri Dec 19 21:15:34 2008
From: jos at xos.nl (Jos Vos)
Date: Fri, 19 Dec 2008 22:15:34 +0100
Subject: rpm %post - check for version being upgraded
In-Reply-To: <46a038f90812191242s1d877989od13a6da7d682fbe2@mail.gmail.com>
References: <46a038f90812191242s1d877989od13a6da7d682fbe2@mail.gmail.com>
Message-ID: <20081219211534.GA21079@jasmine.xos.nl>

On Fri, Dec 19, 2008 at 06:42:34PM -0200, Martin Langhoff wrote:

>    How do I query in %post, when executed during an upgrade,
>    for the version we are upgrading from?

You can't.

But I think you can do what you want via a trigger script like this:

   %triggerpostun -- yourpkg < 0.5
   # do what you want

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From jkeating at redhat.com  Fri Dec 19 21:41:18 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Dec 2008 13:41:18 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229719550.23410.79.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
Message-ID: <1229722878.3861.0.camel@localhost.localdomain>

On Fri, 2008-12-19 at 15:45 -0500, Dimi Paun wrote:
> 95%+

98%+ prefer orange to blue.  We need to change!
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/9a93be1a/attachment.sig>

From dimi at lattica.com  Fri Dec 19 21:47:52 2008
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 19 Dec 2008 16:47:52 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229722878.3861.0.camel@localhost.localdomain>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
Message-ID: <1229723272.23410.84.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 13:41 -0800, Jesse Keating wrote:
> > 95%+
> 
> 98%+ prefer orange to blue.  We need to change!

Indeed. Our change from the accepted norm is so fscking
l33t that it doesn't really matter what people want, we
_know_ what's good for them.

Even quoting out of context seems to be cool as long as
we can make the unwashed masses see the light...

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From jkeating at redhat.com  Fri Dec 19 21:50:28 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Dec 2008 13:50:28 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229723272.23410.84.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
Message-ID: <1229723428.3861.3.camel@localhost.localdomain>

On Fri, 2008-12-19 at 16:47 -0500, Dimi Paun wrote:
> 
> Indeed. Our change from the accepted norm is so fscking
> l33t that it doesn't really matter what people want, we
> _know_ what's good for them.
> 
> Even quoting out of context seems to be cool as long as
> we can make the unwashed masses see the light...

I'm 75% sure that 40%+ of people who read at least 60%+ of your message
will only agree to 20% of it.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/aa4869de/attachment.sig>

From dimi at lattica.com  Fri Dec 19 22:01:38 2008
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 19 Dec 2008 17:01:38 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229723428.3861.3.camel@localhost.localdomain>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
Message-ID: <1229724098.23410.88.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 13:50 -0800, Jesse Keating wrote:
> I'm 75% sure that 40%+ of people who read at least 60%+ of your
> message will only agree to 20% of it.

Right. And acting like a jackass is a lot more constructive 
than (God forbid!) asking for a reasonable change on this list.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From cmadams at hiwaay.net  Fri Dec 19 22:07:13 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 19 Dec 2008 16:07:13 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229724098.23410.88.camel@dimi.lattica.com>
References: <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
Message-ID: <20081219220713.GF595724@hiwaay.net>

Once upon a time, Dimi Paun <dimi at lattica.com> said:
> Right. And acting like a jackass is a lot more constructive 
> than (God forbid!) asking for a reasonable change on this list.

You are assuming "what Dimi Paun wants" == "everybody considers
reasonable", which is (quite obviously from this thread) not true.

If I prefer a white and gold background, and I have 5 friends that
agree, should we all spam fedora-devel with "+1" and "metoo" to change
the default background color?  What if it is 20 friends, or 100, or 500?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From dennis at ausil.us  Fri Dec 19 22:07:59 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Fri, 19 Dec 2008 16:07:59 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229722878.3861.0.camel@localhost.localdomain>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
Message-ID: <200812191608.04911.dennis@ausil.us>

On Friday 19 December 2008 03:41:18 pm Jesse Keating wrote:
> On Fri, 2008-12-19 at 15:45 -0500, Dimi Paun wrote:
> > 95%+
>
> 98%+ prefer orange to blue.  We need to change!
obviously it should be Burnt Orange and Navy Blue.  its the most acceptable 
preferred colour scheme.  Just to prove it that's all ill wear at FUDCon :)

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/90d3398b/attachment.sig>

From lesmikesell at gmail.com  Fri Dec 19 22:15:36 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 19 Dec 2008 16:15:36 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081219220713.GF595724@hiwaay.net>
References: <200812181915.13192.konrad@tylerc.org>	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>	<1229707240.24419.636.camel@lenovo.local.net>	<1229707929.23410.63.camel@dimi.lattica.com>	<494C05A7.6070102@gmail.com>	<1229719550.23410.79.camel@dimi.lattica.com>	<1229722878.3861.0.camel@localhost.localdomain>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>
	<20081219220713.GF595724@hiwaay.net>
Message-ID: <494C1D08.6060300@gmail.com>

Chris Adams wrote:
> Once upon a time, Dimi Paun <dimi at lattica.com> said:
>> Right. And acting like a jackass is a lot more constructive 
>> than (God forbid!) asking for a reasonable change on this list.
> 
> You are assuming "what Dimi Paun wants" == "everybody considers
> reasonable", which is (quite obviously from this thread) not true.
> 
> If I prefer a white and gold background, and I have 5 friends that
> agree, should we all spam fedora-devel with "+1" and "metoo" to change
> the default background color?  What if it is 20 friends, or 100, or 500?

If you don't have a budget for market research or testing consumer 
acceptance yourself, it might be wiser to follow the examples of the 
companies that have done that work instead of just making wild guesses.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From mike at cchtml.com  Fri Dec 19 22:18:13 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Fri, 19 Dec 2008 16:18:13 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081219220713.GF595724@hiwaay.net>
References: <200812181915.13192.konrad@tylerc.org>	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>	<1229707240.24419.636.camel@lenovo.local.net>	<1229707929.23410.63.camel@dimi.lattica.com>	<494C05A7.6070102@gmail.com>	<1229719550.23410.79.camel@dimi.lattica.com>	<1229722878.3861.0.camel@localhost.localdomain>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>
	<20081219220713.GF595724@hiwaay.net>
Message-ID: <494C1DA5.2020602@cchtml.com>

-------- Original Message --------
Subject: Re: Call for vote: Nautilus use Browser view for fedora 11
From: Chris Adams <cmadams at hiwaay.net>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 12/19/2008 04:07 PM

> 
> You are assuming "what Dimi Paun wants" == "everybody considers
> reasonable", which is (quite obviously from this thread) not true.
> 


Where have you been reading? I, for one, hate spatial view. Everyone I 
know hates it. Hate may be a strong word, but it is entirely appropriate 
for the emotion given.

Only people that like spatial view seem to believe everyone loves it and 
the people that hate it are in minority -- without any statistics to 
prove either way. Sure, I don't have any statistics either, but I have 
my friends and colleagues to start with a small sample. From this 
thread, the people that like spatial view simply like it /themselves/ as 
I haven't heard them reference friends or anyone they know as a 
supporting statistic.



From dimi at lattica.com  Fri Dec 19 22:18:23 2008
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 19 Dec 2008 17:18:23 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081219220713.GF595724@hiwaay.net>
References: <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<20081219220713.GF595724@hiwaay.net>
Message-ID: <1229725103.23410.91.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 16:07 -0600, Chris Adams wrote:
> You are assuming "what Dimi Paun wants" == "everybody considers
> reasonable", which is (quite obviously from this thread) not true.

Not at all -- there's hardly any request that will meet the "everybody"
standard. A request can be reasonable even if the majority of people
opposes it.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dr.diesel at gmail.com  Fri Dec 19 22:25:23 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Fri, 19 Dec 2008 17:25:23 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229724098.23410.88.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
Message-ID: <2a28d2ab0812191425x686a826dgfa9efc60f0ec9ae4@mail.gmail.com>

On Fri, Dec 19, 2008 at 5:01 PM, Dimi Paun <dimi at lattica.com> wrote:

>
> On Fri, 2008-12-19 at 13:50 -0800, Jesse Keating wrote:
> > I'm 75% sure that 40%+ of people who read at least 60%+ of your
> > message will only agree to 20% of it.
>
> Right. And acting like a jackass is a lot more constructive
> than (God forbid!) asking for a reasonable change on this list.
>
>
I found Jesse's comment rather amusing amongst the rest in this thread.

Your reply on the other hand definitely points to the true jackass...



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/5ebb3f9b/attachment.htm>

From jamundso at gmail.com  Fri Dec 19 22:39:17 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 19 Dec 2008 16:39:17 -0600
Subject: To pre, or not to pre...
In-Reply-To: <6d06ce20812170810r5bc7c9b1ta062ab57eea5144c@mail.gmail.com>
References: <200812161726.15508.jamundso@gmail.com>
	<1229484821.3028.6.camel@zebes.localdomain>
	<1229485105.3028.9.camel@zebes.localdomain>
	<6d06ce20812170810r5bc7c9b1ta062ab57eea5144c@mail.gmail.com>
Message-ID: <6d06ce20812191439o5ab195cp27064bf78e3bf6b2@mail.gmail.com>

[sorry if this is a duplicate...]
I'm beginning to lean towards *not* pre-upgrading...
[root at jerrya-opti755 ~]# preupgrade-cli Rawhide
Loaded plugins: blacklist, fastestmirror, refresh-packagekit, whiteout
Loaded plugins: fastestmirror, refresh-packagekit
Loading mirror speeds from cached hostfile
 * preupgrade: mirror.hiwaay.net
Reading repository metadata in from local files
Checking for new repos for mirrors
Reading repository metadata in from local files
Traceback (most recent call last):
  File "/usr/share/preupgrade/preupgrade-cli.py", line 284, in <module>
    pu.main(myrelease)
  File "/usr/share/preupgrade/preupgrade-cli.py", line 167, in main
    self.retrieve_treeinfo()
  File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line
455, 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

[root at jerrya-opti755 ~]# rpm -q yum preupgrade
yum-3.2.20-5.fc10.noarch
preupgrade-1.0.0-1.fc10.noarch

jerry
-- 
To be named later.



From loganjerry at gmail.com  Fri Dec 19 22:42:35 2008
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 19 Dec 2008 15:42:35 -0700
Subject: Automatic BuildRequires
In-Reply-To: <494A44DD.2050701@redhat.com>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
	<20081109204946.GA12715@auslistsprd01.us.dell.com>
	<20081109210146.GA16833@auslistsprd01.us.dell.com>
	<494A44DD.2050701@redhat.com>
Message-ID: <870180fe0812191442j74ed15c3hffbabde35c967bf3@mail.gmail.com>

On Thu, Dec 18, 2008 at 5:41 AM, Karsten Hopp <karsten at redhat.com> wrote:
> I've used auto-br-rpmbuild with my latest full-install mass rebuild and
> grepped the
> BuildRequires from the logs.
> They are available at
>        http://karsten.fedorapeople.org/buildrequires/

I'm not sure what to do with this information.  For example, take a
look at one of my packages: automaton.  It's a Java package.  Yet your
logs show gstreamer-devel as a BuildRequires.  How did that get in
there?  And what's going on with the 3 different versions of glibc, on
2 arches?

I've checked a couple of my other packages and had a similar reaction.
 There are BuildRequires listed that make no sense to me.  Can you
give more detail on how these lists were generated?  Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From mschwendt at gmail.com  Fri Dec 19 22:59:31 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 19 Dec 2008 23:59:31 +0100
Subject: Automatic BuildRequires
In-Reply-To: <870180fe0812191442j74ed15c3hffbabde35c967bf3@mail.gmail.com>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
	<20081109204946.GA12715@auslistsprd01.us.dell.com>
	<20081109210146.GA16833@auslistsprd01.us.dell.com>
	<494A44DD.2050701@redhat.com>
	<870180fe0812191442j74ed15c3hffbabde35c967bf3@mail.gmail.com>
Message-ID: <20081219235931.6b8b25b9.mschwendt@gmail.com>

On Fri, 19 Dec 2008 15:42:35 -0700, Jerry wrote:

> On Thu, Dec 18, 2008 at 5:41 AM, Karsten Hopp wrote:
> > I've used auto-br-rpmbuild with my latest full-install mass rebuild and
> > grepped the
> > BuildRequires from the logs.
> > They are available at
> >        http://karsten.fedorapeople.org/buildrequires/
> 
> I'm not sure what to do with this information.  For example, take a
> look at one of my packages: automaton.  It's a Java package.  Yet your
> logs show gstreamer-devel as a BuildRequires.  How did that get in
> there?

A bug. compface also lists gstreamer-devel as a BR, which isn't true.

There are more problems. For example:

xmms-sid (an input plugin for XMMS) lists lots of packages, which
are completely unrelated to the plugin and xmms. Not limited to
wine-core, xulrunner, qt3, libvirt-cim, inn, kdelibs*, mysql-libs,
octave, ogre, ...

Same for sylpheed.
Same for pth.
Same for audacious-plugin-fc.



From jkeating at redhat.com  Fri Dec 19 23:07:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Dec 2008 15:07:14 -0800
Subject: To pre, or not to pre...
In-Reply-To: <6d06ce20812191439o5ab195cp27064bf78e3bf6b2@mail.gmail.com>
References: <200812161726.15508.jamundso@gmail.com>
	<1229484821.3028.6.camel@zebes.localdomain>
	<1229485105.3028.9.camel@zebes.localdomain>
	<6d06ce20812170810r5bc7c9b1ta062ab57eea5144c@mail.gmail.com>
	<6d06ce20812191439o5ab195cp27064bf78e3bf6b2@mail.gmail.com>
Message-ID: <1229728034.3861.7.camel@localhost.localdomain>

On Fri, 2008-12-19 at 16:39 -0600, Jerry Amundson wrote:
> preupgrade-cli Rawhide

The images creation part of the rawhide compose failed last night, ergo
there are no kernels/initrds for preupgrade to find.  I'm still
investigating, but this does happen from time to time in rawhide.  Don't
shoot the messenger.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081219/f2d026ca/attachment.sig>

From vonbrand at inf.utfsm.cl  Sat Dec 20 00:07:07 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 19 Dec 2008 21:07:07 -0300
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494C08B7.5010903@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc> <giepf5$i12$1@ger.gmane.org>
	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
	<6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>
	<494C08B7.5010903@gmail.com>
Message-ID: <200812200007.mBK077J7004429@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:
> Mark wrote:
> > btw. i never understood why Linus Torvalds was so opposed to Gnome.
> > i'm beginning to understand why.

> How much less RAM would your system need if everything shared one
> window toolkit?

Disk and RAM are practically free, given today's prices.

>                  And how much better could it be if all development
> had focused on just one?

How much worse would it be if there was no competition?
-- 
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 vonbrand at inf.utfsm.cl  Sat Dec 20 00:05:41 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 19 Dec 2008 21:05:41 -0300
Subject: rpm %post - check for version being upgraded
In-Reply-To: <46a038f90812191242s1d877989od13a6da7d682fbe2@mail.gmail.com>
References: <46a038f90812191242s1d877989od13a6da7d682fbe2@mail.gmail.com>
Message-ID: <200812200005.mBK05fFw004417@laptop14.inf.utfsm.cl>

Martin Langhoff <martin.langhoff at gmail.com> wrote:
> This is a bit of advanced rpm trickery that probably falls in the
> "don't do that" category. :-/
> 
> Short version:
> 
>    How do I query in %post, when executed during an upgrade,
>    for the version we are upgrading from?

Urgh.

> Long version:
> 
> A custom rpm (that OLPC's XS uses to manage configuration) needs to
> nuke a dynamically generated config file -
> /etc/udev/rules.d/70-persistent-net.rules - _only once_. Before
> version 0.5 of the pkg, the script that drove the device naming was
> subtly wrong.

Why "only once"? Better/much more robust/easier stomp on data
_always_. Perhaps do it with version 1.2.3-0.fc11, and (after a suitable
time) release 1.2.3-1.fc11?
-- 
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 jspaleta at gmail.com  Sat Dec 20 00:19:57 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 19 Dec 2008 15:19:57 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <200812200007.mBK077J7004429@laptop14.inf.utfsm.cl>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc> <giepf5$i12$1@ger.gmane.org>
	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
	<6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>
	<494C08B7.5010903@gmail.com>
	<200812200007.mBK077J7004429@laptop14.inf.utfsm.cl>
Message-ID: <604aa7910812191619k7ec53dacxf1a0d29d00a9c825@mail.gmail.com>

On Fri, Dec 19, 2008 at 3:07 PM, Horst H. von Brand
<vonbrand at inf.utfsm.cl> wrote:
> Disk and RAM are practically free, given today's prices.

Not on netbooks.

-jef



From pertusus at free.fr  Sat Dec 20 00:28:04 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Dec 2008 01:28:04 +0100
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <494BFECE.4050003@gmail.com>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
	<20081219194825.GA16284@bludgeon.org> <494BFECE.4050003@gmail.com>
Message-ID: <20081220002803.GA10679@free.fr>

On Fri, Dec 19, 2008 at 12:06:38PM -0800, Toshio Kuratomi wrote:
> > 
> There isn't but there should be.  Rahul started to put together a policy
> for that that would have modified the NonResponsiveMaintainers policy.
> It was not approved by FESCo but I don't remember what the sticking
> points were.

I only remember vaguely, one thing that was said was that one had
to wait for the packager containment of Jesse to be in place. Though I
think it is a progress to have packagers and provenpackagers, I don't 
think it will help here.

I'll go reread some mails.

--
Pat



From vonbrand at inf.utfsm.cl  Sat Dec 20 00:30:50 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 19 Dec 2008 21:30:50 -0300
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812191255m189b4032ta5991a2ca84ade88@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc> <giepf5$i12$1@ger.gmane.org>
	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
	<6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>
	<494C08B7.5010903@gmail.com>
	<6e24a8e80812191255m189b4032ta5991a2ca84ade88@mail.gmail.com>
Message-ID: <200812200030.mBK0UoxE004739@laptop14.inf.utfsm.cl>

Mark <markg85 at gmail.com> wrote:
> On Fri, Dec 19, 2008 at 9:48 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> > Mark wrote:
> >>
> >> btw. i never understood why Linus Torvalds was so opposed to Gnome.
> >> i'm beginning to understand why.
> >
> > How much less RAM would your system need if everything shared one window
> > toolkit?  And how much better could it be if all development had focused on
> > just one?

> Multiple toolkits is horrible but some desire it. there is no stopping
> in that unless all but one change to a license that simply isn't for
> linux (or closed source).

Nodz.

> And the biggest ram eaters and cpu eaters are all those python scripts
> that keep being pushed in more and more distros (you get the point)

Python (and other) scripts are usually tiny. All scripts share one copy of
the interpreter binary, if that one is large it makes no real difference.

And the prices of RAM and disk (and CPU) being what they are now...
-- 
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 vonbrand at inf.utfsm.cl  Sat Dec 20 00:32:50 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 19 Dec 2008 21:32:50 -0300
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229724098.23410.88.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com>
	<200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
Message-ID: <200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>

Dimi Paun <dimi at lattica.com> wrote:
> On Fri, 2008-12-19 at 13:50 -0800, Jesse Keating wrote:
> > I'm 75% sure that 40%+ of people who read at least 60%+ of your
> > message will only agree to 20% of it.

> Right. And acting like a jackass

Jackass: Someone who doesn't agree with me

>                                  is a lot more constructive 
> than (God forbid!) asking for a reasonable change on this list.

Reasonable change: Whatever I ask for, obviously.


So it is real easy to argue...
-- 
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 pertusus at free.fr  Sat Dec 20 00:48:29 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Dec 2008 01:48:29 +0100
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <494BFECE.4050003@gmail.com>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
	<20081219194825.GA16284@bludgeon.org> <494BFECE.4050003@gmail.com>
Message-ID: <20081220004829.GB10679@free.fr>

On Fri, Dec 19, 2008 at 12:06:38PM -0800, Toshio Kuratomi wrote:
> > 
> There isn't but there should be.  Rahul started to put together a policy
> for that that would have modified the NonResponsiveMaintainers policy.
> It was not approved by FESCo but I don't remember what the sticking
> points were.

I found the FESCo meetng result:

=== Collective Maintenance Proposal ===
* FESCo rejected the collective maintenance proposal (1) for now.  They
had some concerns about the extra bureaucracy, and they wanted to see
how the new maintainer containment policy (2) and opening acls (3) to
packagers helps first, since these are to be implemented in the very
near future.  If there is still a problem, this proposal could be
revisited.

1. http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance
2. http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment
3. http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening


The logs are at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-07-30.html

but not at lot more was said than what is in the summary.

--
Pat



From dimi at lattica.com  Sat Dec 20 00:58:22 2008
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 19 Dec 2008 19:58:22 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
Message-ID: <1229734702.23410.103.camel@dimi.lattica.com>

On Fri, 2008-12-19 at 21:32 -0300, Horst H. von Brand wrote:
> Reasonable change: Whatever I ask for, obviously.

And where is the problem here? I am a reasonable person,
it would expect I can make a reasonable request.

But we are down a nasty road for no good reason: instead of
this absolute relativism, do you have a decent explanation
why this particular change is not reasonable?

It's harder and harder to be part of Fedora's community:
most requests are shut down in a condescending manner, and
users are directed on wild goose chases and/or ridiculed.

Anyway, I have no desire to fight this -- whomever wants to
listen to the user base fine, if not, you are probably a lot
smarter than lower class users like me, sorry to be a bother.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From mjs at clemson.edu  Sat Dec 20 01:03:23 2008
From: mjs at clemson.edu (Matthew Saltzman)
Date: Fri, 19 Dec 2008 20:03:23 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229723428.3861.3.camel@localhost.localdomain>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
Message-ID: <1229735003.19701.1.camel@valkyrie.localdomain>

On Fri, 2008-12-19 at 13:50 -0800, Jesse Keating wrote:
> On Fri, 2008-12-19 at 16:47 -0500, Dimi Paun wrote:
> > 
> > Indeed. Our change from the accepted norm is so fscking
> > l33t that it doesn't really matter what people want, we
> > _know_ what's good for them.
> > 
> > Even quoting out of context seems to be cool as long as
> > we can make the unwashed masses see the light...
> 
> I'm 75% sure that 40%+ of people who read at least 60%+ of your message
> will only agree to 20% of it.

Sheesh!  Everyone knows 78% of statistics are made up...

-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From mjs at clemson.edu  Sat Dec 20 01:03:23 2008
From: mjs at clemson.edu (Matthew Saltzman)
Date: Fri, 19 Dec 2008 20:03:23 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229723428.3861.3.camel@localhost.localdomain>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181825h44fce8abp479343baaa2a8e95@mail.gmail.com>
	<494B0738.1040409@cchtml.com> <200812181915.13192.konrad@tylerc.org>
	<604aa7910812181926t2adf5d7ayf1389faaf49cd55@mail.gmail.com>
	<1229707240.24419.636.camel@lenovo.local.net>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
Message-ID: <1229735003.19701.1.camel@valkyrie.localdomain>

On Fri, 2008-12-19 at 13:50 -0800, Jesse Keating wrote:
> On Fri, 2008-12-19 at 16:47 -0500, Dimi Paun wrote:
> > 
> > Indeed. Our change from the accepted norm is so fscking
> > l33t that it doesn't really matter what people want, we
> > _know_ what's good for them.
> > 
> > Even quoting out of context seems to be cool as long as
> > we can make the unwashed masses see the light...
> 
> I'm 75% sure that 40%+ of people who read at least 60%+ of your message
> will only agree to 20% of it.

Sheesh!  Everyone knows 78% of statistics are made up...

-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From jspaleta at gmail.com  Sat Dec 20 01:40:33 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 19 Dec 2008 16:40:33 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229734702.23410.103.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
Message-ID: <604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>

On Fri, Dec 19, 2008 at 3:58 PM, Dimi Paun <dimi at lattica.com> wrote:
> It's harder and harder to be part of Fedora's community:
> most requests are shut down in a condescending manner, and
> users are directed on wild goose chases and/or ridiculed.

I'll play.  Here are the rules:
1)This is not a democracy.  Nor is GNOME a democracy.
2)Simply taken votes is by definition not a constructive way make or
prevent a technical change either here in Fedora or in the upstream
GNOME development community.
3)Package maintainers and co-maintainers have significant influence on
default configuration choices and the extent to which they diverge
from upstream's defaults.
4)Disagreements are going to happen and consensus cannot always be reached.

Given all that.....when there are passionate disagreements over how to
do things, exactly what would you suggest we do differently when
having discussions concerning those disagreements?

Here we have Mark and other people disagreeing with choices that have
been made. They are very passionate about their opinion.  The current
maintainers and developers disagree. They've listened, the responded,
they still disagree. So other than not agreeing what did they do wrong
in their responses?  What exactly do leaders in our meritocracy need
to do better when they are compelled to inform people that they
disagree and will not be making the requested change?  What exactly
should have been done differently in the main conversation in this
thread that would have made people feel better about the decision to
not change the default setting to what they believe is reasonable?

I'm not seeing an imbalance in tone in the main conversation over the
browser setting. I see an escalation on both sides.  Dimi, here's what
I know...from long long long experience at manipulating people in
mailinglists for both good and evil intentions. If you want people to
raise their level of discourse on a subject, you have to raise yours
first. If your first post in the brawl is a sarcastic jab, like yours
was, you aren't doing your part to raise that level of discourse and
you pretty much forfeit your moral authority to call people out for
being condescending.

But I said I'd play. So let's play.  What are people doing wrong in
how they are communicating their disagreement?

-jef



From lesmikesell at gmail.com  Sat Dec 20 01:48:38 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 19 Dec 2008 19:48:38 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <200812200007.mBK077J7004429@laptop14.inf.utfsm.cl>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc> <giepf5$i12$1@ger.gmane.org>
	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
	<6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>
	<494C08B7.5010903@gmail.com>
	<200812200007.mBK077J7004429@laptop14.inf.utfsm.cl>
Message-ID: <494C4EF6.2090500@gmail.com>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
>> Mark wrote:
>>> btw. i never understood why Linus Torvalds was so opposed to Gnome.
>>> i'm beginning to understand why.
> 
>> How much less RAM would your system need if everything shared one
>> window toolkit?
> 
> Disk and RAM are practically free, given today's prices.

Even on machines where that is true, the time to load extra stuff from 
disk into ram isn't free.


>>                  And how much better could it be if all development
>> had focused on just one?
> 
> How much worse would it be if there was no competition?

Microsoft and Apple are enough competition.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pmachata at redhat.com  Sat Dec 20 02:20:35 2008
From: pmachata at redhat.com (Petr Machata)
Date: Sat, 20 Dec 2008 03:20:35 +0100
Subject: boost rebuild status
In-Reply-To: <20081218204249.33a3adeb@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
	<20081218204249.33a3adeb@balbo.artheist.org>
Message-ID: <494C5673.6040101@redhat.com>

Benjamin Kosnik wrote:
> vegastrike-0:0.5.0-5.fc10.x86_64
>   bump Release, rebuild fails:
>   http://koji.fedoraproject.org/koji/getfile?taskID=1005464&name=build.log
> 
>   boost_python compile error
> /usr/include/boost/python/detail/caller.hpp:102: error: 'struct boost::python::detail::caller_arity<1u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<Vector, int>]::result_converter' has no member named 'get_pytype'

This one can be worked around by compiling with 
-DBOOST_PYTHON_NO_PY_SIGNATURES, but I have no idea what that will 
break.  I'll try to come up with a more definitive solution tomorrow.

PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/0ebe0d60/attachment.sig>

From konrad at tylerc.org  Sat Dec 20 00:25:14 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 19 Dec 2008 16:25:14 -0800
Subject: Orphaning azureus
In-Reply-To: <d3ceea380812190914o369d6970le475ffa2b544ead8@mail.gmail.com>
References: <20081024190916.A41D98E0003@hormel.redhat.com>
	<494BCDF6.4000008@redhat.com>
	<d3ceea380812190914o369d6970le475ffa2b544ead8@mail.gmail.com>
Message-ID: <200812191625.14515.konrad@tylerc.org>

On Friday 19 December 2008 09:14:53 am Itamar Reis Peixoto wrote:
> http://azureus.sourceforge.net/
>
> azureus is now called Vuze
>
> what you think about letting azureus orphaned and submiting  Vuze for
> review ?

I think that's silly, and we should just submit it for a rename review 
(whatever that will entail).

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From jamundso at gmail.com  Sat Dec 20 02:54:57 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 19 Dec 2008 20:54:57 -0600
Subject: To pre, or not to pre...
In-Reply-To: <1229728034.3861.7.camel@localhost.localdomain>
References: <200812161726.15508.jamundso@gmail.com>
	<1229484821.3028.6.camel@zebes.localdomain>
	<1229485105.3028.9.camel@zebes.localdomain>
	<6d06ce20812170810r5bc7c9b1ta062ab57eea5144c@mail.gmail.com>
	<6d06ce20812191439o5ab195cp27064bf78e3bf6b2@mail.gmail.com>
	<1229728034.3861.7.camel@localhost.localdomain>
Message-ID: <6d06ce20812191854q7a2828e7wc5c132393cba7a14@mail.gmail.com>

2008/12/19 Jesse Keating <jkeating at redhat.com>:
> On Fri, 2008-12-19 at 16:39 -0600, Jerry Amundson wrote:
>> preupgrade-cli Rawhide
>
> The images creation part of the rawhide compose failed last night, ergo
> there are no kernels/initrds for preupgrade to find.  I'm still
> investigating, but this does happen from time to time in rawhide.  Don't
> shoot the messenger.

No problem. I was shooting my own foot today, and was just checking if
this was another one. Any way to look up the success/failure of the
images creation part of the rawhide compose?

Thanks,
jerry

-- 
To be named later.



From jamundso at gmail.com  Sat Dec 20 03:01:06 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 19 Dec 2008 21:01:06 -0600
Subject: Orphaning azureus
In-Reply-To: <200812191625.14515.konrad@tylerc.org>
References: <20081024190916.A41D98E0003@hormel.redhat.com>
	<494BCDF6.4000008@redhat.com>
	<d3ceea380812190914o369d6970le475ffa2b544ead8@mail.gmail.com>
	<200812191625.14515.konrad@tylerc.org>
Message-ID: <6d06ce20812191901r3b6fa8dfmf63470c8d427bbc8@mail.gmail.com>

On Fri, Dec 19, 2008 at 6:25 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> On Friday 19 December 2008 09:14:53 am Itamar Reis Peixoto wrote:
>> http://azureus.sourceforge.net/
>>
>> azureus is now called Vuze
>>
>> what you think about letting azureus orphaned and submiting  Vuze for
>> review ?
>
> I think that's silly, and we should just submit it for a rename review
> (whatever that will entail).

They're very different packages. One should not be renamed the other.
They're so different, in fact, that could not even use vuze during the
day for fear it would display objectionable content when I started it.
I just never got around to disabling it's media content start screen
by default.

jerry

-- 
To be named later.



From Matt_Domsch at dell.com  Sat Dec 20 03:00:55 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 19 Dec 2008 21:00:55 -0600
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
Message-ID: <20081220030055.GA22944@mock.linuxdev.us.dell.com>

Fedora Rawhide-in-Mock Build Results for x86_64

This is a full rebuild, using systems running rawhide as of 12/17 to
rebuild all packages in rawhide on 12/17.

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

Total packages: 6658
Number failed to build: 411
Number expected to fail due to ExclusiveArch or ExcludeArch: 34
Leaving:  377

Of those expected to have worked...
Without a bug filed: 376
----------------------------------
DeviceKit-disks-002-0.git20080720.fc10 (build/make) davidz
Macaulay2-1.1-2.fc10 (build/make) rdieter
PyYAML-3.06-2.fc11 (build/make) jeckersb
R-BSgenome.Celegans.UCSC.ce2-1.2.0-5 (build/make) pingou
R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3 (build/make) pingou
R-hgu95av2probe-2.0.0-1.fc9 (build/make) pingou
R-lmtest-0.9-2.fc10 (build/make) orion
R-pls-2.1-2.fc9 (build/make) pingou
Sprog-0.14-13.fc9 (build/make) ghenry
Terminal-0.2.8.3-1.fc10 (build/make) kevin
Thunar-0.9.0-4.fc9 (build/make) kevin,pertusus,cwickert
UnihanDb-5.1.0-7.fc10 (build/make) dchen,i18n-team
WebKit-1.0.0-0.15.svn37790.fc10 (build/make) pgordon,mtasaka
abe-1.1-7.fc9 (build/make) wart
afflib-3.3.4-4.fc10 (build/make) kwizart
alltray-0.70-2.fc9 (build/make) denis
almanah-0.5.0-1.fc11 (build/make) lokthare
alsa-oss-1.0.17-1.fc10 (build/make) jima
apr-1.3.3-1.fc10 (build/make) jorton,oliver,bojan
ardour-2.7-1.fc11 (build/make) green,jwrdegoede
asterisk-1.6.1-0.5beta2.fc11 (build/make) jcollie
atari++-1.55-2.fc11 (build/make) sharkcz
audacity-1.3.5-0.8.beta.fc10 (build/make) gemi,mschwendt,dtimms
autotrace-0.31.1-18.fc10 (build/make) qspencer,roozbeh
avant-window-navigator-0.2.6-13.fc11 (build/make) sindrepb,ngompa
avr-binutils-2.18-2.fc9 (patch_fuzz) tnorth,trondd
awn-extras-applets-0.2.6-6.fc10 (build/make) phuang
ax25-apps-0.0.6-2.fc9 (build/make) bjensen,sindrepb,sconklin,dp67
balsa-2.3.26-2.fc10 (build/make) pawsa
bigboard-0.6.4-3.fc11 (build/make) walters
bitgtkmm-0.4.0-4.fc10 (build/make) rvinyard
blackbox-0.70.1-11 (build/make) thias
bmpx-0.40.14-7.fc10 (build/make) akahl
boo-0.8.1.2865-4.fc9 (build/make) pfj
bzflag-2.0.12-3.fc10 (build/make) nphilipp
bzr-gtk-0.95.0-2.fc10 (build/make) toshio,shahms,toshio
cdo-1.0.8-2.fc9 (build/make) edhill
classpathx-jaf-1.0-12.fc10 (build/make) devrim,dwalluck
clutter-0.8.2-1.fc10 (build/make) allisson
compat-db-4.6.21-5.fc10 (build/make) jnovy,pmatilai
compat-gcc-32-3.2.3-64 (build/make) jakub
compat-gcc-34-3.4.6-9 (patch_fuzz) jakub
compiz-0.7.8-9.fc11 (build/make) krh
compizconfig-backend-gconf-0.7.8-1.fc11 (build/make) izhar
compizconfig-python-0.7.8-2.fc11 (build/make) izhar
conexus-0.5.3-4.fc9 (build/make) rvinyard
conexusmm-0.5.0-3.fc7 (build/make) rvinyard
cook-2.32-1.fc10 (build/make) gemi
coredumper-1.2.1-6.fc10 (build/make) rakesh
cowbell-0.3-0.svn34.4.fc10 (build/make) sindrepb
cpan2rpm-2.028-2.fc8.1 (build/make) ghenry,perl-sig
csound-5.03.0-16.fc9 (build/make) dcbw,pfj
ctemplate-0.91-3.fc10 (build/make) rakesh
cups-1.4-0.b1.4.fc11 (build/make) twaugh
dbmail-2.2.9-2.fc10 (build/make) bjohnson
desktop-data-model-1.2.5-2.fc11 (build/make) walters,otaylor
devhelp-0.22-2.fc11 (build/make) mbarnes
devilspie-0.22-2.fc9 (build/make) svahl
digitemp-3.5.0-3.fc9 (build/make) robert
directfb-1.2.6-3.fc10 (build/make) thias,kwizart
distcache-1.4.5-17 (build/make) jorton
dnssec-tools-1.4.1-2.fc10 (build/make) hardaker
dx-4.4.4-7.fc10 (build/make) rathann
ember-0.5.4-5.fc11 (build/make) atorkhov,wart
emerald-0.7.6-2.fc10 (build/make) turki,thias,jwilson
enlightenment-0.16.999.043-3.fc10 (build/make) stalwart
etherboot-5.4.4-7.fc11 (build/make) ehabkost,glommer
evolution-brutus-1.2.27-2.fc10 (build/make) bpepple,colding
evolution-exchange-2.25.1-1.fc11 (build/make) mbarnes
evolution-remove-duplicates-0.0.4-1.fc10 (build/make) salimma
evolution-sharp-0.18.1-1.fc10 (build/make) mbarnes
expect-5.43.0-15.fc10 (build/make) vcrhonek
file-roller-2.24.2-1.fc10 (build/make) caillon
firewalk-5.0-2.fc9 (build/make) sindrepb
flasm-1.62-4.fc9 (build/make) kkofler,pertusus
fmt-ptrn-1.3.17-2.fc10 (build/make) mikep
fpc-2.2.2-3.fc10 (build/make) joost,tbzatek
freealut-1.1.0-6.fc9 (build/make) awjb
freetds-0.82-2.fc10 (build/make) buc
freetennis-0.4.8-14.fc10 (build/make) rjones
g3data-1.5.1-8.fc9 (build/make) jspaleta
gauche-0.8.13-2.fc10 (build/make) gemi
gauche-gl-0.4.4-3.fc9 (build/make) gemi
gauche-gtk-0.4.1-17.fc9 (build/make) gemi
gcalctool-5.25.1-2.fc11 (build/make) rstrode
gcombust-0.1.55-13 (build/make) thias
gconf-cleaner-0.0.2-6.fc10 (build/make) splinux
gconfmm26-2.24.0-1.fc10 (build/make) denis
gdbm-1.8.0-29.fc10 (build/make) kasal
gdmap-0.7.5-6.fc6 (build/make) splinux
gengetopt-2.22.1-1.fc10 (build/make) rishi
geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser
ggz-gtk-client-0.0.14.1-1.fc9 (build/make) bpepple,rdieter
ghc-gtk2hs-0.9.13-6.20081108.fc11 (build/make) bos,haskell-sig,petersen
gnome-applets-2.25.1-4.fc11 (build/make) rstrode
gnome-compiz-manager-0.10.4-6.fc11 (build/make) jpmahowa
gnome-desktop-sharp-2.24.0-3.fc10 (build/make) laxathom
gnome-do-0.6.1.0-2.fc10 (build/make) sindrepb,salimma,sindrepb
gnome-panel-2.24.1-6.fc11 (build/make) rstrode
gnome-power-manager-2.24.2-2.fc11 (build/make) rhughes,rhughes
gnome-python2-desktop-2.24.0-5.fc11 (build/make) mbarnes
gnome-specimen-0.3-3.fc11 (build/make) splinux
gnome-speech-0.4.22-1.fc10 (build/make) davidz
gnome-system-monitor-2.24.1-1.fc10 (build/make) ssp
gnome-themes-extras-2.22.0-2.fc9 (build/make) mwiriadi,mwiriadi
gnome-web-photo-0.3-12.fc10 (build/make) hadess,mpg
gok-2.25.2-1.fc11 (build/make) davidz
gpm-1.20.5-1.fc10 (build/make) zprikryl,pertusus
gpp4-1.0.4-11.fc11 (build/make) timfenn
grub2-1.98-0.3.20080827svn.fc10 (build/make) lkundrak
gstreamer-java-1.0-1.fc11 (build/make) lfarkas
gstreamer-plugins-base-0.10.21-2.fc10 (build/make) ajax
gthumb-2.10.10-3.fc10 (build/make) behdad
gtkspell-2.0.13-1.fc10 (build/make) mbarnes
guilt-0.30-2.fc10 (build/make) sandeen
gwget-0.99-8.fc10 (build/make) cwickert
haddock09-0.9-3.fc10 (build/make) bos,haskell-sig,petersen
hal-0.5.12-12.20081027git.fc10 (build/make) rhughes
happy-1.18.2-1.fc11 (build/make) bos,haskell-sig,petersen
hdf5-1.8.1-2.fc10 (build/make) orion,pertusus
hercules-3.05-7.20081009cvs.fc10 (build/make) thias
hfsutils-3.2.6-14.fc9 (patch_fuzz) dwmw2
iasl-20061109-4.fc9 (build/make) till
ibus-chewing-0.1.1.20081023-2.fc11 (build/make) phuang,i18n-team
icecream-0.8.0-11.20080117svn.fc9 (build/make) michich
icewm-1.2.35-4.fc10 (build/make) gilboa,pertusus
imsettings-0.105.1-2.fc10 (build/make) tagoh,i18n-team
incollector-1.0-6.fc9.1 (build/make) kurzawa
ini4j-0.3.2-4.fc10 (build/make) victorv
initng-conf-gtk-0.5.1-4.fc9 (build/make) danielm
initscripts-8.86-1 (build/make) notting
insight-6.8-4.fc11 (build/make) monnerat,jkratoch
ipa-1.2.0-3.fc11 (build/make) rcritten,simo,mnagy
jakarta-commons-el-1.0-9.4.fc10 (build/make) fnasser
java-1.6.0-openjdk-1.6.0.0-8.b14.fc11 (build/make) langel,lkundrak,dbhole,langel,mjw
javahelp2-2.0.05-5.fc10 (build/make) jtulach,fitzsim
jline-0.9.94-0.2.fc10 (build/make) mwringe
jsr-305-0-0.1.20080824svn.fc10 (build/make) jjames
junitperf-1.9.1-2.2.fc10 (build/make) mwringe
kaya-0.5.1-1.fc10 (build/make) s4504kr
kde-l10n-4.1.3-1.fc10 (build/make) than,rdieter,kkofler,tuxbrewr,ltinkl
kdebluetooth-0.2-3.fc10 (build/make) gilboa,scop
kdetv-0.8.9-10.fc9 (build/make) subhodip
kudzu-1.2.85-2 (build/make) notting
ladspa-1.12-9.fc9 (build/make) thomasvs
ladspa-swh-plugins-0.4.15-12.fc9 (build/make) green
lam-7.1.4-1.fc10 (build/make) dledford
lasi-1.1.0-2.fc10 (build/make) orion
ldns-1.4.0-1.fc11 (build/make) pwouters
libXTrap-1.0.0-6.fc10 (build/make) ssp
libXfontcache-1.0.4-5.fc9 (build/make) ssp,fonts-sig
libXp-1.0.0-11.fc9 (build/make) ssp
libbonoboui-2.24.0-1.fc10 (build/make) rstrode
libcompizconfig-0.7.8-1.fc11 (build/make) izhar
libctl-3.0.2-6.fc9 (build/make) edhill
libdv-1.0.0-5.fc10 (build/make) jwilson
libfakekey-0.1-1.fc10 (build/make) mccann
libgconf-java-2.12.4-11.fc10 (build/make) kasal
libgii-1.0.2-6.fc9 (build/make) kwizart
libgtk-java-2.8.7-8.fc10 (build/make) kasal,pmuldoon,swagiaal
libgweather-2.25.2-2.fc11 (build/make) mclasen
libibcommon-1.1.0-1.fc10 (build/make) dledford
libibmad-1.2.0-1.fc10 (build/make) dledford
libibumad-1.2.0-1.fc10 (build/make) dledford
libidn-0.6.14-8 (build/make) jorton
libiec61883-1.1.0-5.fc10 (build/make) jwilson
libjpeg-6b-43.fc10 (build/make) tgl
liblqr-1-0.1.0-5.fc9 (build/make) ics
libmatheval-1.1.5-2.fc9 (patch_fuzz) edhill
libnss-mysql-1.5-7.fc9 (build/make) ondrejj
libopensync-0.36-3.fc10 (build/make) awjb
libopensync-plugin-evolution2-0.36-1.fc10 (build/make) awjb
libopensync-plugin-file-0.36-1.fc10 (build/make) awjb
libopensync-plugin-gnokii-0.36-2.fc10 (build/make) cheese,awjb
libopensync-plugin-google-calendar-0.36-1.fc10 (build/make) awjb
libopensync-plugin-gpe-0.36-1.fc10 (build/make) awjb
libopensync-plugin-irmc-0.36-2.fc10 (build/make) awjb
libopensync-plugin-kdepim-0.36-1.fc10 (build/make) awjb
libopensync-plugin-moto-0.36-1.fc10 (build/make) awjb
libopensync-plugin-opie-0.36-1.fc10 (build/make) awjb
libopensync-plugin-palm-0.36-1.fc10 (build/make) awjb
libopensync-plugin-python-0.36-1.fc10 (build/make) awjb
libopensync-plugin-syncml-0.35-4.fc10 (build/make) cheese
libopensync-plugin-vformat-0.36-1.fc10 (build/make) awjb
libpaper-1.1.23-3.fc10 (build/make) spot
libpolyxmass-0.9.1-2.fc9 (build/make) awjb
libpqxx-2.6.8-10.fc9 (build/make) awjb,rdieter
librra-0.11.1-1.fc9 (build/make) awjb,abompard
librsync-0.9.7-12.fc9 (build/make) robert
librx-1.5-10.fc9 (build/make) spot
libsilc-1.1.7-2.fc10 (build/make) nosnilmot,wtogami,nosnilmot
libsndfile-1.0.17-6.fc10 (build/make) ixs
libsoup-2.25.2-1.fc11 (build/make) mbarnes,danw
libstroke-0.5.1-17.fc9 (build/make) chitlesh
libtar-1.2.11-11.fc10 (build/make) huzaifas,huzaifas
libthai-0.1.9-4.fc9 (build/make) behdad
libwvstreams-4.5-1.fc11 (build/make) ovasik
libzzub-0.2.3-12.fc9 (patch_fuzz) orphan
lilypond-2.11.57-2.fc11 (build/make) limb
linphone-2.1.1-1.fc9 (build/make) rakesh
linpsk-0.9-4.fc10 (build/make) bjensen,bjensen,sindrepb,sconklin,dp67
linux-atm-2.5.0-5 (build/make) dwmw2
lirc-0.8.4a-1.fc10 (build/make) jwilson,hadess,jwilson
logjam-4.5.3-25.fc10 (build/make) spot
m17n-lib-1.5.3-1.fc10 (build/make) pnemade,i18n-team,petersen
maildrop-2.0.4-6.fc9 (build/make) athimm
mapnik-0.5.2-0.7.svn738.fc10 (build/make) rezso,snecker
maven-scm-1.0-0.2.b3.1.6.fc10 (build/make) dbhole
maven-shared-1.0-4.6.fc10 (build/make) dbhole
maven2-2.0.4-10.15.fc10 (build/make) dbhole
mboxgrep-0.7.9-6.fc10 (build/make) ixs
mesa-7.2-0.15.fc10 (build/make) ajax,ajax
metacity-2.25.34-1.fc11 (build/make) ssp
modello-1.0-0.1.a8.4.4.fc10 (build/make) mwringe
monkey-bubble-0.4.0-9.fc9 (build/make) jwrdegoede
monodoc-2.0-5.fc10 (build/make) pfj
msynctool-0.36-1.fc10 (build/make) awjb
nautilus-python-0.5.1-1.fc10 (build/make) trondd
nautilus-share-0.7.2-13.fc10 (build/make) orphan
nco-3.9.5-2.fc10 (build/make) edhill,pertusus
net-tools-1.60-91.fc10 (build/make) rvokal,zprikryl
netcdf-decoders-5.0.0-1.fc9 (build/make) orion,pertusus
netcdf-perl-1.2.3-7.fc9 (build/make) orion,perl-sig,pertusus
newscache-1.2-0.6.rc6.fc9 (build/make) buc
nfs4-acl-tools-0.3.2-2.fc9 (patch_fuzz) steved
nip2-7.14.5-1.fc10 (build/make) agoode
notification-daemon-0.4.0-1.fc11 (build/make) davidz
nss_ldap-261-4.fc10 (build/make) nalin
nut-2.2.2-3.fc10 (build/make) mhlavink
octave-forge-20080831-2.fc10 (build/make) qspencer,orion,alexlan
openal-0.0.9-0.15.20060204cvs.fc9 (patch_fuzz) awjb
openjade-1.3.2-31.fc9 (build/make) ovasik,rvokal
openjpeg-1.3-2.fc9 (patch_fuzz) seg
orpie-1.5.1-4.fc10 (build/make) xris
osiv-2.0.0-0.4.beta.fc9 (build/make) edhill
pam-1.0.2-2.fc10 (build/make) tmraz
pam_keyring-0.0.9-2.fc9 (build/make) denis
pam_mount-0.49-1.fc10 (build/make) till
pan-0.133-1.fc10 (build/make) adalloz,mpeters
paprefs-0.9.7-3.fc10 (build/make) emoret
papyrus-0.7.1-3.fc9 (build/make) rvinyard
perl-5.10.0-52.fc11 (build/make) mmaslano,spot,corsepiu,rnorwood,kasal
perl-Archive-Any-0.093-3.fc9 (build/make) cweyl,perl-sig
perl-BSD-Resource-1.28-6.fc9 (build/make) kasal,rnorwood,mmaslano
perl-Class-Autouse-1.29-3.fc9 (build/make) corsepiu,perl-sig,laxathom
perl-Class-Inspector-1.23-1.fc10 (build/make) corsepiu,perl-sig,laxathom
perl-Data-ICal-0.13-3.fc10 (build/make) corsepiu,perl-sig
perl-Data-Stag-0.11-1.fc10 (build/make) alexlan,perl-sig
perl-File-Find-Rule-Perl-1.04-2.fc10 (build/make) corsepiu,perl-sig
perl-Gnome2-GConf-1.044-4.fc10 (build/make) cweyl,perl-sig
perl-Gtk2-Notify-0.04-3.fc9 (build/make) cweyl,perl-sig
perl-HTTP-Proxy-0.20-2.fc9 (build/make) spot,perl-sig
perl-IPC-Shareable-0.60-6.fc9 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
perl-JSON-Any-1.16-3.fc9 (build/make) cweyl,perl-sig
perl-Log-Trivial-0.31-2.fc9 (build/make) orion
perl-Module-CPANTS-Analyse-0.82-2.fc10 (build/make) berrange
perl-Moose-0.62-1.fc11 (build/make) cweyl,perl-sig
perl-MooseX-Params-Validate-0.05-1.fc10 (build/make) cweyl,perl-sig
perl-Net-SSLeay-1.35-1.fc10 (build/make) pghmcfc,perl-sig,jpo,kasal
perl-PDL-2.4.4-1.fc11 (build/make) kasal,orion,rnorwood,mmaslano
perl-POE-Component-SNMP-1.07-3.fc9 (build/make) cweyl,perl-sig
perl-Pugs-Compiler-Rule-0.28-2.fc9 (build/make) steve,perl-sig
perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig
perl-Regexp-Assemble-0.34-1.fc11 (build/make) iarnell,perl-sig
perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig
perl-Sys-Virt-0.1.2-3.fc9 (build/make) steve,perl-sig,berrange
perl-Test-Inline-2.208-3.fc10 (build/make) corsepiu,perl-sig,laxathom
perl-Test-WWW-Mechanize-Catalyst-0.42-1.fc10 (build/make) cweyl,perl-sig
perl-Test-Warn-0.10-3.fc9 (build/make) spot,perl-sig
perl-WWW-Mechanize-1.34-1.fc10 (build/make) cweyl,perl-sig
perl-XML-LibXSLT-1.66-2.fc10 (build/make) kasal,perl-sig,shishz
perl-XML-Smart-1.6.9-1.fc10 (build/make) lkundrak
perl-bioperl-1.5.2_102-13.fc10 (build/make) alexlan,perl-sig
perl-bioperl-run-1.5.2_100-3.fc9 (build/make) alexlan,perl-sig
pidgin-guifications-2.16-1.fc10 (build/make) rvokal,wtogami,nosnilmot
pigment-0.3.11-1.fc10 (build/make) thias
pinot-0.89-1.fc10 (build/make) drago01
player-2.1.1-5.fc10 (build/make) timn,makghosh
plexus-appserver-1.0-0.2.a5.2.6.fc10 (build/make) dbhole
plexus-cdc-1.0-0.2.a4.1.6.fc10 (build/make) dbhole
plexus-i18n-1.0-0.b6.5.3.fc10 (build/make) pcheung
plexus-maven-plugin-1.2-2.4.fc10 (build/make) dbhole
plexus-runtime-builder-1.0-0.2.a9.1.6.fc10 (build/make) dbhole
plexus-xmlrpc-1.0-0.2.b4.2.11.fc10 (build/make) dbhole
plplot-5.9.0-4.svn8985.fc11 (build/make) orion
polyxmass-bin-0.9.7-2.fc8 (build/make) awjb
popt-1.13-4.fc10 (build/make) robert,pmatilai
presto-utils-0.3.3-2.fc10 (build/make) jdieter
protobuf-2.0.2-5.fc11 (build/make) abbot
pyrenamer-0.6.0-2.fc11 (build/make) lokthare
python-bibtex-1.2.4-5.fc11 (build/make) zkota
python-gtkextra-1.1.0-3.fc10 (build/make) mitr
python-openid-2.2.1-1.fc10 (build/make) jcollie
python-peak-rules-0.5a1.dev-4.2582.fc11 (build/make) lmacken
python-reportlab-2.1-4.fc11 (build/make) bpepple
python-storm-0.13-2.fc10 (build/make) salimma
pywbxml-0.1-3.fc9 (build/make) awjb
q-7.11-2.fc10 (build/make) gemi
qemu-0.9.1-10.fc10 (patch_fuzz) dwmw2
qemu-launcher-1.7.4-4.fc9 (build/make) nboyle
qgis-0.11.0-4.fc10 (build/make) silfreed,rezso
qgo-1.5.4r2-1.fc9 (build/make) kaboom
qpidc-0.3.722557-1.fc10 (build/make) aconway,nsantos
quake3-1.34-0.9.rc4.fc9 (patch_fuzz) laxathom
quesa-1.8-1.fc9 (build/make) ajax
rasqal-0.9.15-1.fc9 (build/make) thomasvs
redhat-menus-10.0.1-1.fc11 (build/make) rstrode
regexxer-0.9-3.fc9 (build/make) cwickert
rekall-2.4.6-5.fc10 (build/make) spot
ristretto-0.0.21-1.fc11 (build/make) cwickert
rss-glx-0.8.1.p-20.fc10 (build/make) nphilipp
ruby-hpricot-0.6-2.fc9 (build/make) mtasaka
ruby-rpm-1.2.3-4.fc9 (build/make) lutter,stahnma
rxtx-2.1-0.2.7r2.fc11 (build/make) lfarkas
sagator-1.1.1-0.beta1.fc10 (build/make) ondrejj
sane-backends-1.0.19-12.fc10 (build/make) nphilipp
scidavis-0.1.3-2.fc10 (build/make) tanguy
scim-1.4.7-35.fc10 (build/make) phuang,i18n-team,petersen
scrip-1.4-9.fc8 (build/make) edhill
sepostgresql-8.3.5-2.1183.fc10 (build/make) kaigai
seq24-0.8.7-13.fc10 (patch_fuzz) green
simdock-1.2-3.fc10 (build/make) terjeros
skychart-3.0.1.5-3.20081026svn.fc11 (build/make) lkundrak,mmahut
smarteiffel-2.3-2.fc9 (build/make) gemi
soundtouch-1.3.1-10.fc9 (build/make) jwrdegoede
sudo-1.6.9p17-2.fc10 (build/make) mildew,kzak
sugar-0.83.3-4.fc11 (build/make) mpg,johnp,bernie,morgan,tomeu,erikos
sundials-2.3.0-6.fc9 (build/make) jpye
swfdec-gnome-2.24.0-2.fc10 (build/make) bpepple
synce-software-manager-0.9.0-10.fc9 (build/make) awjb
taglib-sharp-2.0.3.0-7.fc11 (build/make) spot
tcl-snack-2.2.10-6.fc10 (build/make) spot
thunar-archive-plugin-0.2.4-5.fc10 (build/make) cwickert
thunar-media-tags-plugin-0.1.2-4.fc9 (build/make) cwickert
thunar-shares-0.16-1.fc10 (build/make) cwickert,kevin
thunar-volman-0.2.0-2.fc9 (build/make) cwickert,kevin
tiger-3.2.1-8.fc9 (patch_fuzz) abompard
tightvnc-1.5.0-0.9.20081120svn3200.fc11 (build/make) atkac
tkimg-1.4-0.1.20081115svn.fc11 (build/make) sergiopr
totem-2.24.3-3.fc11 (build/make) hadess,firewing
tracker-0.6.6-4.fc11 (build/make) deji
tremulous-1.1.0-6.fc9 (build/make) pgordon,pgordon
uim-1.5.3-1.fc10 (build/make) tagoh,i18n-team
unixODBC-2.2.12-9.fc10 (build/make) tgl
valgrind-3.3.0-4 (build/make) jakub
vdr-1.6.0-15.fc11 (build/make) scop,vpv
vdr-ttxtsubs-0.0.5-6.fc11 (build/make) scop
vdrift-20080805-2.fc10 (build/make) limb
vnc-4.1.2-35.fc10 (patch_fuzz) atkac
wammu-0.28-1.fc10 (build/make) laxathom
wgrib2-1.7.2b-1.fc10 (build/make) orion,pertusus
widelands-0-0.13.Build13.fc11 (build/make) karlik
worminator-3.0R2.1-8.fc9 (build/make) jwrdegoede
ws-commons-util-1.0.1-10.fc10 (build/make) green,overholt
wxGTK-2.8.9-3.fc11 (build/make) mattdm,sharkcz
xastir-1.9.4-5.fc10 (build/make) lucilanga,bjensen
xbacklight-1.1-2.fc9 (build/make) salimma
xcb-proto-1.2-3.fc11 (build/make) ajax
xdx-2.4-2.fc9 (build/make) bjensen,sindrepb,sconklin
xfburn-0.3.91-2.fc11 (build/make) cwickert,denis
xfce4-notes-plugin-1.6.3-1.fc11 (build/make) cwickert
xfce4-places-plugin-1.1.0-3.fc10 (build/make) cwickert,kevin
xfce4-verve-plugin-0.3.6-1.fc11 (build/make) cwickert,kevin
xfce4-volstatus-icon-0.1.0-3.fc9 (build/make) cwickert,kevin
xfce4-xkb-plugin-0.5.2-1.fc11 (build/make) cwickert
xfdesktop-4.4.2-6.fc10 (build/make) kevin
xlhtml-0.5-8.fc9 (build/make) abompard
xmlrpc3-3.0-2.9.fc10 (build/make) overholt,akurtakov
xmms-cdread-0.14-13.fc9 (build/make) jsoeterb
xorg-x11-drv-ati-6.9.0-62.fc10 (build/make) xgl-maint
xorg-x11-drv-i810-2.5.0-3.fc11 (build/make) xgl-maint
xorg-x11-drv-openchrome-0.2.903-2.fc11 (build/make) xavierb
xorg-x11-server-1.5.3-6.fc10 (build/make) xgl-maint
xosview-1.8.3-13.20080301cvs.fc10 (build/make) terjeros
xscorch-0.2.0-12.fc8 (build/make) mgarski
zsh-4.3.4-8.fc9 (patch_fuzz) james

With bugs filed: 1
----------------------------------
libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm




----------------------------------
Packages by owner:
abbot: protobuf

abompard: librra,tiger,xlhtml

aconway: qpidc

adalloz: pan

agoode: nip2

ajax: gstreamer-plugins-base,mesa,mesa,quesa,xcb-proto

akahl: bmpx

akurtakov: xmlrpc3

alexlan: octave-forge,perl-Data-Stag,perl-bioperl,perl-bioperl-run

allisson: clutter

athimm: libFoundation,maildrop

atkac: tightvnc,vnc

atorkhov: ember

awjb: freealut,libopensync,libopensync-plugin-evolution2,libopensync-plugin-file,libopensync-plugin-gnokii,libopensync-plugin-google-calendar,libopensync-plugin-gpe,libopensync-plugin-irmc,libopensync-plugin-kdepim,libopensync-plugin-moto,libopensync-plugin-opie,libopensync-plugin-palm,libopensync-plugin-python,libopensync-plugin-vformat,libpolyxmass,libpqxx,librra,msynctool,openal,polyxmass-bin,pywbxml,synce-software-manager

behdad: gthumb,libthai

bernie: sugar

berrange: perl-Module-CPANTS-Analyse,perl-Sys-Virt

bjensen: ax25-apps,linpsk,linpsk,xastir,xdx

bjohnson: dbmail

bojan: apr

bos: ghc-gtk2hs,haddock09,happy

bpepple: evolution-brutus,ggz-gtk-client,python-reportlab,swfdec-gnome

buc: freetds,newscache

caillon: file-roller

cheese: libopensync-plugin-gnokii,libopensync-plugin-syncml

chitlesh: libstroke

colding: evolution-brutus

corsepiu: perl,perl-Class-Autouse,perl-Class-Inspector,perl-Data-ICal,perl-File-Find-Rule-Perl,perl-Test-Inline

cweyl: perl-Archive-Any,perl-Gnome2-GConf,perl-Gtk2-Notify,perl-JSON-Any,perl-Moose,perl-MooseX-Params-Validate,perl-POE-Component-SNMP,perl-RRD-Simple,perl-Test-WWW-Mechanize-Catalyst,perl-WWW-Mechanize

cwickert: Thunar,gwget,regexxer,ristretto,thunar-archive-plugin,thunar-media-tags-plugin,thunar-shares,thunar-volman,xfburn,xfce4-notes-plugin,xfce4-places-plugin,xfce4-verve-plugin,xfce4-volstatus-icon,xfce4-xkb-plugin

danielm: initng-conf-gtk

danw: libsoup

davidz: DeviceKit-disks,gnome-speech,gok,notification-daemon

dbhole: java-1.6.0-openjdk,maven-scm,maven-shared,maven2,plexus-appserver,plexus-cdc,plexus-maven-plugin,plexus-runtime-builder,plexus-xmlrpc

dcbw: csound

dchen: UnihanDb

deji: tracker

denis: alltray,gconfmm26,pam_keyring,xfburn

devrim: classpathx-jaf

dledford: lam,libibcommon,libibmad,libibumad

dp67: ax25-apps,linpsk

drago01: pinot

dtimms: audacity

dwalluck: classpathx-jaf

dwmw2: hfsutils,linux-atm,qemu

edhill: cdo,libctl,libmatheval,nco,osiv,scrip

ehabkost: etherboot

emoret: paprefs

erikos: sugar

firewing: totem

fitzsim: javahelp2

fnasser: geronimo-specs,jakarta-commons-el

fonts-sig: libXfontcache

gemi: audacity,cook,gauche,gauche-gl,gauche-gtk,q,smarteiffel

ghenry: Sprog,cpan2rpm

gilboa: icewm,kdebluetooth

glommer: etherboot

green: ardour,ladspa-swh-plugins,seq24,ws-commons-util

hadess: gnome-web-photo,lirc,totem

hardaker: dnssec-tools

haskell-sig: ghc-gtk2hs,haddock09,happy

huzaifas: libtar,libtar

i18n-team: UnihanDb,ibus-chewing,imsettings,m17n-lib,scim,uim

iarnell: perl-Regexp-Assemble

iburrell: perl-SVN-Mirror

ics: liblqr-1

ixs: libsndfile,mboxgrep

izhar: compizconfig-backend-gconf,compizconfig-python,libcompizconfig

jakub: compat-gcc-32,compat-gcc-34,valgrind

james: zsh

jcollie: asterisk,python-openid

jdieter: presto-utils

jeckersb: PyYAML

jima: alsa-oss

jjames: jsr-305

jkratoch: insight

jnovy: compat-db

johnp: sugar

joost: fpc

jorton: apr,distcache,libidn

jpmahowa: gnome-compiz-manager

jpo: perl-Net-SSLeay

jpye: sundials

jsoeterb: xmms-cdread

jspaleta: g3data

jtulach: javahelp2

jwilson: emerald,libdv,libiec61883,lirc,lirc

jwrdegoede: ardour,monkey-bubble,soundtouch,worminator

kaboom: qgo

kaigai: sepostgresql

karlik: widelands

kasal: gdbm,libgconf-java,libgtk-java,perl,perl-BSD-Resource,perl-Net-SSLeay,perl-PDL,perl-XML-LibXSLT

kevin: Terminal,Thunar,thunar-shares,thunar-volman,xfce4-places-plugin,xfce4-verve-plugin,xfce4-volstatus-icon,xfdesktop

kkofler: flasm,kde-l10n

krh: compiz

kurzawa: incollector

kwizart: afflib,directfb,libgii

kzak: sudo

langel: java-1.6.0-openjdk,java-1.6.0-openjdk

laxathom: gnome-desktop-sharp,perl-Class-Autouse,perl-Class-Inspector,perl-Test-Inline,quake3,wammu

lfarkas: gstreamer-java,rxtx

limb: lilypond,vdrift

lkundrak: grub2,java-1.6.0-openjdk,perl-XML-Smart,skychart

lmacken: python-peak-rules

lokthare: almanah,pyrenamer

ltinkl: kde-l10n

lucilanga: xastir

lutter: ruby-rpm

makghosh: player

mattdm: wxGTK

mbarnes: devhelp,evolution-exchange,evolution-sharp,gnome-python2-desktop,gtkspell,libsoup

mccann: libfakekey

mclasen: libgweather

mgarski: xscorch

mhlavink: nut

michich: icecream

mikep: fmt-ptrn

mildew: sudo

mitr: python-gtkextra

mjw: java-1.6.0-openjdk

mmahut: skychart

mmaslano: perl,perl-BSD-Resource,perl-PDL

mnagy: ipa

monnerat: insight

morgan: sugar

mpeters: pan

mpg: gnome-web-photo,sugar

mschwendt: audacity

mtasaka: WebKit,ruby-hpricot

mwiriadi: gnome-themes-extras,gnome-themes-extras

mwringe: jline,junitperf,modello

nalin: nss_ldap

nboyle: qemu-launcher

ngompa: avant-window-navigator

nosnilmot: libsilc,libsilc,pidgin-guifications

notting: initscripts,kudzu

nphilipp: bzflag,rss-glx,sane-backends

nsantos: qpidc

oliver: apr

ondrejj: libnss-mysql,sagator

orion: R-lmtest,hdf5,lasi,netcdf-decoders,netcdf-perl,octave-forge,perl-Log-Trivial,perl-PDL,plplot,wgrib2

orphan: libzzub,nautilus-share

otaylor: desktop-data-model

ovasik: libwvstreams,openjade

overholt: ws-commons-util,xmlrpc3

pawsa: balsa

pcheung: plexus-i18n

perl-sig: cpan2rpm,netcdf-perl,perl-Archive-Any,perl-Class-Autouse,perl-Class-Inspector,perl-Data-ICal,perl-Data-Stag,perl-File-Find-Rule-Perl,perl-Gnome2-GConf,perl-Gtk2-Notify,perl-HTTP-Proxy,perl-IPC-Shareable,perl-JSON-Any,perl-Moose,perl-MooseX-Params-Validate,perl-Net-SSLeay,perl-POE-Component-SNMP,perl-Pugs-Compiler-Rule,perl-RRD-Simple,perl-Regexp-Assemble,perl-SVN-Mirror,perl-Sys-Virt,perl-Test-Inline,perl-Test-WWW-Mechanize-Catalyst,perl-Test-Warn,perl-WWW-Mechanize,perl-XML-LibXSLT,perl-bioperl,perl-bioperl-run

pertusus: Thunar,flasm,gpm,hdf5,icewm,nco,netcdf-decoders,netcdf-perl,wgrib2

petersen: ghc-gtk2hs,haddock09,happy,m17n-lib,scim

pfj: boo,csound,monodoc

pghmcfc: perl-Net-SSLeay

pgordon: WebKit,tremulous,tremulous

phuang: awn-extras-applets,ibus-chewing,scim

pingou: R-BSgenome.Celegans.UCSC.ce2,R-BSgenome.Dmelanogaster.FlyBase.r51,R-hgu95av2probe,R-pls

pmatilai: compat-db,popt

pmuldoon: libgtk-java

pnemade: m17n-lib

pwouters: ldns

qspencer: autotrace,octave-forge

rakesh: coredumper,ctemplate,linphone

rathann: dx

rcritten: ipa

rdieter: Macaulay2,ggz-gtk-client,kde-l10n,libpqxx

rezso: mapnik,qgis

rhughes: gnome-power-manager,gnome-power-manager,hal

rishi: gengetopt

rjones: freetennis

rnorwood: perl,perl-BSD-Resource,perl-PDL

robert: digitemp,librsync,popt

roozbeh: autotrace

rstrode: gcalctool,gnome-applets,gnome-panel,libbonoboui,redhat-menus

rvinyard: bitgtkmm,conexus,conexusmm,papyrus

rvokal: net-tools,openjade,pidgin-guifications

s4504kr: kaya

salimma: evolution-remove-duplicates,gnome-do,python-storm,xbacklight

sandeen: guilt

sconklin: ax25-apps,linpsk,xdx

scop: kdebluetooth,vdr,vdr-ttxtsubs

seg: openjpeg

sergiopr: tkimg

shahms: bzr-gtk

sharkcz: atari++,wxGTK

shishz: perl-XML-LibXSLT

silfreed: qgis

simo: ipa

sindrepb: avant-window-navigator,ax25-apps,cowbell,firewalk,gnome-do,gnome-do,linpsk,xdx

snecker: mapnik

splinux: gconf-cleaner,gdmap,gnome-specimen

spot: libpaper,librx,logjam,perl,perl-HTTP-Proxy,perl-IPC-Shareable,perl-Test-Warn,rekall,taglib-sharp,tcl-snack

ssp: gnome-system-monitor,libXTrap,libXfontcache,libXp,metacity

stahnma: ruby-rpm

stalwart: enlightenment

steve: perl-Pugs-Compiler-Rule,perl-Sys-Virt

steved: nfs4-acl-tools

subhodip: kdetv

svahl: devilspie

swagiaal: libgtk-java

tagoh: imsettings,uim

tanguy: scidavis

tbzatek: fpc

terjeros: simdock,xosview

tgl: libjpeg,unixODBC

than: kde-l10n

thias: blackbox,directfb,emerald,gcombust,hercules,pigment

thomasvs: ladspa,rasqal

till: iasl,pam_mount

timfenn: gpp4

timn: player

tmraz: pam

tnorth: avr-binutils

tomeu: sugar

toshio: bzr-gtk,bzr-gtk

trondd: avr-binutils,nautilus-python

turki: emerald

tuxbrewr: kde-l10n

twaugh: cups

vcrhonek: expect

victorv: ini4j

vpv: vdr

walters: bigboard,desktop-data-model

wart: abe,ember

wtogami: libsilc,pidgin-guifications

xavierb: xorg-x11-drv-openchrome

xgl-maint: xorg-x11-drv-ati,xorg-x11-drv-i810,xorg-x11-server

xris: orpie

zkota: python-bibtex

zprikryl: gpm,net-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 Dec 20 03:01:50 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 19 Dec 2008 21:01:50 -0600
Subject: Fedora rawhide rebuild in mock status 2008-12-17 i386
Message-ID: <20081220030150.GA23137@mock.linuxdev.us.dell.com>

Fedora Rawhide-in-Mock Build Results for i386

This is a full rebuild, using systems running rawhide as of 12/17 to
rebuild all packages in rawhide on 12/17.

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

Total packages: 6659
Number failed to build: 377
Number expected to fail due to ExclusiveArch or ExcludeArch: 13
Leaving:  364

Of those expected to have worked...
Without a bug filed: 362
----------------------------------
DeviceKit-disks-002-0.git20080720.fc10 (build/make) davidz
E-0.999.006-2.fc10 (build/make) dwheeler
Macaulay2-1.1-2.fc10 (build/make) rdieter
R-BSgenome.Celegans.UCSC.ce2-1.2.0-5 (build/make) pingou
R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3 (build/make) pingou
R-hgu95av2probe-2.0.0-1.fc9 (build/make) pingou
R-lmtest-0.9-2.fc10 (build/make) orion
R-pls-2.1-2.fc9 (build/make) pingou
Sprog-0.14-13.fc9 (build/make) ghenry
Terminal-0.2.8.3-1.fc10 (build/make) kevin
Thunar-0.9.0-4.fc9 (build/make) kevin,pertusus,cwickert
UnihanDb-5.1.0-7.fc10 (build/make) dchen,i18n-team
WebKit-1.0.0-0.15.svn37790.fc10 (build/make) pgordon,mtasaka
abe-1.1-7.fc9 (build/make) wart
afflib-3.3.4-4.fc10 (build/make) kwizart
alltray-0.70-2.fc9 (build/make) denis
almanah-0.5.0-1.fc11 (build/make) lokthare
alsa-oss-1.0.17-1.fc10 (build/make) jima
apr-1.3.3-1.fc10 (build/make) jorton,oliver,bojan
ardour-2.7-1.fc11 (build/make) green,jwrdegoede
asterisk-1.6.1-0.5beta2.fc11 (build/make) jcollie
atari++-1.55-2.fc11 (build/make) sharkcz
atlas-3.6.0-15.fc10 (build/make) deji,deji
audacity-1.3.5-0.8.beta.fc10 (build/make) gemi,mschwendt,dtimms
autotrace-0.31.1-18.fc10 (build/make) qspencer,roozbeh
avant-window-navigator-0.2.6-13.fc11 (build/make) sindrepb,ngompa
avr-binutils-2.18-2.fc9 (patch_fuzz) tnorth,trondd
awn-extras-applets-0.2.6-6.fc10 (build/make) phuang
ax25-apps-0.0.6-2.fc9 (build/make) bjensen,sindrepb,sconklin,dp67
balsa-2.3.26-2.fc10 (build/make) pawsa
bigboard-0.6.4-3.fc11 (build/make) walters
bitgtkmm-0.4.0-4.fc10 (build/make) rvinyard
blackbox-0.70.1-11 (build/make) thias
bmpx-0.40.14-7.fc10 (build/make) akahl
boo-0.8.1.2865-4.fc9 (build/make) pfj
bzflag-2.0.12-3.fc10 (build/make) nphilipp
bzr-gtk-0.95.0-2.fc10 (build/make) toshio,shahms,toshio
cdo-1.0.8-2.fc9 (build/make) edhill
classpathx-jaf-1.0-12.fc10 (build/make) devrim,dwalluck
clutter-0.8.2-1.fc10 (build/make) allisson
compat-db-4.6.21-5.fc10 (build/make) jnovy,pmatilai
compat-gcc-32-3.2.3-64 (build/make) jakub
compat-gcc-34-3.4.6-9 (patch_fuzz) jakub
compiz-0.7.8-9.fc11 (build/make) krh
compizconfig-backend-gconf-0.7.8-1.fc11 (build/make) izhar
compizconfig-python-0.7.8-2.fc11 (build/make) izhar
conexus-0.5.3-4.fc9 (build/make) rvinyard
conexusmm-0.5.0-3.fc7 (build/make) rvinyard
coredumper-1.2.1-6.fc10 (build/make) rakesh
cowbell-0.3-0.svn34.4.fc10 (build/make) sindrepb
cpan2rpm-2.028-2.fc8.1 (build/make) ghenry,perl-sig
csound-5.03.0-16.fc9 (build/make) dcbw,pfj
ctemplate-0.91-3.fc10 (build/make) rakesh
dbmail-2.2.9-2.fc10 (build/make) bjohnson
desktop-data-model-1.2.5-2.fc11 (build/make) walters,otaylor
devhelp-0.22-2.fc11 (build/make) mbarnes
devilspie-0.22-2.fc9 (build/make) svahl
digitemp-3.5.0-3.fc9 (build/make) robert
directfb-1.2.6-3.fc10 (build/make) thias,kwizart
distcache-1.4.5-17 (build/make) jorton
dnssec-tools-1.4.1-2.fc10 (build/make) hardaker
dx-4.4.4-7.fc10 (build/make) rathann
ember-0.5.4-5.fc11 (build/make) atorkhov,wart
emerald-0.7.6-2.fc10 (build/make) turki,thias,jwilson
enlightenment-0.16.999.043-3.fc10 (build/make) stalwart
evolution-brutus-1.2.27-2.fc10 (build/make) bpepple,colding
evolution-exchange-2.25.1-1.fc11 (build/make) mbarnes
evolution-remove-duplicates-0.0.4-1.fc10 (build/make) salimma
evolution-sharp-0.18.1-1.fc10 (build/make) mbarnes
expect-5.43.0-15.fc10 (build/make) vcrhonek
file-roller-2.24.2-1.fc10 (build/make) caillon
flasm-1.62-4.fc9 (build/make) kkofler,pertusus
fmt-ptrn-1.3.17-2.fc10 (build/make) mikep
freealut-1.1.0-6.fc9 (build/make) awjb
freetds-0.82-2.fc10 (build/make) buc
freetennis-0.4.8-14.fc10 (build/make) rjones
g3data-1.5.1-8.fc9 (build/make) jspaleta
gcalctool-5.25.1-2.fc11 (build/make) rstrode
gconf-cleaner-0.0.2-6.fc10 (build/make) splinux
gconfmm26-2.24.0-1.fc10 (build/make) denis
gdbm-1.8.0-29.fc10 (build/make) kasal
gdmap-0.7.5-6.fc6 (build/make) splinux
gengetopt-2.22.1-1.fc10 (build/make) rishi
geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser
ggz-gtk-client-0.0.14.1-1.fc9 (build/make) bpepple,rdieter
ghc-gtk2hs-0.9.13-6.20081108.fc11 (build/make) bos,haskell-sig,petersen
gnome-applets-2.25.1-4.fc11 (build/make) rstrode
gnome-compiz-manager-0.10.4-6.fc11 (build/make) jpmahowa
gnome-desktop-sharp-2.24.0-3.fc10 (build/make) laxathom
gnome-do-0.6.1.0-2.fc10 (build/make) sindrepb,salimma,sindrepb
gnome-panel-2.24.1-6.fc11 (build/make) rstrode
gnome-power-manager-2.24.2-2.fc11 (build/make) rhughes,rhughes
gnome-python2-desktop-2.24.0-5.fc11 (build/make) mbarnes
gnome-specimen-0.3-3.fc11 (build/make) splinux
gnome-speech-0.4.22-1.fc10 (build/make) davidz
gnome-system-monitor-2.24.1-1.fc10 (build/make) ssp
gnome-themes-extras-2.22.0-2.fc9 (build/make) mwiriadi,mwiriadi
gnome-web-photo-0.3-12.fc10 (build/make) hadess,mpg
gok-2.25.2-1.fc11 (build/make) davidz
gpm-1.20.5-1.fc10 (build/make) zprikryl,pertusus
gpp4-1.0.4-11.fc11 (build/make) timfenn
grub2-1.98-0.3.20080827svn.fc10 (build/make) lkundrak
gstreamer-plugins-base-0.10.21-2.fc10 (build/make) ajax
gthumb-2.10.10-3.fc10 (build/make) behdad
gtkspell-2.0.13-1.fc10 (build/make) mbarnes
guilt-0.30-2.fc10 (build/make) sandeen
gwget-0.99-8.fc10 (build/make) cwickert
haddock09-0.9-3.fc10 (build/make) bos,haskell-sig,petersen
hal-0.5.12-12.20081027git.fc10 (build/make) rhughes
happy-1.18.2-1.fc11 (build/make) bos,haskell-sig,petersen
hdf5-1.8.1-2.fc10 (build/make) orion,pertusus
hercules-3.05-7.20081009cvs.fc10 (build/make) thias
hfsutils-3.2.6-14.fc9 (patch_fuzz) dwmw2
iasl-20061109-4.fc9 (build/make) till
ibus-chewing-0.1.1.20081023-2.fc11 (build/make) phuang,i18n-team
icecream-0.8.0-11.20080117svn.fc9 (build/make) michich
icewm-1.2.35-4.fc10 (build/make) gilboa,pertusus
imsettings-0.105.1-2.fc10 (build/make) tagoh,i18n-team
incollector-1.0-6.fc9.1 (build/make) kurzawa
ini4j-0.3.2-4.fc10 (build/make) victorv
initng-conf-gtk-0.5.1-4.fc9 (build/make) danielm
initscripts-8.86-1 (build/make) notting
insight-6.8-4.fc11 (build/make) monnerat,jkratoch
ipa-1.2.0-3.fc11 (build/make) rcritten,simo,mnagy
jakarta-commons-el-1.0-9.4.fc10 (build/make) fnasser
javahelp2-2.0.05-5.fc10 (build/make) jtulach,fitzsim
jline-0.9.94-0.2.fc10 (build/make) mwringe
jsr-305-0-0.1.20080824svn.fc10 (build/make) jjames
kaya-0.5.1-1.fc10 (build/make) s4504kr
kde-l10n-4.1.3-1.fc10 (build/make) than,rdieter,kkofler,tuxbrewr,ltinkl
kdebluetooth-0.2-3.fc10 (build/make) gilboa,scop
kdetv-0.8.9-10.fc9 (build/make) subhodip
kudzu-1.2.85-2 (build/make) notting
ladspa-1.12-9.fc9 (build/make) thomasvs
ladspa-swh-plugins-0.4.15-12.fc9 (build/make) green
lam-7.1.4-1.fc10 (build/make) dledford
lasi-1.1.0-2.fc10 (build/make) orion
ldns-1.4.0-1.fc11 (build/make) pwouters
libXTrap-1.0.0-6.fc10 (build/make) ssp
libXfontcache-1.0.4-5.fc9 (build/make) ssp,fonts-sig
libXp-1.0.0-11.fc9 (build/make) ssp
libbonoboui-2.24.0-1.fc10 (build/make) rstrode
libcompizconfig-0.7.8-1.fc11 (build/make) izhar
libctl-3.0.2-6.fc9 (build/make) edhill
libdv-1.0.0-5.fc10 (build/make) jwilson
libfakekey-0.1-1.fc10 (build/make) mccann
libgconf-java-2.12.4-11.fc10 (build/make) kasal
libgnome-java-2.12.4-9.fc10 (build/make) kasal
libgweather-2.25.2-2.fc11 (build/make) mclasen
libibcommon-1.1.0-1.fc10 (build/make) dledford
libibmad-1.2.0-1.fc10 (build/make) dledford
libibumad-1.2.0-1.fc10 (build/make) dledford
libidn-0.6.14-8 (build/make) jorton
libiec61883-1.1.0-5.fc10 (build/make) jwilson
libjpeg-6b-43.fc10 (build/make) tgl
liblqr-1-0.1.0-5.fc9 (build/make) ics
libmatheval-1.1.5-2.fc9 (patch_fuzz) edhill
libnss-mysql-1.5-7.fc9 (build/make) ondrejj
libopensync-0.36-3.fc10 (build/make) awjb
libopensync-plugin-evolution2-0.36-1.fc10 (build/make) awjb
libopensync-plugin-file-0.36-1.fc10 (build/make) awjb
libopensync-plugin-gnokii-0.36-2.fc10 (build/make) cheese,awjb
libopensync-plugin-google-calendar-0.36-1.fc10 (build/make) awjb
libopensync-plugin-gpe-0.36-1.fc10 (build/make) awjb
libopensync-plugin-irmc-0.36-2.fc10 (build/make) awjb
libopensync-plugin-kdepim-0.36-1.fc10 (build/make) awjb
libopensync-plugin-moto-0.36-1.fc10 (build/make) awjb
libopensync-plugin-opie-0.36-1.fc10 (build/make) awjb
libopensync-plugin-palm-0.36-1.fc10 (build/make) awjb
libopensync-plugin-python-0.36-1.fc10 (build/make) awjb
libopensync-plugin-syncml-0.35-4.fc10 (build/make) cheese
libopensync-plugin-vformat-0.36-1.fc10 (build/make) awjb
libpaper-1.1.23-3.fc10 (build/make) spot
libpolyxmass-0.9.1-2.fc9 (build/make) awjb
libpqxx-2.6.8-10.fc9 (build/make) awjb,rdieter
librra-0.11.1-1.fc9 (build/make) awjb,abompard
librsync-0.9.7-12.fc9 (build/make) robert
librx-1.5-10.fc9 (build/make) spot
libsilc-1.1.7-2.fc10 (build/make) nosnilmot,wtogami,nosnilmot
libsndfile-1.0.17-6.fc10 (build/make) ixs
libsoup-2.25.2-1.fc11 (build/make) mbarnes,danw
libtar-1.2.11-11.fc10 (build/make) huzaifas,huzaifas
libthai-0.1.9-4.fc9 (build/make) behdad
libwvstreams-4.5-1.fc11 (build/make) ovasik
libzzub-0.2.3-12.fc9 (patch_fuzz) orphan
lightning-1.2c-1.fc10 (build/make) s4504kr,laxathom
lilypond-2.11.57-2.fc11 (build/make) limb
linphone-2.1.1-1.fc9 (build/make) rakesh
linpsk-0.9-4.fc10 (build/make) bjensen,bjensen,sindrepb,sconklin,dp67
linux-atm-2.5.0-5 (build/make) dwmw2
logjam-4.5.3-25.fc10 (build/make) spot
m17n-lib-1.5.3-1.fc10 (build/make) pnemade,i18n-team,petersen
maildrop-2.0.4-6.fc9 (build/make) athimm
mapnik-0.5.2-0.7.svn738.fc10 (build/make) rezso,snecker
maven-scm-1.0-0.2.b3.1.6.fc10 (build/make) dbhole
maven-shared-1.0-4.6.fc10 (build/make) dbhole
maven2-2.0.4-10.15.fc10 (build/make) dbhole
mboxgrep-0.7.9-6.fc10 (build/make) ixs
mesa-7.2-0.15.fc10 (build/make) ajax,ajax
metacity-2.25.34-1.fc11 (build/make) ssp
modello-1.0-0.1.a8.4.4.fc10 (build/make) mwringe
monkey-bubble-0.4.0-9.fc9 (build/make) jwrdegoede
mono-sharpcvslib-0.35-3.fc10 (build/make) spot
monodoc-2.0-5.fc10 (build/make) pfj
monotone-0.41-1.fc10 (build/make) 
msv-1.2-0.2.20050722.3.4.fc10 (build/make) mwringe
msynctool-0.36-1.fc10 (build/make) awjb
nautilus-python-0.5.1-1.fc10 (build/make) trondd
nautilus-share-0.7.2-13.fc10 (build/make) orphan
nco-3.9.5-2.fc10 (build/make) edhill,pertusus
net-tools-1.60-91.fc10 (build/make) rvokal,zprikryl
netcdf-decoders-5.0.0-1.fc9 (build/make) orion,pertusus
netcdf-perl-1.2.3-7.fc9 (build/make) orion,perl-sig,pertusus
newscache-1.2-0.6.rc6.fc9 (build/make) buc
nfs4-acl-tools-0.3.2-2.fc9 (patch_fuzz) steved
nip2-7.14.5-1.fc10 (build/make) agoode
notification-daemon-0.4.0-1.fc11 (build/make) davidz
nss_ldap-261-4.fc10 (build/make) nalin
nut-2.2.2-3.fc10 (build/make) mhlavink
octave-forge-20080831-2.fc10 (build/make) qspencer,orion,alexlan
olpcsound-5.08.92-12.fc11 (build/make) veplaini
openal-0.0.9-0.15.20060204cvs.fc9 (patch_fuzz) awjb
openjade-1.3.2-31.fc9 (build/make) ovasik,rvokal
openjpeg-1.3-2.fc9 (patch_fuzz) seg
orpie-1.5.1-4.fc10 (build/make) xris
osiv-2.0.0-0.4.beta.fc9 (build/make) edhill
pam-1.0.2-2.fc10 (build/make) tmraz
pam_keyring-0.0.9-2.fc9 (build/make) denis
pam_mount-0.49-1.fc10 (build/make) till
pan-0.133-1.fc10 (build/make) adalloz,mpeters
paprefs-0.9.7-3.fc10 (build/make) emoret
papyrus-0.7.1-3.fc9 (build/make) rvinyard
perl-Archive-Any-0.093-3.fc9 (build/make) cweyl,perl-sig
perl-BSD-Resource-1.28-6.fc9 (build/make) kasal,rnorwood,mmaslano
perl-Class-Autouse-1.29-3.fc9 (build/make) corsepiu,perl-sig,laxathom
perl-Class-Inspector-1.23-1.fc10 (build/make) corsepiu,perl-sig,laxathom
perl-Data-ICal-0.13-3.fc10 (build/make) corsepiu,perl-sig
perl-Data-Stag-0.11-1.fc10 (build/make) alexlan,perl-sig
perl-File-Find-Rule-Perl-1.04-2.fc10 (build/make) corsepiu,perl-sig
perl-Gnome2-GConf-1.044-4.fc10 (build/make) cweyl,perl-sig
perl-Gtk2-Notify-0.04-3.fc9 (build/make) cweyl,perl-sig
perl-HTTP-Proxy-0.20-2.fc9 (build/make) spot,perl-sig
perl-IPC-Shareable-0.60-6.fc9 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
perl-JSON-Any-1.16-3.fc9 (build/make) cweyl,perl-sig
perl-Log-Trivial-0.31-2.fc9 (build/make) orion
perl-Module-CPANTS-Analyse-0.82-2.fc10 (build/make) berrange
perl-Moose-0.62-1.fc11 (build/make) cweyl,perl-sig
perl-MooseX-Params-Validate-0.05-1.fc10 (build/make) cweyl,perl-sig
perl-Net-SSLeay-1.35-1.fc10 (build/make) pghmcfc,perl-sig,jpo,kasal
perl-POE-Component-SNMP-1.07-3.fc9 (build/make) cweyl,perl-sig
perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig
perl-Regexp-Assemble-0.34-1.fc11 (build/make) iarnell,perl-sig
perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig
perl-Sys-Virt-0.1.2-3.fc9 (build/make) steve,perl-sig,berrange
perl-Test-Inline-2.208-3.fc10 (build/make) corsepiu,perl-sig,laxathom
perl-Test-WWW-Mechanize-Catalyst-0.42-1.fc10 (build/make) cweyl,perl-sig
perl-Test-Warn-0.10-3.fc9 (build/make) spot,perl-sig
perl-WWW-Mechanize-1.34-1.fc10 (build/make) cweyl,perl-sig
perl-XML-LibXSLT-1.66-2.fc10 (build/make) kasal,perl-sig,shishz
perl-XML-Smart-1.6.9-1.fc10 (build/make) lkundrak
perl-bioperl-1.5.2_102-13.fc10 (build/make) alexlan,perl-sig
perl-bioperl-run-1.5.2_100-3.fc9 (build/make) alexlan,perl-sig
pidgin-guifications-2.16-1.fc10 (build/make) rvokal,wtogami,nosnilmot
pigment-0.3.11-1.fc10 (build/make) thias
pinot-0.89-1.fc10 (build/make) drago01
player-2.1.1-5.fc10 (build/make) timn,makghosh
plexus-appserver-1.0-0.2.a5.2.6.fc10 (build/make) dbhole
plexus-cdc-1.0-0.2.a4.1.6.fc10 (build/make) dbhole
plexus-i18n-1.0-0.b6.5.3.fc10 (build/make) pcheung
plexus-maven-plugin-1.2-2.4.fc10 (build/make) dbhole
plexus-runtime-builder-1.0-0.2.a9.1.6.fc10 (build/make) dbhole
plexus-xmlrpc-1.0-0.2.b4.2.11.fc10 (build/make) dbhole
plplot-5.9.0-4.svn8985.fc11 (build/make) orion
polyxmass-bin-0.9.7-2.fc8 (build/make) awjb
popt-1.13-4.fc10 (build/make) robert,pmatilai
presto-utils-0.3.3-2.fc10 (build/make) jdieter
protobuf-2.0.2-5.fc11 (build/make) abbot
pyrenamer-0.6.0-2.fc11 (build/make) lokthare
python-bibtex-1.2.4-5.fc11 (build/make) zkota
python-cherrypy2-2.3.0-7.fc11 (build/make) toshio,lmacken,fschwarz
python-gtkextra-1.1.0-3.fc10 (build/make) mitr
python-openid-2.2.1-1.fc10 (build/make) jcollie
python-storm-0.13-2.fc10 (build/make) salimma
pywbxml-0.1-3.fc9 (build/make) awjb
q-7.11-2.fc10 (build/make) gemi
qemu-0.9.1-10.fc10 (patch_fuzz) dwmw2
qemu-launcher-1.7.4-4.fc9 (build/make) nboyle
qgis-0.11.0-4.fc10 (build/make) silfreed,rezso
qgo-1.5.4r2-1.fc9 (build/make) kaboom
qpidc-0.3.722557-1.fc10 (build/make) aconway,nsantos
quake3-1.34-0.9.rc4.fc9 (patch_fuzz) laxathom
quesa-1.8-1.fc9 (build/make) ajax
rasqal-0.9.15-1.fc9 (build/make) thomasvs
redhat-menus-10.0.1-1.fc11 (build/make) rstrode
regexxer-0.9-3.fc9 (build/make) cwickert
rekall-2.4.6-5.fc10 (build/make) spot
ristretto-0.0.21-1.fc11 (build/make) cwickert
rss-glx-0.8.1.p-20.fc10 (build/make) nphilipp
ruby-hpricot-0.6-2.fc9 (build/make) mtasaka
ruby-openid-2.1.2-1.fc10 (build/make) allisson
ruby-rpm-1.2.3-4.fc9 (build/make) lutter,stahnma
rxtx-2.1-0.2.7r2.fc11 (build/make) lfarkas
sagator-1.1.1-0.beta1.fc10 (build/make) ondrejj
sane-backends-1.0.19-12.fc10 (build/make) nphilipp
scidavis-0.1.3-2.fc10 (build/make) tanguy
scim-1.4.7-35.fc10 (build/make) phuang,i18n-team,petersen
scrip-1.4-9.fc8 (build/make) edhill
sepostgresql-8.3.5-2.1183.fc10 (build/make) kaigai
seq24-0.8.7-13.fc10 (patch_fuzz) green
simdock-1.2-3.fc10 (build/make) terjeros
smarteiffel-2.3-2.fc9 (build/make) gemi
soundtouch-1.3.1-10.fc9 (build/make) jwrdegoede
sudo-1.6.9p17-2.fc10 (build/make) mildew,kzak
sugar-0.83.3-4.fc11 (build/make) mpg,johnp,bernie,morgan,tomeu,erikos
sundials-2.3.0-6.fc9 (build/make) jpye
swfdec-gnome-2.24.0-2.fc10 (build/make) bpepple
syck-0.61-5.1.fc10 (build/make) oliver
synce-software-manager-0.9.0-10.fc9 (build/make) awjb
taglib-sharp-2.0.3.0-7.fc11 (build/make) spot
tcl-snack-2.2.10-6.fc10 (build/make) spot
teseq-1.0.0-2.fc10 (build/make) bonii
thunar-archive-plugin-0.2.4-5.fc10 (build/make) cwickert
thunar-media-tags-plugin-0.1.2-4.fc9 (build/make) cwickert
thunar-shares-0.16-1.fc10 (build/make) cwickert,kevin
thunar-volman-0.2.0-2.fc9 (build/make) cwickert,kevin
tiger-3.2.1-8.fc9 (patch_fuzz) abompard
tightvnc-1.5.0-0.9.20081120svn3200.fc11 (build/make) atkac
tkimg-1.4-0.1.20081115svn.fc11 (build/make) sergiopr
totem-2.24.3-3.fc11 (build/make) hadess,firewing
tracker-0.6.6-4.fc11 (build/make) deji
tremulous-1.1.0-6.fc9 (build/make) pgordon,pgordon
uim-1.5.3-1.fc10 (build/make) tagoh,i18n-team
unixODBC-2.2.12-9.fc10 (build/make) tgl
valgrind-3.3.0-4 (build/make) jakub
vdr-1.6.0-15.fc11 (build/make) scop,vpv
vdr-ttxtsubs-0.0.5-6.fc11 (build/make) scop
vdrift-20080805-2.fc10 (build/make) limb
vnc-4.1.2-35.fc10 (patch_fuzz) atkac
wammu-0.28-1.fc10 (build/make) laxathom
wgrib2-1.7.2b-1.fc10 (build/make) orion,pertusus
widelands-0-0.13.Build13.fc11 (build/make) karlik
worminator-3.0R2.1-8.fc9 (build/make) jwrdegoede
ws-commons-util-1.0.1-10.fc10 (build/make) green,overholt
wxGTK-2.8.9-3.fc11 (build/make) mattdm,sharkcz
xastir-1.9.4-5.fc10 (build/make) lucilanga,bjensen
xbacklight-1.1-2.fc9 (build/make) salimma
xdx-2.4-2.fc9 (build/make) bjensen,sindrepb,sconklin
xfburn-0.3.91-2.fc11 (build/make) cwickert,denis
xfce4-notes-plugin-1.6.3-1.fc11 (build/make) cwickert
xfce4-places-plugin-1.1.0-3.fc10 (build/make) cwickert,kevin
xfce4-verve-plugin-0.3.6-1.fc11 (build/make) cwickert,kevin
xfce4-volstatus-icon-0.1.0-3.fc9 (build/make) cwickert,kevin
xfce4-xkb-plugin-0.5.2-1.fc11 (build/make) cwickert
xfdesktop-4.4.2-6.fc10 (build/make) kevin
xmlrpc3-3.0-2.9.fc10 (build/make) overholt,akurtakov
xorg-x11-drv-ati-6.9.0-62.fc10 (build/make) xgl-maint
xorg-x11-drv-i810-2.5.0-3.fc11 (build/make) xgl-maint
xorg-x11-drv-openchrome-0.2.903-2.fc11 (build/make) xavierb
xorg-x11-server-1.5.3-6.fc10 (build/make) xgl-maint
xosview-1.8.3-13.20080301cvs.fc10 (build/make) terjeros
xscorch-0.2.0-12.fc8 (build/make) mgarski
zsh-4.3.4-8.fc9 (patch_fuzz) james

With bugs filed: 2
----------------------------------
gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) jjames,green
libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm




----------------------------------
Packages by owner:
abbot: protobuf

abompard: librra,tiger

aconway: qpidc

adalloz: pan

agoode: nip2

ajax: gstreamer-plugins-base,mesa,mesa,quesa

akahl: bmpx

akurtakov: xmlrpc3

alexlan: octave-forge,perl-Data-Stag,perl-bioperl,perl-bioperl-run

allisson: clutter,ruby-openid

athimm: libFoundation,maildrop

atkac: tightvnc,vnc

atorkhov: ember

awjb: freealut,libopensync,libopensync-plugin-evolution2,libopensync-plugin-file,libopensync-plugin-gnokii,libopensync-plugin-google-calendar,libopensync-plugin-gpe,libopensync-plugin-irmc,libopensync-plugin-kdepim,libopensync-plugin-moto,libopensync-plugin-opie,libopensync-plugin-palm,libopensync-plugin-python,libopensync-plugin-vformat,libpolyxmass,libpqxx,librra,msynctool,openal,polyxmass-bin,pywbxml,synce-software-manager

behdad: gthumb,libthai

bernie: sugar

berrange: perl-Module-CPANTS-Analyse,perl-Sys-Virt

bjensen: ax25-apps,linpsk,linpsk,xastir,xdx

bjohnson: dbmail

bojan: apr

bonii: teseq

bos: ghc-gtk2hs,haddock09,happy

bpepple: evolution-brutus,ggz-gtk-client,swfdec-gnome

buc: freetds,newscache

caillon: file-roller

cheese: libopensync-plugin-gnokii,libopensync-plugin-syncml

colding: evolution-brutus

corsepiu: perl-Class-Autouse,perl-Class-Inspector,perl-Data-ICal,perl-File-Find-Rule-Perl,perl-Test-Inline

cweyl: perl-Archive-Any,perl-Gnome2-GConf,perl-Gtk2-Notify,perl-JSON-Any,perl-Moose,perl-MooseX-Params-Validate,perl-POE-Component-SNMP,perl-RRD-Simple,perl-Test-WWW-Mechanize-Catalyst,perl-WWW-Mechanize

cwickert: Thunar,gwget,regexxer,ristretto,thunar-archive-plugin,thunar-media-tags-plugin,thunar-shares,thunar-volman,xfburn,xfce4-notes-plugin,xfce4-places-plugin,xfce4-verve-plugin,xfce4-volstatus-icon,xfce4-xkb-plugin

danielm: initng-conf-gtk

danw: libsoup

davidz: DeviceKit-disks,gnome-speech,gok,notification-daemon

dbhole: maven-scm,maven-shared,maven2,plexus-appserver,plexus-cdc,plexus-maven-plugin,plexus-runtime-builder,plexus-xmlrpc

dcbw: csound

dchen: UnihanDb

deji: atlas,atlas,tracker

denis: alltray,gconfmm26,pam_keyring,xfburn

devrim: classpathx-jaf

dledford: lam,libibcommon,libibmad,libibumad

dp67: ax25-apps,linpsk

drago01: pinot

dtimms: audacity

dwalluck: classpathx-jaf

dwheeler: E

dwmw2: hfsutils,linux-atm,qemu

edhill: cdo,libctl,libmatheval,nco,osiv,scrip

emoret: paprefs

erikos: sugar

firewing: totem

fitzsim: javahelp2

fnasser: geronimo-specs,jakarta-commons-el

fonts-sig: libXfontcache

fschwarz: python-cherrypy2

gemi: audacity,q,smarteiffel

ghenry: Sprog,cpan2rpm

gilboa: icewm,kdebluetooth

green: ardour,gcl,ladspa-swh-plugins,seq24,ws-commons-util

hadess: gnome-web-photo,totem

hardaker: dnssec-tools

haskell-sig: ghc-gtk2hs,haddock09,happy

huzaifas: libtar,libtar

i18n-team: UnihanDb,ibus-chewing,imsettings,m17n-lib,scim,uim

iarnell: perl-Regexp-Assemble

iburrell: perl-SVN-Mirror

ics: liblqr-1

ixs: libsndfile,mboxgrep

izhar: compizconfig-backend-gconf,compizconfig-python,libcompizconfig

jakub: compat-gcc-32,compat-gcc-34,valgrind

james: zsh

jcollie: asterisk,python-openid

jdieter: presto-utils

jima: alsa-oss

jjames: gcl,jsr-305

jkratoch: insight

jnovy: compat-db

johnp: sugar

jorton: apr,distcache,libidn

jpmahowa: gnome-compiz-manager

jpo: perl-Net-SSLeay

jpye: sundials

jspaleta: g3data

jtulach: javahelp2

jwilson: emerald,libdv,libiec61883

jwrdegoede: ardour,monkey-bubble,soundtouch,worminator

kaboom: qgo

kaigai: sepostgresql

karlik: widelands

kasal: gdbm,libgconf-java,libgnome-java,perl-BSD-Resource,perl-Net-SSLeay,perl-XML-LibXSLT

kevin: Terminal,Thunar,thunar-shares,thunar-volman,xfce4-places-plugin,xfce4-verve-plugin,xfce4-volstatus-icon,xfdesktop

kkofler: flasm,kde-l10n

krh: compiz

kurzawa: incollector

kwizart: afflib,directfb

kzak: sudo

laxathom: gnome-desktop-sharp,lightning,perl-Class-Autouse,perl-Class-Inspector,perl-Test-Inline,quake3,wammu

lfarkas: rxtx

limb: lilypond,vdrift

lkundrak: grub2,perl-XML-Smart

lmacken: python-cherrypy2

lokthare: almanah,pyrenamer

ltinkl: kde-l10n

lucilanga: xastir

lutter: ruby-rpm

makghosh: player

mattdm: wxGTK

mbarnes: devhelp,evolution-exchange,evolution-sharp,gnome-python2-desktop,gtkspell,libsoup

mccann: libfakekey

mclasen: libgweather

mgarski: xscorch

mhlavink: nut

michich: icecream

mikep: fmt-ptrn

mildew: sudo

mitr: python-gtkextra

mmaslano: perl-BSD-Resource

mnagy: ipa

monnerat: insight

morgan: sugar

mpeters: pan

mpg: gnome-web-photo,sugar

mschwendt: audacity

mtasaka: WebKit,ruby-hpricot

mwiriadi: gnome-themes-extras,gnome-themes-extras

mwringe: jline,modello,msv

nalin: nss_ldap

nboyle: qemu-launcher

ngompa: avant-window-navigator

nosnilmot: libsilc,libsilc,pidgin-guifications

notting: initscripts,kudzu

nphilipp: bzflag,rss-glx,sane-backends

nsantos: qpidc

oliver: apr,syck

ondrejj: libnss-mysql,sagator

orion: R-lmtest,hdf5,lasi,netcdf-decoders,netcdf-perl,octave-forge,perl-Log-Trivial,plplot,wgrib2

orphan: libzzub,nautilus-share

otaylor: desktop-data-model

ovasik: libwvstreams,openjade

overholt: ws-commons-util,xmlrpc3

pawsa: balsa

pcheung: plexus-i18n

perl-sig: cpan2rpm,netcdf-perl,perl-Archive-Any,perl-Class-Autouse,perl-Class-Inspector,perl-Data-ICal,perl-Data-Stag,perl-File-Find-Rule-Perl,perl-Gnome2-GConf,perl-Gtk2-Notify,perl-HTTP-Proxy,perl-IPC-Shareable,perl-JSON-Any,perl-Moose,perl-MooseX-Params-Validate,perl-Net-SSLeay,perl-POE-Component-SNMP,perl-RRD-Simple,perl-Regexp-Assemble,perl-SVN-Mirror,perl-Sys-Virt,perl-Test-Inline,perl-Test-WWW-Mechanize-Catalyst,perl-Test-Warn,perl-WWW-Mechanize,perl-XML-LibXSLT,perl-bioperl,perl-bioperl-run

pertusus: Thunar,flasm,gpm,hdf5,icewm,nco,netcdf-decoders,netcdf-perl,wgrib2

petersen: ghc-gtk2hs,haddock09,happy,m17n-lib,scim

pfj: boo,csound,monodoc

pghmcfc: perl-Net-SSLeay

pgordon: WebKit,tremulous,tremulous

phuang: awn-extras-applets,ibus-chewing,scim

pingou: R-BSgenome.Celegans.UCSC.ce2,R-BSgenome.Dmelanogaster.FlyBase.r51,R-hgu95av2probe,R-pls

pmatilai: compat-db,popt

pnemade: m17n-lib

pwouters: ldns

qspencer: autotrace,octave-forge

rakesh: coredumper,ctemplate,linphone

rathann: dx

rcritten: ipa

rdieter: Macaulay2,ggz-gtk-client,kde-l10n,libpqxx

rezso: mapnik,qgis

rhughes: gnome-power-manager,gnome-power-manager,hal

rishi: gengetopt

rjones: freetennis

rnorwood: perl-BSD-Resource

robert: digitemp,librsync,popt

roozbeh: autotrace

rstrode: gcalctool,gnome-applets,gnome-panel,libbonoboui,redhat-menus

rvinyard: bitgtkmm,conexus,conexusmm,papyrus

rvokal: net-tools,openjade,pidgin-guifications

s4504kr: kaya,lightning

salimma: evolution-remove-duplicates,gnome-do,python-storm,xbacklight

sandeen: guilt

sconklin: ax25-apps,linpsk,xdx

scop: kdebluetooth,vdr,vdr-ttxtsubs

seg: openjpeg

sergiopr: tkimg

shahms: bzr-gtk

sharkcz: atari++,wxGTK

shishz: perl-XML-LibXSLT

silfreed: qgis

simo: ipa

sindrepb: avant-window-navigator,ax25-apps,cowbell,gnome-do,gnome-do,linpsk,xdx

snecker: mapnik

splinux: gconf-cleaner,gdmap,gnome-specimen

spot: libpaper,librx,logjam,mono-sharpcvslib,perl-HTTP-Proxy,perl-IPC-Shareable,perl-Test-Warn,rekall,taglib-sharp,tcl-snack

ssp: gnome-system-monitor,libXTrap,libXfontcache,libXp,metacity

stahnma: ruby-rpm

stalwart: enlightenment

steve: perl-Sys-Virt

steved: nfs4-acl-tools

subhodip: kdetv

svahl: devilspie

tagoh: imsettings,uim

tanguy: scidavis

terjeros: simdock,xosview

tgl: libjpeg,unixODBC

than: kde-l10n

thias: blackbox,directfb,emerald,hercules,pigment

thomasvs: ladspa,rasqal

till: iasl,pam_mount

timfenn: gpp4

timn: player

tmraz: pam

tnorth: avr-binutils

tomeu: sugar

toshio: bzr-gtk,bzr-gtk,python-cherrypy2

trondd: avr-binutils,nautilus-python

turki: emerald

tuxbrewr: kde-l10n

vcrhonek: expect

veplaini: olpcsound

victorv: ini4j

vpv: vdr

walters: bigboard,desktop-data-model

wart: abe,ember

wtogami: libsilc,pidgin-guifications

xavierb: xorg-x11-drv-openchrome

xgl-maint: xorg-x11-drv-ati,xorg-x11-drv-i810,xorg-x11-server

xris: orpie

zkota: python-bibtex

zprikryl: gpm,net-tools


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From jamundso at gmail.com  Sat Dec 20 03:12:06 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 19 Dec 2008 21:12:06 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812191619k7ec53dacxf1a0d29d00a9c825@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229634566.3300.2.camel@matthiasc> <giepf5$i12$1@ger.gmane.org>
	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>
	<6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>
	<494C08B7.5010903@gmail.com>
	<200812200007.mBK077J7004429@laptop14.inf.utfsm.cl>
	<604aa7910812191619k7ec53dacxf1a0d29d00a9c825@mail.gmail.com>
Message-ID: <6d06ce20812191912m464409efn1d14202da78ebaa7@mail.gmail.com>

On Fri, Dec 19, 2008 at 6:19 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Fri, Dec 19, 2008 at 3:07 PM, Horst H. von Brand
> <vonbrand at inf.utfsm.cl> wrote:
>> Disk and RAM are practically free, given today's prices.
>
> Not on netbooks.

And not for some key open source consumers - students, or those just
entering the job market, OLPC, education targets, middle-agers like,
ahem, "a friend of mine" living in interesting economic times...

jerry
-- 
To be named later.



From orion at cora.nwra.com  Sat Dec 20 04:52:15 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 19 Dec 2008 21:52:15 -0700
Subject: koji client on EL5?
Message-ID: <494C79FF.3060008@cora.nwra.com>

Is it possible to run the koji client to do fedora builds from EL5?

I'm getting:

Unable to log in, no authentication methods available

koji-1.2.6-1.el5

I may not have everything I need, but it's not very verbose about what 
it might be.

- Orion



From orion at cora.nwra.com  Sat Dec 20 04:58:10 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 19 Dec 2008 21:58:10 -0700
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <494C7B62.8060709@cora.nwra.com>

Matt Domsch wrote:
> Fedora Rawhide-in-Mock Build Results for x86_64
> 
> This is a full rebuild, using systems running rawhide as of 12/17 to
> rebuild all packages in rawhide on 12/17.
> 
> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

> R-lmtest-0.9-2.fc10 (build/make) orion

Appears to be some kind of LaTeX issue.  Don't have time to look into it 
right now.


> hdf5-1.8.1-2.fc10 (build/make) orion,pertusus

Waiting on Bug 472385 -  [Bug fortran/38171] [regression] equivalence 
and nested modules broken - need a new version of gcc-gfortran in 
F10/rawhide.


> lasi-1.1.0-2.fc10 (build/make) orion

DEBUG util.py:251:  No Package Found for dejavu-fonts

I must have missed something about a name change....



From iarnell at gmail.com  Sat Dec 20 05:18:57 2008
From: iarnell at gmail.com (Iain Arnell)
Date: Sat, 20 Dec 2008 06:18:57 +0100
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <81487f820812192118t58766288t1bef3f8d04abe45d@mail.gmail.com>

On Sat, Dec 20, 2008 at 4:00 AM, Matt Domsch <Matt_Domsch at dell.com> wrote:
> Fedora Rawhide-in-Mock Build Results for x86_64
>
> perl-5.10.0-52.fc11 (build/make) mmaslano,spot,corsepiu,rnorwood,kasal
> perl-Archive-Any-0.093-3.fc9 (build/make) cweyl,perl-sig
> perl-BSD-Resource-1.28-6.fc9 (build/make) kasal,rnorwood,mmaslano
> perl-Class-Autouse-1.29-3.fc9 (build/make) corsepiu,perl-sig,laxathom
> perl-Class-Inspector-1.23-1.fc10 (build/make) corsepiu,perl-sig,laxathom
> perl-Data-ICal-0.13-3.fc10 (build/make) corsepiu,perl-sig
> perl-Data-Stag-0.11-1.fc10 (build/make) alexlan,perl-sig
> perl-File-Find-Rule-Perl-1.04-2.fc10 (build/make) corsepiu,perl-sig
> perl-Gnome2-GConf-1.044-4.fc10 (build/make) cweyl,perl-sig
> perl-Gtk2-Notify-0.04-3.fc9 (build/make) cweyl,perl-sig
> perl-HTTP-Proxy-0.20-2.fc9 (build/make) spot,perl-sig
> perl-IPC-Shareable-0.60-6.fc9 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
> perl-JSON-Any-1.16-3.fc9 (build/make) cweyl,perl-sig
> perl-Log-Trivial-0.31-2.fc9 (build/make) orion
> perl-Module-CPANTS-Analyse-0.82-2.fc10 (build/make) berrange
> perl-Moose-0.62-1.fc11 (build/make) cweyl,perl-sig
> perl-MooseX-Params-Validate-0.05-1.fc10 (build/make) cweyl,perl-sig
> perl-Net-SSLeay-1.35-1.fc10 (build/make) pghmcfc,perl-sig,jpo,kasal
> perl-PDL-2.4.4-1.fc11 (build/make) kasal,orion,rnorwood,mmaslano
> perl-POE-Component-SNMP-1.07-3.fc9 (build/make) cweyl,perl-sig
> perl-Pugs-Compiler-Rule-0.28-2.fc9 (build/make) steve,perl-sig
> perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig
> perl-Regexp-Assemble-0.34-1.fc11 (build/make) iarnell,perl-sig
> perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig
> perl-Sys-Virt-0.1.2-3.fc9 (build/make) steve,perl-sig,berrange
> perl-Test-Inline-2.208-3.fc10 (build/make) corsepiu,perl-sig,laxathom
> perl-Test-WWW-Mechanize-Catalyst-0.42-1.fc10 (build/make) cweyl,perl-sig
> perl-Test-Warn-0.10-3.fc9 (build/make) spot,perl-sig
> perl-WWW-Mechanize-1.34-1.fc10 (build/make) cweyl,perl-sig
> perl-XML-LibXSLT-1.66-2.fc10 (build/make) kasal,perl-sig,shishz
> perl-XML-Smart-1.6.9-1.fc10 (build/make) lkundrak
> perl-bioperl-1.5.2_102-13.fc10 (build/make) alexlan,perl-sig
> perl-bioperl-run-1.5.2_100-3.fc9 (build/make) alexlan,perl-sig


At least one of these (Regexp::Assemble) is failing because of
problems with perl-Test-Warn following a recent update of
perl-Sub-Uplevel.  Upstream Test::Warn has a fix - needs to be updated
to 0.11.

https://bugzilla.redhat.com/show_bug.cgi?id=477298


-- 
Iain.



From dimi at lattica.com  Sat Dec 20 06:10:24 2008
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 20 Dec 2008 01:10:24 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229707929.23410.63.camel@dimi.lattica.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
Message-ID: <1229753424.23410.153.camel@dimi.lattica.com>


On Fri, 2008-12-19 at 16:40 -0900, Jeff Spaleta wrote:
> But I said I'd play. So let's play.  What are people doing wrong in
> how they are communicating their disagreement?

I said I didn't intend to fight this, but given that you want to
play, I'll play. 

I will not discuss things at an abstract level, that's not useful.
I'll try to refocus the discussion around the issue at hand.

But first, let me state some assumptions:
 1. Most people that have used a compute on planet Earth are
    not familiar with a "spatial" mode, as most people use Windows
    and it uses the "browser" mode for 20+ years.
    (BTW the Windows market share seems to be around 90%)
 2. We have the "Principle of least astonishment" as a good
    rule of thumb in UI design:
    http://en.wikipedia.org/wiki/Principle_of_least_astonishment
 3. The spatial/browser mode is very much within the "look&feel"
    of a distro, and falls quire reasonably within the realm of
    things that can be changed by a distro.

If you put 1&2 together, it's pretty clear that we should change 
this behavior unless we have really good reason to do so.

The original change was shoved down people's throats quite
unceremoniously, without any number, voting, survey, etc, all
the time ignoring the current status quo. We were told to wait,
we would get used to it. We didn't. It follows that it's quite
reasonable to ask that we change back.

So what do we get for asking that we see this changed? 
  - snide remarks
  - we are ask to produce numbers nobody can produce
  - we are sent on wild goose chances "upstream" when this
    is a packages maintained by RH.

All of these responses are painfully frustrating, because everybody
involved knows that they are just excuses for not coming out and
saying:
   "This will not change because we don't want to. Don't search for
    rhyme or reason, it's just the way we want it."

I can live with such an answer. I know where we stand. 

But being asked (and made fun of in a condescending manner) to "prove"
either obvious things, or near impossible numbers like the exact
percentage of GNOME users who prefer A over B... Who does that? How many
of the changes are being held to that standard? This is as close to
a wild goose chase as you'll ever get. It's frustrating.

Is this the way to involve the community? I claim these are clear
cut example of Fedora failing to listen and engage the community
in a constructive manner. It's not the first time. 

But hey, these things happen, we can work around them. What's not cool
is the attitude that it's OK to diss the users. That just sucks the
fun out of being part of Fedora.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From tim.lauridsen at googlemail.com  Sat Dec 20 06:23:33 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sat, 20 Dec 2008 07:23:33 +0100
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <16de708d0812191143s788304e6o8bbb1e1a53b1ad53@mail.gmail.com>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>	<4943D18E.60107@BitWagon.com>	<20081215202939.GE23506@nostromo.devel.redhat.com>	<50baabb30812191125ga621fc5o426e0a46fa832564@mail.gmail.com>
	<16de708d0812191143s788304e6o8bbb1e1a53b1ad53@mail.gmail.com>
Message-ID: <494C8F65.4060102@googlemail.com>

Arthur Pemberton wrote:
> On Fri, Dec 19, 2008 at 1:25 PM, Chitlesh GOORAH
> <chitlesh.goorah at gmail.com> wrote:
>   
>> On Mon, Dec 15, 2008 at 9:29 PM, Bill Nottingham < email hidden from
>> spam > wrote:
>>     
>>> Also, 'Electronics' seems vague ... 'Electronic Design'? 'EDA'?
>>>       
>> I haven't yet updated the somps.xml since I'm waiting for more feedbacks.
>>
>> I prefer "EDA".
>> however "EDA" on kpackagekit will confuse people how are not familiar
>> with the abbreviation EDA.
>> Thereby Electronic Design can be easily understood by both
>> non-electronic friendly and electronic amateurs.
>>
>> Any other suggestions ?
>>     
>
> Just that I wouldn't have guesses Electronics anything from the abbreviation EDA
>
> Do individual comps groups have descriptions by the way?
>
>   
Yes, comps groups has translated descriptions

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/d02e9ff1/attachment.htm>

From rjones at redhat.com  Sat Dec 20 08:25:52 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 20 Dec 2008 08:25:52 +0000
Subject: Automatic BuildRequires
In-Reply-To: <870180fe0812191442j74ed15c3hffbabde35c967bf3@mail.gmail.com>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
	<20081109204946.GA12715@auslistsprd01.us.dell.com>
	<20081109210146.GA16833@auslistsprd01.us.dell.com>
	<494A44DD.2050701@redhat.com>
	<870180fe0812191442j74ed15c3hffbabde35c967bf3@mail.gmail.com>
Message-ID: <20081220082552.GA21475@amd.home.annexia.org>

On Fri, Dec 19, 2008 at 03:42:35PM -0700, Jerry James wrote:
> On Thu, Dec 18, 2008 at 5:41 AM, Karsten Hopp <karsten at redhat.com> wrote:
> > I've used auto-br-rpmbuild with my latest full-install mass rebuild and
> > grepped the
> > BuildRequires from the logs.
> > They are available at
> >        http://karsten.fedorapeople.org/buildrequires/
> 
> I'm not sure what to do with this information.  For example, take a
> look at one of my packages: automaton.  It's a Java package.  Yet your
> logs show gstreamer-devel as a BuildRequires.  How did that get in
> there?  And what's going on with the 3 different versions of glibc, on
> 2 arches?
> 
> I've checked a couple of my other packages and had a similar reaction.
>  There are BuildRequires listed that make no sense to me.  Can you
> give more detail on how these lists were generated?  Thanks,

Possibly a bug, possibly because something in the configure script of
the application touches a file in gstreamer-devel.  Take a look at:

http://et.redhat.com/~rjones/auto-buildrequires/

There'll be a fedorahosted project of this soon.

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  Sat Dec 20 08:28:58 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 20 Dec 2008 08:28:58 +0000
Subject: Orphan freetennis (was: Re: Fedora rawhide rebuild in mock status
	2008-12-17 x86_64)
In-Reply-To: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <20081220082858.GB21475@amd.home.annexia.org>

On Fri, Dec 19, 2008 at 09:00:55PM -0600, Matt Domsch wrote:
> freetennis-0.4.8-14.fc10 (build/make) rjones

I would like to orphan freetennis.  It currently FTBFS and upstream is
dead.  If someone wants to take it and make it work, then please take
it, otherwise I'll probably just drop it from Fedora entirely.

https://admin.fedoraproject.org/pkgdb/packages/name/freetennis

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From jspaleta at gmail.com  Sat Dec 20 09:00:26 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 20 Dec 2008 00:00:26 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229753424.23410.153.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
Message-ID: <604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>

On Fri, Dec 19, 2008 at 9:10 PM, Dimi Paun <dimi at lattica.com> wrote:
> So what do we get for asking that we see this changed?
>  - snide remarks

In this thread..ive seen snide comments from multiple parties on both
sides.  I've seen a round in the cycle of existing hostilities.  There
are no saints here, we are all sinners.  Keeping score of the assumed
intent of the multitude of emotional comments on one side or the other
is futile and serves no useful purpose. If you are keeping score of
snide comments, then you've already given up on a constructive
discussion.  You have to be able to give everyone the benefit of the
doubt as to intent. The medium of email is excruciatingly poor at
communicating irrational emotive discourse. The subtle nuances of body
language, or vocal and facial ques which regulate the flow of face to
face conversations are not there to help us read intent with any
accuracy whatsoever.

>  - we are ask to produce numbers nobody can produce

In this thread, I have not seen the decision makers ask that numbers
be produced. I see numbers being produced by people to sustain their
own arguments and getting upset that other are critical of the
numbers.  The numbers are a false premise, they shouldn't be debated,
they should be summarily ignored. To debate them gives credibility to
the idea that accurate numbers are going to impact the design, and no
one has come forward and promised that in this thread..

>  - we are sent on wild goose chances "upstream" when this
>    is a packages maintained by RH.

Yes this has happened in this thread. I have in fact done this myself
before and I still stand by it.  If this change is going to be made is
going to be made as part of an upstream discussion around the design
goals of the default GNOME experience, a discussion broader in scope
than this one change.

I think the proponents of change do a disservice to their chosen cause
in choosing the argumentation they have so far.  Trying to coerce a
change by hammering away with the blunt instruments of populism.  It's
not going to work. Coercion is the wrong method and populist arguments
are the wrong tool.  You have to persuade the decision-makers, and to
do that you have to understand how they prioritize and think.   The
art of persuasion is a subtle science. It's brain surgery, not to be
performed with the hammer or rhetoric or with the pitchforks and
torches  of populist appeal.   You have to crawl inside the heads of
the people whose minds you are looking to change, and think like them.

> But hey, these things happen, we can work around them. What's not cool
> is the attitude that it's OK to diss the users. That just sucks the
> fun out of being part of Fedora.

I think you are reading way to much into the responses of a a very
long and very heated discussion which this thread is but one chapter.
The exact same sort of thing could be said about it being uncool to
diss developers.  There have certainty been posts in this thread which
could be read as dissing developers.  I think we can all agree that
its uncool to diss people generally.  I'll go further and say that
most people are going to screw up and when things get heated are going
to choose words poorly and end up writing something that is laced with
too much emotion and will be interpreted as a personal slight or
attack.  The real trick is figuring out how to make it possible to
keep those mistakes from invoking another round of emotional responses
in a self-perpetuating cycle of over-reaction.

-jef



From bkoz at redhat.com  Sat Dec 20 09:37:03 2008
From: bkoz at redhat.com (Benjamin Kosnik)
Date: Sat, 20 Dec 2008 01:37:03 -0800
Subject: boost rebuild status
In-Reply-To: <494C5673.6040101@redhat.com>
References: <20081218011435.03690d24@balbo.artheist.org>
	<20081218204249.33a3adeb@balbo.artheist.org>
	<494C5673.6040101@redhat.com>
Message-ID: <20081220013703.4988c1bf@balbo.artheist.org>


> This one can be worked around by compiling with 
> -DBOOST_PYTHON_NO_PY_SIGNATURES, but I have no idea what that will 
> break.  I'll try to come up with a more definitive solution tomorrow.

Beat you to it.

;)

-benjamin



From bkoz at redhat.com  Sat Dec 20 09:40:12 2008
From: bkoz at redhat.com (Benjamin Kosnik)
Date: Sat, 20 Dec 2008 01:40:12 -0800
Subject: boost rebuild status
In-Reply-To: <20081218204249.33a3adeb@balbo.artheist.org>
References: <20081218011435.03690d24@balbo.artheist.org>
	<20081218204249.33a3adeb@balbo.artheist.org>
Message-ID: <20081220014012.6711efeb@balbo.artheist.org>


Only four left, none of the remaining look like boost issues per se.

aqsis-0:1.4.1-4.fc10.x86_64
aqsis-core-0:1.4.1-4.fc10.x86_64
  bump Release, rebuilt Nicolas Chauvet (kwizart)

asc-0:2.1.0.0-2.fc10.x86_64
  bump Release, rebuilt by Petr Machata

barry-0:0.14-4.fc10.x86_64
  bump Release, rebuilt by Petr Machata

bmpx-0:0.40.14-7.fc10.x86_64
  bump Release, rebuilt by Petr Machata

chess-0:1.0-20.fc10.x86_64
  bump Release, rebuilt by Petr Machata

conexus-0:0.5.3-4.fc9.i386
conexus-0:0.5.3-4.fc9.x86_64
  bump Release, rebuilt by Petr Machata

deluge-0:1.0.5-1.fc10.x86_64
  bump Release, rebuilt by Petr Machata

fuse-encfs-0:1.5-1.fc10.x86_64
  bump Release, rebuilt by Petr Machata

glob2-0:0.9.3-1.fc10.x86_64
  bump Release, rebuilt by Petr Machata

gnash-0:0.8.4-3.fc10.x86_64
gnash-cygnal-0:0.8.4-3.fc10.x86_64
  bump Release, rebuilt by Kevin Kofler

HippoDraw-python-0:1.21.1-4.fc9.x86_64
  bump Release, rebuilt

hugin-0:0.7.0-1.fc10.x86_64
hugin-base-0:0.7.0-1.fc10.i386
  bump Release, rebuilt by Petr Machata

k3d-0:0.6.7.0-7.fc10.i386
  bump Release, rebuilt by Petr Machata

kdeedu-0:4.1.2-2.fc10.x86_64
  bump Release, rebuilt by Kevin Kofler

linkage-0:0.2.0-3.fc10.i386
  bump Release, rebuilt

mapnik-0:0.5.2-0.7.svn738.fc10.i386
mapnik-python-0:0.5.2-0.7.svn738.fc10.x86_64
mapnik-utils-0:0.5.2-0.7.svn738.fc10.x86_64
  bump Release, build fails:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1010094

  known blocker bug in scons, Red Hat BZ:475903
  https://bugzilla.redhat.com/show_bug.cgi?id=475903

Miro-0:1.2.7-2.fc10.x86_64
  bump Release, rebuilt by Alex Lancaster (alexlan)

mkvtoolnix-0:2.4.0-1.fc10.x86_64
  bump Release, rebuilt.

openvrml-0:0.17.10-1.0.fc10.i386
openvrml-xembed-0:0.17.10-1.0.fc10.x86_64
  bump Release, rebuilt.

pingus-0:0.7.2-3.fc9.x86_64
  bump Release, rebuilt.

player-0:2.1.1-5.fc10.x86_64
player-examples-0:2.1.1-5.fc10.x86_64
  bump Release, rebuild fails:
  
  known compile error
  /usr/include/linux/serial.h:164: error: '__u32' does not name a type
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1007777
  
  Tim Niemueller on it.

pyexiv2-0:0.1.2-4.fc10.x86_64
  rebuild fails:
  http://koji.fedoraproject.org/koji/getfile?taskID=1007372

  boost_python vs. interface changes? 
  g++ -o build/libpyexiv2.os -c -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC
-I/usr/include/python2.6 src/libpyexiv2.cpp src/libpyexiv2.cpp: In
member function 'boost::python::tuple
LibPyExiv2::Image::getThumbnailData()': src/libpyexiv2.cpp:312: error:
'Exiv2::Thumbnail' has not been declared src/libpyexiv2.cpp:312: error:
expected `;' before 'thumbnail' src/libpyexiv2.cpp:313: error:
'thumbnail' was not declared in this scope

  looks like some people are working on this.

python-tag-0:0.94.1-1.fc10.x86_64
  bump Release, rebuilt.

qmf-0:0.3.705289-1.fc10.x86_64
qpidc-0:0.3.705289-1.fc10.i386
qpidc-perftest-0:0.3.705289-1.fc10.x86_64
qpidc-rdma-0:0.3.705289-1.fc10.i386
qpidd-0:0.3.722557-1.fc10.x86_64
qpidd-cluster-0:0.3.705289-1.fc10.x86_64
qpidd-rdma-0:0.3.705289-1.fc10.x86_64
  bump Release, rebuild fails heartbreakingly close to end.

  libtool/autotools issue.
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1008760

  libtool: install: invalid libtool wrapper script `perftest'
  error: Bad exit status from /var/tmp/rpm-tmp.dOuDVz (%install)
  
  Mail in to maintainer, IRC probe but they seem busy.

  Preliminary build hacking to deal with libtool issues:
  %build
  # Remove m4/extensions.m4 for autoconf > 1.60
  rm m4/extensions.m4
  sed -i 's/gl_CLOCK_TIME/CLOCK_TIME/g' configure.ac
  # Regenerate makefiles to smooth libtool versioning issues.
  autoreconf -i -f
  CXXFLAGS="%{optflags} -DNDEBUG -O3" \

  shows more config/build issues. Punting.

QuantLib-test-0:0.9.0-5.fc10.x86_64
  bump Release, rebuilt
  Note no boost libs in Requires for binary files.

rb_libtorrent-0:0.13.1-3.fc10.x86_64
rb_libtorrent-python-0:0.13.1-3.fc10.x86_64
  bump Release, rebuilt by Petr Machata

rcsslogplayer-13.1.0-2.fc11.src.rpm
  bump Release, rebuilt

rcssbase-0:12.1.2-1.fc10.x86_64
rcssserver-0:12.1.4-1.fc10.i386
  bump Release, rebuilt

rcssserver3d-0:0.6-5.fc10.i386
  bump Release, rebuilt by Petr Machata

referencer-0:1.1.4-1.fc10.x86_64
  bump Release, rebuilt

smc-0:1.5-3.fc10.x86_64
  no devel package?

source-highlight-0:2.10-1.fc10.x86_64
  bump Release, rebuilt

twinkle-0:1.3.2-1.fc10.x86_64
  bump Release, rebuilt

vegastrike-0:0.5.0-5.fc10.x86_64
  bump Release, rebuilt?

wesnoth-0:1.4.5-1.fc10.x86_64
wesnoth-server-0:1.4.5-1.fc10.x86_64
wesnoth-tools-0:1.4.5-1.fc10.x86_64
  bump Release, rebuilt

wp_tray-0:0.5.3-8.fc10.x86_64
  bump Release, rebuilt

xmms2-0:0.5-2.fc10.x86_64
  bump Release, rebuilt



From alexl at users.sourceforge.net  Sat Dec 20 09:51:04 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 20 Dec 2008 02:51:04 -0700
Subject: boost rebuild status
In-Reply-To: <1229708079.24419.640.camel@lenovo.local.net> (Adam Williamson's
	message of "Fri\, 19 Dec 2008 09\:34\:39 -0800")
References: <20081218011435.03690d24@balbo.artheist.org>
	<y68wqcb9sr.fsf@allele2.eebweb.arizona.edu>
	<1229708079.24419.640.camel@lenovo.local.net>
Message-ID: <12prjn9nuf.fsf@allele2.eebweb.arizona.edu>

>>>>> "AW" == Adam Williamson  writes:

[...]

AW> Note that Miro only depends on Boost because it has an internal
AW> copy of rasterbar libtorrent.

Yep, I know about this.  

AW> This means:

AW> a) there is obviously a patch to make rasterbar libtorrent build
AW> and work with Boost 1.37.0, since you made Miro work.

AW> b) Miro should stop using its own copy of libtorrent and use the
AW> system one.

Indeed, I was the person pestering upstream to fix this, which they
have done so in SVN.

AW> I knocked up a patch to make Miro 1.28 use system libtorrent (they
AW> added this to upstream SVN post-1.28, but it required a bit of
AW> re-diffing).  You can find it here:

Rather than adding that patch, I'm probably going to wait until Miro
2.0 is released (which should be very soon) where it will be
unnecessary.  Currently Miro builds and works, and unless there is yet
another boost soname bump, it should continue to build.

Alex



From dan at danny.cz  Sat Dec 20 10:00:16 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Sat, 20 Dec 2008 11:00:16 +0100
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <1229767216.3616.17.camel@eagle.danny.cz>

> wxGTK-2.8.9-3.fc11 (build/make) mattdm,sharkcz

probably broken rawhide used as buildroot, it couldn't find gstreamer
via pkg-config

it builds fine now in mock with recent rawhide


		Dan




From a.badger at gmail.com  Sat Dec 20 10:08:57 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 20 Dec 2008 02:08:57 -0800
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <20081220004829.GB10679@free.fr>
References: <20081219192058.GA15838@bludgeon.org>	<20081219193853.GC2283@free.fr>	<20081219194825.GA16284@bludgeon.org>
	<494BFECE.4050003@gmail.com> <20081220004829.GB10679@free.fr>
Message-ID: <494CC439.4070503@gmail.com>

Patrice Dumas wrote:
> On Fri, Dec 19, 2008 at 12:06:38PM -0800, Toshio Kuratomi wrote:
>> There isn't but there should be.  Rahul started to put together a policy
>> for that that would have modified the NonResponsiveMaintainers policy.
>> It was not approved by FESCo but I don't remember what the sticking
>> points were.
> 
> I found the FESCo meetng result:
> 
> === Collective Maintenance Proposal ===
> * FESCo rejected the collective maintenance proposal (1) for now.  They
> had some concerns about the extra bureaucracy, and they wanted to see
> how the new maintainer containment policy (2) and opening acls (3) to
> packagers helps first, since these are to be implemented in the very
> near future.  If there is still a problem, this proposal could be
> revisited.
> 
> 1. http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance
> 2. http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment
> 3. http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening
> 
> 
> The logs are at:
> http://bpepple.fedorapeople.org/fesco/FESCo-2008-07-30.html
> 
> but not at lot more was said than what is in the summary.

Okay, so it sounds like FESCo wants to see whether:
1) provenpackagers feel comfortable just stepping up and making changes
after they've done due diligence trying to contact the maintainer.

2) Whether there will be any hurt feelings on the part of maintainers
when provenpackagers make changes to their packages.

Since the OP said they have provenpackager and has tried to contact
thias, I guess it's time to see how these two work out.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/9cbe3429/attachment.sig>

From fedora at leemhuis.info  Sat Dec 20 10:32:56 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 20 Dec 2008 11:32:56 +0100
Subject: [Fedora Update] [stable] rcsslogplayer-13.1.0-1.fc8
In-Reply-To: <1229716138.5263.7.camel@localhost.localdomain>
References: <20081219134916.970A020876A@bastion.fedora.phx.redhat.com>	<1229710262.5263.5.camel@localhost.localdomain>	<494BF0A7.8030302@grad.com>
	<1229716138.5263.7.camel@localhost.localdomain>
Message-ID: <494CC9D8.302@leemhuis.info>

On 19.12.2008 20:48, Jesse Keating wrote:
> On Fri, 2008-12-19 at 22:36 +0330, Hedayat Vatnakhah wrote:
>> Sine these updates do not come with many changes, and these packages
>> were stable enough during latest releases, I think these packages will not
>> show any unexpected behavior.
>> But anyway, if you think that it's not appropriate, I will submit them 
>> for testing.
> It's up to you to use your best judgment, but you should share that
> judgment with your users in the form of the bodhi notes, so that they
> can understand why you made that decision.

Jesse, I appreciate your efforts. But OTOH I wonder: Is it time for a 
"Best practices for package updates" document in the wiki? It for 
example could have a sections like "Please only update packages in 
releases that are EOL soon if there is a good reason to", "when filing 
update requests in bodhi please state some good reasons why you are 
shipping the new version as regular update" and similar hints.

I guess above could even be done without FESCo involvement. Or is there 
such a document already somewhere and I just missed it?

Further: Maybe some real guidelines for package updating are needed. 
Right now some maintainers take care of their packages in a debian-like 
way, while others seems to do the follow the "always latest and greatest 
everywhere" concept. From a uses standpoint that just confusing imho. A 
"this is how it normally should be done" could help.

And yes, of course there always will be reasons to do things different 
then the guidelines say now and then. The decision imho still should be 
left to the "best judgment" by the package maintainer. But guiding them 
a bit might be a good idea.

CU
knurd



From j.w.r.degoede at hhs.nl  Sat Dec 20 10:36:02 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 20 Dec 2008 11:36:02 +0100
Subject: Orphan freetennis
In-Reply-To: <20081220082858.GB21475@amd.home.annexia.org>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
	<20081220082858.GB21475@amd.home.annexia.org>
Message-ID: <494CCA92.5080508@hhs.nl>



Richard W.M. Jones wrote:
> On Fri, Dec 19, 2008 at 09:00:55PM -0600, Matt Domsch wrote:
>> freetennis-0.4.8-14.fc10 (build/make) rjones
> 
> I would like to orphan freetennis.  It currently FTBFS and upstream is
> dead.  If someone wants to take it and make it work, then please take
> it, otherwise I'll probably just drop it from Fedora entirely.
> 
> https://admin.fedoraproject.org/pkgdb/packages/name/freetennis
> 

I'll take it, let me know when you've released it. (I've already fixed it so 
that it builds again).

Regards,

Hans



From mschwendt at gmail.com  Sat Dec 20 10:38:46 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 20 Dec 2008 11:38:46 +0100
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <494CC439.4070503@gmail.com>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
	<20081219194825.GA16284@bludgeon.org> <494BFECE.4050003@gmail.com>
	<20081220004829.GB10679@free.fr> <494CC439.4070503@gmail.com>
Message-ID: <20081220113846.08a012a5.mschwendt@gmail.com>

On Sat, 20 Dec 2008 02:08:57 -0800, Toshio wrote:

> Okay, so it sounds like FESCo wants to see whether:
> 1) provenpackagers feel comfortable just stepping up and making changes
> after they've done due diligence trying to contact the maintainer.
> 
> 2) Whether there will be any hurt feelings on the part of maintainers
> when provenpackagers make changes to their packages.
> 
> Since the OP said they have provenpackager and has tried to contact
> thias, I guess it's time to see how these two work out.

2) -> depends on what changes someone wants to apply.

It ought to start with actual bug-fixes (in reply to bz tickets!) and
security-fixes. Not version upgrades, because upstream has released just
another minor release including "rewrites from scratch", feature
enhancements, "minor fixes" and similar stuff that breaks quite often.
Not major spec formatting changes or "cleanup" either.

Package maintainers do need to set up mail filters for the cvs commit
diffs anyway. It wouldn't surprise me if in several cases they would
reply quickly after seeing the commits.


What's the status update on bodhi? Can provenpackagers submit
updates for packages they can commit to and build? Or do they need
to be in the pkg's devel cancommit acl?



From mschwendt at gmail.com  Sat Dec 20 10:43:04 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 20 Dec 2008 11:43:04 +0100
Subject: pkgconfig dep problems in rawhide 20081219
In-Reply-To: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
References: <20081219104838.D5DC41F81D6@releng2.fedora.phx.redhat.com>
Message-ID: <20081220114304.65ae84ed.mschwendt@gmail.com>

Non-devel packages with problematic pkgconfig auto-dependencies
on -devel packages:

  avahi-ui-sharp
  deskbar-applet
  gstreamer-python
  pygoocanvas
  tomboy

bz 477308 to 477312



From rawhide at fedoraproject.org  Sat Dec 20 10:45:20 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 20 Dec 2008 10:45:20 +0000 (UTC)
Subject: rawhide report: 20081220 changes
Message-ID: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>

Compose started at Sat Dec 20 06:01:10 UTC 2008

Updated Packages:

HippoDraw-1.21.1-7.fc11
-----------------------
* Thu Dec 18 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 1.21.1-7
- Rebuild for boost-1.37.0.


WebKit-1.0.0-0.16.svn39370.fc11
-------------------------------
* Sat Nov 29 17:00:00 2008 Peter Gordon <peter at thecodergeek.com> 1.0.0-0.16.svn39370
- Update to new upstream snapshot (SVN 39370)
- Fix ownership of %_docdir in the doc subpackage. 
- Resolves: bug 473619 (WebKit : Unowned directories).
- Adds webinspector data to the gtk-devel subpackage.
- Add patch from upstream bug 22205 to fix compilation errors with Bison 2.4:
  + bison24.patch
- Add build-time conditional for WML support.


abe-1.1-9.fc11
--------------
* Fri Dec 19 17:00:00 2008 Wart <wart at kobold.org> - 1.1-9
- Add coreutils requirement for rpm post scripts

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.1-8
- Fix Patch0:/%patch mismatch.


aqsis-1.4.1-6.fc11
------------------
* Fri Dec 19 17:00:00 2008 kwizart < kwizart at gmail.com > - 1.4.1-6
- Improve -core summary - #477134


authconfig-5.4.6-1.fc11
-----------------------
* Fri Dec 19 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 5.4.6-1
- fix typo in the fingerprint reader patch (#477080)


blam-1.8.5-5.fc10
-----------------
* Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 1.8.5-5
- Rebuild against newer gecko


bodhi-0.5.14-1.fc11
-------------------
* Fri Dec 19 17:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.14-1
- Latest upstream release, containing some masher improvements.


boost-1.37.0-2.fc11
-------------------
* Fri Dec 19 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 1.37.0-2
- Apply a function_template patch from Caolan McNamara
- Resolves: #477131


cairo-dock-2.0.0-0.3.svn1444_trunk.fc11
---------------------------------------
* Sat Dec 20 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1444
- Support xfce plugin again because dependency on hal-devel
  is resoved

* Sat Dec 20 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1444


clojure-20081217-1.fc11
-----------------------
* Thu Dec 18 17:00:00 2008 Colin Walters <walters at verbum.org> - 20081217-1
- New upstream


cobbler-1.4.0-2.fc11
--------------------
* Fri Dec 19 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.4.0-2
- Upstream changes (see CHANGELOG)

* Wed Dec 10 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.3.4-1
- Updated test release (see CHANGELOG)

- Upstream changes (see CHANGELOG)
- Added specfile changes for python 2.6

* Mon Dec  8 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.3.3-1
- Upstream changes (see CHANGELOG)
- Added specfile changes for python 2.6


dbus-1.2.4.2permissive-1.fc11
-----------------------------
* Thu Dec 18 17:00:00 2008 Colin Walters <walters at redhat.com> - 1:1.2.4.2.permissive-1
- New upstream


digikam-0.10.0-0.9.beta7.fc11
-----------------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.10.0-0.9.beta7
- digikam-0.10.0-beta7


eclipse-3.4.1-12.fc11
---------------------
* Fri Dec 19 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 1:3.4.1-12
- Fixed GCJ AOT compilation (Gary Benson).

* Mon Dec 15 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 1:3.4.1-11
- Update pdebuild and package-build patch to include -z option.
- Make ecj default to 1.5 (rh#354721).
- Add GCJ AOT bits for ecj (rh#473674).

* Fri Dec  5 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 1:3.4.1-10
- Remove MaxPermSize from sysproperty lists in library.xml as it was causing the
  JVM to not start.


eclipse-cdt-5.0.1-1.fc10
------------------------
* Fri Nov 28 17:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 5.0.1-1
- Rebase to CDT 5.0.1.
- Fix bug in autotools project type detection.
- Resolve #472731

* Mon Nov 17 17:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 5.0.0-12
- Fix typo in autotools and libhover sources tarballs.
- Remove redundant patches which are already in new tarballs.

* Thu Nov  6 17:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 5.0.0-11
- Fix managed configurations dialog problem.
- Update libhover and autotools source tarballs to 20081106 snapshot.


epiphany-extensions-2.24.0-3.fc10
---------------------------------
* Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.24.0-3
- Rebuild against newer gecko


firefox-3.0.5-1.fc10
--------------------
* Tue Dec 16 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 3.0.5-1
- Update to 3.0.5

* Thu Nov 13 17:00:00 2008 Jan Horak <jhorak at redhat.com> 3.0.4-2
- Removed firefox-2.0-getstartpage.patch patch 
- Start page is set by different way


fontpackages-1.12-1.fc11
------------------------
* Fri Dec 19 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
- 1.12-1
??? Add another macro to allow building fontconfig without cycling


freedroidrpg-0.11.1-2.fc11
--------------------------
* Fri Dec 19 17:00:00 2008 Wart <wart at kobold.org> - 0.11.1-2
- Add coreutils requirement for rpm post scripts (BZ #476162)


gambit-c-4.3.2-1.fc11
---------------------
* Fri Dec 19 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 4.3.2-1
- Update to 4.3.2


gecko-sharp2-0.13-3.fc10
------------------------
* Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.13-3
- Rebuild against newer gecko


gnome-applets-2.25.1-8.fc11
---------------------------
* Fri Dec 19 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.1-5
- Fix the build

* Fri Dec 19 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1:2.25.1-8
- Fix battstat nullification

* Fri Dec 19 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1:2.25.1-7
- Remove the mixer applet

* Thu Dec 18 17:00:00 2008 Jon McCann <jmccann at redhat.com> - 1:2.25.1-5
- Rebuild for gnome-desktop


gnome-launch-box-0.4-13.fc11
----------------------------
* Fri Dec 19 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.4-13
- Rebuild for new gnome-desktop


gnome-power-manager-2.25.1-2.fc11
---------------------------------
* Fri Dec 19 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-2
- Fix the spec file

* Thu Dec 18 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 2.25.1-1
- Update to 2.25.1
- Depend on DeviceKit-power
- Build with PolicyKit support enabled
- Drop gstreamer and pick up libcanberra deps

* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2-3
- Better URL


gnome-python2-2.22.3-3.fc11
---------------------------
* Fri Dec 19 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.22.3-3.fc11
- Add libgnome[ui] requirements to gnome subpackage.


gnome-web-photo-0.3-13.fc10
---------------------------
* Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.3-13
- Rebuild against newer gecko


gnuradio-3.1.3-2.fc11
---------------------
* Fri Dec 19 17:00:00 2008 Marek Mahut <mmahut at fedoraproject.org> - 3.1.3-2
- Upstream release 3.1.3
- Comedi support
- RHBZ#473928 Unowned directories


gridengine-6.2u1-1.fc11
-----------------------
* Thu Dec 18 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 6.2u1-1
- Update to 6.2u1


hal-0.5.12-18.20081219git.fc11
------------------------------
* Fri Dec 19 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-17.20081219git
- Don't run autoreconf in the build-phase, it breaks libtool

* Fri Dec 19 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-16.20081219git
- Update to git snapshot 20081219git

* Fri Dec 19 17:00:00 2008 Colin Walters <walters at verbum.org> - 0.5.12-18.20081219git
- Update dbus permissions patch to include KillSwitch which NetworkManager needs

* Tue Dec  9 17:00:00 2008 Colin Walters <walters at verbum.org> - 0.5.12-15
- Add introspection allow

* Mon Dec  1 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-14
- Update to 0.5.12 release candidate 1.

* Mon Nov 24 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-13.20081027git
- For OLPC, set system.firmware.version to the main system firmware version,
  rather than the version of the embedded controller microcode.
  Thanks to Mitch Bradley for the pointer.


hal-info-20081219-1.fc11
------------------------
* Fri Dec 19 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 20081219-1
- Update to latest upstream release


ikiwiki-2.70-3.fc11
-------------------
* Tue Dec 16 17:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 2.70-3
- Patch for monotone plugin: Prevent broken pipe message.
- Cosmetic changes to satisfy rpmlint.


inksmoto-0.5.0-2.rc1.fc11
-------------------------

ipa-1.2.1-2.fc11
----------------
* Fri Dec 19 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 1.2.1-2
- Fix SELinux code

* Mon Dec 15 17:00:00 2008 Simo Sorce <ssorce at redhat.com> - 1.2.1-1
- Fix breakage caused by python-kerberos update to 1.1

* Fri Dec  5 17:00:00 2008 Simo Sorce <ssorce at redhat.com> - 1.2.1-0
- New upstream release 1.2.1

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.2.0-4
- Rebuild for Python 2.6


iwl4965-firmware-228.57.2.23-2
------------------------------
* Mon Dec 15 17:00:00 2008 kwizart < kwizart at gmail.com > - 228.57.2.23-2
- Drop dist tag until newer update.

* Mon Dec 15 17:00:00 2008 kwizart < kwizart at gmail.com > - 228.57.2.23-1
- Update v2 to 228.57.2.23 - Should fix #457154
- Reintroduce dist tag


jd-2.1.0-0.2.svn2580_trunk.fc11
-------------------------------
* Sat Dec 20 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2580

* Sat Dec 20 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2579
- Use oniguruma on F-9+ for regex


kernel-2.6.28-0.138.rc9.fc11
----------------------------
* Thu Dec 18 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
- Disable SND_HDA_BEEP by default

* Thu Dec 18 17:00:00 2008 Jeremy Katz <katzj at redhat.com>
- explicitly prereq /sbin/new-kernel-pkg as opposed to just mkinitrd

* Thu Dec 18 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc9

* Thu Dec 18 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc8-git6

* Thu Dec 18 17:00:00 2008 Dave Airlie <airlied at redhat.com>
- drm-next.patch/drm-modesetting-radeon.patch - rebase to upstream.
- config-generic: turn of KMS on radeon until we fixup userspace


koan-1.4.0-2.fc11
-----------------
* Fri Dec 19 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.4.0-2
- Upstream changes (see CHANGELOG)

* Wed Dec 10 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.3.4-1
- New test release

* Mon Dec  8 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.3.3-1
- Upstream changes (see CHANGELOG)
- specfile changes for python 2.6 support


libXext-1.0.99.1-1.fc11
-----------------------
* Fri Dec 19 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.0.99.1-1
- libXext 1.0.99.1


libdrm-2.4.3-0.1.fc11
---------------------
* Fri Dec 19 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.4.3-0.1
- libdrm: update to upstream master + add radeon patches from modesetting-gem


libhugetlbfs-2.1.1-1.fc11
-------------------------
* Fri Dec 19 17:00:00 2008 Eric Munson <ebmunson at us.ibm.com> 2.1.1-1
- Updating for libhugetlbfs-2.1.1 release

* Thu Dec 18 17:00:00 2008 Josh Boyer <jwboyer at gmail.com> 2.1-2
- Fix broken dependency caused by just dropping -test
  subpackage

* Thu Oct 16 18:00:00 2008 Eric Munson <ebmunson at us.ibm.com> 2.1-1
- Updating for libhuge-2.1 release
- Adding -devel and -utils subpackages for various utilities
  and devel files.


libpng10-1.0.42-1.fc11
----------------------
* Fri Dec 19 17:00:00 2008 Paul Howarth <paul at city-fan.org> 1.0.42-1
- update to 1.0.42 (various minor bugfixes and code cleanups)


libtranslate-0.99-16.fc11
-------------------------
* Fri Dec 19 17:00:00 2008 Dmitry Butskoy <Dmitry at Butskoy.name> - 0.99-16
- add fix-modules patch (#477077)


linkage-0.2.0-4.fc11
--------------------
* Thu Dec 18 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> 0.2.0-4
- Rebuild for boost-1.37.0.


mono-2.2-14.pre3.20081219svn121833.fc11
---------------------------------------
* Fri Dec 19 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-14.pre3.20081219svn121833
- Get PPC to build itself, will be disabled from the next build

* Fri Dec 19 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-13.pre3.20081219svn121833
- Lots more fixes
- New patch for ppc archs
- Re-enable ppc build


mozvoikko-0.9.5-5.fc10
----------------------
* Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.9.5-5
- Rebuild against newer gecko


mugshot-1.2.2-4.fc10
--------------------
* Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 1.2.2-4
- Rebuild against newer gecko


nautilus-python-0.5.1-3.fc11
----------------------------
* Fri Dec 19 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.5.1-3
- Patch to fix build (thanks to Nicholas Wourms)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.1-2
- Rebuild for Python 2.6


nautilus-search-tool-0.2.2-8.fc11
---------------------------------
* Fri Dec 19 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 0.2.2-8
- Try harder not to link against eel


netpbm-10.35.57-2.fc11
----------------------
* Fri Dec 19 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 10.35.57-2
- fix segfault in pamtosvg caused by not reverting "sentinel value" (#476989)


nrpe-2.12-3.fc11
----------------
* Fri Dec 19 17:00:00 2008 Mike McGrath <mmcgrath at redhat.com> - 2.12-3
- Added Provides: nagios-nrpe

* Fri Dec 19 17:00:00 2008 Mike McGrath <mmcgrath at redhat.com> - 2.12-2
- Upstreamreleased new version


ochusha-0.5.99.71-0.4.cvs20081220T1425.fc11
-------------------------------------------
* Sat Dec 20 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


opencv-1.0.0-11.fc11
--------------------
* Fri Dec 19 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1.0.0-11
- Adopt latest python spec rules.
- Rebuild for Python 2.6 once again.

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.0.0-10
- Rebuild for Python 2.6

* Thu May 22 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.0-9
- fix license tag


openvrml-0.17.10-2.0.fc11
-------------------------
* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 0.17.10-2.0
- Rebuild for boost-1.37.0.


pcmanx-gtk2-0.3.8-4.fc10
------------------------
* Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.3.8-4
- Rebuild against newer gecko


perl-Data-TreeDumper-Renderer-GTK-0.02-4.fc11
---------------------------------------------
* Fri Dec 19 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.02-4
- drop a require on Gtk2::TreeView -- not "provided" by perl-Gtk2 (bug?)


pidgin-libnotify-0.14-1.fc11
----------------------------
* Sat Dec 20 17:00:00 2008 Erik van Pienbroek <erik-fedora at vanpienbroek.nl> - 0.14-1
- Update to version 0.14 (BZ #477267)
- Add BR: intltool


rb_libtorrent-0.13.1-7.fc11
---------------------------
* Fri Dec 19 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.13.1-7
- Rebuild for boost-1.37.0.

* Wed Dec 17 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 0.13.1-6
- Rebuild for boost-1.37.0.


rcssserver3d-0.6-6.fc11
-----------------------
* Fri Dec 19 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.6-6
- Rebuild for boost-1.37.0.
- Add patch to convert make_shared(X) to X.lock()


sendmail-8.14.3-3.fc11
----------------------
* Fri Dec 19 17:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> 8.14.3-3
- run newaliases only when necessary


squid-3.0.STABLE10-3.fc11
-------------------------
* Fri Dec 19 17:00:00 2008 Henrik Nordstrom <henrik at henriknordstrom.net> - 7:3.0.STABLE10-3
- actually include the upstream bugfixes in the build

* Fri Dec 19 17:00:00 2008 Henrik Nordstrom <henrik at henriknordstrom.net> - 7:3.0.STABLE10-2
- upstream bugfixes for cache corruption and access.log response size errors


sylpheed-2.6.0-1.fc11
---------------------
* Fri Dec 19 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.6.0-1
- update to 2.6.0 final (obsoletes SOCK_NONBLOCK patch)


system-config-netboot-0.1.45.3-3.fc11
-------------------------------------
* Fri Dec 19 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> - 0.1.45.3-3
- merge review: fix defattr (bz#226463)
- merge review: parallel make (bz#226463)
- merge review: do not use makeinstall macro (bz#226463)


system-config-printer-1.1.0-1.fc11
----------------------------------
* Fri Dec 19 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.1.0-1
- 1.1.0.

* Fri Dec 19 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.12-7
- Updated patch for 1.0.x changes:
  - Fixed stub scripts (bug #477107).

* Fri Dec 19 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.12-6
- Updated patch for 1.0.x changes:
  - Look harder for locale/page size issues in the troubleshooter
    (trac #118).
  - Troubleshooter speed improvement (trac #123).
  - Localization fixes for authentication dialog (trac #122).
  - Character encoding fixes (trac #124).
  - Handle model names with more than one set of digits (Ubuntu #251244).
  - Catch unable-to-connect error when trying to print a test page
    (Ubuntu #286943).
  - Prevent crash when copying PPD options (Ubuntu #285133).
  - Use get_cursor for the printer properties treeview (Ubuntu #282634).
  - Fix IPP browser when trying to connect to host:port (bug #476396).
  - Make sure we're authenticating as the correct user in authconn.
  - Prevent traceback when adding printer driven by HPLIP
    (bug #477107).
  - Better display of available local HP fax devices.


tailor-0.9.35-3.fc11
--------------------
* Fri Dec 19 17:00:00 2008 Dan Hor??k <dan[at]danny.cz> 0.9.35-3
- add patch for compatibility with mercurial 1.1 by Daniel P. Berrange (Resolves: #477148)


tasque-0.1.7-3.fc10
-------------------

transfig-3.2.5-5.fc11
---------------------
* Sat Dec 20 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1:3.2.5-5
- Add transfig-3.2.5-bitmap.patch, tweak permission on sources (BZ #209865).


uw-imap-2007e-1.fc11
--------------------
* Fri Dec 19 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 2007e-1
- imap-2007e


vte-0.19.4-3.fc11
-----------------
* Fri Dec 19 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> 0.19.4-3
- Add gtk2/pango/glib2 required versions
- Resolves #477213


xcb-util-0.3.2-2.fc11
---------------------
* Fri Dec 19 17:00:00 2008 Michal Nowak <mnowak at redhat.com> - 0.3.2-2
- hack the sed lines after %configure out and hack chrpath in
- make check is running again


xorg-x11-drv-ati-6.9.0-63.fc11
------------------------------
* Sat Dec 20 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-63
- rebase F11 patch to upstream master + modesetting bits


yelp-2.24.0-4.fc10
------------------
* Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.24.0-4
- Rebuild against newer gecko


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 71
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	avant-window-navigator-0.2.6-13.fc11.i386 requires libgnome-desktop-2.so.10
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	cobbler-1.4.0-2.fc11.noarch requires python(abi)=2.6
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	deskbar-applet-2.25.1-5.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	e16-0.16.8.14-1.fc10.i386 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	firefox-3.0.5-1.fc10.i386 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gnomedesktop-2.24.0-5.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mono-sharpcvslib-0.35-3.fc10.i386 requires mono(nunit.framework) = 0:2.2.0.0
	mozvoikko-0.9.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	perl-XML-LibXSLT-1.66-2.fc10.i386 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-examples-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-search-tool-0.6.6-4.fc11.i386 requires libgnome-desktop-2.so.10
	tsclient-2.0.1-9.fc11.i386 requires libgnome-desktop-2.so.10
	ufraw-0.14.1-3.fc11.i386 requires libexiv2.so.4
	ufraw-cinepaint-0.14.1-3.fc11.i386 requires libexiv2.so.4
	ufraw-gimp-0.14.1-3.fc11.i386 requires libexiv2.so.4
	vegastrike-0.5.0-6.fc11.i386 requires libboost_python.so.3
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts
	yelp-2.24.0-4.fc10.i386 requires gecko-libs >= 0:1.9.0.5



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	avant-window-navigator-0.2.6-13.fc11.i386 requires libgnome-desktop-2.so.10
	avant-window-navigator-0.2.6-13.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	banshee-1.4.1-1.fc11.x86_64 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	blam-1.8.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	cobbler-1.4.0-2.fc11.noarch requires python(abi)=2.6
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	deskbar-applet-2.25.1-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.x86_64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	firefox-3.0.5-1.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.x86_64 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mono-sharpcvslib-0.35-3.fc10.x86_64 requires mono(nunit.framework) = 0:2.2.0.0
	mozvoikko-0.9.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	perl-XML-LibXSLT-1.66-2.fc10.x86_64 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-2.1.1-5.fc10.x86_64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libboost_signals.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	tsclient-2.0.1-9.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	ufraw-0.14.1-3.fc11.x86_64 requires libexiv2.so.4()(64bit)
	ufraw-cinepaint-0.14.1-3.fc11.x86_64 requires libexiv2.so.4()(64bit)
	ufraw-gimp-0.14.1-3.fc11.x86_64 requires libexiv2.so.4()(64bit)
	vegastrike-0.5.0-6.fc11.x86_64 requires libboost_python.so.3()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts
	yelp-2.24.0-4.fc10.x86_64 requires gecko-libs >= 0:1.9.0.5



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	avant-window-navigator-0.2.6-13.fc11.ppc requires libgnome-desktop-2.so.10
	avant-window-navigator-0.2.6-13.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	deskbar-applet-2.25.1-5.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.ppc requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	firefox-3.0.5-1.fc10.ppc requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.ppc requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mozvoikko-0.9.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	perl-XML-LibXSLT-1.66-2.fc10.ppc requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc requires libboost_signals.so.3
	player-2.1.1-5.fc10.ppc requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libboost_thread-mt.so.3
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-examples-2.1.1-5.fc10.ppc requires libboost_signals.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc requires libgnome-desktop-2.so.10
	tsclient-2.0.1-9.fc11.ppc requires libgnome-desktop-2.so.10
	ufraw-0.14.1-3.fc11.ppc requires libexiv2.so.4
	ufraw-cinepaint-0.14.1-3.fc11.ppc requires libexiv2.so.4
	ufraw-gimp-0.14.1-3.fc11.ppc requires libexiv2.so.4
	vegastrike-0.5.0-6.fc11.ppc requires libboost_python.so.3
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts
	yelp-2.24.0-4.fc10.ppc requires gecko-libs >= 0:1.9.0.5



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	avant-window-navigator-0.2.6-13.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	deskbar-applet-2.25.1-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	e16-0.16.8.14-1.fc10.ppc64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.4-4.noarch requires bitstream-vera-fonts
	empathy-devel-2.24.1-4.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	firefox-3.0.5-1.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mozvoikko-0.9.5-5.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	perl-XML-LibXSLT-1.66-2.fc10.ppc64 requires perl(XML::LibXML) = 0:1.66
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	tsclient-2.0.1-9.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	ufraw-0.14.1-3.fc11.ppc64 requires libexiv2.so.4()(64bit)
	ufraw-cinepaint-0.14.1-3.fc11.ppc64 requires libexiv2.so.4()(64bit)
	ufraw-gimp-0.14.1-3.fc11.ppc64 requires libexiv2.so.4()(64bit)
	vegastrike-0.5.0-6.fc11.ppc64 requires libboost_python.so.3()(64bit)
	wammu-0.28-1.fc10.noarch requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts
	yelp-2.24.0-4.fc10.ppc64 requires gecko-libs >= 0:1.9.0.5





From rjones at redhat.com  Sat Dec 20 10:45:52 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 20 Dec 2008 10:45:52 +0000
Subject: Orphan freetennis
In-Reply-To: <494CCA92.5080508@hhs.nl>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
	<20081220082858.GB21475@amd.home.annexia.org>
	<494CCA92.5080508@hhs.nl>
Message-ID: <20081220104552.GA21792@amd.home.annexia.org>

On Sat, Dec 20, 2008 at 11:36:02AM +0100, Hans de Goede wrote:
> Richard W.M. Jones wrote:
>> https://admin.fedoraproject.org/pkgdb/packages/name/freetennis
> I'll take it, let me know when you've released it. (I've already fixed it 
> so that it builds again).

Thanks!  I've released devel, F-10 & F-9.  Probably best to just
forget about the F-8 branch now since it's going away in a week or
two.

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 hughsient at gmail.com  Sat Dec 20 10:54:30 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sat, 20 Dec 2008 10:54:30 +0000
Subject: rawhide report: 20081220 changes
In-Reply-To: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
Message-ID: <1229770470.5584.1.camel@hughsie-work.lan>

On Sat, 2008-12-20 at 10:45 +0000, Rawhide Report wrote:
> fontpackages-1.12-1.fc11
> ------------------------
> * Fri Dec 19 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
> - 1.12-1
> ? Add another macro to allow building fontconfig without cycling

Please stop doing this. Just use "*" or "-" like everyone else. Adding
these UTF8 characters adds no value whatsoever.

Richard.




From opensource at till.name  Sat Dec 20 11:12:38 2008
From: opensource at till.name (Till Maas)
Date: Sat, 20 Dec 2008 12:12:38 +0100
Subject: help with bison problems for iasl build (was: Re: Fedora rawhide
 rebuild in mock status 2008-12-17 x86_64)
In-Reply-To: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <200812201212.44778.opensource@till.name>

Hiyas,

On Sat December 20 2008, Matt Domsch wrote:

> iasl-20061109-4.fc9 (build/make) till

I updated to a newer release, but it still fails:
http://koji.fedoraproject.org/koji/getfile?taskID=1011660&name=build.log

It errors out with messages like:

| bison -v -d -y -pAslCompiler aslcompiler.y
| aslcompiler.y:797.42
| -43
| : 
| $$ for the midrule at $3 of `DefinitionBlockTerm' has no declared type

There is also an upstream bug filed at:
http://www.acpica.org/bugzilla/show_bug.cgi?id=744

I do not know how to fix this. Can maybe someone with bison knowledge take a 
look or should I just wait till upstream fixes the bug?

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/8ad0ddfe/attachment.sig>

From opensource at till.name  Sat Dec 20 11:24:11 2008
From: opensource at till.name (Till Maas)
Date: Sat, 20 Dec 2008 12:24:11 +0100
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <200812201224.25956.opensource@till.name>

On Sat December 20 2008, Matt Domsch wrote:

> pam_mount-0.49-1.fc10 (build/make) till

I made an mistake when moving libHX to /lib* in preparation for pam_mount 1.x, 
but I corrected it with libHX-1.25-3.fc11.

Regards,
Till
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/b7e542b9/attachment.sig>

From pertusus at free.fr  Sat Dec 20 11:55:10 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Dec 2008 12:55:10 +0100
Subject: [Fedora Update] [stable] rcsslogplayer-13.1.0-1.fc8
In-Reply-To: <494CC9D8.302@leemhuis.info>
References: <20081219134916.970A020876A@bastion.fedora.phx.redhat.com>
	<1229710262.5263.5.camel@localhost.localdomain>
	<494BF0A7.8030302@grad.com>
	<1229716138.5263.7.camel@localhost.localdomain>
	<494CC9D8.302@leemhuis.info>
Message-ID: <20081220115510.GA2506@free.fr>

On Sat, Dec 20, 2008 at 11:32:56AM +0100, Thorsten Leemhuis wrote:
>
> Jesse, I appreciate your efforts. But OTOH I wonder: Is it time for a  
> "Best practices for package updates" document in the wiki? It for  
> example could have a sections like "Please only update packages in  
> releases that are EOL soon if there is a good reason to", "when filing  
> update requests in bodhi please state some good reasons why you are  
> shipping the new version as regular update" and similar hints.
>
> I guess above could even be done without FESCo involvement. Or is there  
> such a document already somewhere and I just missed it?

I think that all that could fit on 
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility

The "Please only update packages in releases that are EOL soon if there 
is a good reason to" can go in 
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users
it could just be another point in the list.

The following could be an additional point in the same section:
"when filing  
update requests in bodhi please state some good reasons why you are  
shipping the new version as regular update"

> Further: Maybe some real guidelines for package updating are needed.  
> Right now some maintainers take care of their packages in a debian-like  
> way, while others seems to do the follow the "always latest and greatest  
> everywhere" concept. From a uses standpoint that just confusing imho. A  
> "this is how it normally should be done" could help.

Isn't 
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users
enough?

--
Pat



From pertusus at free.fr  Sat Dec 20 11:58:56 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Dec 2008 12:58:56 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229770470.5584.1.camel@hughsie-work.lan>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
Message-ID: <20081220115856.GB2506@free.fr>

On Sat, Dec 20, 2008 at 10:54:30AM +0000, Richard Hughes wrote:
> On Sat, 2008-12-20 at 10:45 +0000, Rawhide Report wrote:
> > fontpackages-1.12-1.fc11
> > ------------------------
> > * Fri Dec 19 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
> > - 1.12-1
> > ? Add another macro to allow building fontconfig without cycling
> 
> Please stop doing this. Just use "*" or "-" like everyone else. Adding
> these UTF8 characters adds no value whatsoever.

In general I find them funny, and Nicolas takes care of choosing the 
appropriate symbol. 

That being said I think that for compatibility it would be better to 
stick to ascii if possible, not all mailer understand utf8.

In the end I think tha this should be left to the packager.

--
Pat



From pertusus at free.fr  Sat Dec 20 12:17:18 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Dec 2008 13:17:18 +0100
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <494CC439.4070503@gmail.com>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
	<20081219194825.GA16284@bludgeon.org>
	<494BFECE.4050003@gmail.com> <20081220004829.GB10679@free.fr>
	<494CC439.4070503@gmail.com>
Message-ID: <20081220121718.GC2506@free.fr>

On Sat, Dec 20, 2008 at 02:08:57AM -0800, Toshio Kuratomi wrote:
> 
> Okay, so it sounds like FESCo wants to see whether:
> 1) provenpackagers feel comfortable just stepping up and making changes
> after they've done due diligence trying to contact the maintainer.
> 
> 2) Whether there will be any hurt feelings on the part of maintainers
> when provenpackagers make changes to their packages.
> 
> Since the OP said they have provenpackager and has tried to contact
> thias, I guess it's time to see how these two work out.

It shouldn't work like this, this contradicts Fedora policies. 
A policy change is needed if 
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages
is to be changed. Currently if thias package is modified for anything
else than what is covered in this policy, and if Ray isn't an 
"Experienced packagers" as defined in this document, he shouldn't
entitled to change thias package. 

Maybe the idea was to replace "Experienced packagers" by provenpackager
group members? If so it should really be done. And it is not a small
change, because the provenpackagers group is much bigger than the
"Experienced packagers" group (though the SIG stuff allows for 
interpretation here, and there could be people considered to be 
"Experienced packagers" because they are in a SIG, though they are not 
provenpackagers).

Once again when FESCo approve policy changes or new policies FESCo
people should make sure that the changes are documented.

--
Pat



From debarshi.ray at gmail.com  Sat Dec 20 12:28:08 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sat, 20 Dec 2008 17:58:08 +0530
Subject: rawhide report: 20081220 changes
In-Reply-To: <20081220115856.GB2506@free.fr>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<20081220115856.GB2506@free.fr>
Message-ID: <3170f42f0812200428wa78506dm7ff5e5e7685f3680@mail.gmail.com>

>>> fontpackages-1.12-1.fc11
>>> ------------------------
>>> * Fri Dec 19 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
>>> - 1.12-1
>>> ? Add another macro to allow building fontconfig without cycling

>> Please stop doing this. Just use "*" or "-" like everyone else. Adding
>> these UTF8 characters adds no value whatsoever.

> That being said I think that for compatibility it would be better to
> stick to ascii if possible, not all mailer understand utf8.
>
> In the end I think tha this should be left to the packager.

Very pedantically speaking, the guideline does not allow it:
https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

Cheerio,
Debarshi



From pertusus at free.fr  Sat Dec 20 12:42:51 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Dec 2008 13:42:51 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <3170f42f0812200428wa78506dm7ff5e5e7685f3680@mail.gmail.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<20081220115856.GB2506@free.fr>
	<3170f42f0812200428wa78506dm7ff5e5e7685f3680@mail.gmail.com>
Message-ID: <20081220124251.GE2506@free.fr>

On Sat, Dec 20, 2008 at 05:58:08PM +0530, Debarshi Ray wrote:
> 
> Very pedantically speaking, the guideline does not allow it:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

That's not my recalling. I may be remembering incorrectly (it 
wouldn't be the first time), but what I remember is that the 
Changelog policy, on the formatting side was especially done for
the location of the version, since there was disagreement
on that, but I am not sure that there was a ruling on using 
- for the changelog entries.

In fact I cannot find the Changelog policy change nor anything
relevant on the packaging list. I'll send a mil then.

--
Pat



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Dec 20 12:54:16 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sat, 20 Dec 2008 21:54:16 +0900
Subject: rawhide report: 20081220 changes
In-Reply-To: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
Message-ID: <494CEAF8.10706@ioa.s.u-tokyo.ac.jp>

Rawhide Report wrote, at 12/20/2008 07:45 PM +9:00:
> Compose started at Sat Dec 20 06:01:10 UTC 2008
> 
> Updated Packages:
>
> blam-1.8.5-5.fc10
> -----------------
> * Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 1.8.5-5
> - Rebuild against newer gecko
> 
> epiphany-extensions-2.24.0-3.fc10
> ---------------------------------
> * Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.24.0-3
> - Rebuild against newer gecko
> 
> 
> firefox-3.0.5-1.fc10
> --------------------
> * Tue Dec 16 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 3.0.5-1
> - Update to 3.0.5
> 
> gnome-web-photo-0.3-13.fc10
> ---------------------------
> * Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.3-13
> - Rebuild against newer gecko
> 
> mozvoikko-0.9.5-5.fc10
> ----------------------
> * Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.9.5-5
> - Rebuild against newer gecko
>
> yelp-2.24.0-4.fc10
> ------------------
> * Wed Dec 17 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.24.0-4
> - Rebuild against newer gecko
> 
> 
> Summary:
> Added Packages: 0
> Removed Packages: 0
> Modified Packages: 71
> Broken deps for i386
> ----------------------------------------------------------
> 	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
> 	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
> 	firefox-3.0.5-1.fc10.i386 requires gecko-libs = 0:1.9.0.5
> 	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
> 	mozvoikko-0.9.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
> 	yelp-2.24.0-4.fc10.i386 requires gecko-libs >= 0:1.9.0.5

Why did this happen? All these package has '.fc10' suffix.
It seems that they were rebuilt on F-10 (not F-11) against F-10 xulrunner 1.9.0.5 and 
brought to F-11 branch, while F-11 xulrunner is still 1.9.0.4.

Mamoru



From nicolas.mailhot at laposte.net  Sat Dec 20 13:16:26 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 20 Dec 2008 14:16:26 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <3170f42f0812200428wa78506dm7ff5e5e7685f3680@mail.gmail.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<20081220115856.GB2506@free.fr>
	<3170f42f0812200428wa78506dm7ff5e5e7685f3680@mail.gmail.com>
Message-ID: <1229778986.14462.4.camel@arekh.okg>

Le samedi 20 d?cembre 2008 ? 17:58 +0530, Debarshi Ray a ?crit :

> Very pedantically speaking, the guideline does not allow it:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

Those are examples. I believe they were never intended to regulate
anything past the version string.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/82730f8e/attachment.sig>

From menthos at menthos.com  Sat Dec 20 13:35:17 2008
From: menthos at menthos.com (Christian Rose)
Date: Sat, 20 Dec 2008 14:35:17 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <3170f42f0812200428wa78506dm7ff5e5e7685f3680@mail.gmail.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<20081220115856.GB2506@free.fr>
	<3170f42f0812200428wa78506dm7ff5e5e7685f3680@mail.gmail.com>
Message-ID: <97da516f0812200535j73455779w43317e157a59d249@mail.gmail.com>

On 12/20/08, Debarshi Ray <debarshi.ray at gmail.com> wrote:
> >>> fontpackages-1.12-1.fc11
>  >>> ------------------------
>  >>> * Fri Dec 19 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
>  >>> - 1.12-1
>  >>> ? Add another macro to allow building fontconfig without cycling
>
>  >> Please stop doing this. Just use "*" or "-" like everyone else. Adding
>  >> these UTF8 characters adds no value whatsoever.
>
>
> > That being said I think that for compatibility it would be better to
>  > stick to ascii if possible, not all mailer understand utf8.
>  >
>  > In the end I think tha this should be left to the packager.
>
>
> Very pedantically speaking, the guideline does not allow it:
>  https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

If only ASCII is allowed, a lot of people will not have the
possibility to have their names spelled correctly, with proper accents
or umlauts, in Changelogs.

For this very reason, we treat all GNOME ChangeLogs as UTF-8. IMHO,
that may make sense in Fedora ChangeLog guidelines as well.


Christian



From nicolas.mailhot at laposte.net  Sat Dec 20 13:13:48 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 20 Dec 2008 14:13:48 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229770470.5584.1.camel@hughsie-work.lan>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
Message-ID: <1229778828.14462.2.camel@arekh.okg>

Le samedi 20 d?cembre 2008 ? 10:54 +0000, Richard Hughes a ?crit :
> On Sat, 2008-12-20 at 10:45 +0000, Rawhide Report wrote:
> > fontpackages-1.12-1.fc11
> > ------------------------
> > * Fri Dec 19 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
> > - 1.12-1
> > ? Add another macro to allow building fontconfig without cycling
> 
> Please stop doing this. Just use "*" or "-" like everyone else. Adding
> these UTF8 characters adds no value whatsoever.

This part of the changelog is in the official freeform UTF-8 plain text
format. It seems to work in all our tools including this release update
noitification bot.

If you disagree with the current rules, ask FPC and FESCO to change
them. Please stop trying to change the distribution packaging rules
without going through the instances appointed to regulate them.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/0f1b6807/attachment.sig>

From ml at bendler-net.de  Sat Dec 20 13:47:06 2008
From: ml at bendler-net.de (Thomas Bendler)
Date: Sat, 20 Dec 2008 14:47:06 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <200812192017.mBJKHVW7002019@laptop14.inf.utfsm.cl>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494AEEAA.3090608@kanarip.com>
	<6e24a8e80812181816y77511252qda398d21b03e3908@mail.gmail.com>
	<1229685176.1599.35.camel@fatty>
	<e5f36bc70812190452j26092a19ud0ec248b688aecaa@mail.gmail.com>
	<1229701953.3741.131.camel@ignacio.lan>
	<e5f36bc70812190831g67f8561alcad08138f29ec72f@mail.gmail.com>
	<200812192017.mBJKHVW7002019@laptop14.inf.utfsm.cl>
Message-ID: <e5f36bc70812200547y1eb403a1s646aa4bd2f63f91@mail.gmail.com>

On Fri, Dec 19, 2008 at 9:17 PM, Horst H. von Brand
<vonbrand at inf.utfsm.cl>wrote:

> Thomas Bendler <ml at bendler-net.de> wrote:
> > [Wants a vote here, as otherwise it is "designing without
> >  numbers". Claims Google shows majority don't like spatial]
> A vote here (where just the ones who feel strongly about the matter) is not
> a way to find out what "the users" want/like.


How did you find out that spatial mode is what the users want? You didn't
vote? Only a few people decided to use spatial mode because they think it's
what users like? Sorry, but the only things I here in this discussion is why
we can't find out what users like (or why this is the wrong approach to find
out what users like) and therefore we simply leave everything as it is. I
agree if you say this might not be representative if we only make a poll on
this list but fact is, no other distributions like Ubuntu, SuSE nor Windows
nor Mac OS use spatial mode by default. I still don't get the point why
Fedora goes a different way and the only answer I saw so far was something
like we can't count what people like more. Make a simple compare, search for
Ubuntu and the question on how to switch to spatial mode and make the same
for Fedora on how to browser mode. Do you see the difference? I think this
something which reflect (not in a perfect way but good enough) what people
want.

And you surely realize that what Google finds is just the complaints of
> those who _don't_ like it, those who like it won't go around commenting on
> the feature. Besides, if Google shows a few hundred complaints, that is
> still a tiny minority of Gnome users.


It's more than a few hundred and as I stated before, compare the number of
entries for people asking to switch to spatial mode with the number of
questions asking to switch to browser mode. For me it is quite clear that
browser mode is preferred by the majority of users but maybe I'm wrong.

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/dd021dcb/attachment.htm>

From pertusus at free.fr  Sat Dec 20 14:07:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Dec 2008 15:07:15 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <97da516f0812200535j73455779w43317e157a59d249@mail.gmail.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<20081220115856.GB2506@free.fr>
	<3170f42f0812200428wa78506dm7ff5e5e7685f3680@mail.gmail.com>
	<97da516f0812200535j73455779w43317e157a59d249@mail.gmail.com>
Message-ID: <20081220140715.GG2506@free.fr>

On Sat, Dec 20, 2008 at 02:35:17PM +0100, Christian Rose wrote:
> 
> For this very reason, we treat all GNOME ChangeLogs as UTF-8. IMHO,
> that may make sense in Fedora ChangeLog guidelines as well.

More generally spec files in fedora should be utf8. I don't know if 
there is an official guideline, but there is a rpmlint warning, and I
have not yet found a maintainer not willing to use utf8 for the spec
file.

--
Pat



From ml at bendler-net.de  Sat Dec 20 14:09:50 2008
From: ml at bendler-net.de (Thomas Bendler)
Date: Sat, 20 Dec 2008 15:09:50 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494C05A7.6070102@gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
Message-ID: <e5f36bc70812200609wd1b4e8fvea4cca621dc5e3b7@mail.gmail.com>

On Sat, Dec 20, 2008 at 2:40 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:

> [...]
> 1)This is not a democracy.  Nor is GNOME a democracy.


If there is even on a development mailing list no democracy, why asking the
community to support Fedora? Sorry, but if you think that you don't need
democracy in an open source project you are on the complete wrong track.

[...]
> Here we have Mark and other people disagreeing with choices that have
> been made. They are very passionate about their opinion.  The current
> maintainers and developers disagree. They've listened, the responded,
> they still disagree. So other than not agreeing what did they do wrong


They might have listen but they didn't argue why this setting is in the
package. They simply say, that's what we like and what the majority of users
like (without any given statistics). Fact is, no other bigger distribution
(Ubuntu, SuSE) nor Windows nor Mac OS use spatial view but appreantly this
completly ignored.



> [...]
> disagree and will not be making the requested change?  What exactly
> should have been done differently in the main conversation in this
> thread that would have made people feel better about the decision to
> not change the default setting to what they believe is reasonable?


If you behave different compared to all other I would expect strong reasons
for this decision. I didn't saw this strong reasons yet, maybe I've didn't
saw them.

[...]
> But I said I'd play. So let's play.  What are people doing wrong in
> how they are communicating their disagreement?


They didn't present the strong reason why going a different way.

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/441e96d8/attachment.htm>

From mschwendt at gmail.com  Sat Dec 20 14:16:28 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 20 Dec 2008 15:16:28 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <494CEAF8.10706@ioa.s.u-tokyo.ac.jp>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<494CEAF8.10706@ioa.s.u-tokyo.ac.jp>
Message-ID: <20081220151628.f89dbbd8.mschwendt@gmail.com>

On Sat, 20 Dec 2008 21:54:16 +0900, Mamoru wrote:

> > 	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
> > 	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
> > 	firefox-3.0.5-1.fc10.i386 requires gecko-libs = 0:1.9.0.5
> > 	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
> > 	mozvoikko-0.9.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
> > 	yelp-2.24.0-4.fc10.i386 requires gecko-libs >= 0:1.9.0.5
> 
> Why did this happen? All these package has '.fc10' suffix.
> It seems that they were rebuilt on F-10 (not F-11) against F-10 xulrunner 1.9.0.5 and 
> brought to F-11 branch, while F-11 xulrunner is still 1.9.0.4.

That's how inheritance in koji works. If these packages have not been
built for Rawhide yet, they are inherited from F-10. Only by building them
for Rawhide, you can stop this.



From Axel.Thimm at ATrpms.net  Sat Dec 20 14:57:52 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 20 Dec 2008 16:57:52 +0200
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <1229619037.3472.26.camel@localhost.localdomain>
References: <494A7A92.9020404@redhat.com>
	<1229618217.14090.543.camel@beck.corsepiu.local>
	<1229619037.3472.26.camel@localhost.localdomain>
Message-ID: <20081220145752.GA12856@victor.nirvana>

On Thu, Dec 18, 2008 at 11:50:37AM -0500, Tom spot Callaway wrote:
> On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
> > Wouldn't it be better to let rpm set _libdir/_lib to match noarch
> > package requirements?
> 
> What should it set it to? It has no knowledge of where the noarch rpm
> package will eventually be installed. Should we assume that /usr/lib is
> always correct (how Debian of me to even suggest this)?

Isn't the norach equivalent of _libdir _datadir? Or phrased in another
way: Shouldn't a noach package avoid both lib and lib64? I think we
even have rules already set for this.

I don't quite agree that rpm should start changing _libdir to point
to _datadir, but the packagers should probably patch up the packages
to use _datadir instead of _libdir if the package is indeed noarch.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/df4e44f0/attachment.sig>

From jos at xos.nl  Sat Dec 20 15:05:48 2008
From: jos at xos.nl (Jos Vos)
Date: Sat, 20 Dec 2008 16:05:48 +0100
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <20081220145752.GA12856@victor.nirvana>
References: <494A7A92.9020404@redhat.com>
	<1229618217.14090.543.camel@beck.corsepiu.local>
	<1229619037.3472.26.camel@localhost.localdomain>
	<20081220145752.GA12856@victor.nirvana>
Message-ID: <20081220150548.GA2327@jasmine.xos.nl>

On Sat, Dec 20, 2008 at 04:57:52PM +0200, Axel Thimm wrote:

> Isn't the norach equivalent of _libdir _datadir? Or phrased in another
> way: Shouldn't a noach package avoid both lib and lib64? I think we
> even have rules already set for this.
> 
> I don't quite agree that rpm should start changing _libdir to point
> to _datadir, but the packagers should probably patch up the packages
> to use _datadir instead of _libdir if the package is indeed noarch.

I tend to agree.  It would be interesting to scan alle noarch packages
and see what they put in /usr/lib* and whether that's ok or not.

B.t.w. I'm also against changing macros per target arch (as far as
possible at all), this will make spec files even less "predictable".

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From happyharrysco1 at yahoo.co.uk  Sat Dec 20 15:11:31 2008
From: happyharrysco1 at yahoo.co.uk (Phil Smith)
Date: Sat, 20 Dec 2008 15:11:31 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <200812200007.mBK077J7004429@laptop14.inf.utfsm.cl>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229634566.3300.2.camel@matthiasc>
	<giepf5$i12$1@ger.gmane.org>	<a993ebee0812190424j15c02db0le081b1778875b94@mail.gmail.com>	<6e24a8e80812190513i1975520esa514567066d80a05@mail.gmail.com>	<494C08B7.5010903@gmail.com>
	<200812200007.mBK077J7004429@laptop14.inf.utfsm.cl>
Message-ID: <494D0B23.1090205@yahoo.co.uk>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
>   
>> Mark wrote:
>>     
>>> btw. i never understood why Linus Torvalds was so opposed to Gnome.
>>> i'm beginning to understand why.
>>>       
>
>   
>> How much less RAM would your system need if everything shared one
>> window toolkit?
>>     
>
> Disk and RAM are practically free, given today's prices.
>
>   
/snip

but in the booming market of netbooks and smaller handheld pc's most of 
them are such that ram and disk space aren't that easily changed



From orion at cora.nwra.com  Sat Dec 20 15:21:04 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Sat, 20 Dec 2008 08:21:04 -0700
Subject: koji client on EL5?
In-Reply-To: <494C79FF.3060008@cora.nwra.com>
References: <494C79FF.3060008@cora.nwra.com>
Message-ID: <494D0D60.9070505@cora.nwra.com>

Orion Poplawski wrote:
> Is it possible to run the koji client to do fedora builds from EL5?
> 
> I'm getting:
> 
> Unable to log in, no authentication methods available
> 
> koji-1.2.6-1.el5
> 
> I may not have everything I need, but it's not very verbose about what 
> it might be.
> 
> - Orion
> 

Sorry, entirely user error.

- Orion



From hughsient at gmail.com  Sat Dec 20 15:40:02 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sat, 20 Dec 2008 15:40:02 +0000
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229778828.14462.2.camel@arekh.okg>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
Message-ID: <1229787602.4136.6.camel@hughsie-work.lan>

On Sat, 2008-12-20 at 14:13 +0100, Nicolas Mailhot wrote:
> Le samedi 20 d?cembre 2008 ? 10:54 +0000, Richard Hughes a ?crit :
> > On Sat, 2008-12-20 at 10:45 +0000, Rawhide Report wrote:
> > > fontpackages-1.12-1.fc11
> > > ------------------------
> > > * Fri Dec 19 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
> > > - 1.12-1
> > > ? Add another macro to allow building fontconfig without cycling
> > 
> > Please stop doing this. Just use "*" or "-" like everyone else. Adding
> > these UTF8 characters adds no value whatsoever.
> 
> This part of the changelog is in the official freeform UTF-8 plain text
> format. It seems to work in all our tools including this release update
> noitification bot.

Right. There's lots of things that work, if you do them wrong:

(&&^*&^(*&^(*&^(*&^(*&^(*&^(*&^(*&^*&^(*&^&^%^%$%^$$^%$^%$^(*&^(*^
(*) update to latest upstream
(*&(*)(*&)(*&*&(^^%)(*_(*_(*&)*&(*&^&^%(*)_(*)(^%%^%&^%$$%?$?"^$&^

Spec file ChangeLogs are not free-form text.

I've got no problem with UTF-8. I just don't think you should be
masturbating over the fact you can do special bullets.

> If you disagree with the current rules, ask FPC and FESCO to change
> them. Please stop trying to change the distribution packaging rules
> without going through the instances appointed to regulate them.

No, if you are unhappy with using "- " and want to make all spec file
authors to use your UTF8 symbols, YOU need to ask FESCO.

Please, just stick to what everyone else is doing. At the moment it's
just you that's being difficult.

Richard.




From john.ellson at comcast.net  Sat Dec 20 15:46:32 2008
From: john.ellson at comcast.net (John Ellson)
Date: Sat, 20 Dec 2008 10:46:32 -0500
Subject: help with bison problems for iasl build
In-Reply-To: <200812201212.44778.opensource@till.name>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
	<200812201212.44778.opensource@till.name>
Message-ID: <494D1358.30106@comcast.net>

Till,

I had the same problem with bison in graphviz.    See
    https://bugzilla.redhat.com/show_bug.cgi?id=474358
for the fix

John



Till Maas wrote:
> Hiyas,
>
> On Sat December 20 2008, Matt Domsch wrote:
>
>   
>> iasl-20061109-4.fc9 (build/make) till
>>     
>
> I updated to a newer release, but it still fails:
> http://koji.fedoraproject.org/koji/getfile?taskID=1011660&name=build.log
>
> It errors out with messages like:
>
> | bison -v -d -y -pAslCompiler aslcompiler.y
> | aslcompiler.y:797.42
> | -43
> | : 
> | $$ for the midrule at $3 of `DefinitionBlockTerm' has no declared type
>
> There is also an upstream bug filed at:
> http://www.acpica.org/bugzilla/show_bug.cgi?id=744
>
> I do not know how to fix this. Can maybe someone with bison knowledge take a 
> look or should I just wait till upstream fixes the bug?
>
> Regards,
> Till
>   


-- 
John Ellson



From nicolas.mailhot at laposte.net  Sat Dec 20 15:57:22 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 20 Dec 2008 16:57:22 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229787602.4136.6.camel@hughsie-work.lan>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
Message-ID: <1229788642.16655.12.camel@arekh.okg>

Le samedi 20 d?cembre 2008 ? 15:40 +0000, Richard Hughes a ?crit :
> On Sat, 2008-12-20 at 14:13 +0100, Nicolas Mailhot wrote:

> > If you disagree with the current rules, ask FPC and FESCO to change
> > them. Please stop trying to change the distribution packaging rules
> > without going through the instances appointed to regulate them.
> 
> No, if you are unhappy with using "- " and want to make all spec file
> authors to use your UTF8 symbols, YOU need to ask FESCO.

I've discussed this particular point several times with past and present
FPC and FESCO members, so I know pretty well where I stand
guidelines-wise, and it's not where you think I am. And I don't demand
of other people to follow my spec writing style.

> Please, just stick to what everyone else is doing. At the moment it's
> just you that's being difficult.

If making it plain what the current official encoding and format of spec
files is is being difficult, yes I'm being difficult.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/bae6ed13/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Dec 20 16:13:35 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 20 Dec 2008 17:13:35 +0100
Subject: New font packaging guidelines
Message-ID: <1229789615.16655.28.camel@arekh.okg>

Dear all,

As some of you may know, after more than a month of consultation,
feedback and tweaking new font packaging guidelines have been approved
by FESCO.

http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18)
http://fedoraproject.org/wiki/Fedora_fonts_policy_package
http://fedoraproject.org/wiki/Simple_fonts_spec_template
http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

New font packages in review must now conform to the new templates, and
current packages be converted in rawhide by their maintainers. To track
the conversion progress I will henceforth file tickets in bugzilla.

The following packages have already been converted in rawhide and can
serve as examples if the templates in the fontpackages-devel package are
not clear enough:

? andika-fonts
? apanov-heuristica-fonts
? bitstream-vera-fonts
? charis-fonts
? dejavu-fonts
? ecolier-court-fonts
? edrip-fonts
? gfs-ambrosia-fonts
? gfs-artemisia-fonts
? gfs-baskerville-fonts
? gfs-bodoni-classic-fonts
? gfs-bodoni-fonts
? gfs-complutum-fonts
? gfs-didot-classic-fonts
? gfs-didot-fonts
? gfs-eustace-fonts
? gfs-fleischman-fonts
? gfs-garaldus-fonts
? gfs-gazis-fonts
? gfs-jackson-fonts
? gfs-neohellenic-fonts
? gfs-nicefore-fonts
? gfs-olga-fonts
? gfs-porson-fonts
? gfs-solomos-fonts
? gfs-theokritos-fonts
? stix-fonts
? yanone-kaffeesatz-fonts

Note that the discussed renames and splits have not been submitted for
approval yet (I'm waiting for the rename process to be clarified), so
the current change is purely technical.

Nevertheless the new templates make creation of sub-packages
considerably easier and safer, so I advice packagers to perform a split
by family now if they don't mind. There was a broad consensus for the
splitting in general, and the only thing that remains to be clarified
before submission FPC-side is the wording of the few exceptions.

Sincerely,

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/bd6885d6/attachment.sig>

From fedora at camperquake.de  Sat Dec 20 17:09:13 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 20 Dec 2008 18:09:13 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229788642.16655.12.camel@arekh.okg>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
	<1229788642.16655.12.camel@arekh.okg>
Message-ID: <20081220180913.45f62880@lain.camperquake.de>

Hi.

On Sat, 20 Dec 2008 16:57:22 +0100, Nicolas Mailhot wrote

> If making it plain what the current official encoding and format of
> spec files is is being difficult, yes I'm being difficult.

So this is 'We do what we must, because we can', kind of?



From lesmikesell at gmail.com  Sat Dec 20 18:01:12 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 12:01:12 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229719550.23410.79.camel@dimi.lattica.com>	<1229722878.3861.0.camel@localhost.localdomain>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
Message-ID: <494D32E8.90901@gmail.com>

Jeff Spaleta wrote:
> 
> I think the proponents of change do a disservice to their chosen cause
> in choosing the argumentation they have so far.  Trying to coerce a
> change by hammering away with the blunt instruments of populism.  It's
> not going to work. Coercion is the wrong method and populist arguments
> are the wrong tool.  You have to persuade the decision-makers, and to
> do that you have to understand how they prioritize and think.   The
> art of persuasion is a subtle science. It's brain surgery, not to be
> performed with the hammer or rhetoric or with the pitchforks and
> torches  of populist appeal.   You have to crawl inside the heads of
> the people whose minds you are looking to change, and think like them.

So what about simple logic:
The companies with big budgets already performed the due diligence that 
no one here is willing to do - and we can see they all made the same choice.

How about simplicity:  You already know how to open one browser window. 
  If you want two for drag/drop or copy/paste operations you don't need 
to do anything different, just do it again.

How about horrible user interface: in the spatial mode you have to use 
the middle mouse button all the time to get expected operation.  Where's 
the middle mouse button on my laptop?

But the worst part about this mess is the way the change in the default 
appeared in the first place.  You make it sound like the burden should 
be on the people who want the current setting changed, but in fact it 
should never have been permitted in the first place.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From markg85 at gmail.com  Sat Dec 20 18:02:26 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 19:02:26 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
Message-ID: <6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>

On Sat, Dec 20, 2008 at 10:00 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Fri, Dec 19, 2008 at 9:10 PM, Dimi Paun <dimi at lattica.com> wrote:
>> So what do we get for asking that we see this changed?
>>  - snide remarks
>
> In this thread..ive seen snide comments from multiple parties on both
> sides.  I've seen a round in the cycle of existing hostilities.  There
> are no saints here, we are all sinners.  Keeping score of the assumed
> intent of the multitude of emotional comments on one side or the other
> is futile and serves no useful purpose. If you are keeping score of
> snide comments, then you've already given up on a constructive
> discussion.  You have to be able to give everyone the benefit of the
> doubt as to intent. The medium of email is excruciatingly poor at
> communicating irrational emotive discourse. The subtle nuances of body
> language, or vocal and facial ques which regulate the flow of face to
> face conversations are not there to help us read intent with any
> accuracy whatsoever.
>
>>  - we are ask to produce numbers nobody can produce
>
> In this thread, I have not seen the decision makers ask that numbers
> be produced. I see numbers being produced by people to sustain their
> own arguments and getting upset that other are critical of the
> numbers.  The numbers are a false premise, they shouldn't be debated,
> they should be summarily ignored. To debate them gives credibility to
> the idea that accurate numbers are going to impact the design, and no
> one has come forward and promised that in this thread..
>
>>  - we are sent on wild goose chances "upstream" when this
>>    is a packages maintained by RH.
>
> Yes this has happened in this thread. I have in fact done this myself
> before and I still stand by it.  If this change is going to be made is
> going to be made as part of an upstream discussion around the design
> goals of the default GNOME experience, a discussion broader in scope
> than this one change.
>
> I think the proponents of change do a disservice to their chosen cause
> in choosing the argumentation they have so far.  Trying to coerce a
> change by hammering away with the blunt instruments of populism.  It's
> not going to work. Coercion is the wrong method and populist arguments
> are the wrong tool.  You have to persuade the decision-makers, and to
> do that you have to understand how they prioritize and think.   The
> art of persuasion is a subtle science. It's brain surgery, not to be
> performed with the hammer or rhetoric or with the pitchforks and
> torches  of populist appeal.   You have to crawl inside the heads of
> the people whose minds you are looking to change, and think like them.
>
>> But hey, these things happen, we can work around them. What's not cool
>> is the attitude that it's OK to diss the users. That just sucks the
>> fun out of being part of Fedora.
>
> I think you are reading way to much into the responses of a a very
> long and very heated discussion which this thread is but one chapter.
> The exact same sort of thing could be said about it being uncool to
> diss developers.  There have certainty been posts in this thread which
> could be read as dissing developers.  I think we can all agree that
> its uncool to diss people generally.  I'll go further and say that
> most people are going to screw up and when things get heated are going
> to choose words poorly and end up writing something that is laced with
> too much emotion and will be interpreted as a personal slight or
> attack.  The real trick is figuring out how to make it possible to
> keep those mistakes from invoking another round of emotional responses
> in a self-perpetuating cycle of over-reaction.
>
> -jef

Oke, first thing first.
I subscribed to the gnome usability list and added that. this mail is
being send to them as well so therefore i include my original message.

My original message:
On Thu, Dec 18, 2008 at 9:56 PM, Mark <markg85 at gmail.com> wrote:
> Hey,
>
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.
>
> Motivation:
> A new window for each folder that i open is so painful!!
> 1. My taskbar fills up in notime each time i open a new folder
> 2. New features of nautilus: tabbed browsing! completely useless if
> your not using the browser mode
> 3. Tabbed browsing (files/folders or web) is "hot" these days
> 4. It feels so.. old (windows 95? 3.11?)
> just to name a few
>
> Cross posted to the devel list because it's for the next fedora
> version (currently in development thus the devel list)
>
> Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
> couldn't find an existing one for this! made one myself)
>
> So, lets vote:
>
> +1 from me
>
> I hope this can be done for Fedora 11 (it's just changing one gconf value).
> All vote plz
>
> Mark.
>

To the people reading the gnome usability list and see this for the
first time.. look here for the full discussion (about 150 posts):
http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=65669&viewmode=flat&order=ASC&start=0

Now to react on the memory and cpu stuff (heavy off topic but i want
to respond on that).
I don't give a damn that memory and cpu are cheap these days. does
that mean my memory needs to be full with junk and have a 100% cpu
load all the time? NO and NO! I want my pc to be fast and not to work
as a heater in my room.

Now on topic.
Lets do a little rounding up (conclusions how i see them! correct me
if i'm wrong on any of them)

1. Somewhere in 2003 or 2004 it is decided for whatever reason to make
the spatial mode in nautilus and put it as the default mode. To my
knowledge no research is done if people even wanted that. it just got
pushed through there throat and they are expected to just take it in
not spit it out. We are now (and a lot of users back then) spitting
that decision out and clear that bad taste. Nearly all gnome based
distributions do the same and the people using those distributions
seems to be happy about the browser mode.

2. I always was under the impression that gnome especially was a
democracy but it turns out it's under dictatorship and then call it:
"Meritocracy" with a dictator like taste.

3. Fedora has a community but when the community starts demanding
something (use the browser mode as default) then it turns out that the
actual fedora community, the ones that are helping to make fedora
"better", are just a hand full of people. the rest (like me) can be
easily put aside and be ignored. It would be good if Max Spevack or
Paul Frields would respond on this. So there we are.. yelling to
change something but just about 10 max 20 ppl are being listened to.
What i or any other community member says is simply being ignored. WE,
the community want this feature to change and i'm not going to be
silent about it! Also i HAD the idea that the fedora community was
democratic as well. They have votes in fesco with just 10!!!! people
but we can't have it here because it's "not representative" the fedora
community lead (those max 20 ppl) is just a dictatorship group. As
long as the community thinks the same as them there is no issue. But
when we think different we see the true fedora community leadership
aka dictatorship.

4. There is just ONE person here that decided to make it spatial and
that one person can't be convinced (Alexander Larson). Just look at
the replys here of the ppl that  want the browser mode and the people
that want the spatial mode. browser mode is heavily in favor here! And
coming with good arguments to "convince" Mr. Larson that his idea is
flawed and browser mode should be the default is useless because he
kinda made it! and he, of cause, believes in his own (broken)
invention. He, Alexander Larson, added the "always_use_browser" in
gconf and turned it to false by default! By turning it to false he,
since gnome 2.6 now, has enabled the spatial mode for all of us. It IS
a flawed desicion which perhaps wasn't obvious back then in 2004 but
is more then clear now in 2008 nearly 2009.

5. I was about to open a bug report on gnome for this now but it turns
out there is one already:
http://bugzilla.gnome.org/show_bug.cgi?id=427628

6. Convincing people.. yea possible but is FOUR (yes 4!) FREAKING
YEARS not proof enough that there decision was wrong. If that doesn't
convince them, again mainly or even only Alexander Larson, then they
can simply not be convinced in this subject.

7. This is a conclusion again about the community. A few months ago
Max Spevack came to my school to hold a presentation about linux,
redhat and fedora and open source in general. He also told some things
about the community and how they got things done that otherwise
wouldn't have been done or a lot later. At that time i already knew
that the fedora community was going in the wrong direction. Everything
they did just didn't seem to lead anywhere. the result of that was the
extremely buggy Fedora 9 release which was another few months before
Max came to my school. So for me the community was going in the wrong
direction. Now it all becomes much clearer to me because now i know
that there is no big community at all! there might be in numbers but
that's it. nice for marketing talk. the actual community is just about
20 ppl from what i can see and they do NOT listen to the others
(thousands?) i'm not quite sure if max said something like 1100
community members or 11000...

A very good example of the bad community direction is, to name someone
again, Rahul. He always points you to your mistakes (fine in a way)
but never adds (not in my experience) something constructive or
helpful.... always a link to a wiki of somekind.

And for this entire issue where i made this thread for in the first
place. Don't expect me to be silent now. I will be vocal about this.
fedora has a "freedom" sign in it's logo so make that a reality!



From lesmikesell at gmail.com  Sat Dec 20 18:30:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 12:30:05 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229681113.3159.13863.camel@cookie.hadess.net>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<494AD0FE.70202@gmail.com>	<494AD768.4030907@fedoraproject.org>	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
	<1229681113.3159.13863.camel@cookie.hadess.net>
Message-ID: <494D39AD.9020705@gmail.com>

Bastien Nocera wrote:
>
>> Also if this isn't the way to get this in fedora then what is? this
>> change will affect everyone and should not rely on one person but
>> should have a solid base behind it.
> 
> Get the defaults changed upstream.
> 
>> In this thread there are just a few -1 posts and the rest seems to be
>> +1 so the solid base is building up here.
> 
> That's called a vocal minority, and is the reason why we don't have
> votes on mailing-lists for this sort of thing.
> 
> And if you think it's a matter of patching the package, note that for
> any GNOME packages you'll find in Fedora for which there are patches,
> you'll find those same patches/functionality being upstreamed.

I think there is really a better approach to this, but it doesn't mesh 
all that well with RPM capabilities.  That is, for every package or 
package group where there is more than one commonly desired 
configuration, there should be multiple configuration packages where the 
last one installed wins, conceptually similar to the way the 
caching-nameserver package is just a different configuration for bind.

Then you could have a gnome-cluttered package for people who like 
leaving trails of open windows splattered all over the screen and 
gnome-clean for people who don't.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From gnomeuser at gmail.com  Sat Dec 20 18:31:43 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Sat, 20 Dec 2008 19:31:43 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
Message-ID: <1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>

2008/12/20 Mark <markg85 at gmail.com>

>
>
> And for this entire issue where i made this thread for in the first
> place. Don't expect me to be silent now. I will be vocal about this.
> fedora has a "freedom" sign in it's logo so make that a reality!
>

And you remain with the freedom to change the setting manually, create your
own spin with the setting changed by default. Your freedom however does not
extend to throwing a hissy fit on the development list because you're
preference is not the default. We have processes for feature goals and there
is upstream GNOME to have this debate with, both will get you input on the
idea without pissing the rest of us off.

I used to have the browser mode activated out of habit, but now because you
made it your mission to spam the devel list and attack developers, I have
changed the setting back and you know what.. I love spatial.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/4d31eb0d/attachment.htm>

From lesmikesell at gmail.com  Sat Dec 20 18:47:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 12:47:14 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
Message-ID: <494D3DB2.4000304@gmail.com>

David Nielsen wrote:
>
>> And for this entire issue where i made this thread for in the first
>> place. Don't expect me to be silent now. I will be vocal about this.
>> fedora has a "freedom" sign in it's logo so make that a reality!
>>
> 
> And you remain with the freedom to change the setting manually, create your
> own spin with the setting changed by default. Your freedom however does not
> extend to throwing a hissy fit on the development list because you're
> preference is not the default. We have processes for feature goals and there
> is upstream GNOME to have this debate with, both will get you input on the
> idea without pissing the rest of us off.
> 
> I used to have the browser mode activated out of habit, but now because you
> made it your mission to spam the devel list and attack developers, I have
> changed the setting back and you know what.. I love spatial.

Can someone who likes (even tolerates) spatial mode describe why?  I'm 
completely baffled as to why anyone would prefer windows left open all 
over the place randomly instead of just explicitly opening ones yourself 
in places where you want them.  For me, it is _always_ extra work to 
close the unwanted windows compared to opening the ones I want.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From markg85 at gmail.com  Sat Dec 20 18:50:18 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 19:50:18 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
Message-ID: <6e24a8e80812201050j2f2126b4x4472606058b2c6e@mail.gmail.com>

2008/12/20 David Nielsen <gnomeuser at gmail.com>:
>
>
> 2008/12/20 Mark <markg85 at gmail.com>
>>
>>
>> And for this entire issue where i made this thread for in the first
>> place. Don't expect me to be silent now. I will be vocal about this.
>> fedora has a "freedom" sign in it's logo so make that a reality!
>
> And you remain with the freedom to change the setting manually, create your
> own spin with the setting changed by default. Your freedom however does not
> extend to throwing a hissy fit on the development list because you're
> preference is not the default. We have processes for feature goals and there
> is upstream GNOME to have this debate with, both will get you input on the
> idea without pissing the rest of us off.
>
> I used to have the browser mode activated out of habit, but now because you
> made it your mission to spam the devel list and attack developers, I have
> changed the setting back and you know what.. I love spatial.

Good for you.
>
> - David

Then i will, especially for you, explain why i included those 2 other
lists (3 in total now)

fodora-general list
-------------------------
this list is included because this concerns the general fedora public
and to give it a more then just developer attention

fedora-devel list
-------------------------
this list is included because is where "features" for new fedora
released belong. if you want it or not this thread belongs there as
well.

gnome usability list
-------------------------
it is a setting in nautilus that i want to see with a different
default value and it affects the usability (in a positive way) for
gnome so that's why i included this list

and i had: nautilus list
-----------------------------
I first had this list included as well but somewhere it got dropped of
by someone.. don't know who or why and doesn't matter much. changes in
nautilus need to be in that list so this message does belong there as
well.

And if this pisses you off, this really valid discussion, then you
probably just need to pass it.

To all other ppl. please keep the usability list included since this
really is something they should be aware of.



From a.badger at gmail.com  Sat Dec 20 18:56:10 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 20 Dec 2008 10:56:10 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D39AD.9020705@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>	<494AD0FE.70202@gmail.com>	<494AD768.4030907@fedoraproject.org>	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>	<1229681113.3159.13863.camel@cookie.hadess.net>
	<494D39AD.9020705@gmail.com>
Message-ID: <494D3FCA.5020305@gmail.com>

Les Mikesell wrote:
> Bastien Nocera wrote:
>>
>>> Also if this isn't the way to get this in fedora then what is? this
>>> change will affect everyone and should not rely on one person but
>>> should have a solid base behind it.
>>
>> Get the defaults changed upstream.
>>
>>> In this thread there are just a few -1 posts and the rest seems to be
>>> +1 so the solid base is building up here.
>>
>> That's called a vocal minority, and is the reason why we don't have
>> votes on mailing-lists for this sort of thing.
>>
>> And if you think it's a matter of patching the package, note that for
>> any GNOME packages you'll find in Fedora for which there are patches,
>> you'll find those same patches/functionality being upstreamed.
> 
> I think there is really a better approach to this, but it doesn't mesh
> all that well with RPM capabilities.  That is, for every package or
> package group where there is more than one commonly desired
> configuration, there should be multiple configuration packages where the
> last one installed wins, conceptually similar to the way the
> caching-nameserver package is just a different configuration for bind.
> 
> Then you could have a gnome-cluttered package for people who like
> leaving trails of open windows splattered all over the screen and
> gnome-clean for people who don't.
> 
I don't think rpm packages are the right way to do this.  There might be
some interesting way to extend sabayon to be a "configuration package
tool", though.  That would be highly experimental and  is likely
something that needs some thought and some work as a separate project
for a while.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/008167b9/attachment.sig>

From jspaleta at gmail.com  Sat Dec 20 19:10:55 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 20 Dec 2008 10:10:55 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D3FCA.5020305@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
	<1229681113.3159.13863.camel@cookie.hadess.net>
	<494D39AD.9020705@gmail.com> <494D3FCA.5020305@gmail.com>
Message-ID: <604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>

2008/12/20 Toshio Kuratomi <a.badger at gmail.com>:
> I don't think rpm packages are the right way to do this.  There might be
> some interesting way to extend sabayon to be a "configuration package
> tool", though.  That would be highly experimental and  is likely
> something that needs some thought and some work as a separate project
> for a while.

Doesn't this fall under a possible spin concept?  We are talking about
config changes.
Mark's Ultimate Fix the Gnome Desktop Defaults Spin... A Fedora Remix.

-jef



From a.badger at gmail.com  Sat Dec 20 19:09:54 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 20 Dec 2008 11:09:54 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D3DB2.4000304@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
Message-ID: <494D4302.4020503@gmail.com>

Les Mikesell wrote:
> Can someone who likes (even tolerates) spatial mode describe why?  I'm
> completely baffled as to why anyone would prefer windows left open all
> over the place randomly instead of just explicitly opening ones yourself
> in places where you want them.  For me, it is _always_ extra work to
> close the unwanted windows compared to opening the ones I want.
> 

You're not concentrating on the good features of spatial, just the
annoyances.  I liked spatial on the Mac for the way it put windows for
certain folders in predictable places.  That way muscle memory could
direct you to the proper place to go.

I seldom have or had multiple windows open.  Instead, I Shift-double
click to close the previous window when opening a new one.  Except when
I need to have two windows open for copying or moving.

The speed of spatial vs browser was one of the early selling points.
When I open a folder,  I want to see the folder ASAP.  I don't know if
that has remained an issue or if it's evened out, though.

Screen real estate is precious and I don't use most of the buttons on
the browser view.  Home, reload, up, computer, search, the places menu
on the left... all extraneous.

All this said, I don't use nautilus as a file manager very often.
Unlike MacOS and Windows where the GUI is the only optimized file
manager, the shell in *NIX is very friendly for file manipulation so I
tend to use it almost exclusively.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/5570dcc8/attachment.sig>

From markg85 at gmail.com  Sat Dec 20 19:14:18 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 20:14:18 +0100
Subject: [Usability] Call for vote: Nautilus use Browser view for fedora
	11
In-Reply-To: <20081220184920.GB12458@bkor.dhs.org>
References: <1229722878.3861.0.camel@localhost.localdomain>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<20081220184920.GB12458@bkor.dhs.org>
Message-ID: <6e24a8e80812201114w6e78bd57hf4c5090769b36f7@mail.gmail.com>

On Sat, Dec 20, 2008 at 7:49 PM, Olav Vitters <olav at bkor.dhs.org> wrote:
> On Sat, Dec 20, 2008 at 07:02:26PM +0100, Mark wrote:
>> To the people reading the gnome usability list and see this for the
>> first time.. look here for the full discussion (about 150 posts):
>> http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=65669&viewmode=flat&order=ASC&start=0
> [..]
>> Now on topic.
>> Lets do a little rounding up (conclusions how i see them! correct me
>> if i'm wrong on any of them)
>>
>> 1. Somewhere in 2003 or 2004 it is decided for whatever reason to make
>> the spatial mode in nautilus and put it as the default mode. To my
>> knowledge no research is done if people even wanted that. it just got
>> pushed through there throat and they are expected to just take it in
>> not spit it out. We are now (and a lot of users back then) spitting
>> that decision out and clear that bad taste. Nearly all gnome based
>
> Please keep it constructive. Above comparison is not. You will likely
> get heated responses because of it (see also below).
>
>> distributions do the same and the people using those distributions
>> seems to be happy about the browser mode.
>
> You provide no basis for that statement.

No basis.. do i need one? Look at Ubuntu and all other distros that
provide gnome and see how much of them use the browser or spatial
mode.
>
>> 2. I always was under the impression that gnome especially was a
>> democracy but it turns out it's under dictatorship and then call it:
>> "Meritocracy" with a dictator like taste.
>
> Please don't make such loaded comparisons if you want to continue to
> post to a GNOME mailing list. See http://live.gnome.org/CodeOfConduct.
> I've read most of the thread on the Fedora mailing list. I am not
> interested in a repeat.

It's just an observation and seems to be true till this moment.
>
>> 3. Fedora has a community but when the community starts demanding
>> something (use the browser mode as default) then it turns out that the
>
> A few votes on a mailing list. This has been dismissed already.
>
>> 4. There is just ONE person here that decided to make it spatial and
>> that one person can't be convinced (Alexander Larson). Just look at
>
> That is not true.

Then give me a link where that disision is made otherwise i see it as true.
>
>> 5. I was about to open a bug report on gnome for this now but it turns
>> out there is one already:
>> http://bugzilla.gnome.org/show_bug.cgi?id=427628
>
> Just general FYI: Discussion is not appreciated on (bgo) bugreports
> (should be done elsewhere, e.g. in a mailing list), so please do not add
> comments about things that have been said before.
> The purpose of a bugreport is to discuss how the bug should be fixed
> (which in above bugreport would just be a config change).

I don't agree on that. i even saw ppl on the gnome bugzilla
(developers!) telling the other users to post it to the mailing
list(s) as well to raise awareness. And i think i did that.
>
>> 6. Convincing people.. yea possible but is FOUR (yes 4!) FREAKING
>> YEARS not proof enough that there decision was wrong. If that doesn't
>> convince them, again mainly or even only Alexander Larson, then they
>> can simply not be convinced in this subject.
>
> Baseless statement. In your mind the decision is wrong. However, you
> even haven't convinced everyone of that fact. This was already mentioned
> on the Fedora mailing list.

Not only in my mind. the majority agrees with me that browser mode
should be the default.
And to give that a base. read this full list and search on google.
>
>> 7. This is a conclusion again about the community. A few months ago
>> Max Spevack came to my school to hold a presentation about linux,
>
> I'm not sure what this has to do with usability at gnome.org. Please be
> concise.

That is true.
>
>> A very good example of the bad community direction is, to name someone
>> again, Rahul. He always points you to your mistakes (fine in a way)
>> but never adds (not in my experience) something constructive or
>> helpful.... always a link to a wiki of somekind.
>
> Take that off list (at least for anything @gnome.org).

Also true but kinda hard when cross posting.
>
>> And for this entire issue where i made this thread for in the first
>> place. Don't expect me to be silent now. I will be vocal about this.
>> fedora has a "freedom" sign in it's logo so make that a reality!
>
> Suggest to be constructive. Just vocal won't be appreciated.

I have been constructive.
That didn't help much so time to put it in a higher gear.
>
> What helps: determine what usability thought was behind the spatial
> mode. Then perform multiple real usability studies to show that for an
> unbiased person spatial mode causes more problems than browser mode.
>
I think the most you could ask of me is what was done to get spatial
in it to begin with.
They didn't seem to conduct a study so i won't do that to revert there
change. Also to conduct a study takes weeks or months and by that time
this discussion is cooled down and put in the fridge. So your actually
asking me to spend months conducting a study to just be silent here.
And so if i did a study what then?

I did do a small one on google for the "new" (in 2004) spatial feature.
I didn't intent to post a bunch of links here but i will do so now.

https://www.linuxquestions.org/questions/linux-software-2/gnome-2.6-spatial-file-manager-options-170027/
http://tweakers.net/nieuws/31799/gnome-introduceert-nieuwe-versie-26.html
(dutch and a lot are against spatial)
http://episteme.arstechnica.com/eve/ubb.x?a=tpc&s=50009562&f=174096756&m=811007643631&r=811007643631
http://osdir.com/ml/gnome.usability/2004-10/msg00026.html
and more: http://www.google.nl/search?q=gnome+2.6+spatial&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

> --
> Regards,
> Olav
>



From jspaleta at gmail.com  Sat Dec 20 19:16:39 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 20 Dec 2008 10:16:39 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
Message-ID: <604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>

On Sat, Dec 20, 2008 at 9:02 AM, Mark <markg85 at gmail.com> wrote:
> To the people reading the gnome usability list and see this for the
> first time.. look here for the full discussion (about 150 posts):
> http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=65669&viewmode=flat&order=ASC&start=0

Mark, you need to re-think your strategy of cross-posting from an
already heated discussion into a new list. You are not necessarily
helping your cause by dragging emotionality around across lists.  If
your is goal is to be sensationalistic, you will probably succeed.  If
your goal is to encourage more people in the meritocracy to listen to
you, you are probably failing.  I think you should re-think your
approach a bit, its extremely heavy handed. All you are doing by
keeping this current thread alive is hardening opinion, not changing
minds.


-jef



From markg85 at gmail.com  Sat Dec 20 19:16:40 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 20:16:40 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
	<1229681113.3159.13863.camel@cookie.hadess.net>
	<494D39AD.9020705@gmail.com> <494D3FCA.5020305@gmail.com>
	<604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>
Message-ID: <6e24a8e80812201116s19795f67y5290e13fe5d8fbaf@mail.gmail.com>

On Sat, Dec 20, 2008 at 8:10 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> 2008/12/20 Toshio Kuratomi <a.badger at gmail.com>:
>> I don't think rpm packages are the right way to do this.  There might be
>> some interesting way to extend sabayon to be a "configuration package
>> tool", though.  That would be highly experimental and  is likely
>> something that needs some thought and some work as a separate project
>> for a while.
>
> Doesn't this fall under a possible spin concept?  We are talking about
> config changes.
> Mark's Ultimate Fix the Gnome Desktop Defaults Spin... A Fedora Remix.
>
> -jef

1. post a reply or don't post at all
2. keep those other lists included plz!



From dimi at lattica.com  Sat Dec 20 19:17:00 2008
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 20 Dec 2008 14:17:00 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
Message-ID: <1229800620.23410.173.camel@dimi.lattica.com>


On Sat, 2008-12-20 at 00:00 -0900, Jeff Spaleta wrote:
> You have to crawl inside the heads of the people whose minds you are
> looking to change, and think like them.

I thought we can get away from silly politics in a technically oriented
list.

Look Jeff, you are right that there were snide comments on each side.
But the pro-change people produced pretty good arguments for change:
  1. both Windows and MacOS (between them they cover something like 95%
     of computer users) use browser mode. These companies have done
     extensive UI studies which we can't afford.
  2. like it or not, (1) + the Principle of least surprise it follows
     that we shouldn't change from expected behavior lightly.
  3. all other major Linux distros (Ubuntu & Suse) use spacial, so
     what kind of meaning is there left in "upstream"?
  4. the change was initially pushed without any consideration to
     people preferences & expected behavior. If held to the same
     standards, it should have never been implemented.
  5. Google for "Ubuntu change nautilus to spatial mode" vs.
     "Fedora change nautilus to browser mode". In the first case,
     you get about 3500 hits (mostly of people _complaining_ about
     spatial mode), whereas in the second case you get over 10000
     hits for people trying to change to browser mode, complaining
     about spatial, or trying to vote for change.

Where there _any_ decent arguments for spatial? No, other than
a few people saying they like it, and plenty of suggestions for
going on wild goose chases. Thanks, but no thanks.

If the community can not have input even in clear-cut scenarios
like this one, you have to understand that people will feel 
frustrated and disappointed. Sad.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From a.badger at gmail.com  Sat Dec 20 19:21:28 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 20 Dec 2008 11:21:28 -0800
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229787602.4136.6.camel@hughsie-work.lan>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>	<1229770470.5584.1.camel@hughsie-work.lan>	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
Message-ID: <494D45B8.7050806@gmail.com>

Richard Hughes wrote:
> On Sat, 2008-12-20 at 14:13 +0100, Nicolas Mailhot wrote:
>> Le samedi 20 d?cembre 2008 ? 10:54 +0000, Richard Hughes a ?crit :
>>> On Sat, 2008-12-20 at 10:45 +0000, Rawhide Report wrote:
>>>> fontpackages-1.12-1.fc11
>>>> ------------------------
>>>> * Fri Dec 19 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
>>>> - 1.12-1
>>>> ? Add another macro to allow building fontconfig without cycling
>>> Please stop doing this. Just use "*" or "-" like everyone else. Adding
>>> these UTF8 characters adds no value whatsoever.
>> This part of the changelog is in the official freeform UTF-8 plain text
>> format. It seems to work in all our tools including this release update
>> noitification bot.
> 
> Right. There's lots of things that work, if you do them wrong:
> 
> (&&^*&^(*&^(*&^(*&^(*&^(*&^(*&^(*&^*&^(*&^&^%^%$%^$$^%$^%$^(*&^(*^
> (*) update to latest upstream
> (*&(*)(*&)(*&*&(^^%)(*_(*_(*&)*&(*&^&^%(*)_(*)(^%%^%&^%$$%?$?"^$&^
> 
> Spec file ChangeLogs are not free-form text.
> 
> I've got no problem with UTF-8. I just don't think you should be
> masturbating over the fact you can do special bullets.
> 
>> If you disagree with the current rules, ask FPC and FESCO to change
>> them. Please stop trying to change the distribution packaging rules
>> without going through the instances appointed to regulate them.
> 
> No, if you are unhappy with using "- " and want to make all spec file
> authors to use your UTF8 symbols, YOU need to ask FESCO.
> 
> Please, just stick to what everyone else is doing. At the moment it's
> just you that's being difficult.
> 
Yes, Nicolas is being difficult.

But he is correct that the ChangeLog has freeform text after the header.
 So his assertion that forcing packagers to conform to certain symbols
for lists would have to come via a Guideline change is also correct.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/28c05e6d/attachment.sig>

From jkeating at redhat.com  Sat Dec 20 19:25:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Dec 2008 11:25:25 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
	<1229681113.3159.13863.camel@cookie.hadess.net>
	<494D39AD.9020705@gmail.com> <494D3FCA.5020305@gmail.com>
	<604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>
Message-ID: <1229801125.3861.12.camel@localhost.localdomain>

On Sat, 2008-12-20 at 10:10 -0900, Jeff Spaleta wrote:
> 
> Doesn't this fall under a possible spin concept?  We are talking about
> config changes.
> Mark's Ultimate Fix the Gnome Desktop Defaults Spin... A Fedora Remix.

The question is what happens to the configs upon upgrade of the rpm?
Does it result in a .rpmnew file, does it result in reverted configs to
Fedora's default?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/f8b8add4/attachment.sig>

From cmadams at hiwaay.net  Sat Dec 20 19:25:38 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 20 Dec 2008 13:25:38 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229800620.23410.173.camel@dimi.lattica.com>
References: <1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
Message-ID: <20081220192538.GA1126040@hiwaay.net>

Once upon a time, Dimi Paun <dimi at lattica.com> said:
>   1. both Windows and MacOS (between them they cover something like 95%
>      of computer users) use browser mode. These companies have done
>      extensive UI studies which we can't afford.

And yet, they have different UIs.  If market share + money = best, then
we should all be using Vista and IE.  The goal is not to copy Windows,
so that's not a technical argument.  Other people do usability studies
as well.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From nicolas.mailhot at laposte.net  Sat Dec 20 19:26:11 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 20 Dec 2008 20:26:11 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <20081220180913.45f62880@lain.camperquake.de>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
	<1229788642.16655.12.camel@arekh.okg>
	<20081220180913.45f62880@lain.camperquake.de>
Message-ID: <1229801171.24251.19.camel@arekh.okg>

Le samedi 20 d?cembre 2008 ? 18:09 +0100, Ralf Ertzinger a ?crit :
> Hi.
> 
> On Sat, 20 Dec 2008 16:57:22 +0100, Nicolas Mailhot wrote
> 
> > If making it plain what the current official encoding and format of
> > spec files is is being difficult, yes I'm being difficult.
> 
> So this is 'We do what we must, because we can', kind of?

It's a case of ?if your application can not handle my conformant file
that's you application problem not mine?.

It's also a case of ?if your application can not handle my UTF-8 it
won't handle someone else's UTF-8, and I didn't spend all this time
working on Fedora i18n support to help you do that?.

Furthermore, it's a case of ?FESCO decides what conformant means in
Fedora, if you want to change Fedora rules you have to go before FESCO?.

And lastly, it's a case of ?I don't take intimidation or bullying well?,
?I don't appreciate of being told I don't know Fedora guidelines when I
spent many hours (today included) improving them?, ?I don't like seing
the valuable experience I gained going through text bugs summarily
dismissed? and ?I'm tired of being ignored when I ask for some stuff to
be resolved FESCO-side so I'll do some ignoring in my turn?.

Is this sufficient for you?

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/50c8175c/attachment.sig>

From lesmikesell at gmail.com  Sat Dec 20 19:27:13 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 13:27:13 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D3FCA.5020305@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>	<494AD0FE.70202@gmail.com>	<494AD768.4030907@fedoraproject.org>	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>	<1229681113.3159.13863.camel@cookie.hadess.net>	<494D39AD.9020705@gmail.com>
	<494D3FCA.5020305@gmail.com>
Message-ID: <494D4711.8010404@gmail.com>

Toshio Kuratomi wrote:
>
>>>
>>> And if you think it's a matter of patching the package, note that for
>>> any GNOME packages you'll find in Fedora for which there are patches,
>>> you'll find those same patches/functionality being upstreamed.
>> I think there is really a better approach to this, but it doesn't mesh
>> all that well with RPM capabilities.  That is, for every package or
>> package group where there is more than one commonly desired
>> configuration, there should be multiple configuration packages where the
>> last one installed wins, conceptually similar to the way the
>> caching-nameserver package is just a different configuration for bind.
>>
>> Then you could have a gnome-cluttered package for people who like
>> leaving trails of open windows splattered all over the screen and
>> gnome-clean for people who don't.
>>
> I don't think rpm packages are the right way to do this.  There might be
> some interesting way to extend sabayon to be a "configuration package
> tool", though.  That would be highly experimental and  is likely
> something that needs some thought and some work as a separate project
> for a while.

The point is that an end user shouldn't need to know the difference, or 
that certain configuration settings come included in certain RPMs and 
are somehow magical compared to other settings.  I think it is somewhat 
of a mistake to embed them with programs in the first place and it would 
be much cleaner to install the configurations as the actual package (and 
the one you know about) with the necessary programs pulled in as 
dependencies.  Pre-yum, this would have been a nightmare, but now it 
would make perfect sense to have descriptively-named configuration 
packages with many alternatives that pull in whatever programs might be 
needed and installs the configuration you want, regardless of how 
upstream or anyone else felt about the defaults.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From markg85 at gmail.com  Sat Dec 20 19:28:27 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 20:28:27 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
Message-ID: <6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>

On Sat, Dec 20, 2008 at 8:16 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Sat, Dec 20, 2008 at 9:02 AM, Mark <markg85 at gmail.com> wrote:
>> To the people reading the gnome usability list and see this for the
>> first time.. look here for the full discussion (about 150 posts):
>> http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=65669&viewmode=flat&order=ASC&start=0
>
> Mark, you need to re-think your strategy of cross-posting from an
> already heated discussion into a new list. You are not necessarily
> helping your cause by dragging emotionality around across lists.  If
> your is goal is to be sensationalistic, you will probably succeed.  If
> your goal is to encourage more people in the meritocracy to listen to
> you, you are probably failing.  I think you should re-think your
> approach a bit, its extremely heavy handed. All you are doing by
> keeping this current thread alive is hardening opinion, not changing
> minds.
>
>
> -jef

What do you expect of me?
I started nice and what did i get in return: "we don't vote here" and
there is no other way to get the word out.

To remember how i started:

On Thu, Dec 18, 2008 at 9:56 PM, Mark <markg85 at gmail.com> wrote:
> Hey,
>
> The question is simple:
> Lets use the browser view of nautilus in the next fedora release.
>
> Motivation:
> A new window for each folder that i open is so painful!!
> 1. My taskbar fills up in notime each time i open a new folder
> 2. New features of nautilus: tabbed browsing! completely useless if
> your not using the browser mode
> 3. Tabbed browsing (files/folders or web) is "hot" these days
> 4. It feels so.. old (windows 95? 3.11?)
> just to name a few
>
> Cross posted to the devel list because it's for the next fedora
> version (currently in development thus the devel list)
>
> Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=477052 (wow! i
> couldn't find an existing one for this! made one myself)
>
> So, lets vote:
>
> +1 from me
>
> I hope this can be done for Fedora 11 (it's just changing one gconf value).
> All vote plz
>
> Mark.
>

I didn't start emotional.. to be honest.. i'm not emotional at all
about this issue. just a little irritated by how easy spatial got in
and how hard it is to get out.

And i seem to be on the moderation list now from gnome's usability..
that's what happens when you try to improve something with the best
intentions.



From tmz at pobox.com  Sat Dec 20 19:35:56 2008
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 20 Dec 2008 14:35:56 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>
References: <494ABC3F.8000700@fedoraproject.org>
	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>
	<494AC569.8070401@fedoraproject.org> <494AD0FE.70202@gmail.com>
	<494AD768.4030907@fedoraproject.org>
	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
	<1229681113.3159.13863.camel@cookie.hadess.net>
	<494D39AD.9020705@gmail.com> <494D3FCA.5020305@gmail.com>
	<604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>
Message-ID: <20081220193556.GZ12325@inocybe.teonanacatl.org>

Jeff Spaleta wrote:
> 2008/12/20 Toshio Kuratomi <a.badger at gmail.com>:
>> I don't think rpm packages are the right way to do this.  There
>> might be some interesting way to extend sabayon to be a
>> "configuration package tool", though.  That would be highly
>> experimental and  is likely something that needs some thought and
>> some work as a separate project for a while.
> 
> Doesn't this fall under a possible spin concept?  We are talking
> about config changes.

Well, what comes to my mind when I read Toshio's idea is to
essentially create profiles (whether using sabayon or whatever).  Then
you wouldn't have any need to have conflicting config file packages.
The profiles would be installed where they are typically installed for
sabayon (I think that's in /etc/sabayon, though it's been a while
since I played with that).  Then, you could create users with specific
profiles.

(But I certainly don't care enough about the default desktop prefs to
worry about it.  I use coreutils as my file manager. ;)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The man who can make hard things easy is the educator
    -- Ralph Waldo Emerson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/04bbb1a5/attachment.sig>

From lesmikesell at gmail.com  Sat Dec 20 19:39:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 13:39:02 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D4302.4020503@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>	<494D3DB2.4000304@gmail.com>
	<494D4302.4020503@gmail.com>
Message-ID: <494D49D6.20302@gmail.com>

Toshio Kuratomi wrote:
> 
>> Can someone who likes (even tolerates) spatial mode describe why?  I'm
>> completely baffled as to why anyone would prefer windows left open all
>> over the place randomly instead of just explicitly opening ones yourself
>> in places where you want them.  For me, it is _always_ extra work to
>> close the unwanted windows compared to opening the ones I want.
>>
> 
> You're not concentrating on the good features of spatial, just the
> annoyances.  I liked spatial on the Mac for the way it put windows for
> certain folders in predictable places.  That way muscle memory could
> direct you to the proper place to go.

How is positioning unique to spatial?  I open windows and put them where 
I want them.  I almost never reboot my mac, so they remain where I left 
them.

> I seldom have or had multiple windows open.  Instead, I Shift-double
> click to close the previous window when opening a new one.  Except when
> I need to have two windows open for copying or moving.

That just sounds horrible to me.  Shift-double-click as the most common 
action?

> The speed of spatial vs browser was one of the early selling points.
> When I open a folder,  I want to see the folder ASAP.  I don't know if
> that has remained an issue or if it's evened out, though.

I don't even understand this concept.

> Screen real estate is precious and I don't use most of the buttons on
> the browser view.  Home, reload, up, computer, search, the places menu
> on the left... all extraneous.

OK, that's a separate issue.

> All this said, I don't use nautilus as a file manager very often.
> Unlike MacOS and Windows where the GUI is the only optimized file
> manager, the shell in *NIX is very friendly for file manipulation so I
> tend to use it almost exclusively.

Same here but would like a friendly visual navigation (i.e. not 
requiring contortions to avoid opening extraneous windows) followed by a 
simple operation to "open terminal window with it's working directory here".

-- 
   Les Mikesell
     lesmikesell at gmail.com




From jkeating at redhat.com  Sat Dec 20 19:39:19 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Dec 2008 11:39:19 -0800
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <20081220121718.GC2506@free.fr>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr> <20081219194825.GA16284@bludgeon.org>
	<494BFECE.4050003@gmail.com> <20081220004829.GB10679@free.fr>
	<494CC439.4070503@gmail.com>  <20081220121718.GC2506@free.fr>
Message-ID: <1229801959.3861.13.camel@localhost.localdomain>

On Sat, 2008-12-20 at 13:17 +0100, Patrice Dumas wrote:
> 
> 
> Once again when FESCo approve policy changes or new policies FESCo
> people should make sure that the changes are documented.

Given how huge the wiki is, FESCo needs help in identifying places that
need changing.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/b36e874b/attachment.sig>

From jspaleta at gmail.com  Sat Dec 20 19:39:13 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 20 Dec 2008 10:39:13 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229800620.23410.173.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
Message-ID: <604aa7910812201139o76a79192ga0eeec425cc2d03b@mail.gmail.com>

On Sat, Dec 20, 2008 at 10:17 AM, Dimi Paun <dimi at lattica.com> wrote:
> Look Jeff, you are right that there were snide comments on each side.
> But the pro-change people produced pretty good arguments for change:

Good "persuasive" arguments come down to knowing what the priorities
of the people you are trying to persuade are.

>  1. both Windows and MacOS (between them they cover something like 95%
>     of computer users) use browser mode. These companies have done
>     extensive UI studies which we can't afford.
>  2. like it or not, (1) + the Principle of least surprise it follows
>     that we shouldn't change from expected behavior lightly.
>  3. all other major Linux distros (Ubuntu & Suse) use spacial, so
>     what kind of meaning is there left in "upstream"?
>  4. the change was initially pushed without any consideration to
>     people preferences & expected behavior. If held to the same
>     standards, it should have never been implemented.

If you were paying attention to the talk coming out of GNOME about the
usability hackfest they had, you would know this isn't a persuasive
argument.  There has been a lot of chatter about significantly
changing the desktop interface away from traditional usage patterns.
If you have problems with spatial, I dare say that the gnome shell
concept will in fact melt your mind.



>  5. Google for "Ubuntu change nautilus to spatial mode" vs.
>     "Fedora change nautilus to browser mode". In the first case,
>     you get about 3500 hits (mostly of people _complaining_ about
>     spatial mode), whereas in the second case you get over 10000
>     hits for people trying to change to browser mode, complaining
>     about spatial, or trying to vote for change.

I do not believe in Google trending as a valid way to do statistically
viable population sampling.  I'm still looking for a peer reviewed
scientific journal article
which attempts to validate this technique.  I'm not a fan of psuedo-science.

>
> Where there _any_ decent arguments for spatial? No, other than
> a few people saying they like it, and plenty of suggestions for
> going on wild goose chases. Thanks, but no thanks.
>
> If the community can not have input even in clear-cut scenarios
> like this one, you have to understand that people will feel
> frustrated and disappointed. Sad.

Feel frustrated. Feel disappointed. Such things are your right as an
irrational human being. Just as the developers are going to feel
frustration and disappointment and how Mark as the leading proponent
of change is handling this with his cross-posting and what not.  We
are way way way past constructive discussion.  We were way past
constructive discussion the moment Mark posted asking for a vote.

-jef



From jspaleta at gmail.com  Sat Dec 20 19:41:30 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 20 Dec 2008 10:41:30 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
Message-ID: <604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>

On Sat, Dec 20, 2008 at 10:28 AM, Mark <markg85 at gmail.com> wrote:
> What do you expect of me?
> I started nice and what did i get in return: "we don't vote here" and
> there is no other way to get the word out.

No mark you didn't start nice.  You started out demanding a vote in
order to coerce a change. Demanding a vote is not a nice way to hold a
discussion. Votes in the real world of democratic town meetings and
representative state legislatures, are what happens at the end of
discussions.  Votes stop discussion in the real world.  By starting
this thread with a vote, you implied that discussion was in fact not
what you wanted.

-jef



From lesmikesell at gmail.com  Sat Dec 20 19:42:42 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 13:42:42 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<494AD0FE.70202@gmail.com>	<494AD768.4030907@fedoraproject.org>	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>	<1229681113.3159.13863.camel@cookie.hadess.net>	<494D39AD.9020705@gmail.com>
	<494D3FCA.5020305@gmail.com>
	<604aa7910812201110k16870a53q6df80afe2366c59@mail.gmail.com>
Message-ID: <494D4AB2.30705@gmail.com>

Jeff Spaleta wrote:
> 2008/12/20 Toshio Kuratomi <a.badger at gmail.com>:
>> I don't think rpm packages are the right way to do this.  There might be
>> some interesting way to extend sabayon to be a "configuration package
>> tool", though.  That would be highly experimental and  is likely
>> something that needs some thought and some work as a separate project
>> for a while.
> 
> Doesn't this fall under a possible spin concept?  We are talking about
> config changes.
> Mark's Ultimate Fix the Gnome Desktop Defaults Spin... A Fedora Remix.

I think it should replace the concept of spins.  That is, the 
configuration is the important part and should be the main package you 
install.  The programs necessary to run that configuration should just 
be dependencies that any configuration can pull in.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From lesmikesell at gmail.com  Sat Dec 20 19:45:38 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 13:45:38 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081220192538.GA1126040@hiwaay.net>
References: <1229722878.3861.0.camel@localhost.localdomain>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<1229800620.23410.173.camel@dimi.lattica.com>
	<20081220192538.GA1126040@hiwaay.net>
Message-ID: <494D4B62.10008@gmail.com>

Chris Adams wrote:
> Once upon a time, Dimi Paun <dimi at lattica.com> said:
>>   1. both Windows and MacOS (between them they cover something like 95%
>>      of computer users) use browser mode. These companies have done
>>      extensive UI studies which we can't afford.
> 
> And yet, they have different UIs.  If market share + money = best, then
> we should all be using Vista and IE.  The goal is not to copy Windows,
> so that's not a technical argument.  Other people do usability studies
> as well.

Can you name one that concluded that splattering windows all over the 
place for every directory you visit was a reasonable thing to do?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Dec 20 19:50:03 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 13:50:03 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201050j2f2126b4x4472606058b2c6e@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<6e24a8e80812201050j2f2126b4x4472606058b2c6e@mail.gmail.com>
Message-ID: <494D4C6B.7090604@gmail.com>

Mark wrote:
>> 
> To all other ppl. please keep the usability list included since this
> really is something they should be aware of.
> 

Keep in mind that cross-posting to multiple lists sucks for everyone who 
is not a member of all of them because they'll get bounces pointing that 
out, and there's a fair chance that they won't get moderator approval 
and ever appear.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From cmadams at hiwaay.net  Sat Dec 20 19:52:16 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 20 Dec 2008 13:52:16 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D4B62.10008@gmail.com>
References: <1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
	<20081220192538.GA1126040@hiwaay.net> <494D4B62.10008@gmail.com>
Message-ID: <20081220195216.GB632403@hiwaay.net>

Once upon a time, Les Mikesell <lesmikesell at gmail.com> said:
> Can you name one that concluded that splattering windows all over the 
> place for every directory you visit was a reasonable thing to do?

You seem to have confused me with someone who cares which way this is
set (I use xterm, ls, cp, and mv as my "file manager").

In any case, the current value is already there, so changing it would
require showing why the proposed change is better.

Someone said that Nautilus in browser mode supports tabs now, which
might be a legitimate improvement.  However, tabs are useless for
drag-n-drop, so that doesn't improve over spatial mode.

Personally, when I've used a GUI file manager, I preferred the Windows
Explorer mode with two panes: left hand side is directories and right
hand side is selected directory.  You can chose one directory and drag
things from it to another directory, without having to have two (or
more) windows open.

I am in general against "change for the sake of change", "I'm louder so
listen to me", and "a bunch of +1 == the way it should be".
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From markg85 at gmail.com  Sat Dec 20 19:53:14 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 20:53:14 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
Message-ID: <6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>

On Sat, Dec 20, 2008 at 8:41 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Sat, Dec 20, 2008 at 10:28 AM, Mark <markg85 at gmail.com> wrote:
>> What do you expect of me?
>> I started nice and what did i get in return: "we don't vote here" and
>> there is no other way to get the word out.
>
> No mark you didn't start nice.  You started out demanding a vote in
> order to coerce a change. Demanding a vote is not a nice way to hold a
> discussion. Votes in the real world of democratic town meetings and
> representative state legislatures, are what happens at the end of
> discussions.  Votes stop discussion in the real world.  By starting
> this thread with a vote, you implied that discussion was in fact not
> what you wanted.
>
> -jef

Now that you say it like that you might be right.
However my post was not with the intention to demand a vote.. just
to.. vote how you liked it.

Btw your idea of "my spin idea" might very well be true ^_^ it's just
that it sucks up so much time which i don't want to spend at it.



From zdzichu at antracis.fordon.pl.eu.org  Sat Dec 20 19:37:55 2008
From: zdzichu at antracis.fordon.pl.eu.org (Tomasz Torcz)
Date: Sat, 20 Dec 2008 20:37:55 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D3DB2.4000304@gmail.com>
References: <1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
Message-ID: <20081220193755.GB7015@irc.pl>

On Sat, Dec 20, 2008 at 12:47:14PM -0600, Les Mikesell wrote:
> Can someone who likes (even tolerates) spatial mode describe why?  I'm 
> completely baffled as to why anyone would prefer windows left open all over 
> the place randomly instead of just explicitly opening ones yourself in 
> places where you want them.  For me, it is _always_ extra work to close the 
> unwanted windows compared to opening the ones I want.


  Let me chime in. I love spatial mode. Because every folder has its
place and size. I know that when I open my Movies folder it will appear
in upper-left part of screen. When I open my NAS share, it will open at
the bottom. When I open my PDF dir it will be at the right place on
screen, and will be scrolled down to position when I finished last time.
When I open my photos folder, it will have List View activated. That's
what spatial is about -- keepin each folder size and position.

  The second part of your question is pure FUD. When I open new window
and don't want parent directory open, I just open with middle button.
Some people prefer Shift+click in this situation. I never has to use
"Close all parent folder" (ctrl-shift-w), but I aware it exist.
  And my middle button is between left and right button. On my laptop.

-- 
Tomasz Torcz                        To co nierealne -- tutaj jest normalne.
zdzichu at irc.-nie.spam-.pl          Ziomale na ?ycie maj? tu patenty specjalne.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 237 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/b850d2db/attachment.sig>

From markg85 at gmail.com  Sat Dec 20 19:56:59 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 20:56:59 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D4C6B.7090604@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<6e24a8e80812201050j2f2126b4x4472606058b2c6e@mail.gmail.com>
	<494D4C6B.7090604@gmail.com>
Message-ID: <6e24a8e80812201156m3cea135fv29a8a9763b9508c@mail.gmail.com>

On Sat, Dec 20, 2008 at 8:50 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Mark wrote:
>>>
>> To all other ppl. please keep the usability list included since this
>> really is something they should be aware of.
>>
>
> Keep in mind that cross-posting to multiple lists sucks for everyone who is
> not a member of all of them because they'll get bounces pointing that out,
> and there's a fair chance that they won't get moderator approval and ever
> appear.

True. and they are apparently afraid that my idea gets through because
i have been put on moderation.
feel free to do whatever you think is right. at this moment i'm sick of gnome.



From mclasen at redhat.com  Sat Dec 20 19:57:23 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 20 Dec 2008 14:57:23 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
Message-ID: <1229803043.4026.8.camel@matthiasc>

On Sat, 2008-12-20 at 20:53 +0100, Mark wrote:

> Btw your idea of "my spin idea" might very well be true ^_^ it's just
> that it sucks up so much time which i don't want to spend at it.
> 

Creating a sabayon profile with your favourite changes and storing it
away in some safe place would take ~10 minutes (including the time to
install sabayon). The time and energy you have invested in this thread
by now probably measures in days...



From markg85 at gmail.com  Sat Dec 20 20:05:17 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 21:05:17 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229803043.4026.8.camel@matthiasc>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
	<1229803043.4026.8.camel@matthiasc>
Message-ID: <6e24a8e80812201205k34093d85v8c6fc5814c5ce825@mail.gmail.com>

On Sat, Dec 20, 2008 at 8:57 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> On Sat, 2008-12-20 at 20:53 +0100, Mark wrote:
>
>> Btw your idea of "my spin idea" might very well be true ^_^ it's just
>> that it sucks up so much time which i don't want to spend at it.
>>
>
> Creating a sabayon profile with your favourite changes and storing it
> away in some safe place would take ~10 minutes (including the time to
> install sabayon). The time and energy you have invested in this thread
> by now probably measures in days...

not really.
It requires me to: download sabyon, install it, figure out in detail
how the profile stuff works and if that fits my needs and it's not
using the RPM package system. I might not agree with all of fedora and
might find ubuntu better then fedora but i find RPM so much easyer
then debs if you make want to edit existing rpm's and that's why i
keep coming back to fedora.



From mjc at avtechpulse.com  Sat Dec 20 20:17:48 2008
From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak)
Date: Sat, 20 Dec 2008 15:17:48 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229722878.3861.0.camel@localhost.localdomain>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
Message-ID: <494D52EC.7090804@avtechpulse.com>

> 2. I always was under the impression that gnome especially was a
> democracy but it turns out it's under dictatorship and then call it:
> "Meritocracy" with a dictator like taste.

No, gnome is not a democracy at all, and does not claim to be. The 
individual module maintainers basically have total control over their 
modules. They can accept or reject patches and ideas. You can call that 
benevolent dictatorship if you like.

Maintainers become maintainers by doing the bulk of the hard coding work.

The Gnome Foundation board is elected, but the foundation does not aim 
to tell what the developers to do. It provides logistics, support, and 
advocacy.

Just dispelling some notions...

Personally, I don't like the spatial view either... or the fact that I 
can't rename a file from within the filechooser...

Some of my patches are accepted. Some are rejected. C'est la vie.

- Mike



From jspaleta at gmail.com  Sat Dec 20 20:24:47 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 20 Dec 2008 11:24:47 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
Message-ID: <604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>

On Sat, Dec 20, 2008 at 10:53 AM, Mark <markg85 at gmail.com> wrote:
> Now that you say it like that you might be right.

I'm always right.  That has never been the problem for me. Its just
one of those inherent truths of the universe.
But you know what, its not enough for me to be right all the time.
The skill I've had to learn over time is how to persuade other people,
I'm still learning.  It's a trick you should probably invest some time
thinking about developing.

> However my post was not with the intention to demand a vote.. just
> to.. vote how you liked it.

Yes, your actual intention was probably not the intention people read
into your actions.  The same could be said for people on the other
side.  Noone has figured out how to write a markup language for human
intention...and as a result any passionate discussion degrades
severely as we are wired to read intention but without body language
and vocal ques...we absolutely do it wrong when relying solely on
written language. Even more so with English! If we mandated everyone
encode thought into Lisp we'd be having more constructive discussions
(and less of them). The productivity of the list would be through the
roof.

> Btw your idea of "my spin idea" might very well be true ^_^ it's just
> that it sucks up so much time which i don't want to spend at it.

That's a copout excuse.  You are spending a lot of time right now
beating your head on the brick wall on this issue.  Figuring out a
technical solution in the form of a LiveCD under the umbrella of the
GNOME project might actually be the better argument than what you are
doing now.


-jef



From metherid at gmail.com  Sat Dec 20 20:28:27 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Sun, 21 Dec 2008 01:58:27 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229722878.3861.0.camel@localhost.localdomain>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
Message-ID: <494D556B.9080807@gmail.com>

Mark wrote:
> 2. I always was under the impression that gnome especially was a
> democracy but it turns out it's under dictatorship and then call it:
> "Meritocracy" with a dictator like taste.
>   
I have yet to see any Free and open source project work like a 
democracy. There might be some democratic aspects to portions of the 
projects but generally, who does the work gets to decide how things are 
done.  If Linus, says no, it doesn't get into the Linux kernel. Period.  
No voting either. You have the full freedom to fork and convince others 
to adopt it but then again, that would require actual work to be done.
> 3. Fedora has a community but when the community starts demanding
> something (use the browser mode as default) then it turns out that the
> actual fedora community, the ones that are helping to make fedora
> "better", are just a hand full of people. 
A entire distribution full of free and open source software is given to 
you at no cost with the all the freedom to modify and redistribute the 
result.
I think it is more appropriate , to do less of "demanding" and more of 
engaging in a discussion. People don't like being forced but they 
generally prefer more participation.
> What i or any other community member says is simply being ignored. WE,
> the community want this feature to change and i'm not going to be
> silent about it! 
A community is inclusive of all its participants, developers and users 
included.  Finding consensus in a diverse community is a hard thing.  As 
seen in this thread, there is no one opinion that is representative of a 
community.  In Fedora, developers engage in a discussion or a debate,  
sometimes a heated one but voting isn't a real discussion. It doesn't 
show WHY people are for or against something which makes it much more 
harder to make a decision either way.  The why is important, perhaps 
more important than gross number count. If you don't agree to me, you 
don't listen to the community is a often repeated thing but isn't a 
valid statement. 

> A very good example of the bad community direction is, to name someone
> again, Rahul. He always points you to your mistakes (fine in a way)
> but never adds (not in my experience) something constructive or
> helpful.... always a link to a wiki of somekind.
>   
Even in my first mail I did point out other things you could have done 
to be more effective. I try to be helpful and give you more references 
instead of repeating the same things over and over again. That is one of 
the reasons, I prefer to document things when questions come up 
frequently on something or the other.  I am pretty sure, that is more 
helpful than your approach but you seem to have penchant to convert this 
into a emotional personal fight instead of just a technical debate.
> And for this entire issue where i made this thread for in the firste 
> place. Don't expect me to be silent now. I will be vocal about this.
> fedora has a "freedom" sign 
Being vocal  (and cross posting to increasing more mailing lists) 
doesn't really change anything. Freedom is not anarchy. There are always 
rules about how things are done within any community.
You do have the full freedom given by the project to do your own thing. 
I even encourage you to do it. If you are really successful, that would 
be a valid statement of your own viewpoints and will help others 
reconsider their current opinions as well.  The current strategy doesn't 
seem to work very well.

Rahul



From markg85 at gmail.com  Sat Dec 20 20:31:03 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 21:31:03 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
	<604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
Message-ID: <6e24a8e80812201231t5470c7e4hf5d49aac408b63@mail.gmail.com>

On Sat, Dec 20, 2008 at 9:24 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Sat, Dec 20, 2008 at 10:53 AM, Mark <markg85 at gmail.com> wrote:
>> Now that you say it like that you might be right.
>
> I'm always right.  That has never been the problem for me. Its just
> one of those inherent truths of the universe.

don't get over confidence now

> But you know what, its not enough for me to be right all the time.
> The skill I've had to learn over time is how to persuade other people,
> I'm still learning.  It's a trick you should probably invest some time
> thinking about developing.

... if i sometime want that i will contact you oke?
>
>> However my post was not with the intention to demand a vote.. just
>> to.. vote how you liked it.
>
> Yes, your actual intention was probably not the intention people read
> into your actions.  The same could be said for people on the other
> side.  Noone has figured out how to write a markup language for human
> intention...and as a result any passionate discussion degrades
> severely as we are wired to read intention but without body language
> and vocal ques...we absolutely do it wrong when relying solely on
> written language. Even more so with English! If we mandated everyone
> encode thought into Lisp we'd be having more constructive discussions
> (and less of them). The productivity of the list would be through the
> roof.

... i think i agree ...
>
>> Btw your idea of "my spin idea" might very well be true ^_^ it's just
>> that it sucks up so much time which i don't want to spend at it.
>
> That's a copout excuse.  You are spending a lot of time right now
> beating your head on the brick wall on this issue.  Figuring out a
> technical solution in the form of a LiveCD under the umbrella of the
> GNOME project might actually be the better argument than what you are
> doing now.

not an excuse just a fact. besides that fact i just need to use fedora
with a project of mine.



From lesmikesell at gmail.com  Sat Dec 20 20:32:12 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 14:32:12 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081220195216.GB632403@hiwaay.net>
References: <1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<1229800620.23410.173.camel@dimi.lattica.com>	<20081220192538.GA1126040@hiwaay.net>
	<494D4B62.10008@gmail.com> <20081220195216.GB632403@hiwaay.net>
Message-ID: <494D564C.7070701@gmail.com>

Chris Adams wrote:
> Once upon a time, Les Mikesell <lesmikesell at gmail.com> said:
>> Can you name one that concluded that splattering windows all over the 
>> place for every directory you visit was a reasonable thing to do?
> 
> You seem to have confused me with someone who cares which way this is
> set (I use xterm, ls, cp, and mv as my "file manager").
> 
> In any case, the current value is already there, so changing it would
> require showing why the proposed change is better.

Huh?  Why has that suddenly become the case when it wasn't when the 
change the other direction was made?

> Someone said that Nautilus in browser mode supports tabs now, which
> might be a legitimate improvement.  However, tabs are useless for
> drag-n-drop, so that doesn't improve over spatial mode.

I hate tabs in general unless they have tear-off mode because I 
inevitably want to see two instances side by side and I can't.  Besides, 
the window manager can collapse all your your instances into one task 
bar item that pops up to let you pick among them like tabs anyway.  Why 
should other applications need to duplicate that functionality?

> Personally, when I've used a GUI file manager, I preferred the Windows
> Explorer mode with two panes: left hand side is directories and right
> hand side is selected directory.  You can chose one directory and drag
> things from it to another directory, without having to have two (or
> more) windows open.

Or, if you do want two windows open for this operation (for when the 
directories don't have a common parent), just open another window...

> I am in general against "change for the sake of change", "I'm louder so
> listen to me", and "a bunch of +1 == the way it should be".

I think many people are still outraged that the change to the current 
default was an unjustified "change for the sake of change".  And in my 
case it is still an unexpected shock because I regularly jump around 
among different OS's.

-- 
   Les Mikesell
      lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Dec 20 20:34:16 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 14:34:16 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229803043.4026.8.camel@matthiasc>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
	<1229803043.4026.8.camel@matthiasc>
Message-ID: <494D56C8.8020109@gmail.com>

Matthias Clasen wrote:
> On Sat, 2008-12-20 at 20:53 +0100, Mark wrote:
> 
>> Btw your idea of "my spin idea" might very well be true ^_^ it's just
>> that it sucks up so much time which i don't want to spend at it.
>>
> 
> Creating a sabayon profile with your favourite changes and storing it
> away in some safe place would take ~10 minutes (including the time to
> install sabayon). The time and energy you have invested in this thread
> by now probably measures in days...

Does sabayon allow publishing a profile so people could share their choices?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Dec 20 20:38:33 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 14:38:33 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
	<604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
Message-ID: <494D57C9.5090809@gmail.com>

Jeff Spaleta wrote:
> 
> That's a copout excuse.  You are spending a lot of time right now
> beating your head on the brick wall on this issue.  Figuring out a
> technical solution in the form of a LiveCD under the umbrella of the
> GNOME project might actually be the better argument than what you are
> doing now.

Is there a fixed policy on how fedora must relate to upstream packages? 
  That is, do you have a requirement to take every default that the 
upstream has (themes, etc.)?  Or can any packager make any whimsical 
change he wants at any time?  Or something in between?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin at scrye.com  Sat Dec 20 20:39:55 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 20 Dec 2008 13:39:55 -0700
Subject: On mass renames
In-Reply-To: <1229629223.13577.11.camel@arekh.okg>
References: <1229629223.13577.11.camel@arekh.okg>
Message-ID: <20081220133955.70468d7e@ohm.scrye.com>

On Thu, 18 Dec 2008 20:40:23 +0100
Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:

> 
> Sometimes, it is necessary to perform a mass rename to bring some
> consistency to a class of packages.

Yeah, after a guideline change or a mass change upstream. ;( 

> In that case any workflow that proceeds package by package is the road
> to failure, since
> ? either each package is done separately by different people with
> little coordination (and you don't get consistency, some packagers
> will always slack or fail)

But if it's done based on a guideline or upstream change, shouldn't
they all be consistent with the new guideline or upstream name?

> ? or one person goes through each package and you get burnout and
> again, failure (and I won't even speak of doing a new review for each
> package)

Yeah, also one person looking at a bunch of packages in a row could
easily miss something from looking at too many things at once. 

> I'd like to see a mode where:
> ? a list of consistent renames is approved collectively
> ? the associated cvs work is done in one shot by infra
> ? each individual packager gets to work on the spec changes of his
> packages
> ? an experienced packager or a group of packagers is mandated to check
> it's done correctly and eventually to substitute to the packagers who
> don't do their bit at all

I'm not sure what this saves over the proposed 'post to the list and
get one packager to check your spec/renamed package' ?
Using that maintainers could update, post to the list, and the
packager/group of packagers could approve them. 

I suppose it might be quicker if timing is important. 

Would you be able to propose an amendment to 
https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages
that would cover this case in a way you think is good? 

In general renaming a package isn't that hard, it's just that some
people don't pay attention to the details on Obsoletes/Provides, which
causes a mess. I would like to get someone to review those changes so
this is caught before the package is built/pushed. Thats all. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/508fb13c/attachment.sig>

From kevin at scrye.com  Sat Dec 20 20:41:26 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 20 Dec 2008 13:41:26 -0700
Subject: Proposed PackageRenaming guideline
In-Reply-To: <494A8F98.4050100@herr-schmitt.de>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<494A8F98.4050100@herr-schmitt.de>
Message-ID: <20081220134126.1788501a@ohm.scrye.com>

On Thu, 18 Dec 2008 18:59:52 +0100
Jochen Schmitt <Jochen at herr-schmitt.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Kevin Fenzi schrieb:
> > https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages
> >
> After a first look on this proposel I have some question and comments:
> 
> 1.) Is the approving process the same as if I submit a new package
> request.

No. This is only for renaming existing packages already reviewed and in
the collection. 
> 
> 2.) Because the CVSAdmin request need a bugzilla ticket, why we don't
> doing the relating
> approving process in the same ticket.

We could. That would be more overhead however. 

> 3.) If we not need a full review process, I think anyone should
> approve that the right
> Provides/Requires statement existing in the new package. A lightwight
> approvement
> process may has the advance that the maintaining process of an
> existing package will not
> delayed for a long time by the renaming process.

Agreed. 

> 4.) Each people which has the right to done a normal package review
> should be abled
> to approve a renamed package.

Also agreed. 

> Best Regards:
> 
> Jochen Schmitt

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/c2e9b974/attachment.sig>

From kevin at scrye.com  Sat Dec 20 20:43:05 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 20 Dec 2008 13:43:05 -0700
Subject: Proposed PackageRenaming guideline
In-Reply-To: <gienqn$cg4$1@ger.gmane.org>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<gienqn$cg4$1@ger.gmane.org>
Message-ID: <20081220134305.3417e4d3@ohm.scrye.com>

On Fri, 19 Dec 2008 00:53:59 +0100
Kevin Kofler <kevin.kofler at chello.at> wrote:

> Kevin Fenzi wrote:
> > As far as I can tell we don't have a guideline for how to do package
> > renames. Here's my first attempt at such a guideline:
> > 
> > https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages
> > 
> > Feel free to leave feedback in talk page for it on the wiki, or
> > here or in personal email to me.
> 
> Somewhere in the distant past, we had a rule that to rename a
> package, all that's needed is a CVS Request. I'd like that to be
> reintroduced. I don't think dropping that rule was ever really
> discussed, it just vanished some day. It doesn't make sense to
> require a rereview just for a name change when any other updates
> (including things like adding subpackages and Obsoletes - and no, I'm
> not suggesting to force rereviews for all that stuff, it wouldn't
> scale!) are allowed. IMHO even a quick review on the ML is too much
> overhead for something as trivial as a name change.

I would normally agree, but I have seen a number of cases where people
got Obsoletes/Provides wrong and caused a mess. ;( 

I would like to see them get another pair of eyes on their package
before pushing the renamed version out. Thats all. 

> 
>         Kevin Kofler
> 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/49720333/attachment.sig>

From markg85 at gmail.com  Sat Dec 20 20:43:29 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 21:43:29 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D556B.9080807@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
Message-ID: <6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>

On Sat, Dec 20, 2008 at 9:28 PM, Rahul Sundaram <metherid at gmail.com> wrote:
> Mark wrote:
>>
>> 2. I always was under the impression that gnome especially was a
>> democracy but it turns out it's under dictatorship and then call it:
>> "Meritocracy" with a dictator like taste.
>>
>
> I have yet to see any Free and open source project work like a democracy.
> There might be some democratic aspects to portions of the projects but
> generally, who does the work gets to decide how things are done.  If Linus,
> says no, it doesn't get into the Linux kernel. Period.  No voting either.
> You have the full freedom to fork and convince others to adopt it but then
> again, that would require actual work to be done.
>>
>> 3. Fedora has a community but when the community starts demanding
>> something (use the browser mode as default) then it turns out that the
>> actual fedora community, the ones that are helping to make fedora
>> "better", are just a hand full of people.
>
> A entire distribution full of free and open source software is given to you
> at no cost with the all the freedom to modify and redistribute the result.
> I think it is more appropriate , to do less of "demanding" and more of
> engaging in a discussion. People don't like being forced but they generally
> prefer more participation.
>>
>> What i or any other community member says is simply being ignored. WE,
>> the community want this feature to change and i'm not going to be
>> silent about it!
>
> A community is inclusive of all its participants, developers and users
> included.  Finding consensus in a diverse community is a hard thing.  As
> seen in this thread, there is no one opinion that is representative of a
> community.  In Fedora, developers engage in a discussion or a debate,
>  sometimes a heated one but voting isn't a real discussion. It doesn't show
> WHY people are for or against something which makes it much more harder to
> make a decision either way.  The why is important, perhaps more important
> than gross number count. If you don't agree to me, you don't listen to the
> community is a often repeated thing but isn't a valid statement.
>>
>> A very good example of the bad community direction is, to name someone
>> again, Rahul. He always points you to your mistakes (fine in a way)
>> but never adds (not in my experience) something constructive or
>> helpful.... always a link to a wiki of somekind.
>>
>
> Even in my first mail I did point out other things you could have done to be
> more effective. I try to be helpful and give you more references instead of
> repeating the same things over and over again. That is one of the reasons, I
> prefer to document things when questions come up frequently on something or
> the other.  I am pretty sure, that is more helpful than your approach but
> you seem to have penchant to convert this into a emotional personal fight
> instead of just a technical debate.
>>
>> And for this entire issue where i made this thread for in the firste
>> place. Don't expect me to be silent now. I will be vocal about this.
>> fedora has a "freedom" sign
>
> Being vocal  (and cross posting to increasing more mailing lists) doesn't
> really change anything. Freedom is not anarchy. There are always rules about
> how things are done within any community.
> You do have the full freedom given by the project to do your own thing. I
> even encourage you to do it. If you are really successful, that would be a
> valid statement of your own viewpoints and will help others reconsider their
> current opinions as well.  The current strategy doesn't seem to work very
> well.
>
> Rahul

For the first time ever i fully agree on what you said and didn't find
your post annoying to read.
Just one thing about my "tactic".. i have none.. i have no preset plan
of how i'm going to do this. i just do it when i'm writing my next
response and till now that got me far (not talking about mailing lists
now but life in general). I tend to do the right thing when i just do
it without planning anything or considering every possible outcome. I
think i am indeed getting done a part of what i hoped and that's
raising awareness that this option in nautilus should be changed and
that the majority of any linux related community is in favor of it. I
don't have hard numbers to back that up but there are no hard numbers
on community users so don't ask the impossible of me.



From markg85 at gmail.com  Sat Dec 20 20:46:47 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 21:46:47 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D57C9.5090809@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
	<604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
	<494D57C9.5090809@gmail.com>
Message-ID: <6e24a8e80812201246x49a3c516w3ba396cc1c154cb1@mail.gmail.com>

On Sat, Dec 20, 2008 at 9:38 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Jeff Spaleta wrote:
>>
>> That's a copout excuse.  You are spending a lot of time right now
>> beating your head on the brick wall on this issue.  Figuring out a
>> technical solution in the form of a LiveCD under the umbrella of the
>> GNOME project might actually be the better argument than what you are
>> doing now.
>
> Is there a fixed policy on how fedora must relate to upstream packages?
>  That is, do you have a requirement to take every default that the upstream
> has (themes, etc.)?  Or can any packager make any whimsical change he wants
> at any time?  Or something in between?
>
> --
>  Les Mikesell
>   lesmikesell at gmail.com

What they all said so far is that it either has to be done upstream or
the package maintainer has to do it by making a patch. In this
nautilus case that's the same person. (i won't name him this time
because they also say that won't help the discussion ^_^)



From metherid at gmail.com  Sat Dec 20 21:02:04 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Sun, 21 Dec 2008 02:32:04 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D57C9.5090809@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>	<604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
	<494D57C9.5090809@gmail.com>
Message-ID: <494D5D4C.7090704@gmail.com>

Les Mikesell wrote:
> Jeff Spaleta wrote:
>>
>> That's a copout excuse.  You are spending a lot of time right now
>> beating your head on the brick wall on this issue.  Figuring out a
>> technical solution in the form of a LiveCD under the umbrella of the
>> GNOME project might actually be the better argument than what you are
>> doing now.
>
> Is there a fixed policy on how fedora must relate to upstream 
> packages?  That is, do you have a requirement to take every default 
> that the upstream has (themes, etc.)?  Or can any packager make any 
> whimsical change he wants at any time?  Or something in between?
https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment

Rahul



From pertusus at free.fr  Sat Dec 20 21:09:33 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Dec 2008 22:09:33 +0100
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <1229801959.3861.13.camel@localhost.localdomain>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
	<20081219194825.GA16284@bludgeon.org>
	<494BFECE.4050003@gmail.com> <20081220004829.GB10679@free.fr>
	<494CC439.4070503@gmail.com> <20081220121718.GC2506@free.fr>
	<1229801959.3861.13.camel@localhost.localdomain>
Message-ID: <20081220210933.GD2790@free.fr>

On Sat, Dec 20, 2008 at 11:39:19AM -0800, Jesse Keating wrote:
> 
> Given how huge the wiki is, FESCo needs help in identifying places that
> need changing.

The only place to change is:
http://fedoraproject.org/wiki/PackageMaintainers/Policy

And
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility
http://fedoraproject.org/wiki/PackageMaintainers/SponsorResponsibility
if they become official.

Am I missing something?

All the policies should be here. Now some places in the documentation
also refer to the policies, but the policies are special, like the
packaging guidelines, they have a normative scope. And of course
policies can refer to other places in the wiki. 

What is in Policies is in my opinion under FESCo responsibilities, 
meaning that FESCo should verify that changes done by community 
members are right, and should make sure that new policies that are 
of relevance for packagers are documented here.

--
Pat



From metherid at gmail.com  Sat Dec 20 21:10:28 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Sun, 21 Dec 2008 02:40:28 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
Message-ID: <494D5F44.6060802@gmail.com>

Mark wrote:
>  I
> think i am indeed getting done a part of what i hoped and that's
> raising awareness that this option in nautilus should be changed and
> that the majority of any linux related community is in favor of it. I
> don't have hard numbers to back that up but there are no hard numbers
> on community users so don't ask the impossible of me
>   
You are being self contradictory. If you don't have any hard numbers, 
you cannot actually claim a majority at all and yes, finding hard 
numbers is difficult if not impossible and doesn't really translate into 
usability anyway. I wouldn't blame you for this.  The real problem is 
that we haven't yet figured out a good community centric approach to 
usability though many different people are trying. Even in cases, where 
there some acclaimed usability tests behind a particular change, many 
Linux users still felt the changes were all wrong. One example is the 
Slab menu or the new KDE 4 default menu. In the end, all that you have 
accomplished is to note again, that the Linux community has strong and 
sometimes deeply conflicting view points and aren't afraid to express 
them but I think,  most of us are already aware of that.

Rahul



From markg85 at gmail.com  Sat Dec 20 21:19:49 2008
From: markg85 at gmail.com (Mark)
Date: Sat, 20 Dec 2008 22:19:49 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D5F44.6060802@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
Message-ID: <6e24a8e80812201319l21c95d8ag42c0d8d9ebaf84b6@mail.gmail.com>

On Sat, Dec 20, 2008 at 10:10 PM, Rahul Sundaram <metherid at gmail.com> wrote:
> Mark wrote:
>>
>>  I
>> think i am indeed getting done a part of what i hoped and that's
>> raising awareness that this option in nautilus should be changed and
>> that the majority of any linux related community is in favor of it. I
>> don't have hard numbers to back that up but there are no hard numbers
>> on community users so don't ask the impossible of me
>>
>
> You are being self contradictory. If you don't have any hard numbers, you
> cannot actually claim a majority at all and yes, finding hard numbers is
> difficult if not impossible and doesn't really translate into usability
> anyway. I wouldn't blame you for this.  The real problem is that we haven't
> yet figured out a good community centric approach to usability though many
> different people are trying. Even in cases, where there some acclaimed
> usability tests behind a particular change, many Linux users still felt the
> changes were all wrong. One example is the Slab menu or the new KDE 4
> default menu. In the end, all that you have accomplished is to note again,
> that the Linux community has strong and sometimes deeply conflicting view
> points and aren't afraid to express them but I think,  most of us are
> already aware of that.
>
> Rahul

To be completely off topic -- the discussion about browser mode seems
over anyway -- the kde 4 menu does suck. besides that it's buggy it's
not intuitive although it might be better if the existing bugs are
fixed. The only thing it is is looking better then what was the
classic menu.

I will see if the bug (talking about the spatial vs browser mode now)
that is targeted for gnome 2.24 is really gonna get in thus meaning
that browser mode is enabled by default again. The link is in one of
my previous posts.



From paul at city-fan.org  Sat Dec 20 21:29:43 2008
From: paul at city-fan.org (Paul Howarth)
Date: Sat, 20 Dec 2008 21:29:43 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229800620.23410.173.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
Message-ID: <20081220212943.5cf357bd@metropolis.intra.city-fan.org>

On Sat, 20 Dec 2008 14:17:00 -0500
Dimi Paun <dimi at lattica.com> wrote:
> Where there _any_ decent arguments for spatial? No, other than
> a few people saying they like it, and plenty of suggestions for
> going on wild goose chases. Thanks, but no thanks.

There's an article on spatial mode here FWIW:

http://www.bytebot.net/geekdocs/spatial-nautilus.html

It offers some thoughts in favour of that approach.

Paul.



From jkeating at redhat.com  Sat Dec 20 21:30:22 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Dec 2008 13:30:22 -0800
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <20081220210933.GD2790@free.fr>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr> <20081219194825.GA16284@bludgeon.org>
	<494BFECE.4050003@gmail.com> <20081220004829.GB10679@free.fr>
	<494CC439.4070503@gmail.com> <20081220121718.GC2506@free.fr>
	<1229801959.3861.13.camel@localhost.localdomain>
	<20081220210933.GD2790@free.fr>
Message-ID: <1229808622.3861.17.camel@localhost.localdomain>

On Sat, 2008-12-20 at 22:09 +0100, Patrice Dumas wrote:
> Am I missing something?

I  meant in general.  As things change via FESCo they could use some
help identifying all the places in the wiki that should change.

> 
> All the policies should be here. Now some places in the documentation
> also refer to the policies, but the policies are special, like the
> packaging guidelines, they have a normative scope. And of course
> policies can refer to other places in the wiki. 
> 
> What is in Policies is in my opinion under FESCo responsibilities, 
> meaning that FESCo should verify that changes done by community 
> members are right, and should make sure that new policies that are 
> of relevance for packagers are documented here.

The discussion tab is perfect for this, drop a comment if you think
something should change.

I don't think however FESCo has appointed any people as maintainers of
the wiki space.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/48075ed4/attachment.sig>

From surenkarapetyan at gmail.com  Sat Dec 20 21:57:10 2008
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Sun, 21 Dec 2008 01:57:10 +0400
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D32E8.90901@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229719550.23410.79.camel@dimi.lattica.com>	<1229722878.3861.0.camel@localhost.localdomain>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<494D32E8.90901@gmail.com>
Message-ID: <494D6A36.2080200@gmail.com>

Les Mikesell wrote:
> Jeff Spaleta wrote:
>>
>> I think the proponents of change do a disservice to their chosen cause
>> in choosing the argumentation they have so far.  Trying to coerce a
>> change by hammering away with the blunt instruments of populism.  It's
>> not going to work. Coercion is the wrong method and populist arguments
>> are the wrong tool.  You have to persuade the decision-makers, and to
>> do that you have to understand how they prioritize and think.   The
>> art of persuasion is a subtle science. It's brain surgery, not to be
>> performed with the hammer or rhetoric or with the pitchforks and
>> torches  of populist appeal.   You have to crawl inside the heads of
>> the people whose minds you are looking to change, and think like them.
>
> So what about simple logic:
> The companies with big budgets already performed the due diligence 
> that no one here is willing to do - and we can see they all made the 
> same choice.
>
> How about simplicity:  You already know how to open one browser 
> window.  If you want two for drag/drop or copy/paste operations you 
> don't need to do anything different, just do it again.
>
> How about horrible user interface: in the spatial mode you have to use 
> the middle mouse button all the time to get expected operation.  
> Where's the middle mouse button on my laptop?
<sarcasm>
Just press left&right buttons together.
If You keep training for a few days You'll be able to trigger a 
middle-click 80% of the time.
</sarcasm>
>
> But the worst part about this mess is the way the change in the 
> default appeared in the first place.  You make it sound like the 
> burden should be on the people who want the current setting changed, 
> but in fact it should never have been permitted in the first place.
>



From jonathan.underwood at gmail.com  Sat Dec 20 22:06:37 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sat, 20 Dec 2008 22:06:37 +0000
Subject: On mass renames
In-Reply-To: <1229629223.13577.11.camel@arekh.okg>
References: <1229629223.13577.11.camel@arekh.okg>
Message-ID: <645d17210812201406h64f52e92ve23d8d0ec47eb0a9@mail.gmail.com>

2008/12/18 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>
> Sometimes, it is necessary to perform a mass rename to bring some
> consistency to a class of packages.
>
> In that case any workflow that proceeds package by package is the road
> to failure, since
> ? either each package is done separately by different people with little
> coordination (and you don't get consistency, some packagers will always
> slack or fail)
> ? or one person goes through each package and you get burnout and again,
> failure (and I won't even speak of doing a new review for each package)
>
> I'd like to see a mode where:
> ? a list of consistent renames is approved collectively
> ? the associated cvs work is done in one shot by infra
> ? each individual packager gets to work on the spec changes of his
> packages
> ? an experienced packager or a group of packagers is mandated to check
> it's done correctly and eventually to substitute to the packagers who
> don't do their bit at all

There's a lot of merit to this (I'm thinking here of the tetex->tex
renames that are needed).



From surenkarapetyan at gmail.com  Sat Dec 20 22:09:27 2008
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Sun, 21 Dec 2008 02:09:27 +0400
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D3DB2.4000304@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
Message-ID: <494D6D17.2030104@gmail.com>

Les Mikesell wrote:
> David Nielsen wrote:
>>
>>> And for this entire issue where i made this thread for in the first
>>> place. Don't expect me to be silent now. I will be vocal about this.
>>> fedora has a "freedom" sign in it's logo so make that a reality!
>>>
>>
>> And you remain with the freedom to change the setting manually, 
>> create your
>> own spin with the setting changed by default. Your freedom however 
>> does not
>> extend to throwing a hissy fit on the development list because you're
>> preference is not the default. We have processes for feature goals 
>> and there
>> is upstream GNOME to have this debate with, both will get you input 
>> on the
>> idea without pissing the rest of us off.
>>
>> I used to have the browser mode activated out of habit, but now 
>> because you
>> made it your mission to spam the devel list and attack developers, I 
>> have
>> changed the setting back and you know what.. I love spatial.
>
> Can someone who likes (even tolerates) spatial mode describe why?  I'm 
> completely baffled as to why anyone would prefer windows left open all 
> over the place randomly instead of just explicitly opening ones 
> yourself in places where you want them.  For me, it is _always_ extra 
> work to close the unwanted windows compared to opening the ones I want.
>
Well I think spatial mode can work and feel OK if Your folder's max 
depth is <=2 (i.e. All pictures are in Pictures and no subdirectories).



From jspaleta at gmail.com  Sat Dec 20 22:15:46 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 20 Dec 2008 13:15:46 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D6D17.2030104@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com> <494D6D17.2030104@gmail.com>
Message-ID: <604aa7910812201415u73f608a1he001c65dc01cc231@mail.gmail.com>

On Sat, Dec 20, 2008 at 1:09 PM, Suren Karapetyan
<surenkarapetyan at gmail.com> wrote:
> Well I think spatial mode can work and feel OK if Your folder's max depth is
> <=2 (i.e. All pictures are in Pictures and no subdirectories).

That's an argument for list view over icon view, not spatial over browser.

-jef



From surenkarapetyan at gmail.com  Sat Dec 20 22:50:02 2008
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Sun, 21 Dec 2008 02:50:02 +0400
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201415u73f608a1he001c65dc01cc231@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>	<494D3DB2.4000304@gmail.com>
	<494D6D17.2030104@gmail.com>
	<604aa7910812201415u73f608a1he001c65dc01cc231@mail.gmail.com>
Message-ID: <494D769A.3030608@gmail.com>

Jeff Spaleta wrote:
> On Sat, Dec 20, 2008 at 1:09 PM, Suren Karapetyan
> <surenkarapetyan at gmail.com> wrote:
>   
>> Well I think spatial mode can work and feel OK if Your folder's max depth is
>> <=2 (i.e. All pictures are in Pictures and no subdirectories).
>>     
>
> That's an argument for list view over icon view, not spatial over browser.
>
> -jef
>
>   
I didn't quite understand what is has to do with icon v.s. list views.
I meant spatial mode can be very useful and nice if you usually use 
(i.e. open) 10 folders daily.
You can remember where on the desktop you made your Videos folder open 
and where Pictures and where Documents,
but I personally don care where ~/Documents/exams/lectures or 
~/Documents/exams/samples or ~/Projects/mytestqtapp/src or even 
~/Pictures/2008/summer/camp pops.
And I don't have time to set folder-specific preferences for each of 100 
folders I may ever open.

And another thing which came to my mind while typing this.
What about creating a way to make folders SPECIAL - make it open in new 
"Folder" window even when I'm using browser mode?
Does it make sense to anyone?



From lesmikesell at gmail.com  Sat Dec 20 23:20:25 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 17:20:25 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201415u73f608a1he001c65dc01cc231@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>	<494D3DB2.4000304@gmail.com>
	<494D6D17.2030104@gmail.com>
	<604aa7910812201415u73f608a1he001c65dc01cc231@mail.gmail.com>
Message-ID: <494D7DB9.2000704@gmail.com>

Jeff Spaleta wrote:
> On Sat, Dec 20, 2008 at 1:09 PM, Suren Karapetyan
> <surenkarapetyan at gmail.com> wrote:
>> Well I think spatial mode can work and feel OK if Your folder's max depth is
>> <=2 (i.e. All pictures are in Pictures and no subdirectories).
> 
> That's an argument for list view over icon view, not spatial over browser.

What does depth of paths have to do with that?   Try nfs-mounting the 
roots of a few remote machines so you can access everything, then 
positioning to some deep paths on each to prepare for a drag/drop 
without remembering the weird way to avoid leaving open windows behind 
you at every level to get the idea.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From lesmikesell at gmail.com  Sat Dec 20 23:24:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 17:24:50 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081220212943.5cf357bd@metropolis.intra.city-fan.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229719550.23410.79.camel@dimi.lattica.com>	<1229722878.3861.0.camel@localhost.localdomain>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<1229800620.23410.173.camel@dimi.lattica.com>
	<20081220212943.5cf357bd@metropolis.intra.city-fan.org>
Message-ID: <494D7EC2.90002@gmail.com>

Paul Howarth wrote:
> On Sat, 20 Dec 2008 14:17:00 -0500
> Dimi Paun <dimi at lattica.com> wrote:
>> Where there _any_ decent arguments for spatial? No, other than
>> a few people saying they like it, and plenty of suggestions for
>> going on wild goose chases. Thanks, but no thanks.
> 
> There's an article on spatial mode here FWIW:
> 
> http://www.bytebot.net/geekdocs/spatial-nautilus.html
> 
> It offers some thoughts in favour of that approach.

But it starts off with the wrong premise.  The right-hand 'navigational' 
view should show multiple windows open too, just ones where you 
navigated there explicitly.  It makes it look like you could only have 
one browser-view window at once.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dimi at lattica.com  Sat Dec 20 23:36:22 2008
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 20 Dec 2008 18:36:22 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D5F44.6060802@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
Message-ID: <1229816182.23410.187.camel@dimi.lattica.com>


On Sun, 2008-12-21 at 02:40 +0530, Rahul Sundaram wrote:
> You are being self contradictory. If you don't have any hard numbers, 
> you cannot actually claim a majority at all and yes, finding hard 
> numbers is difficult if not impossible and doesn't really translate
> into usability anyway. I wouldn't blame you for this.

But this is exactly what drives people up the wall:
  - Please change X
  - Why would we, how can we know if other like it like that?
  - Look, there's plenty of indication on the web that that's the case
  - Pfff, even 95% numbers are not good, we want HARD numbers!
  - ... but ... that's nearly impossible to get :(
  - Sure, we know it's impossible, that's why we asked for them. Duh!

No matter on each side of the debate you are, you must admit this is
insanely frustrating! This is not constructive in any way. Why don't
you have the guts to come out and say:
  "Fsck off, this is the way we like it. End of discussion."

Why mimic this lame community involvement?!? Don't you realize people
know when they are taken for fools?

And you know what? We *have* hard numbers! We know quite well the
percentage of people using Windows and MacOSX. It is close to 95%. Every
time I pointed that out it was completely ignored.

I have presented a fairly tight argument why the default was not chosen
wisely. Did I receive *one* decent counter argument? Stuff along the
lines of "Come back with several solid usability studies" is just
ludicrous.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From seg at haxxed.com  Sat Dec 20 23:40:19 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 20 Dec 2008 17:40:19 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <49467EA4.2060909@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <49467E08.2080806@redhat.com>
	<49467EA4.2060909@redhat.com>
Message-ID: <1229816419.18082.1.camel@localhost.localdomain>

On Mon, 2008-12-15 at 16:58 +0100, Harald Hoyer wrote:
> Eric Sandeen wrote:
> >> Turning off bootchart: 30s
> >>
> >> So all in all we have nearly accomplished the 30 Second Startup Feature 
> >> http://fedoraproject.org/wiki/Features/30SecondStartup.
> > 
> > Well, no; not if this requires data=writeback.  We can't ship that way,
> > it's a potential security hole.  You don't want someone's maildir
> > suddenly containing pieces of /etc/shadow or whatnot.  The old data that
> > may be exposed by data=writeback may not belong to that user.
> > 
> > -Eric
> > 
> 
> So, we switch to xfs as the default FS? :-)

Not until someone writes an XFS filesystem shrinker.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/3add87ae/attachment.sig>

From dimi at lattica.com  Sat Dec 20 23:40:41 2008
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 20 Dec 2008 18:40:41 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <20081220212943.5cf357bd@metropolis.intra.city-fan.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
	<20081220212943.5cf357bd@metropolis.intra.city-fan.org>
Message-ID: <1229816441.23410.192.camel@dimi.lattica.com>


On Sat, 2008-12-20 at 21:29 +0000, Paul Howarth wrote:
> There's an article on spatial mode here FWIW:
> 
> http://www.bytebot.net/geekdocs/spatial-nautilus.html
> 
> It offers some thoughts in favour of that approach.

Theoretical ideas in UI design are a good start, but not the
final answer. There are countless ideas that sound good in theory, 
but few have survived the test of time. 

Nobody cares about such arguments. Spacial had more than enough
time (4 years!) to prove itself. It didn't. Give it a rest.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From sandeen at redhat.com  Sat Dec 20 23:58:47 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 20 Dec 2008 17:58:47 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229816419.18082.1.camel@localhost.localdomain>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<49467E08.2080806@redhat.com>	<49467EA4.2060909@redhat.com>
	<1229816419.18082.1.camel@localhost.localdomain>
Message-ID: <494D86B7.80804@redhat.com>

Callum Lerwick wrote:
> On Mon, 2008-12-15 at 16:58 +0100, Harald Hoyer wrote:
>> Eric Sandeen wrote:
>>>> Turning off bootchart: 30s
>>>>
>>>> So all in all we have nearly accomplished the 30 Second Startup Feature 
>>>> http://fedoraproject.org/wiki/Features/30SecondStartup.
>>> Well, no; not if this requires data=writeback.  We can't ship that way,
>>> it's a potential security hole.  You don't want someone's maildir
>>> suddenly containing pieces of /etc/shadow or whatnot.  The old data that
>>> may be exposed by data=writeback may not belong to that user.
>>>
>>> -Eric
>>>
>> So, we switch to xfs as the default FS? :-)
> 
> Not until someone writes an XFS filesystem shrinker.

Just out of curiosity, do you really do offline root ext3 filesystem
shrinks that often?

-Eric



From markg85 at gmail.com  Sun Dec 21 00:02:20 2008
From: markg85 at gmail.com (Mark)
Date: Sun, 21 Dec 2008 01:02:20 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229816182.23410.187.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
Message-ID: <6e24a8e80812201602v670edb0fj415f8c835cd217e1@mail.gmail.com>

On Sun, Dec 21, 2008 at 12:36 AM, Dimi Paun <dimi at lattica.com> wrote:
>
> On Sun, 2008-12-21 at 02:40 +0530, Rahul Sundaram wrote:
>> You are being self contradictory. If you don't have any hard numbers,
>> you cannot actually claim a majority at all and yes, finding hard
>> numbers is difficult if not impossible and doesn't really translate
>> into usability anyway. I wouldn't blame you for this.
>
> But this is exactly what drives people up the wall:
>  - Please change X
>  - Why would we, how can we know if other like it like that?
>  - Look, there's plenty of indication on the web that that's the case
>  - Pfff, even 95% numbers are not good, we want HARD numbers!
>  - ... but ... that's nearly impossible to get :(
>  - Sure, we know it's impossible, that's why we asked for them. Duh!

exactly right
>
> No matter on each side of the debate you are, you must admit this is
> insanely frustrating! This is not constructive in any way. Why don't
> you have the guts to come out and say:
>  "Fsck off, this is the way we like it. End of discussion."

I wish they would say that. but then again that would have proven me
being right with all my "rants" about dictatorship which they probably
try to avoid.
>
> Why mimic this lame community involvement?!? Don't you realize people
> know when they are taken for fools?

like we are now for about 200 posts.
>
> And you know what? We *have* hard numbers! We know quite well the
> percentage of people using Windows and MacOSX. It is close to 95%. Every
> time I pointed that out it was completely ignored.

I'm not going to give an argument against it ^_^ i agree with you on
all your points
>
> I have presented a fairly tight argument why the default was not chosen
> wisely. Did I receive *one* decent counter argument? Stuff along the
> lines of "Come back with several solid usability studies" is just
> ludicrous.

that seems to be the way this "Meritocracy" likes to work.
>
> --
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.

I am kinda stunned by the divided community in this subject..
specially since probably about 90 - 95% is in favor of the change and
roughly 5% isn't and yet they fail to admit that they made a "small"
mistake 4 years ago. interesting and sad to see. This whole discussion
gave me a good insight in all of that.

I however don't intent to put more heat in this discussion so will be
a little more friendly in my responses now (and shorter ones).

Mark



From kevin.kofler at chello.at  Sun Dec 21 00:07:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 01:07:44 +0100
Subject: Forcing Gnome to start sans metacity
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<1229704828.24417.0.camel@matthiasc>
	<7f692fec0812191223o524eb1b3ub0b3178f8bd788ca@mail.gmail.com>
Message-ID: <gik1cg$hb8$1@ger.gmane.org>

Yaakov Nemoy wrote:
> Openbox complies with certain standards that the xmonad devs decided are a
> waste of lines of code.

Well, if they refuse to support freedesktop.org standards, it's no wonder
the WM integrates poorly. Those standards exist for a reason.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Dec 21 00:14:49 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 01:14:49 +0100
Subject: boost rebuild status
References: <20081218011435.03690d24@balbo.artheist.org>
	<a9d183c80812190025w27c81bb4hf2d543b4a3fbf375@mail.gmail.com>
Message-ID: <gik1pp$jtj$1@ger.gmane.org>

Thomas Moschny wrote:
> kdenetwork-7:4.1.85-1.fc11.src
> kdepim-6:4.1.85-1.fc11.src
> kdepimlibs-0:4.1.85-2.fc11.src
> kdeplasma-addons-0:4.1.85-2.fc11.src
> kdesdk-0:4.1.85-1.fc11.src
> koffice-1:1.9.98.3-1.fc11.src

FYI, all these are going to be updated really soon anyway (KDE 4.2 RC1 is
scheduled to be tagged on January 6, KOffice 2.0 Beta 5 on December 30),
and they don't require Boost at runtime, so I think it's not worth bumping
them now.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Dec 21 00:22:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 01:22:59 +0100
Subject: Proposed PackageRenaming guideline
References: <20081218104319.75305a5b@ohm.scrye.com>
	<gienqn$cg4$1@ger.gmane.org>
	<20081220134305.3417e4d3@ohm.scrye.com>
Message-ID: <gik293$jtj$2@ger.gmane.org>

Kevin Fenzi wrote:
> I would normally agree, but I have seen a number of cases where people
> got Obsoletes/Provides wrong and caused a mess. ;(
> 
> I would like to see them get another pair of eyes on their package
> before pushing the renamed version out. Thats all.

Then maybe the guideline should be that the reviewer has to check for valid
Obsoletes/Provides, but any other checks are optional (as in: if the
reviewer notices something obviously wrong, he/she should report it and
request it fixed before approving the rename, but he/she shouldn't be
required to go through the whole checklist again)?

        Kevin Kofler



From pertusus at free.fr  Sun Dec 21 00:26:59 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 01:26:59 +0100
Subject: Proposed PackageRenaming guideline
In-Reply-To: <gik293$jtj$2@ger.gmane.org>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<gienqn$cg4$1@ger.gmane.org>
	<20081220134305.3417e4d3@ohm.scrye.com>
	<gik293$jtj$2@ger.gmane.org>
Message-ID: <20081221002659.GH2790@free.fr>

On Sun, Dec 21, 2008 at 01:22:59AM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > I would normally agree, but I have seen a number of cases where people
> > got Obsoletes/Provides wrong and caused a mess. ;(
> > 
> > I would like to see them get another pair of eyes on their package
> > before pushing the renamed version out. Thats all.
> 
> Then maybe the guideline should be that the reviewer has to check for valid
> Obsoletes/Provides, but any other checks are optional (as in: if the
> reviewer notices something obviously wrong, he/she should report it and
> request it fixed before approving the rename, but he/she shouldn't be
> required to go through the whole checklist again)?

I think it would be right like that. A normal review is unneeded in my
opinion, and not checking obsoletes... is wrong too.

--
Pat



From kevin.kofler at chello.at  Sun Dec 21 00:28:29 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 01:28:29 +0100
Subject: boost rebuild status
References: <20081218011435.03690d24@balbo.artheist.org>
	<a9d183c80812190025w27c81bb4hf2d543b4a3fbf375@mail.gmail.com>
	<gik1pp$jtj$1@ger.gmane.org>
Message-ID: <gik2jd$jtj$3@ger.gmane.org>

I wrote:

> Thomas Moschny wrote:
>> kdenetwork-7:4.1.85-1.fc11.src
>> kdepim-6:4.1.85-1.fc11.src
>> kdepimlibs-0:4.1.85-2.fc11.src
>> kdeplasma-addons-0:4.1.85-2.fc11.src
>> kdesdk-0:4.1.85-1.fc11.src
>> koffice-1:1.9.98.3-1.fc11.src
> 
> FYI, all these are going to be updated really soon anyway (KDE 4.2 RC1 is
> scheduled to be tagged on January 6, KOffice 2.0 Beta 5 on December 30),
> and they don't require Boost at runtime, so I think it's not worth bumping
> them now.

PS: Actually KOffice is going to be rebuilt anyway for the new exiv2.

        Kevin Kofler



From jspaleta at gmail.com  Sun Dec 21 00:32:14 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 20 Dec 2008 15:32:14 -0900
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229816182.23410.187.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
Message-ID: <604aa7910812201632n4065f29ag59e66603dddd32be@mail.gmail.com>

On Sat, Dec 20, 2008 at 2:36 PM, Dimi Paun <dimi at lattica.com> wrote:

> And you know what? We *have* hard numbers! We know quite well the
> percentage of people using Windows and MacOSX. It is close to 95%. Every
> time I pointed that out it was completely ignored.

I'm seeing the same argumentation being made in upstream
desktop-devel-list discussions back in December 2005.  Do you expect
the same arguments to be more persuasive now? I don't think that's a
rational thing to expect.  Honestly I'm not seeing anything new in
terms of argument that I can't find in a previous round of upstream
discussion going as far back as 2005 if not earlier, in the concerns
expressed in the original discussion from 2002 on nautilus-list. No
one here asked Mark to bring this up...again.  No one here asked Mark
to make the same arguments...again.  Noone here has told him or you to
do exactly the same things which have failed to bring change in the
past.   But that's exactly what you are doing. These exact same
arguments were used in upstream discussion in 2005.

There is a long history here, the approach you are taking hasn't
worked in the past.  If you are unwilling to try a different approach
and instead choose to view suggestions as to different approaches to
take as being condescending and ludicrous instead of helpful, then
that's your decision. But I will say that I think you are behaving
irrationally, in your continued fervent support of your rational
argument as the only argument worth supporting.  Its just not rational
to expect a different outcome to the discussion than we have seen
before unless a new approach is taken.  There's nothing new here in
terms of information or thought.

It's simply not enough for you to believe that your arguments are
sufficient. History shows these arguments aren't connecting and are
not persuasive.  Keep the objective in mind.  The goal is not to be
right, you are not winning points for being rational or 'tight' in
your argument making. The goal is to persuade others to make a change
you desire.  Hammering away at them with an argument that has been
used repeatedly for years now, and has so far  been unpersuasive, is
not going to achieve the goal.

>
> I have presented a fairly tight argument why the default was not chosen
> wisely. Did I receive *one* decent counter argument? Stuff along the
> lines of "Come back with several solid usability studies" is just
> ludicrous.

Dimi, words like 'ludicrous' could be considered representative of a
condescending attitude.  Be wary of emotive speech like that. As a
proponent of rational thought, help others discuss this rationally by
tempering your own speech so as to avoid baiting emotional outbursts
from others.

-jef



From kevin.kofler at chello.at  Sun Dec 21 01:12:16 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 02:12:16 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>
	<1229692775.3209.670.camel@beck.corsepiu.local>
	<494C07F6.7050302@gmail.com>
Message-ID: <gik55g$q83$1@ger.gmane.org>

Les Mikesell wrote:
> Or for people who don't realize you can open _exactly_ two windows for
> this in browser mode whenever you need them...

Or you can use a real file manager which always has 2 panes, e.g. Krusader.
I hate having to open 2 windows by hand.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Dec 21 01:25:26 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 02:25:26 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>
	<494AD0FE.70202@gmail.com>	<494AD768.4030907@fedoraproject.org>	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>
	<1229681113.3159.13863.camel@cookie.hadess.net>
	<494D39AD.9020705@gmail.com>
Message-ID: <gik5u7$sbc$1@ger.gmane.org>

Les Mikesell wrote:
> I think there is really a better approach to this, but it doesn't mesh
> all that well with RPM capabilities.  That is, for every package or
> package group where there is more than one commonly desired
> configuration, there should be multiple configuration packages where the
> last one installed wins, conceptually similar to the way the
> caching-nameserver package is just a different configuration for bind.

For KDE, this is already possible, and in fact one of the reasons why our
settings are in a separate kde-settings package.

You can have a package with:
Name: kde-settings-lesmikesell
Provides: kde-settings = 1:4.1
Conflicts: kde-settings < 1:4.1 kde-settings > 1:4.1
(but I don't think we should allow such packages within Fedora, they're a
matter of personal preference and should thus be kept local).

We also support /etc/kde for custom per-machine configuration changes, so
it's also possible to have a package which puts settings there, overriding
only the settings you want to change instead of replacing kde-settings.
That way you inherit any kde-settings changes automatically and don't have
to rebuild the customized kde-settings for them. The drawback is that this
makes it harder to customize the settings per machine, so it's only a good
idea if the person building the package is also the site admin and does all
configuration changes in the package.

Maybe a hierarchical system like that would be possible in GNOME? The config
file search path in F10's KDE looks like this:
/home/kevin/.kde/share/config/:/etc/kde/:/usr/share/kde-settings/kde-profile/default/share/config/:/usr/share/config/
* ~/.kde/share/config/ is per user.
* /etc/kde/ is per machine.
* /usr/share/kde-settings/kde-profile/default/share/config/ is per distro
(Fedora's kde-settings defaults).
* /usr/share/config/ is what KDE upstream defaults to.
and of course some software has builtin defaults. But often the builtin
default for things like bookmarks is empty and upstream fills them
in /usr/share/config/ config files.

It's also possible to use a different profile than the kde-settings default
profile, but unfortunately support for that in KDE 4 is currently
lackluster, so I recommend using /etc/kde instead.

(I dropped the Nautilus list from the CC because this has nothing to do with
Nautilus. If it was to be applied to GNOME, it'd have to be set up for all
of GNOME, not just Nautilus.)

        Kevin Kofler



From kevin.kofler at chello.at  Sun Dec 21 01:27:35 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 02:27:35 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>
	<1229692775.3209.670.camel@beck.corsepiu.local>
	<494C07F6.7050302@gmail.com> <gik55g$q83$1@ger.gmane.org>
Message-ID: <gik628$sbc$2@ger.gmane.org>

I wrote:

> Or you can use a real file manager which always has 2 panes, e.g.
> Krusader. I hate having to open 2 windows by hand.

Oh by the way, even if it doesn't start up that way by default, Dolphin also
supports split panes. Just hit F3.

        Kevin Kofler



From loupgaroublond at gmail.com  Sun Dec 21 01:38:55 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Sat, 20 Dec 2008 20:38:55 -0500
Subject: Forcing Gnome to start sans metacity
In-Reply-To: <gik1cg$hb8$1@ger.gmane.org>
References: <7f692fec0812172319v20652c39x40cecca223e70155@mail.gmail.com>
	<1229606638.3301.11.camel@localhost.localdomain>
	<1229704828.24417.0.camel@matthiasc>
	<7f692fec0812191223o524eb1b3ub0b3178f8bd788ca@mail.gmail.com>
	<gik1cg$hb8$1@ger.gmane.org>
Message-ID: <7f692fec0812201738m5064c735i7da6241c9c1d8548@mail.gmail.com>

2008/12/20 Kevin Kofler <kevin.kofler at chello.at>:
> Yaakov Nemoy wrote:
>> Openbox complies with certain standards that the xmonad devs decided are a
>> waste of lines of code.
>
> Well, if they refuse to support freedesktop.org standards, it's no wonder
> the WM integrates poorly. Those standards exist for a reason.

I'm keeping my personal thoughts on those standards out of things :).
I just have to support it.

-Yaakov



From lesmikesell at gmail.com  Sun Dec 21 01:46:27 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 19:46:27 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <gik5u7$sbc$1@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<494AC569.8070401@fedoraproject.org>	<494AD0FE.70202@gmail.com>	<494AD768.4030907@fedoraproject.org>	<6e24a8e80812181521y3ec400b5p975cc497ace260a6@mail.gmail.com>	<1229681113.3159.13863.camel@cookie.hadess.net>	<494D39AD.9020705@gmail.com>
	<gik5u7$sbc$1@ger.gmane.org>
Message-ID: <494D9FF3.3000807@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> I think there is really a better approach to this, but it doesn't mesh
>> all that well with RPM capabilities.  That is, for every package or
>> package group where there is more than one commonly desired
>> configuration, there should be multiple configuration packages where the
>> last one installed wins, conceptually similar to the way the
>> caching-nameserver package is just a different configuration for bind.
> 
> For KDE, this is already possible, and in fact one of the reasons why our
> settings are in a separate kde-settings package.

I really meant for this to start at the top level and replace the 
concept of spins.  Of course it could cascade down to pull custom 
configurations for each package where it makes sense too.

> You can have a package with:
> Name: kde-settings-lesmikesell
> Provides: kde-settings = 1:4.1
> Conflicts: kde-settings < 1:4.1 kde-settings > 1:4.1
> (but I don't think we should allow such packages within Fedora, they're a
> matter of personal preference and should thus be kept local).

Ideally there would be a way for anyone to publish a customized setup 
that others could duplicate automatically.  I've always thought that a 
few hundred choices could cover almost all of the ways that anyone would 
need.  But, I'm not sure that hardware configuration choices are 
sufficiently separated from functional preferences to completely 
automate this.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sun Dec 21 01:51:33 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 19:51:33 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <gik55g$q83$1@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>	<1229692775.3209.670.camel@beck.corsepiu.local>	<494C07F6.7050302@gmail.com>
	<gik55g$q83$1@ger.gmane.org>
Message-ID: <494DA125.50501@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> Or for people who don't realize you can open _exactly_ two windows for
>> this in browser mode whenever you need them...
> 
> Or you can use a real file manager which always has 2 panes, e.g. Krusader.

But I don't always want 2 panes - or just 2.

> I hate having to open 2 windows by hand.

The concept is symmetrical.  How can you hate opening the 2nd window if 
you didn't hate the first? It's the same thing.  Is is odd vs. even and 
fun again the 3rd time?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Sun Dec 21 01:53:09 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 02:53:09 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>	<494D3DB2.4000304@gmail.com>
	<494D4302.4020503@gmail.com> <494D49D6.20302@gmail.com>
Message-ID: <gik7i5$utp$1@ger.gmane.org>

Les Mikesell wrote:
> Same here but would like a friendly visual navigation (i.e. not
> requiring contortions to avoid opening extraneous windows) followed by a
> simple operation to "open terminal window with it's working directory
> here".

Why don't you use Dolphin? You even get an embedded Konsole there (hit
F4). :-)

        Kevin Kofler



From adamwill at shaw.ca  Sun Dec 21 01:53:23 2008
From: adamwill at shaw.ca (Adam Williamson)
Date: Sat, 20 Dec 2008 17:53:23 -0800
Subject: boost rebuild status
In-Reply-To: <12prjn9nuf.fsf@allele2.eebweb.arizona.edu>
References: <20081218011435.03690d24@balbo.artheist.org>
	<y68wqcb9sr.fsf@allele2.eebweb.arizona.edu>
	<1229708079.24419.640.camel@lenovo.local.net>
	<12prjn9nuf.fsf@allele2.eebweb.arizona.edu>
Message-ID: <1229824403.17294.33.camel@lenovo.local.net>

On Sat, 2008-12-20 at 02:51 -0700, Alex Lancaster wrote:

> Indeed, I was the person pestering upstream to fix this, which they
> have done so in SVN.

Ah, right, fair enough - I believe I saw your name in the upstream
discussion, but didn't know you were the Fedora maintainer.

> AW> I knocked up a patch to make Miro 1.28 use system libtorrent (they
> AW> added this to upstream SVN post-1.28, but it required a bit of
> AW> re-diffing).  You can find it here:
> 
> Rather than adding that patch, I'm probably going to wait until Miro
> 2.0 is released (which should be very soon) where it will be
> unnecessary.  Currently Miro builds and works, and unless there is yet
> another boost soname bump, it should continue to build.

Again, sounds fine. I wasn't sure what the timeframe on 2.0 was.
-- 
adamw



From kevin.kofler at chello.at  Sun Dec 21 02:05:40 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 03:05:40 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>	<604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
	<494D57C9.5090809@gmail.com> <494D5D4C.7090704@gmail.com>
Message-ID: <gik89l$utp$2@ger.gmane.org>

Rahul Sundaram wrote:
>https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment

That's only relevant if the configuration change is actually a patch against
an upstream package. The KDE settings are in a kde-settings package for
which we are upstream ( https://fedorahosted.org/kde-settings/ ). :-) Also
note that it's only a SHOULD, not a MUST, and that "# change braindead
upstream default" is a perfectly valid comment under that guideline.

        Kevin Kofler



From clive at vacuumtube.org.uk  Sun Dec 21 02:07:40 2008
From: clive at vacuumtube.org.uk (Clive Messer)
Date: Sun, 21 Dec 2008 02:07:40 +0000
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201139o76a79192ga0eeec425cc2d03b@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
	<604aa7910812201139o76a79192ga0eeec425cc2d03b@mail.gmail.com>
Message-ID: <1229825260.27634.34.camel@pc343.objectsoft-systems.ltd.uk>


On Sat, 2008-12-20 at 10:39 -0900, Jeff Spaleta wrote:

> We are way way way past constructive discussion.  We were way past
> constructive discussion the moment Mark posted asking for a vote.

Sure, the original call for a vote was not the best way of "discussing"
the behaviour, but the reality is that anyone wanting to see the default
changed in Fedora is wasting their time. A decision was made that
'spatial' mode should be the default. That decision is not going to be
changed. There is no need for a discussion. Well, at least that is one
persons (my) opinion standing on the outside looking in.

Regards

Clive





From kevin.kofler at chello.at  Sun Dec 21 02:07:00 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 03:07:00 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
	<604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
	<494D57C9.5090809@gmail.com>
Message-ID: <gik8c4$utp$3@ger.gmane.org>

Les Mikesell wrote:
> Is there a fixed policy on how fedora must relate to upstream packages?
>   That is, do you have a requirement to take every default that the
> upstream has (themes, etc.)?  Or can any packager make any whimsical
> change he wants at any time?  Or something in between?

The packager can make changes.

But in the case of the Fedora GNOME packages, upstream and packagers are
mostly the same people.

        Kevin Kofler



From dimi at lattica.com  Sun Dec 21 02:18:10 2008
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 20 Dec 2008 21:18:10 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <604aa7910812201632n4065f29ag59e66603dddd32be@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
	<604aa7910812201632n4065f29ag59e66603dddd32be@mail.gmail.com>
Message-ID: <1229825890.23410.203.camel@dimi.lattica.com>


On Sat, 2008-12-20 at 15:32 -0900, Jeff Spaleta wrote:
> I'm seeing the same argumentation being made in upstream
> desktop-devel-list discussions back in December 2005.  Do you expect
> the same arguments to be more persuasive now?

Yes. Back than it was a new idea with lots of potential. You can't
just follow the established norm all the time, otherwise progress
would not be possible. Sometimes you have to change.

Now, I think that initially the change was rushed into Prod without
proper testing, but that's watter under the bridge. It was hoped that
once people would get used to the new feature, they would love it.
That's reasonable. However, we gave it more than enough time (4 years!)
for this to happen. It didn't pan out as hoped. 

There is plenty of circumstantial evidence to warrant a second look
at that decision. And yes, this time around the same arguments that
were put forward 4 years ago have more weight 'cause we have the
hindsight of the last 4 years.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From lesmikesell at gmail.com  Sun Dec 21 02:22:56 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 20:22:56 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229825260.27634.34.camel@pc343.objectsoft-systems.ltd.uk>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723272.23410.84.camel@dimi.lattica.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<1229800620.23410.173.camel@dimi.lattica.com>	<604aa7910812201139o76a79192ga0eeec425cc2d03b@mail.gmail.com>
	<1229825260.27634.34.camel@pc343.objectsoft-systems.ltd.uk>
Message-ID: <494DA880.50504@gmail.com>

Clive Messer wrote:
> 
> Sure, the original call for a vote was not the best way of "discussing"
> the behaviour, but the reality is that anyone wanting to see the default
> changed in Fedora is wasting their time. A decision was made that
> 'spatial' mode should be the default. That decision is not going to be
> changed. There is no need for a discussion. 

Gotta love these open community driven projects...

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Sun Dec 21 02:21:24 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 03:21:24 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<6e24a8e80812201319l21c95d8ag42c0d8d9ebaf84b6@mail.gmail.com>
Message-ID: <gik975$2eu$1@ger.gmane.org>

Mark wrote:
> To be completely off topic -- the discussion about browser mode seems
> over anyway -- the kde 4 menu does suck. besides that it's buggy it's
> not intuitive although it might be better if the existing bugs are
> fixed. The only thing it is is looking better then what was the
> classic menu.

Well, I can only suggest that you talk to us on #fedora-kde and try to
gather feedback in some sensible way (but a ML vote is not a good way to do
so, as you have seen - we really don't need another flamewar like this
one!). That's assuming KDE 4's classic menu implementation is good enough
for you: if it also fails to meet your expectations, then actual coding
work is needed! We can't just use the original Kicker menu, it doesn't work
in KDE 4.

Please keep in mind that many people do like the new Kickoff menu, and that
we did hold a kind of vote among KDE maintainers and the result was 3-2 for
Kickoff (and for the record, I voted for the classic menu, I hate Kickoff).
We also tried to gather user feedback but didn't get all that much of it,
maybe because it was too early and KDE 4 wasn't widely used yet (it was
before the Fedora 9 release, so it was only in Rawhide).

Also keep in mind that changing the menu style is just 2 clicks
(right-click, Switch to Classic menu style), KDE upstream made it easily
accessible because they know there are differing strong preferences. (If
the default is switched to Classic, the people who want Kickoff will
complain, we can't make everyone happy.)

Oh, and if you want to participate in our decision making, the best way is
to join the KDE SIG and help with KDE packaging. :-)

        Kevin Kofler



From kevin.kofler at chello.at  Sun Dec 21 02:31:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 03:31:02 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>	<1229692775.3209.670.camel@beck.corsepiu.local>	<494C07F6.7050302@gmail.com>
	<gik55g$q83$1@ger.gmane.org> <494DA125.50501@gmail.com>
Message-ID: <gik9p7$3fg$1@ger.gmane.org>

Les Mikesell wrote:
> The concept is symmetrical.  How can you hate opening the 2nd window if
> you didn't hate the first? It's the same thing.  Is is odd vs. even and
> fun again the 3rd time?

Krusader supports tabs (independent tabs in each pane). There are no ternary
file operations in Krusader, so there's nothing which could be done with a
third pane which can't be done with tabs in the 2 panes.

And the nice thing about having the 2 panes in the same window is that you
don't have to play around with positioning the windows so they don't
overlap. You just maximize the window (or even better, have it start up
maximized, which Krusader supports just fine) and get it nicely split in
the middle. It's also nice for things like keyboard accessibility because
everything in the file manager knows there's a second pane (for
example, "copy" defaults to copying to the other pane, so it can be quickly
used with the keyboard or with one click, no drop target to specify (but
drag&drop is also possible and the panes are guaranteed not to
overlap), "unpack" defaults to unpacking to the directory in the other pane
etc.).

Having used 2-pane file managers for some time now, I'd never want to go
back.

        Kevin Kofler



From vonbrand at inf.utfsm.cl  Sun Dec 21 02:31:44 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sat, 20 Dec 2008 23:31:44 -0300
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201231t5470c7e4hf5d49aac408b63@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
	<604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>
	<6e24a8e80812201231t5470c7e4hf5d49aac408b63@mail.gmail.com>
Message-ID: <200812210231.mBL2ViJP020727@laptop14.inf.utfsm.cl>

Mark <markg85 at gmail.com> wrote:
> On Sat, Dec 20, 2008 at 9:24 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> > On Sat, Dec 20, 2008 at 10:53 AM, Mark <markg85 at gmail.com> wrote:

[...]

> >> Btw your idea of "my spin idea" might very well be true ^_^ it's just
> >> that it sucks up so much time which i don't want to spend at it.

> > That's a copout excuse.  You are spending a lot of time right now
> > beating your head on the brick wall on this issue.  Figuring out a
> > technical solution in the form of a LiveCD under the umbrella of the
> > GNOME project might actually be the better argument than what you are
> > doing now.

> not an excuse just a fact. besides that fact i just need to use fedora
> with a project of mine.

Yes, it is an excuse. If you want something done, do it yourself.
-- 
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 kevin.kofler at chello.at  Sun Dec 21 02:34:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 03:34:37 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
Message-ID: <gik9vt$3fg$2@ger.gmane.org>

Dimi Paun wrote:
>   3. all other major Linux distros (Ubuntu & Suse) use spacial, so
>      what kind of meaning is there left in "upstream"?

I think you mean "do not use spatial" there, don't you?

        Kevin Kofler



From kevin.kofler at chello.at  Sun Dec 21 02:43:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 03:43:55 +0100
Subject: Amarok 2 on F9
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gieuf2$uok$1@ger.gmane.org>
	<8536ef10812182026l7bebb1afnbe38874e697c706b@mail.gmail.com>
	<494B3ECC.6090404@rincon.com>
	<7f692fec0812190848o26980f92wd76d9eee9dabc7f7@mail.gmail.com>
Message-ID: <gikahc$3fg$3@ger.gmane.org>

Yaakov Nemoy wrote:
> Name       : yum-versionlock

But this means you won't get security updates, nor bugfix releases from the
1.4 branch. It's a horribly bad idea to use this.

There are no plans to push out Amarok 2 as an official F9 update anyway. See
kde-redhat unstable if you want it. Or just upgrade to F10. :-)

        Kevin Kofler



From kevin.kofler at chello.at  Sun Dec 21 02:45:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 03:45:59 +0100
Subject: Amarok 2 on F9
References: <5f6f8c5f0812181711w9e35ddpec14b9099624da25@mail.gmail.com>
	<gigtj0$pkc$1@ger.gmane.org>
	<7f692fec0812191220u5f513089ie01e0495da85d78e@mail.gmail.com>
Message-ID: <gikal7$3fg$4@ger.gmane.org>

Yaakov Nemoy wrote:
> Fedora 9 is a current release.

No, it's a previous release. :-) F10 is current.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Dec 21 02:54:43 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 03:54:43 +0100
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <gikb5j$3fg$5@ger.gmane.org>

Matt Domsch wrote:
> flasm-1.62-4.fc9 (build/make) kkofler,pertusus

Patrice Dumas (pertusus) fixed this one a few hours ago.

> kde-l10n-4.1.3-1.fc10 (build/make) than,rdieter,kkofler,tuxbrewr,ltinkl

This one has been fixed for a while: kde-l10n-4.1.85-1.fc11 built
successfully (also need the latest kdelibs).

        Kevin Kofler



From jkeating at redhat.com  Sun Dec 21 02:57:55 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Dec 2008 18:57:55 -0800
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229825260.27634.34.camel@pc343.objectsoft-systems.ltd.uk>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
	<604aa7910812201139o76a79192ga0eeec425cc2d03b@mail.gmail.com>
	<1229825260.27634.34.camel@pc343.objectsoft-systems.ltd.uk>
Message-ID: <1229828275.3861.19.camel@localhost.localdomain>

On Sun, 2008-12-21 at 02:07 +0000, Clive Messer wrote:
> On Sat, 2008-12-20 at 10:39 -0900, Jeff Spaleta wrote:
> 
> > We are way way way past constructive discussion.  We were way past
> > constructive discussion the moment Mark posted asking for a vote.
> 
> Sure, the original call for a vote was not the best way of "discussing"
> the behaviour, but the reality is that anyone wanting to see the default
> changed in Fedora is wasting their time. A decision was made that
> 'spatial' mode should be the default. That decision is not going to be
> changed. There is no need for a discussion. Well, at least that is one
> persons (my) opinion standing on the outside looking in.
> 
> Regards
> 
> Clive
> 
> 

To quote the maintainer in this very thread:

Yes, it is possible to
have a discussion of what the defaults should be, but it should be a
sane one with less emotions, no namecalling, a realization that someone
else (who spent many many years working on the piece of software) may
have a valid opinion, and a genuine interest in finding out the
reasoning behind the various options.

I have been convinced to change my mind by such discussions before, so
I'm not just blocking other peoples ideas. Of course, your random
rantings and namecallings don't exactly make me interested in having a
discussion with you.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/d5701a99/attachment.sig>

From markg85 at gmail.com  Sun Dec 21 03:24:35 2008
From: markg85 at gmail.com (Mark)
Date: Sun, 21 Dec 2008 04:24:35 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <gik975$2eu$1@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<6e24a8e80812201319l21c95d8ag42c0d8d9ebaf84b6@mail.gmail.com>
	<gik975$2eu$1@ger.gmane.org>
Message-ID: <6e24a8e80812201924j13d85048gfd28ffb24d58a4fc@mail.gmail.com>

On Sun, Dec 21, 2008 at 3:21 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Mark wrote:
>> To be completely off topic -- the discussion about browser mode seems
>> over anyway -- the kde 4 menu does suck. besides that it's buggy it's
>> not intuitive although it might be better if the existing bugs are
>> fixed. The only thing it is is looking better then what was the
>> classic menu.
>
> Well, I can only suggest that you talk to us on #fedora-kde and try to
> gather feedback in some sensible way (but a ML vote is not a good way to do
> so, as you have seen - we really don't need another flamewar like this
> one!). That's assuming KDE 4's classic menu implementation is good enough
> for you: if it also fails to meet your expectations, then actual coding
> work is needed! We can't just use the original Kicker menu, it doesn't work
> in KDE 4.
>
> Please keep in mind that many people do like the new Kickoff menu, and that
> we did hold a kind of vote among KDE maintainers and the result was 3-2 for
> Kickoff (and for the record, I voted for the classic menu, I hate Kickoff).
> We also tried to gather user feedback but didn't get all that much of it,
> maybe because it was too early and KDE 4 wasn't widely used yet (it was
> before the Fedora 9 release, so it was only in Rawhide).
>
> Also keep in mind that changing the menu style is just 2 clicks
> (right-click, Switch to Classic menu style), KDE upstream made it easily
> accessible because they know there are differing strong preferences. (If
> the default is switched to Classic, the people who want Kickoff will
> complain, we can't make everyone happy.)
>
> Oh, and if you want to participate in our decision making, the best way is
> to join the KDE SIG and help with KDE packaging. :-)
>
>        Kevin Kofler

Lol calm down on getting yourself safe lol.

I have just tried KDE 4 for a few hours and it's still not stable
enough for me to use.
so don't worry that i'm gonna make a new vote on this ML to get the
original menu back because i won't do that when i'm not using it. Ask
me again when KDE 4 is stable enough to use and doesn't crash when you
set you desktop to folder mode and does indeed remember the setting
and... and... and... there is so much that feels unstable but it's
really looking wonderful already.

And f.y.i. there is no menu in existence that i like ^_^ i did saw a
few mockups but nothing resembles what i would like to see. Not even
vista's! the one in windows 7 is getting closer though but that's only
because the theme there fully fits the panel.

So this is a flame war?... then i don't understand why. it's just
expressing facts and opinion to a few that don't want to listen
anyway.

On Sun, Dec 21, 2008 at 3:31 AM, Horst H. von Brand
<vonbrand at inf.utfsm.cl> wrote:
> Mark <markg85 at gmail.com> wrote:
>> On Sat, Dec 20, 2008 at 9:24 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
>> > On Sat, Dec 20, 2008 at 10:53 AM, Mark <markg85 at gmail.com> wrote:
>
> [...]
>
>> >> Btw your idea of "my spin idea" might very well be true ^_^ it's just
>> >> that it sucks up so much time which i don't want to spend at it.
>
>> > That's a copout excuse.  You are spending a lot of time right now
>> > beating your head on the brick wall on this issue.  Figuring out a
>> > technical solution in the form of a LiveCD under the umbrella of the
>> > GNOME project might actually be the better argument than what you are
>> > doing now.
>
>> not an excuse just a fact. besides that fact i just need to use fedora
>> with a project of mine.
>
> Yes, it is an excuse. If you want something done, do it yourself.

Just when i'm "calm down again" you come here and post that line.
i absolutely HATE those lines the most in the entire open source world!
i've seen that so many times.. "if you don't like it, make it
yourself! it's open so your free to do so" it's such a lame excuse of
YOU to get rid of me the fast way. Most people are not even capable of
making it! i am not but am going in that direction to make it. (for
the wise guys: i don't mean remaking gnome but learning c++ and
actually now struggling with QT).



From lesmikesell at gmail.com  Sun Dec 21 03:41:13 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 21:41:13 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <gik9p7$3fg$1@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>	<1229692775.3209.670.camel@beck.corsepiu.local>	<494C07F6.7050302@gmail.com>	<gik55g$q83$1@ger.gmane.org>
	<494DA125.50501@gmail.com> <gik9p7$3fg$1@ger.gmane.org>
Message-ID: <494DBAD9.9020004@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> The concept is symmetrical.  How can you hate opening the 2nd window if
>> you didn't hate the first? It's the same thing.  Is is odd vs. even and
>> fun again the 3rd time?
> 
> Krusader supports tabs (independent tabs in each pane). There are no ternary
> file operations in Krusader, so there's nothing which could be done with a
> third pane which can't be done with tabs in the 2 panes.

But if you jump back and forth among more than 2 there would be a lot of 
extra contortions compared to just parking them where you can see them all.

> And the nice thing about having the 2 panes in the same window is that you
> don't have to play around with positioning the windows so they don't
> overlap.

What's wrong with overlap?

> You just maximize the window (or even better, have it start up
> maximized, which Krusader supports just fine) and get it nicely split in
> the middle.

I hate maximized screens. I usually have unrelated windows open that 
need their space too.

> It's also nice for things like keyboard accessibility because
> everything in the file manager knows there's a second pane (for
> example, "copy" defaults to copying to the other pane, so it can be quickly
> used with the keyboard or with one click, no drop target to specify (but
> drag&drop is also possible and the panes are guaranteed not to
> overlap), "unpack" defaults to unpacking to the directory in the other pane
> etc.).

Don't think I'd like that either.  I often leave the target window 
positioned one level above the actual target directories so I can drop 
or paste into any of the visible folders.

> Having used 2-pane file managers for some time now, I'd never want to go
> back.

I've used them and can sort of tolerate them, but (a) don't prefer them 
over independent windows and (b) generally don't like things that behave 
differently as I jump among windows/linux/mac often sharing the screen 
via vmware/rdesktop/NX/vnc, etc.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From seg at haxxed.com  Sun Dec 21 03:53:13 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 20 Dec 2008 21:53:13 -0600
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494D86B7.80804@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <49467E08.2080806@redhat.com>
	<49467EA4.2060909@redhat.com>
	<1229816419.18082.1.camel@localhost.localdomain>
	<494D86B7.80804@redhat.com>
Message-ID: <1229831593.18082.19.camel@localhost.localdomain>

On Sat, 2008-12-20 at 17:58 -0600, Eric Sandeen wrote:
> Callum Lerwick wrote:
> > On Mon, 2008-12-15 at 16:58 +0100, Harald Hoyer wrote:
> >> Eric Sandeen wrote:
> >>>> Turning off bootchart: 30s
> >>>>
> >>>> So all in all we have nearly accomplished the 30 Second Startup Feature 
> >>>> http://fedoraproject.org/wiki/Features/30SecondStartup.
> >>> Well, no; not if this requires data=writeback.  We can't ship that way,
> >>> it's a potential security hole.  You don't want someone's maildir
> >>> suddenly containing pieces of /etc/shadow or whatnot.  The old data that
> >>> may be exposed by data=writeback may not belong to that user.
> >>>
> >>> -Eric
> >>>
> >> So, we switch to xfs as the default FS? :-)
> > 
> > Not until someone writes an XFS filesystem shrinker.
> 
> Just out of curiosity, do you really do offline root ext3 filesystem
> shrinks that often?

Often? It's not a question of frequency. It's a question of... ever.

Anyway yes, most recently when caving in and installing Windows XP
dual-boot on previously Fedora only machines. Three of them, to be
exact.

Ableton Live, Team Fortress 2, and Spore just aren't usable in Wine, or
a VM.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/85a24c17/attachment.sig>

From jkeating at redhat.com  Sun Dec 21 04:14:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Dec 2008 20:14:01 -0800
Subject: Should packages be quiet when nodocs flag is used?
Message-ID: <1229832841.3861.23.camel@localhost.localdomain>

When we compose images for anaconda, we install a bunch of things into a
chroot using the nodocs flag.  MANY packages don't expect this and have
noisy %post sections (more often than not involving trying to call
install-info).

Should packages try to quiet this down or skip install-info if there is
no info file?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/597a9d28/attachment.sig>

From dakingun at gmail.com  Sun Dec 21 04:34:02 2008
From: dakingun at gmail.com (Deji Akingunola)
Date: Sat, 20 Dec 2008 23:34:02 -0500
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <b80014de0812202034s1af80a99md6bb18315834db80@mail.gmail.com>

On Tue, Dec 16, 2008 at 4:47 AM, Patrice Dumas <pertusus at free.fr> wrote:
> Hello,
>
> I am orphaning all my packages. I orphan the devel branch, but I'd
> prefer
> also orphan the stable branches too, so if you are interested don't
> hesitate to ask. I am still willing to maintain the EPEL branches, but
> here, also, if you want to take over, say so.
...

> * grads
> there is an update available for grads, but it has some functionalities
> removed, and also upstream is complicated, with a friendly fork at
> opengrads and last libgadap can be packaged now. I'll still be working
> with upstream, so I could help with chosing which version to package and
> things like that.

I can take over looking after grads, I use it often. What are these
functionalities that you claimed were removed? I've not noticed any
yet.

Deji



From kevin.kofler at chello.at  Sun Dec 21 04:33:52 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 05:33:52 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>	<1229692775.3209.670.camel@beck.corsepiu.local>	<494C07F6.7050302@gmail.com>	<gik55g$q83$1@ger.gmane.org>
	<494DA125.50501@gmail.com> <gik9p7$3fg$1@ger.gmane.org>
	<494DBAD9.9020004@gmail.com>
Message-ID: <gikgvg$dlv$7@ger.gmane.org>

Les Mikesell wrote:
> What's wrong with overlap?

Can't drag&drop (easily).

> Don't think I'd like that either.  I often leave the target window
> positioned one level above the actual target directories so I can drop
> or paste into any of the visible folders.

The target is editable in a text box (using the default is as easy as
pushing ENTER or clicking OK, but you can add some subfolder, or you can
delete the path entirely and enter some relative path, which will then be
relative to the source directory, not the target directory).

> I've used them and can sort of tolerate them, but (a) don't prefer them
> over independent windows and (b) generally don't like things that behave
> differently as I jump among windows/linux/mac often sharing the screen
> via vmware/rdesktop/NX/vnc, etc.

There are also plenty of 2-pane file managers for Window$. I don't want to
advertise any particular one though (not until Krusader 2 binaries for
Window$ are available from the kdewin project ;-) ).

        Kevin Kofler



From lesmikesell at gmail.com  Sun Dec 21 05:08:32 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 20 Dec 2008 23:08:32 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <gikgvg$dlv$7@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>	<1229692775.3209.670.camel@beck.corsepiu.local>	<494C07F6.7050302@gmail.com>	<gik55g$q83$1@ger.gmane.org>	<494DA125.50501@gmail.com>
	<gik9p7$3fg$1@ger.gmane.org>	<494DBAD9.9020004@gmail.com>
	<gikgvg$dlv$7@ger.gmane.org>
Message-ID: <494DCF50.60100@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> What's wrong with overlap?
> 
> Can't drag&drop (easily).

I usually use the right-mouse context menus to cut/copy and paste so it 
doesn't have to be a continuous motion to the destination and I can 
bring a new target to the front if needed.  I don't have to remember the 
modifier to distinguish between copy/move (or whether it is the same 
across all platforms) and it is less susceptible to wiggles that 
accidentally land in the wrong place.

>> Don't think I'd like that either.  I often leave the target window
>> positioned one level above the actual target directories so I can drop
>> or paste into any of the visible folders.
> 
> The target is editable in a text box (using the default is as easy as
> pushing ENTER or clicking OK, but you can add some subfolder, or you can
> delete the path entirely and enter some relative path, which will then be
> relative to the source directory, not the target directory).

Still sounds worse than being able to position over any visible folder 
or the desktop with the right-mouse/paste.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin at scrye.com  Sun Dec 21 05:13:40 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 20 Dec 2008 22:13:40 -0700
Subject: Proposed PackageRenaming guideline
In-Reply-To: <20081221002659.GH2790@free.fr>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<gienqn$cg4$1@ger.gmane.org>
	<20081220134305.3417e4d3@ohm.scrye.com>
	<gik293$jtj$2@ger.gmane.org> <20081221002659.GH2790@free.fr>
Message-ID: <20081220221340.54f61d67@ohm.scrye.com>

On Sun, 21 Dec 2008 01:26:59 +0100
Patrice Dumas <pertusus at free.fr> wrote:

> On Sun, Dec 21, 2008 at 01:22:59AM +0100, Kevin Kofler wrote:
> > Kevin Fenzi wrote:
> > > I would normally agree, but I have seen a number of cases where
> > > people got Obsoletes/Provides wrong and caused a mess. ;(
> > > 
> > > I would like to see them get another pair of eyes on their package
> > > before pushing the renamed version out. Thats all.
> > 
> > Then maybe the guideline should be that the reviewer has to check
> > for valid Obsoletes/Provides, but any other checks are optional (as
> > in: if the reviewer notices something obviously wrong, he/she
> > should report it and request it fixed before approving the rename,
> > but he/she shouldn't be required to go through the whole checklist
> > again)?
> 
> I think it would be right like that. A normal review is unneeded in my
> opinion, and not checking obsoletes... is wrong too.

Yes, that was my intent... just checking the Obsoletes/Provides against
the renaming part of the naming guidelines. 

Of course if they notice something else that could be improved, they
could mention it, but it shouldn't block the rename unless it's
something very serious. 

> Pat

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/d1ab3a57/attachment.sig>

From jkeating at redhat.com  Sun Dec 21 05:15:19 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Dec 2008 21:15:19 -0800
Subject: Packages adding groups in %pre/post
Message-ID: <1229836519.3861.44.camel@localhost.localdomain>

I've noticed that in some situations, packages that add users/groups in
%pre/post can fail.  What I most often see happening is while groupadd
or useradd is installed, and properly requested by Requires(pre) or
Requires(post) on shadow-utils, the /etc/group and /etc/passwd files
themselves aren't in place.  These come from the setup package.

Should the shadow-utils package Require the setup package, or require it
in such a way that it is in place before anything that calls
shadow-utils?  Should the packages that need to add users/groups not
only Requires(foo) on shadow-utils, but also setup?

Thoughts? 
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/ba7da1b0/attachment.sig>

From wolfy at nobugconsulting.ro  Sun Dec 21 05:40:36 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sun, 21 Dec 2008 07:40:36 +0200
Subject: Should packages be quiet when nodocs flag is used?
In-Reply-To: <1229832841.3861.23.camel@localhost.localdomain>
References: <1229832841.3861.23.camel@localhost.localdomain>
Message-ID: <494DD6D4.4090008@nobugconsulting.ro>

On 12/21/2008 06:14 AM, Jesse Keating wrote:
> When we compose images for anaconda, we install a bunch of things into a
> chroot using the nodocs flag.  MANY packages don't expect this and have
> noisy %post sections (more often than not involving trying to call
> install-info).
>   
I've seen that too, I often install servers where there is no need for 
docs, being them either man or info pages. no man*, no groff, no pinfo

> Should packages try to quiet this down or skip install-info if there is
> no info file?
>   
packages  should skip installing ALL the docs. info pages are doc.



From anubis at iinet.net.au  Sun Dec 21 05:43:56 2008
From: anubis at iinet.net.au (anubis at iinet.net.au)
Date: Sun, 21 Dec 2008 14:43:56 +0900
Subject: Stability and Release Cycles - An Idea
Message-ID: <9020.1229838236@iinet.net.au>

Hi folks. I've been a Redhat/Fedora user since RH9. I like it, but I wish there was an option that was a tad less aggressive whilst not being as stagnant or relatively featureless as RHEL (or CentOS). As I understand it, I'm far from alone in that wish.

I have an idea that may improve stability whilst limiting any downside. A brief description follows.

*****

To keep Fedora's identity and purpose, Fedora should maintain the aggressive 6-month release cycle and policy of upstream inclusions - that's no change from now. 

BUT, with every second release (I'll assume every even-numbered release), produce a re-spin at the 6-month mark, call it Fedora "stable" (or some such) and change the policy for updates and quality assurance at that point to maintain improved stability through to EOL - this may translate to fewer new features from that point to EOL but only within that release. 

Shorten the odd-numbered release EOL to 7 months after release - that's one month after the next release. BUT, lengthen the even-numbered release EOL to 19 months - that's one month after the next "stable" re-spin is produced. 

The main advantage is that it puts choice back in the hands of the user who can now choose to go from stable re-spin to stable re-spin (every 12 months) without ever touching the "bleeding edge" of Fedora, yet still gain the advantage of relatively new upstream inclusions that occured in the "aggressive" phase of that release cycle (the first six months) plus the progress gained from the previous odd-numbered release. And, the user can switch from aggressive to stable to aggresive, or any permutation thereof, at will, often (hopefully always) using upgrades.

Doing it this way, Fedora maintains its audience of thrill seekers and Red Hat retains its testing ground for potential inclusions. Uber thrill seekers still have Rawhide and a new release every six months, while more mainsteam users can upgrade to, or install, a "stable" re-spin annually while still doing things "the Fedora/Red Hat way". I expect newer users will be more attracted to the stable re-spins.

This might, and hopefully will, improve user-base growth. Based on my experience and interaction with other users, a sizable proportion of users would be pleased with the additional choice and option of enhanced stability. I expect newer users would be less likely to become frustrated (and possibly switch to another distro or OS) if they have that choice. It also might improve the result for Red Hat with higher conversions from Fedora users to corporate Red Hat users (I'm guessing that a larger and more satisfied user community must be a good thing).

By my thinking (which, of course, I can't promise is right), the workload placed on the Fedora Project shouldn't be much larger than today, if at all. The extra effort applied to even-numbered releases should be roughly cancelled by reduced effort on odd-numbered releases.

*****

So, over to the experts who actually build Fedora. Does the idea have merit?



From ivazqueznet at gmail.com  Sun Dec 21 05:52:06 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sun, 21 Dec 2008 00:52:06 -0500
Subject: rpms/hydrogen-drumkits/devel Classic-626.h2drumkit, NONE, 1.1
	Classic-808.h2drumkit, NONE, 1.1 ColomboAcousticDrumkit.h2drumkit,
	NONE, 
	1.1 ElectricEmpireKit.h2drumkit, NONE, 1.1 HardElectro1.h2drumkit,
	NONE, 
	1.1 K-27_Trash_Kit.h2drumkit, NONE, 1.1 Millo-Drums_v.1.h2drumkit,
	NONE, 1.1 Millo_MultiLayered2.h2drumkit, NONE,
	1.1 Millo_MultiLayered3.h2drumkit, 
	NONE, 1.1 VariBreaks.h2drumkit, NONE, 1.1 hydrogen-drumkits.spec, NONE,
	1.1 import.log, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
In-Reply-To: <20081221053409.EF65D70130@cvs1.fedora.phx.redhat.com>
References: <20081221053409.EF65D70130@cvs1.fedora.phx.redhat.com>
Message-ID: <1229838726.3847.16.camel@ignacio.lan>

On Sun, 2008-12-21 at 05:34 +0000, Orcan Ogetbil wrote:
> Author: oget
> 
> Update of /cvs/pkgs/rpms/hydrogen-drumkits/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv14190/devel
> 
> Modified Files:
> 	.cvsignore sources 
> Added Files:
> 	Classic-626.h2drumkit Classic-808.h2drumkit 
> 	ColomboAcousticDrumkit.h2drumkit ElectricEmpireKit.h2drumkit 
> 	HardElectro1.h2drumkit K-27_Trash_Kit.h2drumkit 
> 	Millo-Drums_v.1.h2drumkit Millo_MultiLayered2.h2drumkit 
> 	Millo_MultiLayered3.h2drumkit VariBreaks.h2drumkit 

> --- NEW FILE Classic-626.h2drumkit ---
> 
> %@;^ ?w^t
B]@^(M?mv??3<g@$qN>>X8

I can't help but think that these are the sort of files that belong in
the lookaside cache and not, in fact, in CVS. Use make upload to place
them in the cache, then cvs remove them.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/36bb887c/attachment.sig>

From jkeating at redhat.com  Sun Dec 21 05:53:20 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Dec 2008 21:53:20 -0800
Subject: Should packages be quiet when nodocs flag is used?
In-Reply-To: <494DD6D4.4090008@nobugconsulting.ro>
References: <1229832841.3861.23.camel@localhost.localdomain>
	<494DD6D4.4090008@nobugconsulting.ro>
Message-ID: <1229838800.3861.45.camel@localhost.localdomain>

On Sun, 2008-12-21 at 07:40 +0200, Manuel Wolfshant wrote:
> packages  should skip installing ALL the docs. info pages are doc.

Well, it does skip it, however it's the %post command that isn't setup
to account for that.  Apparently you have to mung some file after the
rpm is installed to update a cache or something.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081220/6dbc55fa/attachment.sig>

From oget.fedora at gmail.com  Sun Dec 21 05:57:46 2008
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Sun, 21 Dec 2008 00:57:46 -0500
Subject: rpms/hydrogen-drumkits/devel Classic-626.h2drumkit, NONE,
	1.1 Classic-808.h2drumkit, NONE,
	1.1 ColomboAcousticDrumkit.h2drumkit, NONE,
	1.1 ElectricEmpireKit.h2drumkit, NONE,
	1.1 HardElectro1.h2drumkit, NONE, 1.1 K-27_Trash_Kit.h2drumkit,
	NONE, 1.
Message-ID: <e76492710812202157p672c9bfeg66f25d3c32c94225@mail.gmail.com>

2008/12/21 Ignacio Vazquez-Abrams wrote:
>
> On Sun, 2008-12-21 at 05:34 +0000, Orcan Ogetbil wrote:
> > Author: oget
> >
> > Update of /cvs/pkgs/rpms/hydrogen-drumkits/devel
> > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv14190/devel
> >
> > Modified Files:
> >       .cvsignore sources
> > Added Files:
> >       Classic-626.h2drumkit Classic-808.h2drumkit
> >       ColomboAcousticDrumkit.h2drumkit ElectricEmpireKit.h2drumkit
> >       HardElectro1.h2drumkit K-27_Trash_Kit.h2drumkit
> >       Millo-Drums_v.1.h2drumkit Millo_MultiLayered2.h2drumkit
> >       Millo_MultiLayered3.h2drumkit VariBreaks.h2drumkit
>
> > --- NEW FILE Classic-626.h2drumkit ---
> >
> > %@ ;^   ?w ^t   B]@^ (M?mv??3<g@$qN>>X8
>
> I can't help but think that these are the sort of files that belong in
> the lookaside cache and not, in fact, in CVS. Use make upload to place
> them in the cache, then cvs remove them.
>
I noticed. I used the cvs-import.sh script that the guidelines told
me. The script identified these files as non-binary for some reason
(bug?).
I removed them and put them in the look-aside cache.

Thanks for the warning

-Orcan



From mtasaka at ioa.s.u-tokyo.ac.jp  Sun Dec 21 06:02:36 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sun, 21 Dec 2008 15:02:36 +0900
Subject: Should packages be quiet when nodocs flag is used?
In-Reply-To: <1229832841.3861.23.camel@localhost.localdomain>
References: <1229832841.3861.23.camel@localhost.localdomain>
Message-ID: <494DDBFC.4020906@ioa.s.u-tokyo.ac.jp>

Jesse Keating wrote, at 12/21/2008 01:14 PM +9:00:
> When we compose images for anaconda, we install a bunch of things into a
> chroot using the nodocs flag.  MANY packages don't expect this and have
> noisy %post sections (more often than not involving trying to call
> install-info).
> 
> Should packages try to quiet this down or skip install-info if there is
> no info file?

Just for info:
Whether error messages on scriptlets should be completely silent or
not was once discussed (one year ago) and somes person said yes
and some persons said no.

ref:
http://www.redhat.com/archives/fedora-maintainers/2007-July/msg00046.html
http://www.redhat.com/archives/fedora-maintainers/2007-July/msg00048.html
http://www.redhat.com/archives/fedora-maintainers/2007-July/msg00050.html

Mamoru



From mjs at clemson.edu  Sun Dec 21 05:59:44 2008
From: mjs at clemson.edu (Matthew Saltzman)
Date: Sun, 21 Dec 2008 00:59:44 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229816182.23410.187.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
Message-ID: <1229839184.11949.19.camel@valkyrie.localdomain>

On Sat, 2008-12-20 at 18:36 -0500, Dimi Paun wrote:

> And you know what? We *have* hard numbers! We know quite well the
> percentage of people using Windows and MacOSX. It is close to 95%. Every
> time I pointed that out it was completely ignored.

And we know for sure that they use those OSes because they think that
the usability is superior?  Not because practically every computer sold
comes with one or the other and most people still have no idea what
Linux, GNOME, or KDE is, much less are in a position to critique
usability?

> 
> I have presented a fairly tight argument why the default was not chosen
> wisely. Did I receive *one* decent counter argument? Stuff along the
> lines of "Come back with several solid usability studies" is just
> ludicrous.

One thing I've been hoping to see in this discussion--but haven't--is a
citation of a serious usability study by *either* side.  Are there *any*
such studies published in the open literature?  Or are some of us just
assuming that MS and Apple must have done them and are keeping the
results secret for some reason?
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From tim.lauridsen at googlemail.com  Sun Dec 21 06:54:31 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sun, 21 Dec 2008 07:54:31 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <9020.1229838236@iinet.net.au>
References: <9020.1229838236@iinet.net.au>
Message-ID: <494DE827.3020006@googlemail.com>

anubis at iinet.net.au wrote:
> Hi folks. I've been a Redhat/Fedora user since RH9. I like it, but I wish there was an option that was a tad less aggressive whilst not being as stagnant or relatively featureless as RHEL (or CentOS). As I understand it, I'm far from alone in that wish.
>
> I have an idea that may improve stability whilst limiting any downside. A brief description follows.
>
> *****
>
> To keep Fedora's identity and purpose, Fedora should maintain the aggressive 6-month release cycle and policy of upstream inclusions - that's no change from now. 
>
> BUT, with every second release (I'll assume every even-numbered release), produce a re-spin at the 6-month mark, call it Fedora "stable" (or some such) and change the policy for updates and quality assurance at that point to maintain improved stability through to EOL - this may translate to fewer new features from that point to EOL but only within that release. 
>
> Shorten the odd-numbered release EOL to 7 months after release - that's one month after the next release. BUT, lengthen the even-numbered release EOL to 19 months - that's one month after the next "stable" re-spin is produced. 
>
> The main advantage is that it puts choice back in the hands of the user who can now choose to go from stable re-spin to stable re-spin (every 12 months) without ever touching the "bleeding edge" of Fedora, yet still gain the advantage of relatively new upstream inclusions that occured in the "aggressive" phase of that release cycle (the first six months) plus the progress gained from the previous odd-numbered release. And, the user can switch from aggressive to stable to aggresive, or any permutation thereof, at will, often (hopefully always) using upgrades.
>
> Doing it this way, Fedora maintains its audience of thrill seekers and Red Hat retains its testing ground for potential inclusions. Uber thrill seekers still have Rawhide and a new release every six months, while more mainsteam users can upgrade to, or install, a "stable" re-spin annually while still doing things "the Fedora/Red Hat way". I expect newer users will be more attracted to the stable re-spins.
>
> This might, and hopefully will, improve user-base growth. Based on my experience and interaction with other users, a sizable proportion of users would be pleased with the additional choice and option of enhanced stability. I expect newer users would be less likely to become frustrated (and possibly switch to another distro or OS) if they have that choice. It also might improve the result for Red Hat with higher conversions from Fedora users to corporate Red Hat users (I'm guessing that a larger and more satisfied user community must be a good thing).
>
> By my thinking (which, of course, I can't promise is right), the workload placed on the Fedora Project shouldn't be much larger than today, if at all. The extra effort applied to even-numbered releases should be roughly cancelled by reduced effort on odd-numbered releases.
>
> *****
>
> So, over to the experts who actually build Fedora. Does the idea have merit?
>
>   
This has been discussed many time on the list, the problem is that you 
cant have it both ways, you cant have a LTS release with the latest and 
greatest.
The only way a LTS release make sence is to freeze the code, test, test 
and test. And then backport security related fixes.
RHEL/Centos does this well and Fedora does  the latest and greatest part.

Tim



From oget.fedora at gmail.com  Sun Dec 21 07:15:02 2008
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Sun, 21 Dec 2008 02:15:02 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229839184.11949.19.camel@valkyrie.localdomain>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
	<1229839184.11949.19.camel@valkyrie.localdomain>
Message-ID: <e76492710812202315k76e93c0s3adf097a6709c0de@mail.gmail.com>

On Sun, Dec 21, 2008 at 12:59 AM, Matthew Saltzman wrote:
> On Sat, 2008-12-20 at 18:36 -0500, Dimi Paun wrote:
>
>> And you know what? We *have* hard numbers! We know quite well the
>> percentage of people using Windows and MacOSX. It is close to 95%. Every
>> time I pointed that out it was completely ignored.
>
> And we know for sure that they use those OSes because they think that
> the usability is superior?  Not because practically every computer sold
> comes with one or the other and most people still have no idea what
> Linux, GNOME, or KDE is, much less are in a position to critique
> usability?
>
>>
>> I have presented a fairly tight argument why the default was not chosen
>> wisely. Did I receive *one* decent counter argument? Stuff along the
>> lines of "Come back with several solid usability studies" is just
>> ludicrous.
>
> One thing I've been hoping to see in this discussion--but haven't--is a
> citation of a serious usability study by *either* side.  Are there *any*
> such studies published in the open literature?  Or are some of us just
> assuming that MS and Apple must have done them and are keeping the
> results secret for some reason?
> --
>                Matthew Saltzman
>

This reminds me of a recent discussion I had in the plasma-devel list
of KDE. The topic was setting the default behavior (enable/disable)
for grouping tasks in the taskbar. Without exception, everybody, that
I talked about this subject in person regardless of what OS they use,
disables task grouping. Moreover most people find that having this as
default is insulting. I even found a HOWTO online that describes the
way to disable this behavior on Windows. The HOWTO ended with a
sentence in the lines of "... and enjoy feeling less retarded."

Nevertheless, I am from a scientific community and most people I talk
to do not represent a group of typical users. People from the
plasma-devel list told me that such studies have been done in detail,
and that's why MAC and Windows enabled task grouping as default and
that's what KDE will do too.

As a researcher, I do not believe in the studies done by these
companies. They do not have scientific value. Do you remember the
"research article" pubslihed by MS, claiming that maintaining a
Windows server is cheaper than a Linux server? Didn't you laugh
when/if you saw that article? This illustrates their understanding of
doing research.

This kind of research (setting the defaults) needs to be done by
researchers, I am talking about statisticians, mathematicians,
physicists. I offered my help in bringing in such a project to life in
KDE, but I haven't got any responses. Maybe we should do such a
project in Fedora. Since we are the ones who build the bridge between
the developers and the users, we have the best sight of both sides.

-Orcan



From metherid at gmail.com  Sun Dec 21 07:20:37 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Sun, 21 Dec 2008 12:50:37 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229816182.23410.187.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229723428.3861.3.camel@localhost.localdomain>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<494D556B.9080807@gmail.com>	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
Message-ID: <494DEE45.9090304@gmail.com>

Dimi Paun wrote:
> On Sun, 2008-12-21 at 02:40 +0530, Rahul Sundaram wrote:
>   
>> You are being self contradictory. If you don't have any hard numbers, 
>> you cannot actually claim a majority at all and yes, finding hard 
>> numbers is difficult if not impossible and doesn't really translate
>> into usability anyway. I wouldn't blame you for this.
>>     
>
> But this is exactly what drives people up the wall:
>   - Please change X
>   - Why would we, how can we know if other like it like that?
>   - Look, there's plenty of indication on the web that that's the case
>   - Pfff, even 95% numbers are not good, we want HARD numbers!
>   - ... but ... that's nearly impossible to get :(
>   - Sure, we know it's impossible, that's why we asked for them. Duh
>   
I explicitly did not ask for them. 95% is just made up statistics as 
usual. I merely said that claiming a majority is impossible too. I also 
noted that even things changed with many usability studies behind them 
have lots of people hating that particular change.  So there isn't one 
particular default that satisfies everybody's tastes and that's ok since 
changing it is pretty easy in this case and the non default cases are 
being improved all the time as well.

Rahul



From kevin.kofler at chello.at  Sun Dec 21 07:24:33 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 08:24:33 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<494ABC3F.8000700@fedoraproject.org>	<6e24a8e80812181327j3d127a01y9b99ffcb7ee4ab01@mail.gmail.com>	<20081218215107.GB1366434@hiwaay.net>	<e5f36bc70812190429n17f19abbla14b1a9828ba3fda@mail.gmail.com>	<385866f0812190438n2125f497r84b35ef5618557d8@mail.gmail.com>	<1229692775.3209.670.camel@beck.corsepiu.local>	<494C07F6.7050302@gmail.com>	<gik55g$q83$1@ger.gmane.org>	<494DA125.50501@gmail.com>
	<gik9p7$3fg$1@ger.gmane.org>	<494DBAD9.9020004@gmail.com>
	<gikgvg$dlv$7@ger.gmane.org> <494DCF50.60100@gmail.com>
Message-ID: <gikqvh$110$1@ger.gmane.org>

Les Mikesell wrote:
> Still sounds worse than being able to position over any visible folder
> or the desktop with the right-mouse/paste.

Krusader also supports using the clipboard for files.

        Kevin Kofler



From metherid at gmail.com  Sun Dec 21 07:28:50 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Sun, 21 Dec 2008 12:58:50 +0530
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <gik89l$utp$2@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>	<604aa7910812201224t8c9b86bk8f0066975f753467@mail.gmail.com>	<494D57C9.5090809@gmail.com>
	<494D5D4C.7090704@gmail.com> <gik89l$utp$2@ger.gmane.org>
Message-ID: <494DF032.10809@gmail.com>

Kevin Kofler wrote:
> Rahul Sundaram wrote:
>   
>> https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment
>>     
>
> That's only relevant if the configuration change is actually a patch against
> an upstream package. The KDE settings are in a kde-settings package for
> which we are upstream ( https://fedorahosted.org/kde-settings/ ). :-) A
You are merely consolidating all your changes into a separate package 
(what has its advantages) but it is still deviations from upstream. The 
spirit of the guidelines is to avoid such changes or atleast document 
them and that is the case for kde-settings as well. I was around in 
FUDCon Boston when Aaron Seigo suggested that changed btw and even then 
talked to Rex Dieter that we should make a good faith effort to atleast 
notify upstream of the changes we are making. If a number of downstreams 
are making a change, they might be convinced to change the defaults.  
Sometimes, upstream projects have noted important side effects of such 
changes, which package maintainers were not aware of that  (that opens a 
security risk, that particular option is unstable and hard to reproduce 
etc).
> lso
> note that it's only a SHOULD, not a MUST, and that "# change braindead
> upstream default" is a perfectly valid comment under that guideline.
>   
See above. 

Rahul



From kevin.kofler at chello.at  Sun Dec 21 07:33:12 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 08:33:12 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
	<1229839184.11949.19.camel@valkyrie.localdomain>
	<e76492710812202315k76e93c0s3adf097a6709c0de@mail.gmail.com>
Message-ID: <gikrfp$26k$1@ger.gmane.org>

Orcan Ogetbil wrote:
> This reminds me of a recent discussion I had in the plasma-devel list
> of KDE. The topic was setting the default behavior (enable/disable)
> for grouping tasks in the taskbar. Without exception, everybody, that
> I talked about this subject in person regardless of what OS they use,
> disables task grouping. Moreover most people find that having this as
> default is insulting. I even found a HOWTO online that describes the
> way to disable this behavior on Windows. The HOWTO ended with a
> sentence in the lines of "... and enjoy feeling less retarded."

Actually I liked task grouping in KDE 3, I didn't disable it. Right now I'm
using 4.1.3 which doesn't support it, and I don't really notice it missing,
but still I plan to leave it on when it'll be supported again.

        Kevin Kofler



From rakesh.pandit at gmail.com  Sun Dec 21 09:06:58 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 21 Dec 2008 14:36:58 +0530
Subject: Package Review Stats for the week ending December 14, 2008
In-Reply-To: <b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
References: <1229435781.4103.5.camel@localhost.localdomain>
	<1229443261.4049.324.camel@macbook.infradead.org>
	<b401d2530812160808r655736b8pb3a7ae3d15a635f4@mail.gmail.com>
Message-ID: <b401d2530812210106t3328952k4e56de47908db4f0@mail.gmail.com>

2008/12/16 Rakesh Pandit <rakesh.pandit at gmail.com>:
> 2008/12/16 David Woodhouse <dwmw2 at infradead.org>:
>> On Tue, 2008-12-16 at 08:56 -0500, Brian Pepple wrote:
>>> Top three  FAS account holders who have completed reviewing "Package
>>> review" components on bugzilla for the week ending December 14th, 2008
>>> were Parag AN(????), Manuel Wolfshant, and Jason Tibbitts.  Below is
>>> the number of completed package reviews done.
>>
>> Thanks for doing these reports -- it's useful. And it reminds me that I
>> haven't done many reviews in the last few weeks, while my DSL line has
>> been crap. I'll try to catch up.
>>
>> Any chance we could include the number of open review bugs in the
>> report? And the number of _new_ reviews opened since the previous
>> report?
>>

Done

https://fedorahosted.org/triage/ticket/11

@paragn

Thanks for reporting the issue.

-- 
rakesh



From hughsient at gmail.com  Sun Dec 21 10:11:09 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 21 Dec 2008 10:11:09 +0000
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229801171.24251.19.camel@arekh.okg>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
	<1229788642.16655.12.camel@arekh.okg>
	<20081220180913.45f62880@lain.camperquake.de>
	<1229801171.24251.19.camel@arekh.okg>
Message-ID: <1229854269.3382.5.camel@hughsie-work.lan>

On Sat, 2008-12-20 at 20:26 +0100, Nicolas Mailhot wrote:
> Le samedi 20 d?cembre 2008 ? 18:09 +0100, Ralf Ertzinger a ?crit :
> > Hi.
> > 
> > On Sat, 20 Dec 2008 16:57:22 +0100, Nicolas Mailhot wrote
> > 
> > > If making it plain what the current official encoding and format of
> > > spec files is is being difficult, yes I'm being difficult.
> > 
> > So this is 'We do what we must, because we can', kind of?
> 
> It's a case of ?if your application can not handle my conformant file
> that's you application problem not mine?.

This isn't about applications supporting UTF8. If it doesn't support
UTF8 it's broken, we both agree about that.

> And lastly, it's a case of ?I don't take intimidation or bullying well?

I'm not bullying you. I'm asking you to stop doing your own thing, and
start using the convention that everyone else _except you_ is using.

> Is this sufficient for you?

No. Please stop being difficult and just follow what everyone else is
doing. You're just making yourself look ridiculous.

Richard.




From metherid at gmail.com  Sun Dec 21 10:21:47 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Sun, 21 Dec 2008 15:51:47 +0530
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229854269.3382.5.camel@hughsie-work.lan>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>	<1229770470.5584.1.camel@hughsie-work.lan>	<1229778828.14462.2.camel@arekh.okg>	<1229787602.4136.6.camel@hughsie-work.lan>	<1229788642.16655.12.camel@arekh.okg>	<20081220180913.45f62880@lain.camperquake.de>	<1229801171.24251.19.camel@arekh.okg>
	<1229854269.3382.5.camel@hughsie-work.lan>
Message-ID: <494E18BB.8050005@gmail.com>

Richard Hughes wrote:
> I'm not bullying you. I'm asking you to stop doing your own thing, 
> andstart using the convention that everyone else _except you_ is using.
Convention here translates into fuzzy undocumented packaging guidelines. 
If we truly want to enforce something, we need to make it a packaging 
guideline that everyone will more consistently follow. 

https://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure

If you need more help, feel free to ask.

Rahul



From rawhide at fedoraproject.org  Sun Dec 21 11:41:44 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 21 Dec 2008 11:41:44 +0000 (UTC)
Subject: rawhide report: 20081221 changes
Message-ID: <20081221114144.E9B1F1F8247@releng2.fedora.phx.redhat.com>

Compose started at Sun Dec 21 06:01:12 UTC 2008

New package ario
        Ario MPD Client
New package rainbow
        A one-person isolation shell
New package vhd2vl
        VHDL to Verilog translator
Updated Packages:

avant-window-navigator-0.2.6-14.fc11
------------------------------------
* Sat Dec 20 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 0.2.6-14
- Add missing libXres buildrequires


cairo-dock-2.0.0-0.3.svn1447_trunk.fc11
---------------------------------------
* Sun Dec 21 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1447


cstream-2.7.6-1.fc11
--------------------
* Sat Dec 20 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 2.7.6-1
- Update to upstream's 2.7.6 release.


ctemplate-0.91-3.fc11
---------------------

cyphesis-0.5.18-1.fc11
----------------------
* Thu Dec 18 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.18-1
- Update to 0.5.18


deskbar-applet-2.25.1-6.fc11
----------------------------
* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.25.1-6
- Rebuild for new libgnome-desktop


ember-0.5.5-1.fc11
------------------
* Sat Dec 20 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.5-1
- Update to 0.5.5


ember-media-0.5.5-1
-------------------
* Sat Dec 20 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.5-1
- Update to 0.5.5


empathy-2.25.3-2.fc11
---------------------
* Sat Dec 20 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 2.25.3-2
- Update mission-control-convert patch.

* Wed Dec 17 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.3-1
- Update to 2.25.3

* Mon Dec  1 17:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 2.25.2-1
- Update to new upstream release (2.25.2)


flasm-1.62-5.fc11
-----------------
* Sat Dec 20 17:00:00 2008 Patrice Dumas <pertusus at free.fr> 1.62-4
- patch for new bison, give type for $$ in midrule


freetennis-0.4.8-16.fc11
------------------------
* Sat Dec 20 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> - 0.4.8-16
- Fix building with latest ocaml-images

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.4.8-15
- Rebuild for OCaml 3.11.0+beta1.


git-1.6.0.6-1.fc11
------------------
* Sat Dec 20 17:00:00 2008 Todd Zullinger <tmz at pobox.com> 1.6.0.6-1
- git-1.6.0.6
- Fixes a local privilege escalation bug in gitweb
  (http://article.gmane.org/gmane.comp.version-control.git/103624)
- Add gitk Requires to git-gui (bug 476308)


gnome-commander-1.2.8-0.3.svn2368_trunk.fc11
--------------------------------------------
* Sun Dec 21 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2368


gnome-keyring-2.25.2-3.fc11
---------------------------
* Sat Dec 20 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.25.2-3
- Init dbus later (fixes ssh-agent,
  patch from Yanko Kaneti, bug 476300)


google-gadgets-0.10.4-1.fc11
----------------------------
* Sat Dec 20 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.10.4-1
- Update to 0.10.4 (#477251)
- -devel: Requires: %name-gtk %name-qt (devel symlinks)
- BR: pkgconfig (automatic pkgconfig deps)


gpicview-0.1.11-1.fc11
----------------------
* Sat Dec 20 17:00:00 2008 Marc Wiriadisastra <marc at mwiriadi.id.au> - 0.1.11-1
- New upstream release


gpp4-1.0.4-12.fc11
------------------
* Sat Dec 20 17:00:00 2008 Tim Fenn <fenn at stanford.edu> - 1.0.4-12
- add libtoolize


gtk-sharp2-2.12.7-2.fc11
------------------------
* Sat Dec 20 17:00:00 2008 Xavier lamien <lxtnow[at]gmail.com> - 2.12.7-2
- Rebuild.

* Fri Dec 12 17:00:00 2008 Xavier lamien <lxtnow[at]gmail.com> - 2.12.7-1
- Update release.


gyachi-1.1.59-7.fc11
--------------------
* Fri Dec 19 17:00:00 2008 Rakesh Pandit <rakesh at fedoraproject.org> - 1.1.59-7
- Fixed wrong obsoletes names for xmms and photo album plugin
- Fixed rpmlint noise for changelog and removed mix of space and tabs on SRPM


jd-2.1.0-0.4.svn2587_trunk.fc11
-------------------------------
* Sun Dec 21 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2587


kernel-2.6.28-0.140.rc9.git1.fc11
---------------------------------
* Sat Dec 20 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
- Linux 2.6.28-rc9-git1
  Rebased patches:
   linux-2.6-pciehp-update.patch
   drm-next.patch

* Fri Dec 19 17:00:00 2008 Adam Jackson <ajax at redhat.com>
- config-generic: FB_VIRTUAL=m


libHX-1.25-3.fc11
-----------------
* Sat Dec 20 17:00:00 2008 Till Maas <opensource at till.name> - 1.25-3
- Fix .so symlink


librsync-0.9.7-13.fc11
----------------------
* Sat Dec 20 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 0.9.7-13
- Run libtoolize before %configure to avoid libtool 2.2 errors
- Added a patch to make rdiff aware of -i and -z getopt options
- Updated man page for how to use rdiff and removed a dead link


libstroke-0.5.1-20.fc11
-----------------------
* Sat Dec 20 17:00:00 2008 Chitlesh Goorah <chitlesh at fedoraproject.org> - 0.5.1-20
- fix for rawhide's libtool 2.2.6

* Sat Dec 20 17:00:00 2008 Chitlesh Goorah <chitlesh at fedoraproject.org> - 0.5.1-19
- rebuild for proper tagging

* Sat Dec 20 17:00:00 2008 Chitlesh Goorah <chitlesh at fedoraproject.org> - 0.5.1-18
- fix for x86_64 build fix RHBZ # 465030

* Mon Jun 16 18:00:00 2008 Chitlesh Goorah <chitlesh at fedoraproject.org> - 0.5.1-17
- Bugfix 449516 FTBFS libstroke-0.5.1-17.fc9


libtheora-1.0-2.fc11
--------------------
* Sat Dec 20 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1:1.0-2
- Put development documentation in its own subpackage to fix multilib
  conflicts (rh 477290)


mesa-7.3-0.2.fc11
-----------------
* Sun Dec 21 17:00:00 2008 Dave Airlie <airlied at redhat.com> 7.3-0.2
- intel-fix-sarea-define.patch - workaround wrong define
- intel-triple-remove.patch - remove triple buffering

* Sat Dec 20 17:00:00 2008 Dave Airlie <airlied at redhat.com> 7.3-0.1
- Mesa rebase to upstream + new r300 bufmgr code (may need more work)


midori-0.1.1-1.fc11
-------------------
* Sat Dec 20 17:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 0.1.1-1
- Update to new upstream release (0.1.1): contains many enhancements and
  bugfixes - including error pages, basic documentation, panel history
  support, icon caching, libsoup integration, support for WebKit's Inspector
  functionality, and the beginnings of support for runtime extensions (in C).


monkey-bubble-0.4.0-10.fc11
---------------------------
* Sat Dec 20 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.4.0-10
- Fix building on rawhide (explicitly BR esound-devel)


monosim-1.3.0.2-1.fc11
----------------------

nco-3.9.5-3.fc11
----------------
* Sun Dec 21 17:00:00 2008 - Patrice Dumas <pertusus at free.fr> - 3.9.5-3
- call libtoolize
- remove unneeded dependencies on curl-devel, libxml2-devel, librx-devel
- ship more documentation


netcdf-decoders-5.0.0-3.fc11
----------------------------
* Fri Dec 19 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 5.0.0-3
- New netcdf location

* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 5.0.0-2
- Fix unowned directory /usr/share/netcdf-decoders


netcdf-perl-1.2.3-8.fc11
------------------------
* Fri Dec 19 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 1.2.3-8
- Rebuild for new netcdf


nfs-utils-1.1.4-10.fc11
-----------------------
* Fri Dec 19 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-10
- Re-enabled and fixed/enhanced tcp wrappers.

* Wed Dec 17 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-9
- text-based mount command: add function to parse numeric mount options
- text-based mount command: use po_get_numeric() for handling retry
- sm-notify command: fix a use-after-free bug
- statd: not unlinking host files

* Thu Dec 11 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-8
- mount command: AF_INET6 support for probe_bothports()
- mount command: support AF_INET6 in probe_nfsport() and probe_mntport()
- mount command: full support for AF_INET6 addresses in probe_port()
- gssd/svcgssd: add support to retrieve actual context expiration
- svcgssd: use the actual context expiration for cache

* Sat Dec  6 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-7
- sm-notify: always exiting without any notification.


ochusha-0.5.99.71-0.4.cvs20081221T1420.fc11
-------------------------------------------
* Sun Dec 21 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


offlineimap-6.0.3-2.fc11
------------------------
* Thu Dec 18 17:00:00 2008 Christoph H??ger <choeger at cs.tu-berlin.de> 6.0.3-1
- Update to latest version
- use own tarball instead of debian ftp


openoffice.org-3.0.1-14.1.fc11
------------------------------
* Fri Dec 19 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-14.1
- next milestone
- Resolves: rhbz#475007 openoffice.org-3.0.1.ooo97196.vcl.ensuretheme.whenqttesting.patch
- add ga thesaurus
- add workspace.vcl98.patch, and merge 
  openoffice.org-3.0.1.ooo97064.fpicker.honour-uilang-override.patch
  into it
- Resolves: rhbz#477016 playing video under full-screen presentation went away
- Resolves: rhbz#474719 openoffice.org-3.0.1.ooo97428.config_office.xinerama-on-x86_64.patch
- drop integrated workspace.sjfixes12.patch
- drop integrated workspace.swffixes02.patch
- Workaround: rhbz#477174 where gdk_x11_get_server_time now hangs for us


perl-Class-MethodMaker-2.13-1.fc11
----------------------------------
* Sat Dec 20 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 2.13-1
- Upstream update.


perl-Locale-Maketext-Lexicon-0.76-1.fc11
----------------------------------------
* Sat Dec 20 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.76-1
- Upstream update.


perl-Test-Warn-0.11-1.fc11
--------------------------
* Sat Dec 20 17:00:00 2008 Paul Howarth <paul at city-fan.org> - 0.11-1
- Update to 0.11 (#477298)
- Buildreq ExtUtils::MakeMaker, File::Spec, Test::Builder,
  Test::Builder::Tester, and Test::More (from upstream Makefile.PL)
- Add runtime dependencies on Test::Builder and Test::Builder::Tester


perl-XML-LibXSLT-1.68-1.fc11
----------------------------
* Sat Dec 20 17:00:00 2008 Paul Howarth <paul at city-fan.org> - 1.68-1
- update to 1.68
- relax hard version requirement on XML::LibXML, which is at 1.69 upstream
  but 1.67 or above will suffice (care will still have to be taken to keep
  the packages in sync, particularly when XML::LibXML is updated)
- specify $RPM_OPT_FLAGS once rather than twice
- drop historical perl version requirement, which is met even by EL-3
- explicitly buildreq ExtUtils::MakeMaker rather than just perl-devel


prboom-2.5.0-1.fc11
-------------------
* Sat Dec 20 17:00:00 2008 Wart <wart at kobold.org> 2.5.0-1
- Update to 2.5.0


ruby-hpricot-0.6-3.fc11
-----------------------
* Sat Dec 20 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.6-3
- Fix build error related to Windows constant, detected
  by Matt's mass build
  (possibly due to rubygems 1.3.1 change)


smstools-3.1.3-5.fc11
---------------------
* Sat Dec 20 17:00:00 2008 Marek Mahut <mmahut at fedoraproject.org> - 3.1.3-5
- Upstream release
- RHBZ#437620 root privileges are mandatory for sending/receiving an sms
- RHBZ#443790 smstools logrotate does not work properly
- RHBZ#461862 smssend creates rw------- files


soundtouch-1.3.1-11.fc11
------------------------
* Sat Dec 20 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.3.1-11
- Fix compilation with libtool 2.x


system-config-printer-1.1.1-1.fc11
----------------------------------
* Sat Dec 20 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.1.1-1
- 1.1.1.


tcl-tktreectrl-2.2.8-2.fc11
---------------------------
* Thu Dec 18 17:00:00 2008 Wart <wart at kobold.org> 2.2.8-2
- Move html documentation to proper doc directory
- Add missing Requires: on tk
- Remove redundant BuildRequires.  Everything necessary is brought in by
  tk-devel.


tcllib-1.11.1-1.fc11
--------------------
* Sat Dec 20 17:00:00 2008 Wart <wart at kobold.org> - 1.11.1-1
- Update to 1.11.1


themonospot-0.7.1.1-1.fc11
--------------------------

tsclient-2.0.1-10.fc11
----------------------
* Sat Dec 20 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 2.0.1-10
- Rebuild


ufraw-0.14.1-4.fc11
-------------------
* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.14.1-4
- respin (eviv2)


unique-1.0.4-3.fc11
-------------------
* Sat Dec 20 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1.0.4-3
- Actually apply the patch

* Sat Dec 20 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1.0.4-2
- Fix a nautilus segfault


vegastrike-0.5.0-7.fc11
-----------------------
* Fri Dec 19 17:00:00 2008 Benjamin Kosnik  <bkoz at redhat.com> - 0.5.0-7
- Add boost-make_shared.patch
- Use -DBOOST_PYTHON_NO_PY_SIGNATURES.
- Rebuild for boost-1.37.0.


wammu-0.29-3.fc11
-----------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.29-3
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.29-2
- Rebuild for Python 2.6

* Sun Oct 12 18:00:00 2008 Xavier Lamien <lxtnow[at]gmail.com> - 0.29-1
- Update release.


xorg-x11-drv-i810-2.5.99.1-0.1.fc11
-----------------------------------
* Sun Dec 21 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.5.99.1-0.1
- intel rebase to upstream release + master fixes


xorg-x11-proto-devel-7.4-12.fc11
--------------------------------
* Sat Dec 20 17:00:00 2008 Dave Airlie <airlied at redhat.com> 7.4-12
- update dri2proto


xplanet-1.2.0-4.fc11
--------------------
* Sun Dec 21 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.2.0-4
- Remove xplanet private ttf file, use system one


Summary:
Added Packages: 3
Removed Packages: 0
Modified Packages: 56
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	cobbler-1.4.0-2.fc11.noarch requires python(abi)=2.6
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	e16-0.16.8.14-1.fc10.i386 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.5-1.noarch requires dejavu-fonts
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	firefox-3.0.5-1.fc10.i386 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gnomedesktop-2.24.0-5.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mono-sharpcvslib-0.35-3.fc10.i386 requires mono(nunit.framework) = 0:2.2.0.0
	mozvoikko-0.9.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-examples-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-examples-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-examples-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-python-2.1.1-5.fc10.i386 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.i386 requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.i386 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-search-tool-0.6.6-4.fc11.i386 requires libgnome-desktop-2.so.10
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts
	yelp-2.24.0-4.fc10.i386 requires gecko-libs >= 0:1.9.0.5



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	banshee-1.4.1-1.fc11.x86_64 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	blam-1.8.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	cobbler-1.4.0-2.fc11.noarch requires python(abi)=2.6
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.x86_64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.5-1.noarch requires dejavu-fonts
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	firefox-3.0.5-1.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.x86_64 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mono-sharpcvslib-0.35-3.fc10.x86_64 requires mono(nunit.framework) = 0:2.2.0.0
	mozvoikko-0.9.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.i386 requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.i386 requires libltdl.so.3
	player-2.1.1-5.fc10.i386 requires libboost_signals.so.3
	player-2.1.1-5.fc10.x86_64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libboost_signals.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	player-examples-2.1.1-5.fc10.x86_64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.x86_64 requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-5.1.fc10.x86_64 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts
	yelp-2.24.0-4.fc10.x86_64 requires gecko-libs >= 0:1.9.0.5



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.5-1.noarch requires dejavu-fonts
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	firefox-3.0.5-1.fc10.ppc requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.ppc requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mozvoikko-0.9.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	player-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-2.1.1-5.fc10.ppc requires libboost_signals.so.3
	player-2.1.1-5.fc10.ppc requires libboost_thread-mt.so.3
	player-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc requires libboost_thread-mt.so.3
	player-examples-2.1.1-5.fc10.ppc requires libltdl.so.3
	player-examples-2.1.1-5.fc10.ppc requires libboost_signals.so.3
	player-python-2.1.1-5.fc10.ppc requires python(abi) = 0:2.5
	player-python-2.1.1-5.fc10.ppc requires libpython2.5.so.1.0
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-5.1.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-5.1.fc10.ppc requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc requires libgnome-desktop-2.so.10
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts
	yelp-2.24.0-4.fc10.ppc requires gecko-libs >= 0:1.9.0.5



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	ember-media-0.5.5-1.noarch requires dejavu-fonts
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	firefox-3.0.5-1.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mozvoikko-0.9.5-5.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libboost_signals.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	player-examples-2.1.1-5.fc10.ppc64 requires libltdl.so.3()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	player-python-2.1.1-5.fc10.ppc64 requires python(abi) = 0:2.5
	presto-utils-0.3.3-2.fc10.noarch requires python(abi) = 0:2.5
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-5.1.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-5.1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts
	yelp-2.24.0-4.fc10.ppc64 requires gecko-libs >= 0:1.9.0.5





From hughsient at gmail.com  Sun Dec 21 11:55:52 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 21 Dec 2008 11:55:52 +0000
Subject: rawhide report: 20081220 changes
In-Reply-To: <494E18BB.8050005@gmail.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
	<1229788642.16655.12.camel@arekh.okg>
	<20081220180913.45f62880@lain.camperquake.de>
	<1229801171.24251.19.camel@arekh.okg>
	<1229854269.3382.5.camel@hughsie-work.lan> <494E18BB.8050005@gmail.com>
Message-ID: <1229860552.3382.98.camel@hughsie-work.lan>

On Sun, 2008-12-21 at 15:51 +0530, Rahul Sundaram wrote:
> Convention here translates into fuzzy undocumented packaging
> guidelines. 

Right. There's loads of guidelines that people follow every day, but we
don't need to make laws about them.

When you stand on an escalator, it's polite to stand to one side so
people in a rush can walk up the side.

There's no law saying you have to do that, but it's common courtesy to
copy everyone else and stand to one side. People tend to get pretty
pissed off if kids are doing handstands on escalators, even though there
is no law saying you can't.

> If we truly want to enforce something, we need to make it a packaging 
> guideline that everyone will more consistently follow. 
> 
> https://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure

If we have to ratify every small detail of building a distro using a
formal means, we've become Debian. In my opinion Debian is dying because
of all the politics and guidelines, and Fedora shouldn't go down the
same route.

This is a simple case where I'm asking someone politely to do the same
thing as everyone else. Like a gentleman asking a person doing
handstands on escalators to stop doing that and stand to one side like
everyone else.

> If you need more help, feel free to ask.

I'll support anyone proposing guidelines, but I don't want to spend any
more of my time on this trivial issue. It would be like campaigning to
ban people doing handstands on escalators, making me look as ridiculous
in the process.

Richard.




From muepsj at gmail.com  Sun Dec 21 12:39:39 2008
From: muepsj at gmail.com (=?UTF-8?Q?Joonas_Saraj=C3=A4rvi?=)
Date: Sun, 21 Dec 2008 14:39:39 +0200
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D3DB2.4000304@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
Message-ID: <66ec675b0812210439t3063059bgaf8eb5cf23966652@mail.gmail.com>

2008/12/20 Les Mikesell <lesmikesell at gmail.com>:

> Can someone who likes (even tolerates) spatial mode describe why?  I'm
> completely baffled as to why anyone would prefer windows left open all over
> the place randomly instead of just explicitly opening ones yourself in
> places where you want them.  For me, it is _always_ extra work to close the
> unwanted windows compared to opening the ones I want.

I have used Nautilus in spatial mode as my main file manager for a
couple of years.

I like the spatial mode because:

The interface is very clean and simple. There are no toolbars or tabs,
just the actual files that I am interested in.

The folders open where I left them the last time, also retaining their
settings. I can have a bigger window for directories with lots of
stuff or where I want to have a bigger zoom level to make better use
of the preview images, or a smaller window for others.

Drag and drop is easy, but I don't think this is the best thing about
spatial mode. It's just an adde bonus.

Things I don't like in spatial mode:

Tendency to create create lots of windows.

What I can do to avoid opening a hundred and one windows?

Use shift-click or middle click to close the parent folder's window.

Use the bookmark feature of Nautilus.

Set common 'root' directories, like your homedir and to list mode
(ctrl+2) and use the tree to navigate to your target without opening
new windows at all.

Use Gnome's session management to have your desired directories
already open when you need them. Less navigating -> less windows. This
of course doesn't work for those who switch the task they are doing
all the time, but it certainly works for me.

Plan your home directory's contents so that you don't have too many
levels of directories there. This also doesn't work for everyone, but
it may suit some.


What could Nautilus developers do to make spatial mode more useful?

Nautilus' spatial mode sucks worst when I need to get to a specific
directory that I don't happen to have a shortcut available for. Making
it easier to 'get to places' would greatly make spatial mode more
useful by avoiding the need to surf through a lot of dirs, while
possibly leaving a long trail of windows behind.

For example, make a global Gnome shortcut that would open the dialog
that Nautilus currently displays when I press Ctrl+L in it. Also try
to make the dialog easier to use by offering more visual cues and
keyboard shortcuts. I think the deskbar applet can be used to do this,
at least to an extent, but I haven't used it much lately.

Also, it would be nice if I could easily get rid of the windows I have
happened to create. A shortcut for closing all the Nautilus windows
would sometimes be nice. Other potential targets for shortcuts could
be to kill the all the other Nautilus windows but the one I currently
have focused, or maybe only the parent directories of the currently
focused directory.


I think that spatial mode is very useful as it is, but is also has
potential to be a lot better and easier and faster to use.


Somewhere it was mentioned that all the other major distros have the
browser mode as default. However, I think at least Debian has spatial
mode as the default mode for Nautilus.

-- 
Joonas Saraj?rvi
muepsj at gmail.com



From bernie at codewiz.org  Sun Dec 21 12:40:49 2008
From: bernie at codewiz.org (Bernie Innocenti)
Date: Sun, 21 Dec 2008 07:40:49 -0500
Subject: Orphaned font packages
Message-ID: <494E3951.9030601@codewiz.org>

Hello,

I've just converted these two packages to the new font packaging
guidelines, but then I realized I didn't make an ideal maintainer
because I don't use them and I can't even read those languages :-)

So here they are, for anyone who would like to take them over from me:

https://admin.fedoraproject.org/pkgdb/packages/name/nafees-web-naskh-fonts
https://admin.fedoraproject.org/pkgdb/packages/name/abyssinica-fonts

-- 
   // Bernie Innocenti - http://www.codewiz.org/
 \X/  Sugar Labs       - http://www.sugarlabs.org/



From nicolas.mailhot at laposte.net  Sun Dec 21 12:53:19 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 21 Dec 2008 13:53:19 +0100
Subject: Orphaned font packages
In-Reply-To: <494E3951.9030601@codewiz.org>
References: <494E3951.9030601@codewiz.org>
Message-ID: <1229863999.4483.2.camel@arekh.okg>

Le dimanche 21 d?cembre 2008 ? 07:40 -0500, Bernie Innocenti a ?crit :
> Hello,

Hello,

> I've just converted these two packages to the new font packaging
> guidelines, but then I realized I didn't make an ideal maintainer
> because I don't use them and I can't even read those languages :-)

Actually, repoquery found 159 packages with TrueType, OpenType or Type1
fonts in them in rawhide, and you're one of the first packagers to
respond to the resulting bug mass bombing, so I don't think anyone can
complain of your maintainership.

You're doing great, really.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/145a054e/attachment.sig>

From mschwendt at gmail.com  Sun Dec 21 12:57:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 21 Dec 2008 12:57:33 -0000
Subject: Broken dependencies in Fedora 10 - 2008-12-21
Message-ID: <20081221125733.13430.15828@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by src.rpm name):

    audacity
    gyachi
    perl-Padre
    qpidc
    rubberband
    sonic-visualiser
    trytond


Summary of broken packages (by primary owner):

    aconway AT redhat com
        qpidc                           (1 co-owner)

    dan AT danny cz
        trytond

    gemi AT bluewin ch
        audacity                        (2 co-owners)

    michel.sylvan AT gmail com
        rubberband
        sonic-visualiser

    mmaslano AT redhat com
        perl-Padre                      (1 co-owner)

    sundaram AT redhat com
        gyachi                          (1 co-owner)


======================================================================
Broken packages in fedora-10-i386:

    gyachi-plugin-photo_album-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.i386  requires  gyachi = 0:1.1.49-10.fc10
    qpidd-cluster-0.3.705289-1.fc10.i386  requires  qpidd = 0:0.3.705289-1.fc10
    rubberband-1.2-1.fc10.i386  requires  libvamp-sdk.so.1
    sonic-visualiser-1.3-1.fc10.i386  requires  libvamp-hostsdk.so.2


======================================================================
Broken packages in fedora-10-ppc:

    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc  requires  gyachi = 0:1.1.49-10.fc10
    rubberband-1.2-1.fc10.ppc  requires  libvamp-sdk.so.1
    rubberband-1.2-1.fc10.ppc64  requires  libvamp-sdk.so.1()(64bit)
    sonic-visualiser-1.3-1.fc10.ppc  requires  libvamp-hostsdk.so.2


======================================================================
Broken packages in fedora-10-ppc64:

    gyachi-plugin-photo_album-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.ppc64  requires  gyachi = 0:1.1.49-10.fc10
    rubberband-1.2-1.fc10.ppc64  requires  libvamp-sdk.so.1()(64bit)
    sonic-visualiser-1.3-1.fc10.ppc64  requires  libvamp-hostsdk.so.2()(64bit)


======================================================================
Broken packages in fedora-10-x86_64:

    gyachi-plugin-photo_album-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    gyachi-plugin-xmms-1.1.49-10.fc10.x86_64  requires  gyachi = 0:1.1.49-10.fc10
    qpidd-cluster-0.3.705289-1.fc10.x86_64  requires  qpidd = 0:0.3.705289-1.fc10
    rubberband-1.2-1.fc10.i386  requires  libvamp-sdk.so.1
    rubberband-1.2-1.fc10.x86_64  requires  libvamp-sdk.so.1()(64bit)
    sonic-visualiser-1.3-1.fc10.x86_64  requires  libvamp-hostsdk.so.2()(64bit)


======================================================================
Broken packages in fedora-updates-10-i386:

    audacity-1.3.5-0.8.beta.fc10.i386  requires  libvamp-hostsdk.so.2
    trytond-1.0.1-2.fc10.noarch  requires  python-relatorio


======================================================================
Broken packages in fedora-updates-10-ppc:

    audacity-1.3.5-0.8.beta.fc10.ppc  requires  libvamp-hostsdk.so.2
    trytond-1.0.1-2.fc10.noarch  requires  python-relatorio


======================================================================
Broken packages in fedora-updates-10-ppc64:

    audacity-1.3.5-0.8.beta.fc10.ppc64  requires  libvamp-hostsdk.so.2()(64bit)
    trytond-1.0.1-2.fc10.noarch  requires  python-relatorio


======================================================================
Broken packages in fedora-updates-10-x86_64:

    audacity-1.3.5-0.8.beta.fc10.x86_64  requires  libvamp-hostsdk.so.2()(64bit)
    trytond-1.0.1-2.fc10.noarch  requires  python-relatorio


======================================================================
Broken packages in fedora-updates-testing-10-i386:

    perl-Padre-0.20-1.fc10.noarch  requires  perl(ORLite) >= 0:0.15
    perl-Padre-0.20-1.fc10.noarch  requires  perl(Pod::Simple::XHTML)
    perl-Padre-0.20-1.fc10.noarch  requires  perl(Class::Adapter)


======================================================================
Broken packages in fedora-updates-testing-10-ppc:

    perl-Padre-0.20-1.fc10.noarch  requires  perl(ORLite) >= 0:0.15
    perl-Padre-0.20-1.fc10.noarch  requires  perl(Pod::Simple::XHTML)
    perl-Padre-0.20-1.fc10.noarch  requires  perl(Class::Adapter)


======================================================================
Broken packages in fedora-updates-testing-10-ppc64:

    perl-Padre-0.20-1.fc10.noarch  requires  perl(ORLite) >= 0:0.15
    perl-Padre-0.20-1.fc10.noarch  requires  perl(Pod::Simple::XHTML)
    perl-Padre-0.20-1.fc10.noarch  requires  perl(Class::Adapter)


======================================================================
Broken packages in fedora-updates-testing-10-x86_64:

    perl-Padre-0.20-1.fc10.noarch  requires  perl(ORLite) >= 0:0.15
    perl-Padre-0.20-1.fc10.noarch  requires  perl(Pod::Simple::XHTML)
    perl-Padre-0.20-1.fc10.noarch  requires  perl(Class::Adapter)



From mschwendt at gmail.com  Sun Dec 21 12:59:18 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 21 Dec 2008 12:59:18 -0000
Subject: Broken dependencies in Fedora 9 - 2008-12-21
Message-ID: <20081221125918.13483.33781@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by src.rpm name):

    aasaver
    audacity
    claws-mail-plugins
    cyphesis
    gyachi
    kbiof
    livecd-tools
    mediawiki-SpecialInterwiki
    openvas-libraries
    paraview
    perl-Test-AutoBuild
    php
    pigment-python
    rubberband
    sear
    sonic-visualiser
    syck
    trytond


Summary of broken packages (by primary owner):

    andreas.bierfert AT lowlatency de
        claws-mail-plugins

    berrange AT redhat com
        perl-Test-AutoBuild

    dan AT danny cz
        trytond

    extras-orphan AT fedoraproject org
        aasaver
        kbiof

    gemi AT bluewin ch
        audacity                        (2 co-owners)

    huzaifas AT redhat com
        openvas-libraries

    jorton AT redhat com
        php                             (2 co-owners)

    katzj AT redhat com
        livecd-tools                    (2 co-owners)

    matthias AT rpmforge net
        pigment-python

    michel.sylvan AT gmail com
        rubberband
        sonic-visualiser

    nigjones AT redhat com
        mediawiki-SpecialInterwiki

    oliver AT linux-kernel at
        syck

    orion AT cora.nwra com
        paraview                        (1 co-owner)

    sundaram AT redhat com
        gyachi                          (1 co-owner)

    wart AT kobold org
        cyphesis                        (1 co-owner)
        sear


======================================================================
Broken packages in fedora-9-i386:

    aasaver-0.3.2-3.fc9.i386  requires  libkscreensaver.so.4
    cyphesis-selinux-0.5.15-6.fc9.i386  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.i386  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.i386  requires  gyachi = 0:1.1.0-7.fc9
    kbiof-0.3-3.fc9.i386  requires  libkscreensaver.so.4
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-gtk-0.3.so.4
    rubberband-1.0.1-1.fc9.i386  requires  libvamp-sdk.so.1.1.0
    sear-0.6.3-10.fc9.i386  requires  libmercator-0.2.so.4
    sonic-visualiser-1.2-1.fc9.i386  requires  libvamp-hostsdk.so.2.0.0
    syck-php-0.61-4.3.fc9.i386  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc:

    aasaver-0.3.2-3.fc9.ppc  requires  libkscreensaver.so.4
    cyphesis-selinux-0.5.15-6.fc9.ppc  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.ppc  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.ppc  requires  gyachi = 0:1.1.0-7.fc9
    kbiof-0.3-3.fc9.ppc  requires  libkscreensaver.so.4
    paraview-3.2.1-6.fc9.ppc64  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.ppc64  requires  paraview-data = 0:3.2.1-6.fc9
    php-devel-5.2.5-7.fc9.ppc64  requires  php = 0:5.2.5-7.fc9
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-gtk-0.3.so.4
    rubberband-1.0.1-1.fc9.ppc  requires  libvamp-sdk.so.1.1.0
    rubberband-1.0.1-1.fc9.ppc64  requires  libvamp-sdk.so.1.1.0()(64bit)
    sear-0.6.3-10.fc9.ppc  requires  libmercator-0.2.so.4
    sonic-visualiser-1.2-1.fc9.ppc  requires  libvamp-hostsdk.so.2.0.0
    syck-php-0.61-4.3.fc9.ppc  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc64:

    aasaver-0.3.2-3.fc9.ppc64  requires  libkscreensaver.so.4()(64bit)
    cyphesis-selinux-0.5.15-6.fc9.ppc64  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.ppc64  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.ppc64  requires  gyachi = 0:1.1.0-7.fc9
    kbiof-0.3-3.fc9.ppc64  requires  libkscreensaver.so.4()(64bit)
    perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch  requires  darcs >= 0:1.0.0
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-0.3.so.4()(64bit)
    rubberband-1.0.1-1.fc9.ppc64  requires  libvamp-sdk.so.1.1.0()(64bit)
    sear-0.6.3-10.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    sonic-visualiser-1.2-1.fc9.ppc64  requires  libvamp-hostsdk.so.2.0.0()(64bit)
    syck-php-0.61-4.3.fc9.ppc64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-x86_64:

    aasaver-0.3.2-3.fc9.x86_64  requires  libkscreensaver.so.4()(64bit)
    cyphesis-selinux-0.5.15-6.fc9.x86_64  requires  cyphesis = 0:0.5.15-6.fc9
    gyachi-plugin-photosharing-1.1.0-7.fc9.x86_64  requires  gyachi = 0:1.1.0-7.fc9
    gyachi-plugin-xmms-1.1.0-7.fc9.x86_64  requires  gyachi = 0:1.1.0-7.fc9
    kbiof-0.3-3.fc9.x86_64  requires  libkscreensaver.so.4()(64bit)
    paraview-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    php-devel-5.2.5-7.fc9.i386  requires  php = 0:5.2.5-7.fc9
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-0.3.so.4()(64bit)
    rubberband-1.0.1-1.fc9.i386  requires  libvamp-sdk.so.1.1.0
    rubberband-1.0.1-1.fc9.x86_64  requires  libvamp-sdk.so.1.1.0()(64bit)
    sear-0.6.3-10.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    sonic-visualiser-1.2-1.fc9.x86_64  requires  libvamp-hostsdk.so.2.0.0()(64bit)
    syck-php-0.61-4.3.fc9.x86_64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-updates-9-i386:

    audacity-1.3.5-0.7.beta.fc9.i386  requires  libvamp-hostsdk.so.2.0.0
    claws-mail-plugins-3.5.0-1.fc9.i386  requires  claws-mail-plugins-smime = 0:3.5.0-1.fc9
    cyphesis-0.5.15-8.fc9.i386  requires  libmercator-0.2.so.4
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.i386  requires  libresolv.so.2(GLIBC_PRIVATE)
    trytond-1.0.1-2.fc9.noarch  requires  python-relatorio


======================================================================
Broken packages in fedora-updates-9-ppc:

    audacity-1.3.5-0.7.beta.fc9.ppc  requires  libvamp-hostsdk.so.2.0.0
    claws-mail-plugins-3.5.0-1.fc9.ppc  requires  claws-mail-plugins-smime = 0:3.5.0-1.fc9
    cyphesis-0.5.15-8.fc9.ppc  requires  libmercator-0.2.so.4
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.ppc  requires  libresolv.so.2(GLIBC_PRIVATE)
    openvas-libraries-1.0.2-2.fc9.ppc64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)
    trytond-1.0.1-2.fc9.noarch  requires  python-relatorio


======================================================================
Broken packages in fedora-updates-9-ppc64:

    audacity-1.3.5-0.7.beta.fc9.ppc64  requires  libvamp-hostsdk.so.2.0.0()(64bit)
    claws-mail-plugins-3.5.0-1.fc9.ppc64  requires  claws-mail-plugins-smime = 0:3.5.0-1.fc9
    cyphesis-0.5.15-8.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.ppc64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)
    trytond-1.0.1-2.fc9.noarch  requires  python-relatorio


======================================================================
Broken packages in fedora-updates-9-x86_64:

    audacity-1.3.5-0.7.beta.fc9.x86_64  requires  libvamp-hostsdk.so.2.0.0()(64bit)
    claws-mail-plugins-3.5.0-1.fc9.x86_64  requires  claws-mail-plugins-smime = 0:3.5.0-1.fc9
    cyphesis-0.5.15-8.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    openvas-libraries-1.0.2-2.fc9.i386  requires  libresolv.so.2(GLIBC_PRIVATE)
    openvas-libraries-1.0.2-2.fc9.x86_64  requires  libresolv.so.2(GLIBC_PRIVATE)(64bit)
    trytond-1.0.1-2.fc9.noarch  requires  python-relatorio


======================================================================
Broken packages in fedora-updates-testing-9-ppc64:

    livecd-tools-017.2-1.fc9.ppc64  requires  yaboot



From mschwendt at gmail.com  Sun Dec 21 13:00:12 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 21 Dec 2008 13:00:12 -0000
Subject: Broken dependencies in Fedora 8 - 2008-12-21
Message-ID: <20081221130012.13494.74793@faldor.intranet>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by src.rpm name):

    callweaver
    gtkmozembedmm
    idm-console-framework
    ipa
    joda-time
    libhugetlbfs
    mediawiki-HNP
    mediawiki-imagemap
    mediawiki-openid
    mediawiki-ParserFunctions
    mediawiki-SpecialInterwiki
    mediawiki-StubManager
    nxt_python
    perl-Test-AutoBuild
    php
    pytrainer
    syck


Summary of broken packages (by primary owner):

    UNKNOWN OWNER
        callweaver
        gtkmozembedmm
        idm-console-framework
        ipa
        joda-time
        libhugetlbfs
        mediawiki-HNP
        mediawiki-ParserFunctions
        mediawiki-SpecialInterwiki
        mediawiki-StubManager
        mediawiki-imagemap
        mediawiki-openid
        nxt_python
        perl-Test-AutoBuild
        php
        pytrainer
        syck


======================================================================
Broken packages in fedora-8-i386:

    callweaver-zaptel-1.2-0.3.rc4.20070822.i386  requires  libpri.so.1.0
    libhugetlbfs-test-1.1-4.fc8.i386  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.i386  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-ppc:

    callweaver-zaptel-1.2-0.3.rc4.20070822.ppc  requires  libpri.so.1.0
    libhugetlbfs-test-1.1-4.fc8.ppc  requires  libhugetlbfs = 0:1.1-4.fc8
    php-devel-5.2.4-3.ppc64  requires  php = 0:5.2.4-3
    syck-php-0.61-2.fc8.ppc  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-ppc64:

    callweaver-zaptel-1.2-0.3.rc4.20070822.ppc64  requires  libpri.so.1.0()(64bit)
    libhugetlbfs-test-1.1-4.fc8.ppc64  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.ppc64  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-x86_64:

    callweaver-zaptel-1.2-0.3.rc4.20070822.x86_64  requires  libpri.so.1.0()(64bit)
    libhugetlbfs-test-1.1-4.fc8.x86_64  requires  libhugetlbfs = 0:1.1-4.fc8
    php-devel-5.2.4-3.i386  requires  php = 0:5.2.4-3
    syck-php-0.61-2.fc8.x86_64  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-updates-8-i386:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.i386  requires  gecko-libs = 0:1.8.1.17
    ipa-radius-server-1.2.1-0.fc8.i386  requires  freeradius-ldap
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    pytrainer-1.6.0.5-5.fc8.noarch  requires  firefox = 0:2.0.0.18


======================================================================
Broken packages in fedora-updates-8-ppc:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc  requires  gecko-libs = 0:1.8.1.17
    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc64  requires  gecko-libs = 0:1.8.1.17
    idm-console-framework-1.1.2-1.fc8.noarch  requires  java > 0:1.5.0
    ipa-radius-server-1.2.1-0.fc8.ppc  requires  freeradius-ldap
    joda-time-1.5.2-7.tzdata2008d.fc8.noarch  requires  java > 0:1.5.0
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    pytrainer-1.6.0.5-5.fc8.noarch  requires  firefox = 0:2.0.0.18


======================================================================
Broken packages in fedora-updates-8-ppc64:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.ppc64  requires  gecko-libs = 0:1.8.1.17
    idm-console-framework-1.1.2-1.fc8.noarch  requires  java > 0:1.5.0
    ipa-radius-server-1.2.1-0.fc8.ppc64  requires  freeradius-ldap
    joda-time-1.5.2-7.tzdata2008d.fc8.noarch  requires  java > 0:1.5.0
    mediawiki-HNP-1.1.2-1.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    mediawiki-StubManager-1.2.0-1.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-imagemap-0-0.1.r37906.fc8.noarch  requires  mediawiki >= 0:1.13
    mediawiki-openid-0.8.2-7.0.1.noarch  requires  mediawiki
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch  requires  darcs >= 0:1.0.0
    pytrainer-1.6.0.5-5.fc8.noarch  requires  firefox = 0:2.0.0.18


======================================================================
Broken packages in fedora-updates-8-x86_64:

    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.i386  requires  gecko-libs = 0:1.8.1.17
    gtkmozembedmm-1.4.2.cvs20060817-23.fc8.x86_64  requires  gecko-libs = 0:1.8.1.17
    ipa-radius-server-1.2.1-0.fc8.x86_64  requires  freeradius-ldap
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    pytrainer-1.6.0.5-5.fc8.noarch  requires  firefox = 0:2.0.0.18



From dominik at greysector.net  Sun Dec 21 13:01:51 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sun, 21 Dec 2008 14:01:51 +0100
Subject: Proposed PackageRenaming guideline
In-Reply-To: <20081220221340.54f61d67@ohm.scrye.com>
References: <20081218104319.75305a5b@ohm.scrye.com>
	<gienqn$cg4$1@ger.gmane.org>
	<20081220134305.3417e4d3@ohm.scrye.com>
	<gik293$jtj$2@ger.gmane.org> <20081221002659.GH2790@free.fr>
	<20081220221340.54f61d67@ohm.scrye.com>
Message-ID: <20081221130150.GB4705@mokona.greysector.net>

On Sunday, 21 December 2008 at 06:13, Kevin Fenzi wrote:
[...]
> Yes, that was my intent... just checking the Obsoletes/Provides against
> the renaming part of the naming guidelines. 
> 
> Of course if they notice something else that could be improved, they
> could mention it, but it shouldn't block the rename unless it's
> something very serious.

This is reasonable. +1

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From pertusus at free.fr  Sun Dec 21 13:43:07 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 14:43:07 +0100
Subject: orphaning all my packages
In-Reply-To: <b80014de0812202034s1af80a99md6bb18315834db80@mail.gmail.com>
References: <20081216094739.GA3877@free.fr>
	<b80014de0812202034s1af80a99md6bb18315834db80@mail.gmail.com>
Message-ID: <20081221134307.GA2791@free.fr>

On Sat, Dec 20, 2008 at 11:34:02PM -0500, Deji Akingunola wrote:
> On Tue, Dec 16, 2008 at 4:47 AM, Patrice Dumas <pertusus at free.fr> wrote:
> > * grads
> > there is an update available for grads, but it has some functionalities
> > removed, and also upstream is complicated, with a friendly fork at
> > opengrads and last libgadap can be packaged now. I'll still be working
> > with upstream, so I could help with chosing which version to package and
> > things like that.
> 
> I can take over looking after grads, I use it often. What are these
> functionalities that you claimed were removed? I've not noticed any
> yet.

lat is not in. The removed files are:
fgbds.c
fgutil.c
gagui.c
gaimg.c
gaimg.h
gsgui.c
gstmp.c
lats.c
latsgrib.c
lats.h
latsint.c
latsint.h
latsnc.c
latsparm.h
latsstat.c
latstime.c
latstime.h
pcx11e.c

But apart from lats, there is not much problematic left out.

Do you want all the branches?

Also do you want libsx? It is a dependency though it isn't currently
used because of at the time I packaged grads gagui.c was not under an
acceptable license, but now it is, at least upstream.

--
Pat



From pertusus at free.fr  Sun Dec 21 13:44:59 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 14:44:59 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <494D86B7.80804@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <49467E08.2080806@redhat.com>
	<49467EA4.2060909@redhat.com>
	<1229816419.18082.1.camel@localhost.localdomain>
	<494D86B7.80804@redhat.com>
Message-ID: <20081221134459.GB2791@free.fr>

On Sat, Dec 20, 2008 at 05:58:47PM -0600, Eric Sandeen wrote:
> 
> Just out of curiosity, do you really do offline root ext3 filesystem
> shrinks that often?

A few days ago, to leave room for the debian I use now, while still 
keeping a fedora around, in case...

--
Pat



From pertusus at free.fr  Sun Dec 21 13:57:12 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 14:57:12 +0100
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <1229808622.3861.17.camel@localhost.localdomain>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
	<20081219194825.GA16284@bludgeon.org>
	<494BFECE.4050003@gmail.com> <20081220004829.GB10679@free.fr>
	<494CC439.4070503@gmail.com> <20081220121718.GC2506@free.fr>
	<1229801959.3861.13.camel@localhost.localdomain>
	<20081220210933.GD2790@free.fr>
	<1229808622.3861.17.camel@localhost.localdomain>
Message-ID: <20081221135712.GC2791@free.fr>

On Sat, Dec 20, 2008 at 01:30:22PM -0800, Jesse Keating wrote:
> On Sat, 2008-12-20 at 22:09 +0100, Patrice Dumas wrote:
> > Am I missing something?
> 
> I  meant in general.  As things change via FESCo they could use some
> help identifying all the places in the wiki that should change.

I am speaking about Policies, not about the whole wiki.

> The discussion tab is perfect for this, drop a comment if you think
> something should change.

If I think something should change, I prefer changing it myself, 
or when the whole page needs to be reworked, I ask on 
fedora-devel-list.

> I don't think however FESCo has appointed any people as maintainers of
> the wiki space.

You are missing my point. What I am saying is that each time FESCo 
accepts a new policy or a modification of a policy, someone from
FESCo should make sure that it is documented/changed in 
http://fedoraproject.org/wiki/PackageMaintainers/Policy

Not in th ewhole wiki, in the policies part. And it should not 
necessarily be somebody from FESCo who do the documentation, it
could be the person who proposed the policy.

Otherwise said, FESCo should appoint somebody to document accepted
or modified policies in the normative section,
http://fedoraproject.org/wiki/PackageMaintainers/Policy
when they are accepted or modified. It is a one tiume job on a
specific wiki subset.

--
Pat



From pertusus at free.fr  Sun Dec 21 14:05:07 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 15:05:07 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494DE827.3020006@googlemail.com>
References: <9020.1229838236@iinet.net.au> <494DE827.3020006@googlemail.com>
Message-ID: <20081221140507.GD2791@free.fr>

On Sun, Dec 21, 2008 at 07:54:31AM +0100, Tim Lauridsen wrote:
>>
>> So, over to the experts who actually build Fedora. Does the idea have merit?
>>
>>   
> This has been discussed many time on the list, the problem is that you  
> cant have it both ways, you cant have a LTS release with the latest and  
> greatest.
> The only way a LTS release make sence is to freeze the code, test, test  
> and test. And then backport security related fixes.
> RHEL/Centos does this well and Fedora does  the latest and greatest part.

It is untrue. You can have a distribution which begins with the latest 
and greatest but is gradually stabilizing. You didn't read this proposal, 
did you? It has been retired, but you saw the discussions, don't you?
https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL

--
Pat



From rc040203 at freenet.de  Sun Dec 21 14:29:10 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 21 Dec 2008 15:29:10 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <494E18BB.8050005@gmail.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
	<1229788642.16655.12.camel@arekh.okg>
	<20081220180913.45f62880@lain.camperquake.de>
	<1229801171.24251.19.camel@arekh.okg>
	<1229854269.3382.5.camel@hughsie-work.lan> <494E18BB.8050005@gmail.com>
Message-ID: <1229869750.3209.6836.camel@beck.corsepiu.local>

On Sun, 2008-12-21 at 15:51 +0530, Rahul Sundaram wrote:
> Richard Hughes wrote:
> > I'm not bullying you. I'm asking you to stop doing your own thing, 
> > andstart using the convention that everyone else _except you_ is using.
> Convention here translates into fuzzy undocumented packaging guidelines.
Wrong. The convention %description is NOT fuzzy.

Richard is simply overinterpreting the rules.





From thomas.moschny at gmail.com  Sun Dec 21 15:28:38 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Sun, 21 Dec 2008 16:28:38 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <1229869750.3209.6836.camel@beck.corsepiu.local>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>
	<1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
	<1229788642.16655.12.camel@arekh.okg>
	<20081220180913.45f62880@lain.camperquake.de>
	<1229801171.24251.19.camel@arekh.okg>
	<1229854269.3382.5.camel@hughsie-work.lan>
	<494E18BB.8050005@gmail.com>
	<1229869750.3209.6836.camel@beck.corsepiu.local>
Message-ID: <a9d183c80812210728r3856cadbx27d7e1c6a86a544b@mail.gmail.com>

2008/12/21 Ralf Corsepius <rc040203 at freenet.de>:
> On Sun, 2008-12-21 at 15:51 +0530, Rahul Sundaram wrote:
>> Richard Hughes wrote:
>> > I'm not bullying you. I'm asking you to stop doing your own thing,
>> > andstart using the convention that everyone else _except you_ is using.
>> Convention here translates into fuzzy undocumented packaging guidelines.
> Wrong. The convention %description is NOT fuzzy.
>
> Richard is simply overinterpreting the rules.

I also didn't find the rules fuzzy, but - they read:

== snip ==

You must use one of the following formats:

* Fri Jun 23 2006 Jesse Keating <jkeating at redhat.com> - 0.6-4
- And fix the link syntax.

* Fri Jun 23 2006 Jesse Keating <jkeating at redhat.com> 0.6-4
- And fix the link syntax.

* Fri Jun 23 2006 Jesse Keating <jkeating at redhat.com>
- 0.6-4
- And fix the link syntax.

== snip ==

And while these three variants only differ in the way the
version-release is specified, I can't see how from that follows that
the rest is free form? Maybe I'm missing something, but all three
clearly use simple dashes for each stanza of the changelog entry.

Not that I'm not sympathizing in principle with people using the full
unicode character set for their communications ?, but in that case I
think Richard is right, can't see where he's overinterpreting.

- Thomas



From orion at cora.nwra.com  Sun Dec 21 15:43:07 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Sun, 21 Dec 2008 08:43:07 -0700
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <494E640B.4060202@cora.nwra.com>

Matt Domsch wrote:
> Fedora Rawhide-in-Mock Build Results for x86_64
> wgrib2-1.7.2b-1.fc10 (build/make) orion,pertusus

I cannot figure this one out.  Seems to be a problem setting up the 
build root, but I can't find any errors there.

- Orion



From orion at cora.nwra.com  Sun Dec 21 15:45:01 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Sun, 21 Dec 2008 08:45:01 -0700
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
Message-ID: <494E647D.7000503@cora.nwra.com>

Matt Domsch wrote:
> Fedora Rawhide-in-Mock Build Results for x86_64
> 
> perl-PDL-2.4.4-1.fc11 (build/make) kasal,orion,rnorwood,mmaslano
> plplot-5.9.0-4.svn8985.fc11 (build/make) orion

I'm awaiting a new release of the PDL-Graphics-PLplot component to 
rebuild perl-PDL and then plplot.


- Orion



From alan at redhat.com  Sun Dec 21 15:53:23 2008
From: alan at redhat.com (Alan Cox)
Date: Sun, 21 Dec 2008 10:53:23 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <9020.1229838236@iinet.net.au>
References: <9020.1229838236@iinet.net.au>
Message-ID: <20081221155323.GC23993@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 02:43:56PM +0900, anubis at iinet.net.au wrote:
> BUT, with every second release (I'll assume every even-numbered release), produce a re-spin at the 6-month mark, call it Fedora "stable" (or some such) and change the policy for updates and quality assurance at that point to maintain improved stability through to EOL - this may translate to fewer new features from that point to EOL but only within that release. 

You are free to do this. The previous attempts to do this failed because not
enough people could be bothered to contribute. If you can find some other folks
who believe this is possible and between you the technical knowledge and large
amounts of time required then go for it. Nobody is stopping you or anyone else
producing updates to a Fedora release after its "officially" out of support.

Alan



From cmadams at hiwaay.net  Sun Dec 21 16:03:23 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 21 Dec 2008 10:03:23 -0600
Subject: Packages adding groups in %pre/post
In-Reply-To: <1229836519.3861.44.camel@localhost.localdomain>
References: <1229836519.3861.44.camel@localhost.localdomain>
Message-ID: <20081221160322.GA1096521@hiwaay.net>

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> I've noticed that in some situations, packages that add users/groups in
> %pre/post can fail.  What I most often see happening is while groupadd
> or useradd is installed, and properly requested by Requires(pre) or
> Requires(post) on shadow-utils, the /etc/group and /etc/passwd files
> themselves aren't in place.  These come from the setup package.
> 
> Should the shadow-utils package Require the setup package, or require it
> in such a way that it is in place before anything that calls
> shadow-utils?  Should the packages that need to add users/groups not
> only Requires(foo) on shadow-utils, but also setup?

I'd say that if useradd and groupadd can't work without /etc/passwd and
/etc/group, then shadow-utils should require /etc/passwd and /etc/group
(wouldn't a file Requires make more sense than a static package
Requires?).  It doesn't make sense to change a bunch of packages to
require setup, since that could always change (and what a PITA that
would be).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From mschwendt at gmail.com  Sun Dec 21 16:04:29 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 21 Dec 2008 17:04:29 +0100
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <494E640B.4060202@cora.nwra.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
	<494E640B.4060202@cora.nwra.com>
Message-ID: <20081221170429.b16420e1.mschwendt@gmail.com>

On Sun, 21 Dec 2008 08:43:07 -0700, Orion wrote:

> Matt Domsch wrote:
> > Fedora Rawhide-in-Mock Build Results for x86_64
> > wgrib2-1.7.2b-1.fc10 (build/make) orion,pertusus
> 
> I cannot figure this one out.  Seems to be a problem setting up the 
> build root, but I can't find any errors there.

See build.log:

  error: %patch without corresponding "Patch:" tag

This happens if Patch0/%patch and Patch/%patch0 are mixed.
Use them consistently. Prefer Patch0 with %patch0.



From cmadams at hiwaay.net  Sun Dec 21 16:05:34 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 21 Dec 2008 10:05:34 -0600
Subject: Should packages be quiet when nodocs flag is used?
In-Reply-To: <1229838800.3861.45.camel@localhost.localdomain>
References: <1229832841.3861.23.camel@localhost.localdomain>
	<494DD6D4.4090008@nobugconsulting.ro>
	<1229838800.3861.45.camel@localhost.localdomain>
Message-ID: <20081221160534.GB1096521@hiwaay.net>

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> On Sun, 2008-12-21 at 07:40 +0200, Manuel Wolfshant wrote:
> > packages  should skip installing ALL the docs. info pages are doc.
> 
> Well, it does skip it, however it's the %post command that isn't setup
> to account for that.  Apparently you have to mung some file after the
> rpm is installed to update a cache or something.

Is there a way for a %post to know if --excludedocs was set?

Alternately, maybe RPM should take care of this step, not every package
that wants to install info pages.  If you excludedocs, you'll still get
the install-info Requires for each of those packages, even though it is
not really required now.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From ville.skytta at iki.fi  Sun Dec 21 16:14:48 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 21 Dec 2008 18:14:48 +0200
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <gieksb$2ph$1@ger.gmane.org>
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<200812181859.12885.ville.skytta@iki.fi>
	<gieksb$2ph$1@ger.gmane.org>
Message-ID: <200812211814.49044.ville.skytta@iki.fi>

On Friday 19 December 2008, Kevin Kofler wrote:
> Ville Skytt? wrote:
> > We encourage garbage collecting old cruft, keeping it around indefinitely
> > should be a pretty rare exception for quite specific cases (or at least
> > that's the way I remember it when we worked on it in FPC).
>
> Once again, a Provides with a version number attached is *not* old cruft,
> it's both backwards and *forwards* thinking, because another new major
> version will inevitably happen.

This thinking sounds even worse - it is not only about preservation cruft in 
Provides, but it prepares things so that it is usual/expected and easier to 
ship cruft as several versions of packages, and thus more or less encourages 
it.  I thought we had guidelines how to do compat-* packages properly and 
some guidelines about their life cycle but it appears I'm wrong or just can't 
find it now :(



From pertusus at free.fr  Sun Dec 21 16:35:26 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 17:35:26 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221155323.GC23993@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
Message-ID: <20081221163526.GA2448@free.fr>

On Sun, Dec 21, 2008 at 10:53:23AM -0500, Alan Cox wrote:
> On Sun, Dec 21, 2008 at 02:43:56PM +0900, anubis at iinet.net.au wrote:
> > BUT, with every second release (I'll assume every even-numbered release), produce a re-spin at the 6-month mark, call it Fedora "stable" (or some such) and change the policy for updates and quality assurance at that point to maintain improved stability through to EOL - this may translate to fewer new features from that point to EOL but only within that release. 
> 
> You are free to do this. The previous attempts to do this failed because not
> enough people could be bothered to contribute. If you can find some other folks

Last time it was not the reason why it failed. It failed because FESCo
refused, and asked the board that certainly refused too. See
https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL
especially the discussion.

It could also have failed because of the lack of contributors, but 
it didn't went far enough to be able to judge.

--
Pat



From pertusus at free.fr  Sun Dec 21 16:38:18 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 17:38:18 +0100
Subject: rawhide report: 20081220 changes
In-Reply-To: <a9d183c80812210728r3856cadbx27d7e1c6a86a544b@mail.gmail.com>
References: <1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
	<1229788642.16655.12.camel@arekh.okg>
	<20081220180913.45f62880@lain.camperquake.de>
	<1229801171.24251.19.camel@arekh.okg>
	<1229854269.3382.5.camel@hughsie-work.lan>
	<494E18BB.8050005@gmail.com>
	<1229869750.3209.6836.camel@beck.corsepiu.local>
	<a9d183c80812210728r3856cadbx27d7e1c6a86a544b@mail.gmail.com>
Message-ID: <20081221163818.GB2448@free.fr>

On Sun, Dec 21, 2008 at 04:28:38PM +0100, Thomas Moschny wrote:
> 
> I also didn't find the rules fuzzy, but - they read:
> 
> == snip ==
> 
> You must use one of the following formats:
> 
> * Fri Jun 23 2006 Jesse Keating <jkeating at redhat.com> - 0.6-4
> - And fix the link syntax.
> 
> * Fri Jun 23 2006 Jesse Keating <jkeating at redhat.com> 0.6-4
> - And fix the link syntax.
> 
> * Fri Jun 23 2006 Jesse Keating <jkeating at redhat.com>
> - 0.6-4
> - And fix the link syntax.
> 
> == snip ==
> 
> And while these three variants only differ in the way the
> version-release is specified, I can't see how from that follows that
> the rest is free form? Maybe I'm missing something, but all three
> clearly use simple dashes for each stanza of the changelog entry.

If I recall well, the FPC ruling was not about anything else than 
the version release format. I didn't found any trace of that, though.
That being said it is indeed unclear from the guideline that only 
the date and version-release is specified here.

--
Pat



From orion at cora.nwra.com  Sun Dec 21 16:46:56 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Sun, 21 Dec 2008 09:46:56 -0700
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <20081221170429.b16420e1.mschwendt@gmail.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>	<494E640B.4060202@cora.nwra.com>
	<20081221170429.b16420e1.mschwendt@gmail.com>
Message-ID: <494E7300.4020802@cora.nwra.com>

Michael Schwendt wrote:
> On Sun, 21 Dec 2008 08:43:07 -0700, Orion wrote:
> 
>> Matt Domsch wrote:
>>> Fedora Rawhide-in-Mock Build Results for x86_64
>>> wgrib2-1.7.2b-1.fc10 (build/make) orion,pertusus
>> I cannot figure this one out.  Seems to be a problem setting up the 
>> build root, but I can't find any errors there.
> 
> See build.log:
> 
>   error: %patch without corresponding "Patch:" tag
> 
> This happens if Patch0/%patch and Patch/%patch0 are mixed.
> Use them consistently. Prefer Patch0 with %patch0.
> 

Ah okay.  Ville had already checked in the fix to rawhide.  I've updated 
to new upstream as well and rebuilt.

- Orion



From ndbecker2 at gmail.com  Sun Dec 21 16:52:21 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 21 Dec 2008 11:52:21 -0500
Subject: Do I need to take action on these broken dependencies (python
	related)
Message-ID: <gils85$ds7$1@ger.gmane.org>

python-igraph has broken dependencies in the development tree:
On ppc:
        python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
        python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
On x86_64:
        python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
        python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
On i386:
        python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
        python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
On ppc64:
        python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
        python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
Please resolve this as soon as possible.




From jkeating at redhat.com  Sun Dec 21 16:57:38 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 08:57:38 -0800
Subject: Do I need to take action on these broken dependencies (python
 related)
In-Reply-To: <gils85$ds7$1@ger.gmane.org>
References: <gils85$ds7$1@ger.gmane.org>
Message-ID: <1229878658.3861.66.camel@localhost.localdomain>

On Sun, 2008-12-21 at 11:52 -0500, Neal Becker wrote:
> python-igraph has broken dependencies in the development tree:
> On ppc:
>         python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
>         python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
> On x86_64:
>         python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
>         python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
> On i386:
>         python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
>         python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
> On ppc64:
>         python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
>         python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
> Please resolve this as soon as possible.
> 

If you're a (co)maintainer for python-igraph, then yes you need to
address it.  The things that weren't auto-rebuilt for the python bump
either had closed ACLs or failed to build from source.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/833d514d/attachment.sig>

From jkeating at redhat.com  Sun Dec 21 17:02:55 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 09:02:55 -0800
Subject: Packages adding groups in %pre/post
In-Reply-To: <20081221160322.GA1096521@hiwaay.net>
References: <1229836519.3861.44.camel@localhost.localdomain>
	<20081221160322.GA1096521@hiwaay.net>
Message-ID: <1229878975.3861.68.camel@localhost.localdomain>

On Sun, 2008-12-21 at 10:03 -0600, Chris Adams wrote:
> Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> > I've noticed that in some situations, packages that add users/groups in
> > %pre/post can fail.  What I most often see happening is while groupadd
> > or useradd is installed, and properly requested by Requires(pre) or
> > Requires(post) on shadow-utils, the /etc/group and /etc/passwd files
> > themselves aren't in place.  These come from the setup package.
> > 
> > Should the shadow-utils package Require the setup package, or require it
> > in such a way that it is in place before anything that calls
> > shadow-utils?  Should the packages that need to add users/groups not
> > only Requires(foo) on shadow-utils, but also setup?
> 
> I'd say that if useradd and groupadd can't work without /etc/passwd and
> /etc/group, then shadow-utils should require /etc/passwd and /etc/group
> (wouldn't a file Requires make more sense than a static package
> Requires?).  It doesn't make sense to change a bunch of packages to
> require setup, since that could always change (and what a PITA that
> would be).

FWIW for the short term I've added 'setup' as a Requires in
shadow-utils.  This fixes the rpm ordering issue I was seeing.  The
maintainer for shadow-utils can choose to adjust that to a series of
file requirements if they feel that's better.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/dcc5767a/attachment.sig>

From dimi at lattica.com  Sun Dec 21 17:04:08 2008
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 21 Dec 2008 12:04:08 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494DEE45.9090304@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
	<494DEE45.9090304@gmail.com>
Message-ID: <1229879048.23410.222.camel@dimi.lattica.com>


On Sun, 2008-12-21 at 12:50 +0530, Rahul Sundaram wrote:
> > But this is exactly what drives people up the wall:
> >   - Please change X
> >   - Why would we, how can we know if other like it like that?
> >   - Look, there's plenty of indication on the web that that's the case
> >   - Pfff, even 95% numbers are not good, we want HARD numbers!
> >   - ... but ... that's nearly impossible to get :(
> >   - Sure, we know it's impossible, that's why we asked for them. Duh
> >   

> 95% is just made up statistics as usual. 

No, it's not. You are just dismissing it off hand as usual.
I have stated that 95% of computer users on Planet Earth are
used to browser mode. That's an easy number to get to,
see for example:
http://gizmodo.com/340117/mac-os-x-market-share-at-731-and-rising

In fact, judging by the above it may be more like 99.5%,
but does it matter?!? The point still stands, but it was
repeatedly dismissed out of hand because it's a heck of a 
lot more fun to argue about 93.5% vs. 95%. 

> I merely said that claiming a majority is impossible too. I also 
> noted that even things changed with many usability studies behind them 
> have lots of people hating that particular change.  So there isn't one 
> particular default that satisfies everybody's tastes and that's ok since 
> changing it is pretty easy in this case and the non default cases are 
> being improved all the time as well.

Just saying "it's easy to change" is just a lame cop-out. Most people
don't bother changing from the defaults, they either like or dislike the
system.

The old "mechanism without defaults" has been proven time and again
to be a total failure when it comes to "normal" users.

We are here to build a desktop OS that's suitable for everybody do
use. Defaults matter a great deal.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From alan at redhat.com  Sun Dec 21 17:14:38 2008
From: alan at redhat.com (Alan Cox)
Date: Sun, 21 Dec 2008 12:14:38 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221163526.GA2448@free.fr>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
Message-ID: <20081221171438.GA6830@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 05:35:26PM +0100, Patrice Dumas wrote:
> Last time it was not the reason why it failed. It failed because FESCo
> refused, and asked the board that certainly refused too. See

FESCo has no power to make it work or not work. The GPL gave people all the
rights they need to create a long term Fedora variant.

Alan



From jamundso at gmail.com  Sun Dec 21 17:16:53 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 21 Dec 2008 11:16:53 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229879048.23410.222.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<494D556B.9080807@gmail.com>
	<6e24a8e80812201243w5245b199kd84520110b5f5ee@mail.gmail.com>
	<494D5F44.6060802@gmail.com>
	<1229816182.23410.187.camel@dimi.lattica.com>
	<494DEE45.9090304@gmail.com>
	<1229879048.23410.222.camel@dimi.lattica.com>
Message-ID: <6d06ce20812210916i1775f799l9eb80581893efa57@mail.gmail.com>

On 12/21/08, Dimi Paun <dimi at lattica.com> wrote:
> On Sun, 2008-12-21 at 12:50 +0530, Rahul Sundaram wrote:
>> > But this is exactly what drives people up the wall:
>> >   - Please change X
>> >   - Why would we, how can we know if other like it like that?
>> >   - Look, there's plenty of indication on the web that that's the case
>> >   - Pfff, even 95% numbers are not good, we want HARD numbers!
>> >   - ... but ... that's nearly impossible to get :(
>> >   - Sure, we know it's impossible, that's why we asked for them. Duh
>
>> 95% is just made up statistics as usual.
>
> No, it's not. You are just dismissing it off hand as usual.

And rightfully so. This thread needs to fsck'ing end.

> We are here to build a desktop OS that's suitable for everybody do
> use. Defaults matter a great deal.

I'm here to promote FWD (Fedora World Domination) as well.
The first step is quality and stability, not nit-picking defaults.

jerry

-- 
To be named later.



From kevin.kofler at chello.at  Sun Dec 21 17:23:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 18:23:44 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<200812181859.12885.ville.skytta@iki.fi>
	<gieksb$2ph$1@ger.gmane.org>
	<200812211814.49044.ville.skytta@iki.fi>
Message-ID: <gilu31$i5m$1@ger.gmane.org>

Ville Skytt? wrote:
> This thinking sounds even worse - it is not only about preservation cruft
> in Provides, but it prepares things so that it is usual/expected and
> easier to ship cruft as several versions of packages, and thus more or
> less encourages
> it.  I thought we had guidelines how to do compat-* packages properly and
> some guidelines about their life cycle but it appears I'm wrong or just
> can't find it now :(

It's just plain impossible to get all the dozens of packages which use a
library like qt ported at the same time. Some changes (e.g. Qt 3 -> 4) will
invariably take longer than others (e.g. Qt 2 -> 3), but there's just no
way a migration like this can happen with no transition period, especially
with the current size of the Fedora Package Collection.

        Kevin Kofler



From jkeating at redhat.com  Sun Dec 21 17:29:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 09:29:00 -0800
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221171438.GA6830@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
Message-ID: <1229880540.3861.70.camel@localhost.localdomain>

On Sun, 2008-12-21 at 12:14 -0500, Alan Cox wrote:
> On Sun, Dec 21, 2008 at 05:35:26PM +0100, Patrice Dumas wrote:
> > Last time it was not the reason why it failed. It failed because FESCo
> > refused, and asked the board that certainly refused too. See
> 
> FESCo has no power to make it work or not work. The GPL gave people all the
> rights they need to create a long term Fedora variant.
> 
> Alan

Right, all FESCo did was decide to not spend Fedora Infrastructure
resources on the venture until it had a proven set of producers and
consumers.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/bc079116/attachment.sig>

From kevin.kofler at chello.at  Sun Dec 21 17:30:56 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 21 Dec 2008 18:30:56 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
Message-ID: <gilugg$i5m$2@ger.gmane.org>

Alan Cox wrote:
> FESCo has no power to make it work or not work. The GPL gave people all
> the rights they need to create a long term Fedora variant.

But it's impossible to pull off without infrastructure, and setting up the
infrastructure required for this project outside of Fedora requires months
of work, and with the expected bandwidth requirements (think OO.o security
updates), quite possibly also lots of money. That's why this project is
doomed to fail without access to the official Fedora infrastructure, which
is what was refused.

That said, with Patrice leaving Fedora, I don't think there's any driving
force for such a project left anyway.

        Kevin Kofler



From pertusus at free.fr  Sun Dec 21 17:29:25 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 18:29:25 +0100
Subject: wxGTK2 -> wxGTK rename without Provides
In-Reply-To: <200812211814.49044.ville.skytta@iki.fi>
References: <20081217210617.499559ea.mschwendt@gmail.com>
	<200812181859.12885.ville.skytta@iki.fi>
	<gieksb$2ph$1@ger.gmane.org>
	<200812211814.49044.ville.skytta@iki.fi>
Message-ID: <20081221172925.GF2448@free.fr>

On Sun, Dec 21, 2008 at 06:14:48PM +0200, Ville Skytt? wrote:
> 
> This thinking sounds even worse - it is not only about preservation cruft in 
> Provides, but it prepares things so that it is usual/expected and easier to 
> ship cruft as several versions of packages, and thus more or less encourages 
> it.  I thought we had guidelines how to do compat-* packages properly and 
> some guidelines about their life cycle but it appears I'm wrong or just can't 
> find it now :(

There is
http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages
but I don't know if it was ratified. Even if it was not ratified
FESCo supported the part about vetoing a compat package if the 
primary maintainer is not ok twice for compat-python for zope. 

There was also
http://markmail.org/message/lu6votnbktff4peo?q=fedora+compat+packaging+libraries&page=1&refer=5hs7vskgzu26oxt4
but there is no conclusion as far as I can tell.

I guess that my personal opinion doesn't matter much (especially 
now that I left fedora), but I think that having packages in fedora
link against compat packages should be avoided as much as possible,
but compat packages for fedora users should be considered as regular
packages (with a need for parallel installation not to disturb main
packages). I would favor a policy to have compat packages maintainers
be in initial-CC of main package to help triaging bugs that are 
in fact for the compat package.

In any case there is already some precedent of compat packages
still used in fedora and here for a long time, glib and gtk+.
Also the kde people keep precedent kdelibs quite a long tie 
for the benefit of fedora users. Last there is libnet10 which is 
here since 2003, and found a new maintainer when I orphaned it
though nothing in fedora itself links against libnet10.

--
Pat



From pertusus at free.fr  Sun Dec 21 17:30:57 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 18:30:57 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221171438.GA6830@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
Message-ID: <20081221173057.GG2448@free.fr>

On Sun, Dec 21, 2008 at 12:14:38PM -0500, Alan Cox wrote:
> 
> FESCo has no power to make it work or not work. The GPL gave people all the
> rights they need to create a long term Fedora variant.

Of course, but doing it within fedora (even not officially) is
what FESCo can accept or reject.

--
Pat



From lsof at nodata.co.uk  Sun Dec 21 17:35:15 2008
From: lsof at nodata.co.uk (nodata)
Date: Sun, 21 Dec 2008 18:35:15 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217234853.GE23212@shell.devel.redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org> <49467E08.2080806@redhat.com>
	<49467EA4.2060909@redhat.com> <1229546027.2882.3.camel@sb-home>
	<20081217234853.GE23212@shell.devel.redhat.com>
Message-ID: <1229880915.2893.2.camel@sb-home>

Am Mittwoch, den 17.12.2008, 18:48 -0500 schrieb Alan Cox:
> On Wed, Dec 17, 2008 at 09:33:47PM +0100, nodata wrote:
> > XFS has a nasty bug where it will leave files full of zeros on disk in a
> > crash.
> > 
> > I think it was Alan Cox that said this could be fixed quite easily by
> > changing the write ordering for XFS, but that someone who was willing to
> > maintain the patch would need to do it.
> 
> Not guilty.
> 
> Ext3 has a set of options for data journalling (at a performance cost). XFS
> is not something I look into the innards of as I don't have enough chickens
> to sacrifice
> 
> 

Sorry was Andrew Morton in his Google Tech Talk.




From jamundso at gmail.com  Sun Dec 21 17:40:15 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 21 Dec 2008 11:40:15 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1229880540.3861.70.camel@localhost.localdomain>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<1229880540.3861.70.camel@localhost.localdomain>
Message-ID: <6d06ce20812210940p6a88a7e3nbbdc097b1227dbe5@mail.gmail.com>

On 12/21/08, Jesse Keating <jkeating at redhat.com> wrote:
> On Sun, 2008-12-21 at 12:14 -0500, Alan Cox wrote:
>> On Sun, Dec 21, 2008 at 05:35:26PM +0100, Patrice Dumas wrote:
>> > Last time it was not the reason why it failed. It failed because FESCo
>> > refused, and asked the board that certainly refused too. See
>>
>> FESCo has no power to make it work or not work. The GPL gave people all
>> the
>> rights they need to create a long term Fedora variant.
>>
>> Alan
>
> Right, all FESCo did was decide to not spend Fedora Infrastructure
> resources on the venture until it had a proven set of producers and
> consumers.

Yes, the kiss of death, practically speaking.

jerry

-- 
To be named later.



From metherid at gmail.com  Sun Dec 21 17:39:13 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Sun, 21 Dec 2008 23:09:13 +0530
Subject: Do I need to take action on these broken dependencies (python
 related)
In-Reply-To: <1229878658.3861.66.camel@localhost.localdomain>
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
Message-ID: <494E7F41.5020601@gmail.com>

Jesse Keating wrote:
> On Sun, 2008-12-21 at 11:52 -0500, Neal Becker wrote:
>   
>> python-igraph has broken dependencies in the development tree:
>> On ppc:
>>         python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
>>         python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
>> On x86_64:
>>         python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
>>         python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
>> On i386:
>>         python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
>>         python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
>> On ppc64:
>>         python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
>>         python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
>> Please resolve this as soon as possible.
>>
>>     
>
> If you're a (co)maintainer for python-igraph, then yes you need to
> address it.  The things that weren't auto-rebuilt for the python bump
> either had closed ACLs or failed to build from source.
>   
Alternatively, stop using ACL's and let others help you.

Rahul



From alan at redhat.com  Sun Dec 21 17:42:56 2008
From: alan at redhat.com (Alan Cox)
Date: Sun, 21 Dec 2008 12:42:56 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gilugg$i5m$2@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
Message-ID: <20081221174256.GA9876@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 06:30:56PM +0100, Kevin Kofler wrote:
> But it's impossible to pull off without infrastructure, and setting up the
> infrastructure required for this project outside of Fedora requires months
> of work, and with the expected bandwidth requirements (think OO.o security
> updates), quite possibly also lots of money. That's why this project is
> doomed to fail without access to the official Fedora infrastructure, which
> is what was refused.

In other words you don't have enough interest to make the project work. If you
had enough interest you'd soon find bandwidth and infrastructure. The Debian
project appears to manage this just fine and several of the well known current
distributions started out as a small group of people.

Your infrastructure estimates are pretty ridiculous. If it takes you more than
a week to kick start a basic build environment for doing security updates and
you can't find a linux related site to host your stuff initially you are
doing something wrong or don't have enough interested skilled people.

Remember Fedora existed originally as a volunteer additional set of repositories
before it ever teamed up with Red Hat. They seem to have managed quite well
as a volunteer project on their own.

Alan



From alan at redhat.com  Sun Dec 21 17:44:50 2008
From: alan at redhat.com (Alan Cox)
Date: Sun, 21 Dec 2008 12:44:50 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221173057.GG2448@free.fr>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
Message-ID: <20081221174450.GB9876@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 06:30:57PM +0100, Patrice Dumas wrote:
> On Sun, Dec 21, 2008 at 12:14:38PM -0500, Alan Cox wrote:
> > 
> > FESCo has no power to make it work or not work. The GPL gave people all the
> > rights they need to create a long term Fedora variant.
> 
> Of course, but doing it within fedora (even not officially) is
> what FESCo can accept or reject.

And why do you need to do it within Fedora - if the answer is "I can only do
it by piggybacking on Fedora resources" then that sounds to me like you don't
have the resources to do it without harming the existing Fedora by freeloading.

Alan




From pertusus at free.fr  Sun Dec 21 17:48:11 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 18:48:11 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1229880540.3861.70.camel@localhost.localdomain>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<1229880540.3861.70.camel@localhost.localdomain>
Message-ID: <20081221174811.GH2448@free.fr>

On Sun, Dec 21, 2008 at 09:29:00AM -0800, Jesse Keating wrote:
> 
> Right, all FESCo did was decide to not spend Fedora Infrastructure
> resources on the venture until it had a proven set of producers and
> consumers.

The infrastructure resource point was explicitly handled in the 
proposal. How can there be a proven set of producers and consumers if 
it doesn't exists yet? Proving that something is succesful before it 
is started This is a task that is impossible to achieve.

Besides the reason was not that reason, the final decision was left 
to the board. Many people on FESCo didn't like the proposal for 
various reasons, including the Infrastructure resources, but it 
wasn't the official reason. In fact I have never heard back the 
board answer, but I prefer not knowing how the board refused it.

There was also  the joke about 'metrics', that are very difficult
or impossible to set up in free software projects, and are especially 
not something in fedora -- nor EPEL. And that was a task to perform 
before another proposal in the past (UAEL) could be accepted. A way 
to say no in a authoritative way without saying it frankly.

Honestly, I would have preferred an authoritative answer like 'we 
don't want because we don't want to devote a single resource to
that', rather than lame excuses and unfair impossible prerequisite 
tasks.

--
Pat



From pertusus at free.fr  Sun Dec 21 17:57:00 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 18:57:00 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221174450.GB9876@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
Message-ID: <20081221175700.GI2448@free.fr>

On Sun, Dec 21, 2008 at 12:44:50PM -0500, Alan Cox wrote:
> 
> And why do you need to do it within Fedora - if the answer is "I can only do
> it by piggybacking on Fedora resources" then that sounds to me like you don't
> have the resources to do it without harming the existing Fedora by freeloading.


Here was what I said in my proposal:
https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL

 This proposal does not want to divert resources from other uses in fedora. The idea is to profit from economies of scale and unused capacities (in the build system). Therefore infrastructure and releng teams should have a lot to say and the possibility to block if resources used are considered to be too high, especially if some work has to be done from those teams by people who are not volunteering to help that proposal to happen. 

It is not about freeloading or anything like that, but using an
already existing infrastructure. You seem to underestimate the 
costs of setting up an infrastructure, if you want to have an idea
about that you could have a look at rpmfusion. I followed rpmfusion
and it seems that it was quite a lot of work to have it done.
Or you can have a look at EPEL which is still needing a lot of
improvements in the infrastructure part.

--
Pat



From ascii79 at gmail.com  Sun Dec 21 18:13:44 2008
From: ascii79 at gmail.com (Sachin)
Date: Sun, 21 Dec 2008 12:13:44 -0600
Subject: Encrypted home directory
Message-ID: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>

Hi All,

Can we have the feature of the encrypted the home directory with out of the
box experience.

Ubuntu is planning for the next release. This is not real motivation.

http://www.ubuntu.com/testing/jaunty/alpha2

But to have this feature on a laptop is very useful.

I know user can implement this with some configuration changes but for
average person like me this could too much.

There is also not much of performance loss. Following is benchmarking from
Phoronix,

http://www.phoronix.com/scan.php?page=article&item=ubuntu_jaunty_encrypt&num=1

Regards,
Sachin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/38a2ba3e/attachment.htm>

From tcallawa at redhat.com  Sun Dec 21 18:28:18 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sun, 21 Dec 2008 13:28:18 -0500
Subject: rawhide report: 20081220 changes
In-Reply-To: <20081221163818.GB2448@free.fr>
References: <1229770470.5584.1.camel@hughsie-work.lan>
	<1229778828.14462.2.camel@arekh.okg>
	<1229787602.4136.6.camel@hughsie-work.lan>
	<1229788642.16655.12.camel@arekh.okg>
	<20081220180913.45f62880@lain.camperquake.de>
	<1229801171.24251.19.camel@arekh.okg>
	<1229854269.3382.5.camel@hughsie-work.lan> <494E18BB.8050005@gmail.com>
	<1229869750.3209.6836.camel@beck.corsepiu.local>
	<a9d183c80812210728r3856cadbx27d7e1c6a86a544b@mail.gmail.com>
	<20081221163818.GB2448@free.fr>
Message-ID: <1229884098.19374.80.camel@localhost.localdomain>

On Sun, 2008-12-21 at 17:38 +0100, Patrice Dumas wrote:
> If I recall well, the FPC ruling was not about anything else than 
> the version release format. I didn't found any trace of that, though.
> That being said it is indeed unclear from the guideline that only 
> the date and version-release is specified here.

We were focused on the version release issue because it was being
omitted. I could care less what people put in the description field,
common sense permitting.

~spot



From sandeen at redhat.com  Sun Dec 21 18:30:43 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sun, 21 Dec 2008 12:30:43 -0600
Subject: Encrypted home directory
In-Reply-To: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
Message-ID: <494E8B53.4050005@redhat.com>

Sachin wrote:
> Hi All,
> 
> Can we have the feature of the encrypted the home directory with out of
> the box experience.
> 
> Ubuntu is planning for the next release. This is not real motivation.
> 
> http://www.ubuntu.com/testing/jaunty/alpha2

eCryptfs is still somewhat fragile at times; under constrained usecases
it's reasonably ok but if you stray from that things can go badly...
The stuff Ubuntu has done is interesting but I'm wondering if anyone
there has really given the kernelspace side a good workout.  (I've
worked on eCryptfs a lot, and it's pretty nifty, but there are still
some kinks to work out).

dm-crypt is available for Fedora too, and while it is not as flexible on
a per-dir or per-file basis, it may be an option for you.

> But to have this feature on a laptop is very useful.
> 
> I know user can implement this with some configuration changes but for
> average person like me this could too much.
> 
> There is also not much of performance loss. Following is benchmarking
> from Phoronix,
> 
> http://www.phoronix.com/scan.php?page=article&item=ubuntu_jaunty_encrypt&num=1
> <http://www.phoronix.com/scan.php?page=article&item=ubuntu_jaunty_encrypt&num=1>

Ah, the vaunted phoronix benchmark suite ;)

-Eric

> Regards,
> Sachin.
> 



From gnomeuser at gmail.com  Sun Dec 21 18:47:15 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Sun, 21 Dec 2008 19:47:15 +0100
Subject: Encrypted home directory
In-Reply-To: <494E8B53.4050005@redhat.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
Message-ID: <1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>

2008/12/21 Eric Sandeen <sandeen at redhat.com>

> Sachin wrote:
> > Hi All,
> >
> > Can we have the feature of the encrypted the home directory with out of
> > the box experience.
> >
> > Ubuntu is planning for the next release. This is not real motivation.
> >
> > http://www.ubuntu.com/testing/jaunty/alpha2
>
> eCryptfs is still somewhat fragile at times; under constrained usecases
> it's reasonably ok but if you stray from that things can go badly...
> The stuff Ubuntu has done is interesting but I'm wondering if anyone
> there has really given the kernelspace side a good workout.  (I've
> worked on eCryptfs a lot, and it's pretty nifty, but there are still
> some kinks to work out).
>

encfs provides another solution, in userspace via fuse. On a glance it looks
like a good base for an equaliant feature, any thoughts?

I've been running using dm-crypt for a while now but it seems to me that
when all I have is some photos and documents I don't want to fall into the
wrong hands in case my machine is stolen, it's seems like overkill to
encrypt everything. Additionally it's some what cumbersome to have to unlock
the drive during boot. Another problem might be the performance hit of full
disk encryption on these low powered netbooks being unacceptable making
those a good target for a more lightweight solution?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/771cd1b0/attachment.htm>

From mike at flyn.org  Sun Dec 21 18:51:01 2008
From: mike at flyn.org (W. Michael Petullo)
Date: Sun, 21 Dec 2008 13:51:01 -0500
Subject: Encrypted home directory
In-Reply-To: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
Message-ID: <6991EF39-880D-4A02-8231-A48684EDB405@flyn.org>

> Can we have the feature of the encrypted the home directory with  
> out of the box experience.

The pam_mount package has been included in Fedora for quite some  
time. This module can provide an encrypted home directory that is  
mounted at login time with the user's account password.

See http://www.linuxjournal.com/article/6481 (note that his article  
is old, but much of its content is still relevant).

I have found that the big problem is unmounting, as processes are  
left behind when a user logs out that block unmounting $HOME. For  
some examples of this, see:

http://bugzilla.gnome.org/show_bug.cgi?id=134666
http://bugzilla.gnome.org/show_bug.cgi?id=134667
http://bugzilla.gnome.org/show_bug.cgi?id=134668

What is probably needed is integration into the Fedora install  
process or a utility that make configuring pam_mount easier.

Mike



From vonbrand at inf.utfsm.cl  Sun Dec 21 18:59:39 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 21 Dec 2008 15:59:39 -0300
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gilugg$i5m$2@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
Message-ID: <200812211859.mBLIxdma010947@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> Alan Cox wrote:
> > FESCo has no power to make it work or not work. The GPL gave people all
> > the rights they need to create a long term Fedora variant.
> 
> But it's impossible to pull off without infrastructure, and setting up the
> infrastructure required for this project outside of Fedora requires months
> of work, and with the expected bandwidth requirements (think OO.o security
> updates), quite possibly also lots of money. That's why this project is
> doomed to fail without access to the official Fedora infrastructure, which
> is what was refused.

You do realize that said bandwidth would have to come out of Fedora's
allotment, I presume.
-- 
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 ak at axet.ru  Sun Dec 21 19:01:15 2008
From: ak at axet.ru (Alexey Kuznetsov)
Date: Sun, 21 Dec 2008 22:01:15 +0300
Subject: Suggest new Suspend policy
Message-ID: <b38773640812211101u3ae976c2nf6673da9df0f50cc@mail.gmail.com>

Current suspend policy prevent do normal mobile work. I suggest for fedora
11 change suspend policy to new one.

Here is current points:
- normal state
- automatic suspend when inactivity (power managment option)
- session application (torrents, update process)
- user actions (close laptop, press power button)

For now if some session application active, she prevent move your laptop
from one place to another, that because ANY application can prevent you
close laptop and change his location. Everyone know - no good to transport
notebook in active state.

I suggest to create new rule for power managment system: any user action can
turn off machine or send it to suspend state, session application can
prevent only AUTOMATIC actions like automatic suspending.

Thanks for reading.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/d822033c/attachment.htm>

From paul at xelerance.com  Sun Dec 21 19:13:34 2008
From: paul at xelerance.com (Paul Wouters)
Date: Sun, 21 Dec 2008 14:13:34 -0500 (EST)
Subject: Encrypted home directory
In-Reply-To: <1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0812211409010.17649@newtla.xelerance.com>

On Sun, 21 Dec 2008, David Nielsen wrote:

> I've been running using dm-crypt for a while now but it seems to me that
> when all I have is some photos and documents I don't want to fall into the
> wrong hands in case my machine is stolen, it's seems like overkill to
> encrypt everything.

The overkill is pretty minimal imho.

> Additionally it's some what cumbersome to have to unlock
> the drive during boot. 

don't you have the same issue with your homedir? I take it the password
for that should not be the same as your regular login password.

> Another problem might be the performance hit of full
> disk encryption on these low powered netbooks being unacceptable making
> those a good target for a more lightweight solution?

Using it on my thinkpad x61, I don't notice it impacting me at all. I
even run other VM's that are files on the crypted fs.

Paul



From lesmikesell at gmail.com  Sun Dec 21 19:08:31 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 21 Dec 2008 13:08:31 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221174450.GB9876@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
Message-ID: <494E942F.2000309@gmail.com>

Alan Cox wrote:
> On Sun, Dec 21, 2008 at 06:30:57PM +0100, Patrice Dumas wrote:
>> On Sun, Dec 21, 2008 at 12:14:38PM -0500, Alan Cox wrote:
>>> FESCo has no power to make it work or not work. The GPL gave people all the
>>> rights they need to create a long term Fedora variant.
>> Of course, but doing it within fedora (even not officially) is
>> what FESCo can accept or reject.
> 
> And why do you need to do it within Fedora - if the answer is "I can only do
> it by piggybacking on Fedora resources" then that sounds to me like you don't
> have the resources to do it without harming the existing Fedora by freeloading.

And what is your guess on the time it would take for a lawsuit threat if 
someone actually did provide a Fedora-labeled distribution that didn't 
meet Fedora policies?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From nicolas.mailhot at laposte.net  Sun Dec 21 19:08:41 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 21 Dec 2008 20:08:41 +0100
Subject: Font package splitting clarification
Message-ID: <1229886521.5818.7.camel@arekh.okg>

Hi all,

Since the discussion on font package splitting rules seems to be
exhausted, and since no one stepped up with an obviously better proposal
than mine, I've queued the following FPC-side:

http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21)

I've tried to integrate all the exceptions that were brought up during
the discussion and that were consensual, and to separate the rules from
their rationale (so packagers in a hurry only need to read the first
part). I've ended up with four simple master rules that should not be
open to interpretation.

Best regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/1d72396e/attachment.sig>

From alan at redhat.com  Sun Dec 21 19:23:00 2008
From: alan at redhat.com (Alan Cox)
Date: Sun, 21 Dec 2008 14:23:00 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221175700.GI2448@free.fr>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
Message-ID: <20081221192300.GA21625@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 06:57:00PM +0100, Patrice Dumas wrote:
> already existing infrastructure. You seem to underestimate the 
> costs of setting up an infrastructure, if you want to have an idea
> about that you could have a look at rpmfusion. I followed rpmfusion
> and it seems that it was quite a lot of work to have it done.
> Or you can have a look at EPEL which is still needing a lot of
> improvements in the infrastructure part.

You seem to be trying to build a complete Fedora-alike infrastructure before
you do anything. That to me seems crazy. What do you actually need - a corner
on your own box to build rpms. A guest environment to test them and some disk
space on an ftp site.

Yes you'll need to grow that - if you get lots of users/contributors, but you
don't need to start that way. As it is so well put "Rome was not built in a day"


Alan



From alan at redhat.com  Sun Dec 21 19:26:40 2008
From: alan at redhat.com (Alan Cox)
Date: Sun, 21 Dec 2008 14:26:40 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494E942F.2000309@gmail.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<494E942F.2000309@gmail.com>
Message-ID: <20081221192640.GB21625@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 01:08:31PM -0600, Les Mikesell wrote:
> And what is your guess on the time it would take for a lawsuit threat if 
> someone actually did provide a Fedora-labeled distribution that didn't 
> meet Fedora policies?

I don't see the relevance of that question. If it doesn't follow Fedora policy
it isn't Fedora. It's another Fedora based distro with a longer lifetime.

Nothing to do with whether it can be done, and if it works well then maybe
it'll later become an official bit of Fedora.

The other way I can read you email is "I want to use the Fedora name for my own
purposes and do as I like so screw you all", which I hope is not the intent you
want to convey.

Alan



From gnomeuser at gmail.com  Sun Dec 21 19:28:24 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Sun, 21 Dec 2008 20:28:24 +0100
Subject: Suggest new Suspend policy
In-Reply-To: <b38773640812211101u3ae976c2nf6673da9df0f50cc@mail.gmail.com>
References: <b38773640812211101u3ae976c2nf6673da9df0f50cc@mail.gmail.com>
Message-ID: <1dedbbfc0812211128x7f8c9722k7fcd3c050b26ac50@mail.gmail.com>

Den 21. dec. 2008 20.01 skrev Alexey Kuznetsov <ak at axet.ru>:

> Current suspend policy prevent do normal mobile work. I suggest for fedora
> 11 change suspend policy to new one.
>
> Here is current points:
> - normal state
> - automatic suspend when inactivity (power managment option)
> - session application (torrents, update process)
> - user actions (close laptop, press power button)
>
> For now if some session application active, she prevent move your laptop
> from one place to another, that because ANY application can prevent you
> close laptop and change his location. Everyone know - no good to transport
> notebook in active state.
>
> I suggest to create new rule for power managment system: any user action
> can turn off machine or send it to suspend state, session application can
> prevent only AUTOMATIC actions like automatic suspending.


For that to work we would have to first put out extensive information on
this change in behaviour along with information on how to opt-out (in case
of a broken setup, during the time the problem is being debugged I might
want to be able to use my machine). You would also need really good guides
on how to narrow the search for the problem and gathering of information to
avoid wasting development time repeating the same questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/3bfb5bd2/attachment.htm>

From metherid at gmail.com  Sun Dec 21 19:31:44 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Mon, 22 Dec 2008 01:01:44 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494E942F.2000309@gmail.com>
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>
	<494E942F.2000309@gmail.com>
Message-ID: <494E99A0.5020105@gmail.com>

Les Mikesell wrote:
>
> And what is your guess on the time it would take for a lawsuit threat 
> if someone actually did provide a Fedora-labeled distribution that 
> didn't meet Fedora policies?
His guess is irrelevant. Don't deliberately break policies and you don't 
have to worry about that. 

Rahul




From lesmikesell at gmail.com  Sun Dec 21 19:40:37 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 21 Dec 2008 13:40:37 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <66ec675b0812210439t3063059bgaf8eb5cf23966652@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229724098.23410.88.camel@dimi.lattica.com>	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>	<494D3DB2.4000304@gmail.com>
	<66ec675b0812210439t3063059bgaf8eb5cf23966652@mail.gmail.com>
Message-ID: <494E9BB5.2080504@gmail.com>

Joonas Saraj?rvi wrote:
>
>> Can someone who likes (even tolerates) spatial mode describe why?  I'm
>> completely baffled as to why anyone would prefer windows left open all over
>> the place randomly instead of just explicitly opening ones yourself in
>> places where you want them.  For me, it is _always_ extra work to close the
>> unwanted windows compared to opening the ones I want.
> 
> I have used Nautilus in spatial mode as my main file manager for a
> couple of years.
> 
> I like the spatial mode because:
> 
> The interface is very clean and simple. There are no toolbars or tabs,
> just the actual files that I am interested in.

Something that could have been better provided by options to view or not 
each of the other sections of the window in browser mode.

> The folders open where I left them the last time, also retaining their
> settings. 

Again, something that would be more useful as a separate option.

> I can have a bigger window for directories with lots of
> stuff or where I want to have a bigger zoom level to make better use
> of the preview images, or a smaller window for others.

That's reasonable only for some tiny number of directories and only 
repeat the same operations.  What about people who have a lot or 
nfs-mount many resources from other machines and seldom do the same 
thing in the same place?

> Drag and drop is easy, but I don't think this is the best thing about
> spatial mode. It's just an adde bonus.
> 
> Things I don't like in spatial mode:
> 
> Tendency to create create lots of windows.

The whole mess could have been avoided simply by keeping the standard 
mechanism to move to a new directory in the current window and adding 
the oddball method for the less likely circumstance when you want a new 
window.   Why did all of the behavior changes have to bundled into one 
choice that includes backwards-incompatibility?


> What I can do to avoid opening a hundred and one windows?
> 
> Use shift-click or middle click to close the parent folder's window.
> 
> Use the bookmark feature of Nautilus.
> 
> Set common 'root' directories, like your homedir and to list mode
> (ctrl+2) and use the tree to navigate to your target without opening
> new windows at all.

If you only repeat operations among a few directories you could just 
throw symlinks on your desktop and never navigate at all...

> Somewhere it was mentioned that all the other major distros have the
> browser mode as default. However, I think at least Debian has spatial
> mode as the default mode for Nautilus.

Maybe - there are plenty of things in debian that Ubuntu has to fix to 
be usable.

-- 
    Les Mikesell
     lesmikesell at gmail.com




From rjones at redhat.com  Sun Dec 21 19:48:44 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 21 Dec 2008 19:48:44 +0000
Subject: Can we make it so that Bodhi runs automatically?
Message-ID: <20081221194844.GA10113@amd.home.annexia.org>


I know I should make a patch to do this, but ...

Is there any reason why you _wouldn't_ want Bodhi to take an update
automatically after a successful Koji build of a non-Rawhide package?
It's an extra step that I always have to do manually, and I've never
seen a case where I wouldn't want Bodhi to just happen automatically.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From lesmikesell at gmail.com  Sun Dec 21 20:05:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 21 Dec 2008 14:05:19 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221192640.GB21625@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>
	<20081221192640.GB21625@shell.devel.redhat.com>
Message-ID: <494EA17F.6010708@gmail.com>

Alan Cox wrote:
> On Sun, Dec 21, 2008 at 01:08:31PM -0600, Les Mikesell wrote:
>> And what is your guess on the time it would take for a lawsuit threat if 
>> someone actually did provide a Fedora-labeled distribution that didn't 
>> meet Fedora policies?
> 
> I don't see the relevance of that question. If it doesn't follow Fedora policy
> it isn't Fedora. It's another Fedora based distro with a longer lifetime.
> 
> Nothing to do with whether it can be done, and if it works well then maybe
> it'll later become an official bit of Fedora.
> 
> The other way I can read you email is "I want to use the Fedora name for my own
> purposes and do as I like so screw you all", which I hope is not the intent you
> want to convey.

It's more like "Fedora would have to change before I would find it 
useful for any purpose", which I guess is only slightly different.  Or 
at least any purpose other than a preview of what the next RHEL might 
contain and even that hasn't looked too promising lately.

But as far as making usably stable versions, there are a couple of 
approaches that would avoid wasting a lot of resources.  One is to plan 
a smooth transition into the next Centos via yum update to end up with a 
real long term supported system without duplicating any work on 
backported updates.  Another which isn't really a long-term approach but 
could produce usably-stable versions that overlapped a bit would be to 
stop introducing new features in updates in one release by or before the 
beta of the next release and focus only on stability from that point to 
end of life.  Even if EOL is not extended you'd have a version that you 
could run until the next version reached that point - and people who 
want new features can jump to the next release instead.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From rjones at redhat.com  Sun Dec 21 20:05:05 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 21 Dec 2008 20:05:05 +0000
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221192300.GA21625@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
Message-ID: <20081221200505.GB10113@amd.home.annexia.org>

On Sun, Dec 21, 2008 at 02:23:00PM -0500, Alan Cox wrote:
> You seem to be trying to build a complete Fedora-alike infrastructure before
> you do anything. That to me seems crazy. What do you actually need - a corner
> on your own box to build rpms. A guest environment to test them and some disk
> space on an ftp site.

Alan's quite right.  I am hosting the MinGW RPMs temporarily on my own
site (something like 700-800 MBs worth):

http://www.annexia.org/tmp/mingw/fedora-10/

This is of course no substitute for proper, reliable Fedora hosting
and mirroring, which we'll get eventually once the packages are
reviewed.

But I spend under $30 / month on this server, and there is no
noticable load from the 565 people[1] synching their development
machines to it.

Rich.

[1] "people" = distinct IPs making > 1 request for repomd.xml, so
probably the real number of users is a bit less than this.

-- 
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  Sun Dec 21 20:15:23 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 21 Dec 2008 20:15:23 +0000
Subject: Encrypted home directory
In-Reply-To: <1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
Message-ID: <20081221201523.GC10113@amd.home.annexia.org>

On Sun, Dec 21, 2008 at 07:47:15PM +0100, David Nielsen wrote:
> I've been running using dm-crypt for a while now but it seems to me that
> when all I have is some photos and documents I don't want to fall into the
> wrong hands in case my machine is stolen, it's seems like overkill to
> encrypt everything. Additionally it's some what cumbersome to have to unlock
> the drive during boot. Another problem might be the performance hit of full
> disk encryption on these low powered netbooks being unacceptable making
> those a good target for a more lightweight solution?

Won't solve your unlocking problem, but why not have a separate
encrypted /home partition?  I've had separate /home partitions for
years, not for encryption, just because that's the directory I really
care about, so I want to be able to handle it specially anyway.

The other reason to _not_ encrypt the system directories is so that
system files can be easily mmapped into memory.  And after all, there
is no secret in the system files.

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  Sun Dec 21 20:16:18 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 21 Dec 2008 20:16:18 +0000
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221200505.GB10113@amd.home.annexia.org>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221200505.GB10113@amd.home.annexia.org>
Message-ID: <20081221201618.GD10113@amd.home.annexia.org>

On Sun, Dec 21, 2008 at 08:05:05PM +0000, Richard W.M. Jones wrote:
> [1] "people" = distinct IPs making > 1 request for repomd.xml, so
> probably the real number of users is a bit less than this.

I should add that I only count requests where the user-agent field
indicates yum, so this doesn't include spiders/spammers/etc.

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 pertusus at free.fr  Sun Dec 21 20:21:10 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 21:21:10 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221192300.GA21625@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
Message-ID: <20081221202110.GJ2448@free.fr>

On Sun, Dec 21, 2008 at 02:23:00PM -0500, Alan Cox wrote:
> 
> You seem to be trying to build a complete Fedora-alike infrastructure before
> you do anything. That to me seems crazy. What do you actually need - a corner
> on your own box to build rpms. A guest environment to test them and some disk
> space on an ftp site.
> 
> Yes you'll need to grow that - if you get lots of users/contributors, but you
> don't need to start that way. As it is so well put "Rome was not built in a day"

Of course that can be done like that. But what was appealing in 
the use of fedora infrastructure after end of life was that it could 
be possible to avoid most costs associated with setting up an 
infrastructure of any size. The setup could have been done 
using already accumulated work (including community building) at 
litte additional cost.

It may be done otherwise, sure, it is free software, but I still
think that it would be much less cost-effective.

Now FESCo/board can still veto that, the fact that it is cost-effective
doesn't make it free. But saying that FESCo has no responsibility in
this is wrong.

--
Pat



From lists at sapience.com  Sun Dec 21 20:31:34 2008
From: lists at sapience.com (Mail Lists)
Date: Sun, 21 Dec 2008 15:31:34 -0500
Subject: Encrypted home directory
In-Reply-To: <20081221201523.GC10113@amd.home.annexia.org>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>	<494E8B53.4050005@redhat.com>	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
Message-ID: <494EA7A6.6020009@sapience.com>

On 12/21/2008 03:15 PM, Richard W.M. Jones wrote:

> The other reason to _not_ encrypt the system directories is so that
> system files can be easily mmapped into memory.  And after all, there
> is no secret in the system files.


  Remember also /tmp, /var/tmp and swap - where much a lovely secret can
be found!

  I encrypt /home and /swap and I bind mount /tmp and /var/tmp from
/home/tmp and /home/var/tmp for completeness. If you run certain
services you may want to bind mount /var out of the encrypted partition
as well.


 best,

   gene/



From alan at redhat.com  Sun Dec 21 20:33:12 2008
From: alan at redhat.com (Alan Cox)
Date: Sun, 21 Dec 2008 15:33:12 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221202110.GJ2448@free.fr>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
Message-ID: <20081221203312.GA30301@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 09:21:10PM +0100, Patrice Dumas wrote:
> infrastructure of any size. The setup could have been done 
> using already accumulated work (including community building) at 
> litte additional cost.

But cost and risk dumped on the community not the people proposing the idea.

> It may be done otherwise, sure, it is free software, but I still
> think that it would be much less cost-effective.

Perhaps.. but the sooner you go do it the sooner it happens.

Alan



From gnomeuser at gmail.com  Sun Dec 21 20:35:08 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Sun, 21 Dec 2008 21:35:08 +0100
Subject: Encrypted home directory
In-Reply-To: <20081221201523.GC10113@amd.home.annexia.org>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
Message-ID: <1dedbbfc0812211235p7dfbc5aey9a8589d80100282b@mail.gmail.com>

2008/12/21 Richard W.M. Jones <rjones at redhat.com>

> On Sun, Dec 21, 2008 at 07:47:15PM +0100, David Nielsen wrote:
> > I've been running using dm-crypt for a while now but it seems to me that
> > when all I have is some photos and documents I don't want to fall into
> the
> > wrong hands in case my machine is stolen, it's seems like overkill to
> > encrypt everything. Additionally it's some what cumbersome to have to
> unlock
> > the drive during boot. Another problem might be the performance hit of
> full
> > disk encryption on these low powered netbooks being unacceptable making
> > those a good target for a more lightweight solution?
>
> Won't solve your unlocking problem, but why not have a separate
> encrypted /home partition?  I've had separate /home partitions for
> years, not for encryption, just because that's the directory I really
> care about, so I want to be able to handle it specially anyway.


/home is seperate on all my boxes, so yes that solution would work. I do
believe Ubuntu' solution is a seperate partition they map to a folder called
Private in your home dir which is unlocked at login. I have no idea of the
security of that solution but it does seem that this way one could keep a
few files secret while the machine is powered down so if it gets lost in the
airport e.g. those few precious personal files don't fall into the wrong
hands.


> The other reason to _not_ encrypt the system directories is so that
> system files can be easily mmapped into memory.  And after all, there
> is no secret in the system files.


no secrets.. but how else would the penguins send me coded messages to
convey the dropbox locations?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/6f885061/attachment.htm>

From stlwrt at gmail.com  Sun Dec 21 20:22:44 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Sun, 21 Dec 2008 22:22:44 +0200
Subject: Can we make it so that Bodhi runs automatically?
In-Reply-To: <20081221194844.GA10113@amd.home.annexia.org>
References: <20081221194844.GA10113@amd.home.annexia.org>
Message-ID: <d25f375f0812211222h1f6e5d7ew3ee3fb0d53b6df34@mail.gmail.com>

Because it won't allow to update highly modular packages properly.
Imaging gedit update being pushed before updated gnome-libs are built

On Sun, Dec 21, 2008 at 9:48 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
>
> I know I should make a patch to do this, but ...
>
> Is there any reason why you _wouldn't_ want Bodhi to take an update
> automatically after a successful Koji build of a non-Rawhide package?
> It's an extra step that I always have to do manually, and I've never
> seen a case where I wouldn't want Bodhi to just happen automatically.
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://et.redhat.com/~rjones/virt-df/
>
> --
> 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  Sun Dec 21 21:03:39 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Dec 2008 22:03:39 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221203312.GA30301@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
Message-ID: <20081221210339.GK2448@free.fr>

On Sun, Dec 21, 2008 at 03:33:12PM -0500, Alan Cox wrote:
> 
> But cost and risk dumped on the community not the people proposing the idea.

There was no risk, since it was explitcitly unofficial.
Regarding the cost, the idea was that they could be 
assessed and the project reevaluated after the proposal
was tested (I did paste the paragraph in a previous mail).

An underlying idea of mine was that it could help re-attract 
users and contributors or avoid that they leave, given that 
the balance in Fedora was much more on the innovative side.
So, in my opinion there was some value for the Fedora project.

But this is certainly the weak part of such proposals, since
instead many of the people leading fedora explicitely want 
such a project not to happen (irrespective of the costs)
and the others are not in favor of it. And it is the real 
reason why the proposal was rejected, that's why I don't 
want to let think that there was a specific reason like 
cost or bug handling or size of the contributor base or 
whatever.

That being said I agree that the cost is still there and
it is a valid reason.

> > It may be done otherwise, sure, it is free software, but I still
> > think that it would be much less cost-effective.
> 
> Perhaps.. but the sooner you go do it the sooner it happens.

If the cost is higher, it may never happen. 

--
Pat



From fedora at camperquake.de  Sun Dec 21 20:46:30 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 21 Dec 2008 21:46:30 +0100
Subject: Encrypted home directory
In-Reply-To: <20081221201523.GC10113@amd.home.annexia.org>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
Message-ID: <20081221214630.669fbad3@lain.camperquake.de>

Hi.

On Sun, 21 Dec 2008 20:15:23 +0000, Richard W.M. Jones wrote

> The other reason to _not_ encrypt the system directories is so that
> system files can be easily mmapped into memory.

How would encrypting the system directories prevent you from doing that?



From jkeating at redhat.com  Sun Dec 21 22:31:04 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 14:31:04 -0800
Subject: Can we make it so that Bodhi runs automatically?
In-Reply-To: <20081221194844.GA10113@amd.home.annexia.org>
References: <20081221194844.GA10113@amd.home.annexia.org>
Message-ID: <1229898664.3861.73.camel@localhost.localdomain>

On Sun, 2008-12-21 at 19:48 +0000, Richard W.M. Jones wrote:
> I know I should make a patch to do this, but ...

make build update 

?

We don't automatically take things because we expect you to fill in some
details about the update, what it's fixing, what bugs should be closed,
what enhancements are added, what users should test for, if it's
security, etc...  We don't want people to just throw builds over the
wall at users and hope it sticks.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/3e599af1/attachment.sig>

From ndbecker2 at gmail.com  Sun Dec 21 22:31:52 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 21 Dec 2008 17:31:52 -0500
Subject: Do I need to take action on these broken dependencies (python
	related)
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
	<494E7F41.5020601@gmail.com>
Message-ID: <gimg4o$584$1@ger.gmane.org>

Rahul Sundaram wrote:

> Jesse Keating wrote:
>> On Sun, 2008-12-21 at 11:52 -0500, Neal Becker wrote:
>>   
>>> python-igraph has broken dependencies in the development tree:
>>> On ppc:
>>>         python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
>>>         python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
>>> On x86_64:
>>>         python-igraph-0.5-5.fc9.x86_64 requires
>>>         libpython2.5.so.1.0()(64bit) python-igraph-0.5-5.fc9.x86_64
>>>         requires python(abi) = 0:2.5
>>> On i386:
>>>         python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
>>>         python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
>>> On ppc64:
>>>         python-igraph-0.5-5.fc9.ppc64 requires
>>>         libpython2.5.so.1.0()(64bit) python-igraph-0.5-5.fc9.ppc64
>>>         requires python(abi) = 0:2.5
>>> Please resolve this as soon as possible.
>>>
>>>     
>>
>> If you're a (co)maintainer for python-igraph, then yes you need to
>> address it.  The things that weren't auto-rebuilt for the python bump
>> either had closed ACLs or failed to build from source.
>>   
> Alternatively, stop using ACL's and let others help you.
> 
> Rahul
> 
Can someone remind me where to find the web page for editing the acls?  (Not easily found from fedoraproject.org/wiki, I'm afraid)




From jkeating at redhat.com  Sun Dec 21 22:36:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 14:36:13 -0800
Subject: [Fedora Update] [stable] fakeroot-1.11-19.fc8
In-Reply-To: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>
Message-ID: <1229898973.3861.75.camel@localhost.localdomain>

On Sun, 2008-12-21 at 21:54 +0000, updates at fedoraproject.org wrote:
> athimm has requested the pushing of the following update stable:
> 
> ================================================================================
>      fakeroot-1.11-19.fc8
> ================================================================================
>     Release: Fedora 8
>      Status: pending
>        Type: enhancement
>       Karma: 0
>     Request: stable
>   Submitter: athimm
>   Submitted: 2008-12-21 21:54:06
>    Comments: athimm - 2008-12-21 21:54:07 (karma 0)
>              This update has been submitted for stable
> 
>   http://admin.fedoraproject.org/updates/fakeroot-1.11-19.fc8
> 

Why is there a major version change (1.9.7 -> 1.11.19) going directly
into stable on F8 (which has days to live) without any information for
users what so ever that this update is providing.  Please provide some
details for users and reconsider if this update is really suitable for
F8.

http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/3561c886/attachment.sig>

From jkeating at redhat.com  Sun Dec 21 22:37:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 14:37:35 -0800
Subject: Do I need to take action on these broken dependencies (python
 related)
In-Reply-To: <gimg4o$584$1@ger.gmane.org>
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
	<494E7F41.5020601@gmail.com>  <gimg4o$584$1@ger.gmane.org>
Message-ID: <1229899055.3861.76.camel@localhost.localdomain>

On Sun, 2008-12-21 at 17:31 -0500, Neal Becker wrote:
> Can someone remind me where to find the web page for editing the acls?
> (Not easily found from fedoraproject.org/wiki, I'm afraid)

https://admin.fedoraproject.org/pkgdb

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/d40e884b/attachment.sig>

From trever.adams at gmail.com  Sun Dec 21 22:41:37 2008
From: trever.adams at gmail.com (Trever L. Adams)
Date: Sun, 21 Dec 2008 15:41:37 -0700
Subject: Multiple packages from one tarball and spec file
In-Reply-To: <494AB974.1070803@gmail.com>
References: <493162FA.6030705@gmail.com>
	<200811291322.11215.konrad@tylerc.org>	<494AB1CB.2000705@gmail.com>
	<494AB974.1070803@gmail.com>
Message-ID: <494EC621.6020107@gmail.com>

Toshio Kuratomi wrote:
> Yes.
> I believe the vim package does this to generate the vim-minimal (with
> /bin/vi) and vim-enhanced  (with /usr/bin/vim).
>
> -Toshio
>
>   
Toshio,

Again, thank you. This turned out to be exactly what I needed. I have 
now rebuilt my packages from one source tree.

Trever


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/751e7759/attachment.sig>

From muepsj at gmail.com  Sun Dec 21 22:46:37 2008
From: muepsj at gmail.com (=?UTF-8?Q?Joonas_Saraj=C3=A4rvi?=)
Date: Mon, 22 Dec 2008 00:46:37 +0200
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494E9BB5.2080504@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
	<66ec675b0812210439t3063059bgaf8eb5cf23966652@mail.gmail.com>
	<494E9BB5.2080504@gmail.com>
Message-ID: <66ec675b0812211446i3b284930o6bd7973b58391ea9@mail.gmail.com>

Hello,

It seems a few points about the spatial mode need to be clarified
first. And btw, I didn't invent these things and I may have gotten
some things wrong, so please correct me if need be.

The spatial paradigm is a shift from application centric design to an
object centric one. It requires every object to have a consistent
state which is remembered. When a new directory is opened, it is
exactly where the user left it last time. Actually the user doesn't
open a new window, but a folder instead. Opening a folder shouldn't
affect another folder's state, which is why the existing folder is
left open.


2008/12/21 Les Mikesell <lesmikesell at gmail.com>:
> Joonas Saraj?rvi wrote:
>> The interface is very clean and simple. There are no toolbars or tabs,
>> just the actual files that I am interested in.
>
> Something that could have been better provided by options to view or not
> each of the other sections of the window in browser mode.

There are such options already in the View menu. However, browser mode
is quite inconvenient to use without the toolbar and and the location
bar.

>> The folders open where I left them the last time, also retaining their
>> settings.
>
> Again, something that would be more useful as a separate option.


Moving the one window to a completely different place and size on the
screen, while also maybe changing the view mode and zoom level would
in my opinion be no better than opening a new window, but a lot more
confusing. It already does this with the shift-click if desired,
though.

I think Ubuntu once did this always, before switching to default to
browser mode, but I may be wrong.

>> I can have a bigger window for directories with lots of
>> stuff or where I want to have a bigger zoom level to make better use
>> of the preview images, or a smaller window for others.
>
> That's reasonable only for some tiny number of directories and only repeat
> the same operations.  What about people who have a lot or nfs-mount many
> resources from other machines and seldom do the same thing in the same
> place?

Spatial mode isn't optimal for everyone. Many computer users use their
machine only for a small number of tasks. There is the browser mode
(Available either from menu for one time browsing or from settings to
have it always) for those who need it.

It wouldn't be very hard to set the view for all the NFS share roots
to the list view, after which one could use the tree to navigate.

>> Drag and drop is easy, but I don't think this is the best thing about
>> spatial mode. It's just an adde bonus.
>>
>> Things I don't like in spatial mode:
>>
>> Tendency to create create lots of windows.
>
> The whole mess could have been avoided simply by keeping the standard
> mechanism to move to a new directory in the current window and adding the
> oddball method for the less likely circumstance when you want a new window.
>   Why did all of the behavior changes have to bundled into one choice that
> includes backwards-incompatibility?

If the spatial mode did that, it wouldn't really be spatial.


>> What I can do to avoid opening a hundred and one windows?
>>
>> Use shift-click or middle click to close the parent folder's window.
>>
>> Use the bookmark feature of Nautilus.
>>
>> Set common 'root' directories, like your homedir and to list mode
>> (ctrl+2) and use the tree to navigate to your target without opening
>> new windows at all.
>
> If you only repeat operations among a few directories you could just throw
> symlinks on your desktop and never navigate at all...

I can set every remote resource I use to have a list view at its root.
Alternatively, I can also use the browser mode to deal with that kind
of situations.

>> Somewhere it was mentioned that all the other major distros have the
>> browser mode as default. However, I think at least Debian has spatial
>> mode as the default mode for Nautilus.
>
> Maybe - there are plenty of things in debian that Ubuntu has to fix to be
> usable.

In my opinion, Debian is at least as usable as a desktop software
distribution as Ubuntu is.

-- 
Joonas Saraj?rvi
muepsj at gmail.com



From ndbecker2 at gmail.com  Sun Dec 21 22:47:38 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 21 Dec 2008 17:47:38 -0500
Subject: Do I need to take action on these broken dependencies (python
	related)
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
	<494E7F41.5020601@gmail.com> <gimg4o$584$1@ger.gmane.org>
	<1229899055.3861.76.camel@localhost.localdomain>
Message-ID: <gimh2a$7af$1@ger.gmane.org>

Jesse Keating wrote:

> On Sun, 2008-12-21 at 17:31 -0500, Neal Becker wrote:
>> Can someone remind me where to find the web page for editing the acls?
>> (Not easily found from fedoraproject.org/wiki, I'm afraid)
> 
> https://admin.fedoraproject.org/pkgdb
> 

OK, so how do I 'stop using acls and let others help you'?  When I look at 
https://admin.fedoraproject.org/pkgdb/packages/name/python-igraph

it looks to me that 
provenpackager group members can commit? on




From jkeating at redhat.com  Sun Dec 21 22:54:40 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 14:54:40 -0800
Subject: Do I need to take action on these broken dependencies (python
 related)
In-Reply-To: <gimh2a$7af$1@ger.gmane.org>
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
	<494E7F41.5020601@gmail.com> <gimg4o$584$1@ger.gmane.org>
	<1229899055.3861.76.camel@localhost.localdomain>
	<gimh2a$7af$1@ger.gmane.org>
Message-ID: <1229900080.3861.77.camel@localhost.localdomain>

On Sun, 2008-12-21 at 17:47 -0500, Neal Becker wrote:
> OK, so how do I 'stop using acls and let others help you'?  When I
> look at 
> https://admin.fedoraproject.org/pkgdb/packages/name/python-igraph
> 
> it looks to me that 
> provenpackager group members can commit? on

Perhaps Rahul was speaking in the general sense, and not specifically
about your package.  I never claimed that your package was closed, only
that it didn't automatically get rebuilt for one of two reasons.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/9d10bef2/attachment.sig>

From ndbecker2 at gmail.com  Sun Dec 21 23:08:06 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 21 Dec 2008 18:08:06 -0500
Subject: Do I need to take action on these broken dependencies (python
	related)
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
	<494E7F41.5020601@gmail.com> <gimg4o$584$1@ger.gmane.org>
	<1229899055.3861.76.camel@localhost.localdomain>
	<gimh2a$7af$1@ger.gmane.org>
	<1229900080.3861.77.camel@localhost.localdomain>
Message-ID: <gimi8n$b5m$1@ger.gmane.org>

Jesse Keating wrote:

> On Sun, 2008-12-21 at 17:47 -0500, Neal Becker wrote:
>> OK, so how do I 'stop using acls and let others help you'?  When I
>> look at
>> https://admin.fedoraproject.org/pkgdb/packages/name/python-igraph
>> 
>> it looks to me that
>> provenpackager group members can commit? on
> 
> Perhaps Rahul was speaking in the general sense, and not specifically
> about your package.  I never claimed that your package was closed, only
> that it didn't automatically get rebuilt for one of two reasons.
> 

Could someone please tell me what action I need to take?



From jkeating at redhat.com  Sun Dec 21 23:17:56 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 15:17:56 -0800
Subject: Do I need to take action on these broken dependencies (python
 related)
In-Reply-To: <gimi8n$b5m$1@ger.gmane.org>
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
	<494E7F41.5020601@gmail.com> <gimg4o$584$1@ger.gmane.org>
	<1229899055.3861.76.camel@localhost.localdomain>
	<gimh2a$7af$1@ger.gmane.org>
	<1229900080.3861.77.camel@localhost.localdomain>
	<gimi8n$b5m$1@ger.gmane.org>
Message-ID: <1229901476.3861.81.camel@localhost.localdomain>

On Sun, 2008-12-21 at 18:08 -0500, Neal Becker wrote:
> Could someone please tell me what action I need to take?

The bottom line is your package needs to be rebuilt against the new
python.  Apparently in the past it didn't work
( http://koji.fedoraproject.org/koji/taskinfo?taskID=958430 )
unfortunately there aren't any logs left, so you should try a build
again, see why it fails, and fix it.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/381a99dd/attachment.sig>

From jamundso at gmail.com  Sun Dec 21 23:22:13 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 21 Dec 2008 17:22:13 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
Message-ID: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>

I'm re-visiting my FAS account after several months hiatus. All the
reasons I've avoided "joining" are coming back to me.
How do I resolve the
Todo queue:
Download a client-side certificate
always appearing at login?
(yes, I've downloaded it, imported it, cast it in bronze...)
I got to the point of
http://fedoraproject.org/wiki/PackageMaintainers/Join where "You'll
also need two more certs:" is followed by blank space.
Going back to the beginning of the fun, the ever so tempting Join
Fedora. link from fp.o does not even mention Package Maintainers or
Bug Zappers, yet has pretty pics/links of seemingly every other role.
And we wonder why help is lacking?
The Help/Documentation tab of FAS accounts home points to the
docs.fp.o - how does that help with FAS? What is documented with FAS?

jerry

--
To be named later.



From ndbecker2 at gmail.com  Sun Dec 21 23:33:18 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 21 Dec 2008 18:33:18 -0500
Subject: Do I need to take action on these broken dependencies (python
	related)
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
	<494E7F41.5020601@gmail.com> <gimg4o$584$1@ger.gmane.org>
	<1229899055.3861.76.camel@localhost.localdomain>
	<gimh2a$7af$1@ger.gmane.org>
	<1229900080.3861.77.camel@localhost.localdomain>
	<gimi8n$b5m$1@ger.gmane.org>
	<1229901476.3861.81.camel@localhost.localdomain>
Message-ID: <gimjnu$dqb$1@ger.gmane.org>

Jesse Keating wrote:

> On Sun, 2008-12-21 at 18:08 -0500, Neal Becker wrote:
>> Could someone please tell me what action I need to take?
> 
> The bottom line is your package needs to be rebuilt against the new
> python.  Apparently in the past it didn't work
> ( http://koji.fedoraproject.org/koji/taskinfo?taskID=958430 )
> unfortunately there aren't any logs left, so you should try a build
> again, see why it fails, and fix it.
> 
DEBUG util.py:250:  No Package Found for igraph-devel = 0.5.1

How do I ensure igraph-devel is available to build against?



From lesmikesell at gmail.com  Sun Dec 21 23:26:57 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 21 Dec 2008 17:26:57 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <66ec675b0812211446i3b284930o6bd7973b58391ea9@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>	<1229734702.23410.103.camel@dimi.lattica.com>	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>	<1229753424.23410.153.camel@dimi.lattica.com>	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>	<494D3DB2.4000304@gmail.com>	<66ec675b0812210439t3063059bgaf8eb5cf23966652@mail.gmail.com>	<494E9BB5.2080504@gmail.com>
	<66ec675b0812211446i3b284930o6bd7973b58391ea9@mail.gmail.com>
Message-ID: <494ED0C1.2060307@gmail.com>

Joonas Saraj?rvi wrote:
>
> It seems a few points about the spatial mode need to be clarified
> first. And btw, I didn't invent these things and I may have gotten
> some things wrong, so please correct me if need be.
> 
> The spatial paradigm is a shift from application centric design to an
> object centric one. It requires every object to have a consistent
> state which is remembered.

OK, but that's never what I want to happen.  I don't want to observe the 
inherent clutter of the objects.  I want to open windows only to 
specific places, and I want the windows to be positioned where I want 
them _now_, not where they might have landed some other time.

> When a new directory is opened, it is
> exactly where the user left it last time.

For some tiny number of directories, that might be handy.  But then 
again, how much time can it possibly save if all you are visiting is a 
tiny number of directories?

> Actually the user doesn't
> open a new window, but a folder instead. Opening a folder shouldn't
> affect another folder's state, which is why the existing folder is
> left open.

But except in rare cases the reason I navigate to a new location is that 
I'm done in the current one, or it was just an intermediate node in a 
long path.  So leaving it open is nearly always the wrong thing to do.

>>> Tendency to create create lots of windows.
>> The whole mess could have been avoided simply by keeping the standard
>> mechanism to move to a new directory in the current window and adding the
>> oddball method for the less likely circumstance when you want a new window.
>>   Why did all of the behavior changes have to bundled into one choice that
>> includes backwards-incompatibility?
> 
> If the spatial mode did that, it wouldn't really be spatial.

You lost me there.  What does the specific click-mechanism that leaves 1 
window open vs. 2 windows have to do with being spatial or not?  I might 
be able to tolerate the window shifting location/size as long as it 
didn't leave the unnecessary open windows down the path.  But that might 
depend on the defaults for new locations since a lot of places are only 
visited once.

>> If you only repeat operations among a few directories you could just throw
>> symlinks on your desktop and never navigate at all...
> 
> I can set every remote resource I use to have a list view at its root.
> Alternatively, I can also use the browser mode to deal with that kind
> of situations.

If you have to set options to make them reasonable, discussing the 
defaults doesn't make a lot of sense.

>>> Somewhere it was mentioned that all the other major distros have the
>>> browser mode as default. However, I think at least Debian has spatial
>>> mode as the default mode for Nautilus.
>> Maybe - there are plenty of things in debian that Ubuntu has to fix to be
>> usable.
> 
> In my opinion, Debian is at least as usable as a desktop software
> distribution as Ubuntu is.

That makes one of us.  I can't think of any change in Ubuntu that wasn't 
needed or that makes it worse than debian.

--
    Les Mikesell
     lesmikesell at gmail.com




From jkeating at redhat.com  Sun Dec 21 23:37:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 15:37:35 -0800
Subject: Do I need to take action on these broken dependencies (python
 related)
In-Reply-To: <gimjnu$dqb$1@ger.gmane.org>
References: <gils85$ds7$1@ger.gmane.org>
	<1229878658.3861.66.camel@localhost.localdomain>
	<494E7F41.5020601@gmail.com> <gimg4o$584$1@ger.gmane.org>
	<1229899055.3861.76.camel@localhost.localdomain>
	<gimh2a$7af$1@ger.gmane.org>
	<1229900080.3861.77.camel@localhost.localdomain>
	<gimi8n$b5m$1@ger.gmane.org>
	<1229901476.3861.81.camel@localhost.localdomain>
	<gimjnu$dqb$1@ger.gmane.org>
Message-ID: <1229902655.3861.83.camel@localhost.localdomain>

On Sun, 2008-12-21 at 18:33 -0500, Neal Becker wrote:
> DEBUG util.py:250:  No Package Found for igraph-devel = 0.5.1
> 
> How do I ensure igraph-devel is available to build against?

Well, your python-igraph is looking explicitly for igraph-devel version
0.5.1, however you bumped igraph only on F8 and F9 branches, none of the
others.  You'll need to bump igraph in devel/ for your F11 build, and
likely the same in the F-10/ branch so that your NVRs don't go backwards
between F9 and F10.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/67f2990c/attachment.sig>

From loganjerry at gmail.com  Sun Dec 21 23:39:02 2008
From: loganjerry at gmail.com (Jerry James)
Date: Sun, 21 Dec 2008 16:39:02 -0700
Subject: Automatic BuildRequires
In-Reply-To: <20081220082552.GA21475@amd.home.annexia.org>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
	<20081109204946.GA12715@auslistsprd01.us.dell.com>
	<20081109210146.GA16833@auslistsprd01.us.dell.com>
	<494A44DD.2050701@redhat.com>
	<870180fe0812191442j74ed15c3hffbabde35c967bf3@mail.gmail.com>
	<20081220082552.GA21475@amd.home.annexia.org>
Message-ID: <870180fe0812211539g62e2687cgebb69845f27b7996@mail.gmail.com>

On Sat, Dec 20, 2008 at 1:25 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> Possibly a bug, possibly because something in the configure script of
> the application touches a file in gstreamer-devel.  Take a look at:
>
> http://et.redhat.com/~rjones/auto-buildrequires/
>
> There'll be a fedorahosted project of this soon.
>
> 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

I would like to debug this.  That would be much easier if there was
some way to tell the script to not "rm $logfile" when it is done.
I'll cheat and edit the script for now, but please add an option to do
that.

Okay, cheating done.  The gstreamer-devel dependency is being pulled
in because /usr/lib/rpm/gstreamer.prov is being opened.  Since
rpmbuild itself does that, it appears that the script will tell you
that gstreamer-devel is a BuildRequires for every package, right?

This probably explains why the script is also telling me that both
perl and python are BuildRequires for my Java package.
-- 
Jerry James
http://loganjerry.googlepages.com/



From mschmidt at redhat.com  Sun Dec 21 23:39:21 2008
From: mschmidt at redhat.com (Michal Schmidt)
Date: Mon, 22 Dec 2008 00:39:21 +0100
Subject: performance test by Phoronix
In-Reply-To: <20081218131841.0726d6c0@brian.englab.brq.redhat.com>
References: <1229596333.3612.78.camel@eagle.danny.cz>
	<385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>
	<20081218131841.0726d6c0@brian.englab.brq.redhat.com>
Message-ID: <20081222003921.7170d3c5@hammerfall>

Dne Thu, 18 Dec 2008 13:18:41 +0100
Michal Schmidt <mschmidt at redhat.com> napsal:

> On Thu, 18 Dec 2008 13:51:27 +0200
> "Muayyad AlSadi" <alsadi at gmail.com> wrote:
> 
> > Hmmmmmmmm, faster processing slower IO......
> > what to consider
> > 1. SELinux
> > 2. some ext3 fs mount options
> > 3. having some daemon
> > ...etc.
> 
> 4. I wonder if they could have done some really stupid mistake, like
> having the distributions on different partitions on the disk. 
> 
> > BTW: I'm pleased by fedora performance,
> > I don't care about benchmarks
> 
> Well, benchmarks can point out real problems.
> 
> But I don't trust Phoronix. I guess I'll have to see if I can
> reproduce their results (not on the same hw, alas).

Last night I ran the IOzone benchmark on Fedora 10 and Ubuntu 8.10 to
see if I could reproduce a similarly big difference.

In short: there was no difference between Fedora and Ubuntu.

In detail:

My test machine is: Asus A8V Deluxe, Athlon 64 FX-53 (2,4 GHz), 2 GB
RAM, Seagate SATA 1TB ST31000340AS.

First I installed Fedora 10 into a 20 GB logical volume, ran the
benchmark, saved the results, then installed Ubuntu 8.10 into the same
logical volume (letting its installer mkfs it), and ran the benchmark.

I used x86_64 version of both distros, and I always installed a
base system without X11 and server daemons. In both cases I let the
installers use the current stable updates for their distros. Then I
installed the dependencies needed for the Phoronix test suite (php-cli,
gcc). I downloaded phoronix-test-suite-1.4.2, installed it, and used it
do fetch IOZone3_308 and install it.

I had a problem getting IOzone working on Ubuntu. P-T-S downloaded it
and built it, but it crashed on startup with "overflow detected". I
worked around it by copying the iozone binary from Fedora 10.

The benchmark was run always after booting to single user mode.
In all test runs the write performance was about 54 MB/s, never
differed by more than 0.3 MB/s.

Some random observations:
 - SELinux did not cause any significant slowdown in F10
   (I re-ran the test also with SELinux disabled.)
 - The mount options for the ext3 root fs as shown in /proc/mounts:
     - F10:    rw,errors=continue,user_xattr,acl,data=ordered
     - Ubuntu: rw,relatime,errors=remount-ro,data=ordered
 - When booted into the default runlevel, Fedora enabled ondemand CPU
   frequency scaling. Ubuntu did not.

Conclusion:
I still don't know what could have caused such a large difference
between Fedora and Ubuntu in Phoronix's results. It's not SELinux. The
mount options are different, but do not seem to influence IOzone results
either. Maybe Fedora has a problem only on the hardware they tested? Or
maybe they made a silly mistake.

Michal



From sandeen at redhat.com  Sun Dec 21 23:58:15 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sun, 21 Dec 2008 17:58:15 -0600
Subject: performance test by Phoronix
In-Reply-To: <20081218131841.0726d6c0@brian.englab.brq.redhat.com>
References: <1229596333.3612.78.camel@eagle.danny.cz>	<385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>
	<20081218131841.0726d6c0@brian.englab.brq.redhat.com>
Message-ID: <494ED817.50707@redhat.com>

Michal Schmidt wrote:

> But I don't trust Phoronix. I guess I'll have to see if I can
> reproduce their results (not on the same hw, alas).

Nor do I.  lame mp3 encoding for filesystem perf tests?  please.

and:

http://www.phoronix.com/data/img/results/ext4_benchmarks/1.png

is completely utterly wrong and busted.  There is no test in bonnie++
which does a "4GB random delete" by default - and ext3 cannot delete 210
4G files per second anyway, which would be obvious to anyone who's tried
deleting a single DVD iso on ext3, for example.

What they're actually reporting from bonnie++ is seeks per second on the
sequential input test (and I'd have to dig to see what that even means.)

So they've misunderstood what the delete test does (it deletes empty
files not 4G files by default), and reported a number that is impossible
to anyone who's tried, due to sloppy test output parsing.

I let them know about this - fairly politely even! - but they apparently
don't care to update the site.

But since it's on the internets it must be true, and this kind of crap
will be taken as the gospel truth for the next decade.  Sigh.

Anyway, I don't put much stock in phoronix test reports at this point.

-Eric



From martin.langhoff at gmail.com  Sun Dec 21 23:58:13 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Sun, 21 Dec 2008 21:58:13 -0200
Subject: [Fedora Update] [stable] fakeroot-1.11-19.fc8
In-Reply-To: <1229898973.3861.75.camel@localhost.localdomain>
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>
	<1229898973.3861.75.camel@localhost.localdomain>
Message-ID: <46a038f90812211558v559a3fcfpc3931b5c091b25a7@mail.gmail.com>

2008/12/21 Jesse Keating <jkeating at redhat.com>:
> Why is there a major version change (1.9.7 -> 1.11.19) going directly
> into stable on F8 (which has days to live) without any information for
> users what so ever that this update is providing.  Please provide some
> details for users and reconsider if this update is really suitable for
> F8.

I won't speak for Axel, and I'm not sure about F8 criteria - the pkgs
were put in updates-testing months ago. The old fakeroot has a nasty
race condition that leads to dataloss. The delta is a pileup of fixes,
no new features to speak of.

For some background, we had a good thread on this list - which I opened with

On Sun, Aug 3, 2008 at 7:35 AM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> Hi!
>
> Fedora 7, 8 and 9 are shipping a version of fakeroot that is affected
> by a somewhat nasty race condition.
>
> The bug was characterised here
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381016 , and with
> trivial repo steps here
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446351 . This bug was
> fixed in 1.8.2 - F7,8,9 ship 1.6.4.
>
> Hopefully, F9/F8 can get an updated version of the package included.
> Help and pointers welcome :-) If that's not possible, I will prepare a
> package for the school server and offer it here.

cheers,


m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From jkeating at redhat.com  Mon Dec 22 00:04:39 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 16:04:39 -0800
Subject: [Fedora Update] [stable] fakeroot-1.11-19.fc8
In-Reply-To: <46a038f90812211558v559a3fcfpc3931b5c091b25a7@mail.gmail.com>
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>
	<1229898973.3861.75.camel@localhost.localdomain>
	<46a038f90812211558v559a3fcfpc3931b5c091b25a7@mail.gmail.com>
Message-ID: <1229904279.3861.84.camel@localhost.localdomain>

On Sun, 2008-12-21 at 21:58 -0200, Martin Langhoff wrote:
> I won't speak for Axel, and I'm not sure about F8 criteria - the pkgs
> were put in updates-testing months ago. The old fakeroot has a nasty
> race condition that leads to dataloss. The delta is a pileup of fixes,
> no new features to speak of.

This would have all been good info to put in the update request.  What I
see is a update request to go straight to stable, bypassing
updates-testing all together, and no information for users about what
they're going to consume.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/b92758c7/attachment.sig>

From opensource at till.name  Mon Dec 22 00:46:23 2008
From: opensource at till.name (Till Maas)
Date: Mon, 22 Dec 2008 01:46:23 +0100
Subject: Can we make it so that Bodhi runs automatically?
In-Reply-To: <1229898664.3861.73.camel@localhost.localdomain>
References: <20081221194844.GA10113@amd.home.annexia.org>
	<1229898664.3861.73.camel@localhost.localdomain>
Message-ID: <200812220146.36851.opensource@till.name>

On Sunday 21 December 2008 23:31:04 Jesse Keating wrote:
> On Sun, 2008-12-21 at 19:48 +0000, Richard W.M. Jones wrote:
> > I know I should make a patch to do this, but ...
>
> make build update

Can this be done nowadays before the build suceeded?  
There is also still a patch available to get a "create update" link within 
koji:
https://fedorahosted.org/koji/ticket/87
It can probably be easy expanded to add this link to e-mails of sucessful 
builds, too.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/b2ee12ca/attachment.sig>

From jspaleta at gmail.com  Mon Dec 22 00:54:21 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 21 Dec 2008 15:54:21 -0900
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221174450.GB9876@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
Message-ID: <604aa7910812211654y4b452ce8y9dc8462bf595e870@mail.gmail.com>

On Sun, Dec 21, 2008 at 8:44 AM, Alan Cox <alan at redhat.com> wrote:
> On Sun, Dec 21, 2008 at 06:30:57PM +0100, Patrice Dumas wrote:
>> On Sun, Dec 21, 2008 at 12:14:38PM -0500, Alan Cox wrote:
>> >
>> > FESCo has no power to make it work or not work. The GPL gave people all the
>> > rights they need to create a long term Fedora variant.
>>
>> Of course, but doing it within fedora (even not officially) is
>> what FESCo can accept or reject.
>
> And why do you need to do it within Fedora - if the answer is "I can only do
> it by piggybacking on Fedora resources" then that sounds to me like you don't


You know what I find interesting, This particular idea wasn't in any
of the candidate statements for any of the people running for FESCo.
If this were really a problem with existing governance decision making
I would have expected to see a candidate running for FESCo mention
supporting this idea explicitly in their nomination wiki info. I don't
remember seeing that.

-jef



From emmanuel.seyman at club-internet.fr  Mon Dec 22 01:55:45 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 02:55:45 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494EA17F.6010708@gmail.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<494E942F.2000309@gmail.com>
	<20081221192640.GB21625@shell.devel.redhat.com>
	<494EA17F.6010708@gmail.com>
Message-ID: <20081222015545.GA604@orient.maison.lan>

* Les Mikesell [21/12/2008 22:03] :
>
>                                                          One is to plan  
> a smooth transition into the next Centos via yum update to end up with a  
> real long term supported system without duplicating any work on  
> backported updates.

This, to me, not only conveys the intent : "I'm going to drain Fedora
ressources away from Fedora's mission" but also the intent "I'm going to
use thoses ressources to promote another distribution".

Emmanuel



From philipp_subx at redfish-solutions.com  Mon Dec 22 02:07:44 2008
From: philipp_subx at redfish-solutions.com (Philip A. Prindeville)
Date: Sun, 21 Dec 2008 18:07:44 -0800
Subject: FC9, "missing syscalls" kernel target, and Promise Fasttrak TX4650
 controller
Message-ID: <494EF670.9040400@redfish-solutions.com>

I was going to build an RPM for the modules for the Promise FastTrak 
TX4650 PCI-e RAID controller for FC9.

Their support website claims it's supported "in-box" in FC9, but it 
turns out that's not true:

$ lspci -v -s 02:00.0
02:00.0 RAID bus controller: Promise Technology, Inc. Unknown device 3f20
	Subsystem: Promise Technology, Inc. Unknown device 3f22
	Flags: bus master, fast devsel, latency 0, IRQ 10
	I/O ports at dc00 [size=128]
	I/O ports at d800 [size=256]
	Memory at fbeff000 (32-bit, non-prefetchable) [size=4K]
	Memory at fbec0000 (32-bit, non-prefetchable) [size=128K]
	Memory at fbefc000 (32-bit, non-prefetchable) [size=8K]
	Expansion ROM at fbe80000 [disabled] [size=256K]
	Capabilities: [50] Power Management version 2
	Capabilities: [70] Express Legacy Endpoint, MSI 00
	Capabilities: [94] SATA HBA <?>
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Virtual Channel <?>
	Capabilities: [160] Device Serial Number 01-00-00-00-02-00-00-00
	Capabilities: [170] Power Budgeting <?>


so...  I downloaded their drivers from their website:

http://www.promise.com/upload/Support/Driver/FT%20TX4650-2650%20Linux%20Kernl%202.6%20PSC%20v1.1.0.12.tgz

(Yes, I realize it will taint my kernel... and it doesn't include all of the source.)

I tried to build it, but getting into the kernel directory:

[root at builder 2.6.27.7-53.fc9.x86_64]# pwd
/usr/src/kernels/2.6.27.7-53.fc9.x86_64
[root at builder 2.6.27.7-53.fc9.x86_64]# make oldconfig
scripts/kconfig/conf -o arch/x86/Kconfig
#
# configuration written to .config
#
[root at builder 2.6.27.7-53.fc9.x86_64]# make prepare
scripts/kconfig/conf -s arch/x86/Kconfig
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
make[1]: *** No rule to make target `missing-syscalls'.  Stop.
make: *** [prepare0] Error 2
[root at builder 2.6.27.7-53.fc9.x86_64]# 



I noticed that there was a chunk missing from upstream...

Is this a known issue? Reading various archives, it seems to go back to 
at least 2.6.23... What's the workaround?

And has anyone else gotten this compiler to build/run on their system?

I'm trying to set up an automated build factory to do about 200 nightly 
package builds...

Thanks,

-Philip



From jamundso at gmail.com  Mon Dec 22 02:52:25 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 21 Dec 2008 20:52:25 -0600
Subject: FC9, "missing syscalls" kernel target,
	and Promise Fasttrak TX4650 controller
In-Reply-To: <494EF670.9040400@redfish-solutions.com>
References: <494EF670.9040400@redfish-solutions.com>
Message-ID: <6d06ce20812211852t12694524v6e0a3b4379ca373f@mail.gmail.com>

On 12/21/08, Philip A. Prindeville <philipp_subx at redfish-solutions.com> wrote:
> I was going to build an RPM for the modules for the Promise FastTrak
> TX4650 PCI-e RAID controller for FC9.
>
> Their support website claims it's supported "in-box" in FC9, but it
> turns out that's not true:
>
> $ lspci -v -s 02:00.0
> 02:00.0 RAID bus controller: Promise Technology, Inc. Unknown device 3f20
> 	Subsystem: Promise Technology, Inc. Unknown device 3f22
> 	Flags: bus master, fast devsel, latency 0, IRQ 10
> 	I/O ports at dc00 [size=128]
> 	I/O ports at d800 [size=256]
> 	Memory at fbeff000 (32-bit, non-prefetchable) [size=4K]
> 	Memory at fbec0000 (32-bit, non-prefetchable) [size=128K]
> 	Memory at fbefc000 (32-bit, non-prefetchable) [size=8K]
> 	Expansion ROM at fbe80000 [disabled] [size=256K]
> 	Capabilities: [50] Power Management version 2
> 	Capabilities: [70] Express Legacy Endpoint, MSI 00
> 	Capabilities: [94] SATA HBA <?>
> 	Capabilities: [100] Advanced Error Reporting <?>
> 	Capabilities: [140] Virtual Channel <?>
> 	Capabilities: [160] Device Serial Number 01-00-00-00-02-00-00-00
> 	Capabilities: [170] Power Budgeting <?>
>
>
> so...  I downloaded their drivers from their website:
>
> http://www.promise.com/upload/Support/Driver/FT%20TX4650-2650%20Linux%20Kernl%202.6%20PSC%20v1.1.0.12.tgz
>
> (Yes, I realize it will taint my kernel... and it doesn't include all of the
> source.)
>
> I tried to build it, but getting into the kernel directory:

Don't start there. Start with the README of the source you downloaded.

jerry

-- 
To be named later.



From jamundso at gmail.com  Mon Dec 22 03:24:40 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 21 Dec 2008 21:24:40 -0600
Subject: FC9, "missing syscalls" kernel target,
	and Promise Fasttrak TX4650 controller
In-Reply-To: <6d06ce20812211852t12694524v6e0a3b4379ca373f@mail.gmail.com>
References: <494EF670.9040400@redfish-solutions.com>
	<6d06ce20812211852t12694524v6e0a3b4379ca373f@mail.gmail.com>
Message-ID: <6d06ce20812211924x69094475ue8bb37446c37a107@mail.gmail.com>

On 12/21/08, Jerry Amundson <jamundso at gmail.com> wrote:
> On 12/21/08, Philip A. Prindeville <philipp_subx at redfish-solutions.com>
> wrote:
>> I was going to build an RPM for the modules for the Promise FastTrak
>> TX4650 PCI-e RAID controller for FC9.
>>
>> Their support website claims it's supported "in-box" in FC9, but it
>> turns out that's not true:
>>
>> $ lspci -v -s 02:00.0
>> 02:00.0 RAID bus controller: Promise Technology, Inc. Unknown device 3f20
>> 	Subsystem: Promise Technology, Inc. Unknown device 3f22
>> 	Flags: bus master, fast devsel, latency 0, IRQ 10
>> 	I/O ports at dc00 [size=128]
>> 	I/O ports at d800 [size=256]
>> 	Memory at fbeff000 (32-bit, non-prefetchable) [size=4K]
>> 	Memory at fbec0000 (32-bit, non-prefetchable) [size=128K]
>> 	Memory at fbefc000 (32-bit, non-prefetchable) [size=8K]
>> 	Expansion ROM at fbe80000 [disabled] [size=256K]
>> 	Capabilities: [50] Power Management version 2
>> 	Capabilities: [70] Express Legacy Endpoint, MSI 00
>> 	Capabilities: [94] SATA HBA <?>
>> 	Capabilities: [100] Advanced Error Reporting <?>
>> 	Capabilities: [140] Virtual Channel <?>
>> 	Capabilities: [160] Device Serial Number 01-00-00-00-02-00-00-00
>> 	Capabilities: [170] Power Budgeting <?>
>>
>>
>> so...  I downloaded their drivers from their website:
>>
>> http://www.promise.com/upload/Support/Driver/FT%20TX4650-2650%20Linux%20Kernl%202.6%20PSC%20v1.1.0.12.tgz
>>
>> (Yes, I realize it will taint my kernel... and it doesn't include all of
>> the
>> source.)
>>
>> I tried to build it, but getting into the kernel directory:
>
> Don't start there. Start with the README of the source you downloaded.

And it looks like you'll some code fixing to get it to compile...
http://www.colinmackenzie.net/index.php?option=com_content&view=article&id=12:promise-satasas-driver-update-tx4650tx2650&catid=8:rotator&Itemid=7

jerry

-- 
To be named later.



From tmz at pobox.com  Mon Dec 22 03:25:35 2008
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 21 Dec 2008 22:25:35 -0500
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
Message-ID: <20081222032535.GJ12325@inocybe.teonanacatl.org>

Jerry Amundson wrote:
> I got to the point of
> http://fedoraproject.org/wiki/PackageMaintainers/Join where "You'll
> also need two more certs:" is followed by blank space.

I just fixed this on the wiki.  That text was just some leftover cruft
I believe.  Running fedora-packager-setup downloads the certs to which
that referred.

> Going back to the beginning of the fun, the ever so tempting Join
> Fedora. link from fp.o does not even mention Package Maintainers or
> Bug Zappers, yet has pretty pics/links of seemingly every other
> role.

Both Bug triage and Packaging are listed under OS Developer.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If I was the King Adrock I'd get stupid dumb,
and if rhymes were Valiums I'd be comfortably numb.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/0a73a1ca/attachment.sig>

From lesmikesell at gmail.com  Mon Dec 22 03:39:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 21 Dec 2008 21:39:51 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222015545.GA604@orient.maison.lan>
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>
	<20081222015545.GA604@orient.maison.lan>
Message-ID: <494F0C07.1020707@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [21/12/2008 22:03] :
>>                                                          One is to plan  
>> a smooth transition into the next Centos via yum update to end up with a  
>> real long term supported system without duplicating any work on  
>> backported updates.
> 
> This, to me, not only conveys the intent : "I'm going to drain Fedora
> ressources away from Fedora's mission" but also the intent "I'm going to
> use thoses ressources to promote another distribution".
> 

Better said as "any reduction in the fragmentation into incompatible 
flavors is a win for everyone involved with unix-like operating 
systems".  Or, "any effort to separately maintain fragmented 
distributions is a wasted effort".

-- 
   Les Mikesell
    lesmikesell at gmail.com




From jamundso at gmail.com  Mon Dec 22 03:55:26 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 21 Dec 2008 21:55:26 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <20081222032535.GJ12325@inocybe.teonanacatl.org>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
Message-ID: <6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>

On 12/21/08, Todd Zullinger <tmz at pobox.com> wrote:
> Jerry Amundson wrote:
>> I got to the point of
>> http://fedoraproject.org/wiki/PackageMaintainers/Join where "You'll
>> also need two more certs:" is followed by blank space.
>
> I just fixed this on the wiki.  That text was just some leftover cruft
> I believe.  Running fedora-packager-setup downloads the certs to which
> that referred.

Looks good. Thank you!

>> Going back to the beginning of the fun, the ever so tempting Join
>> Fedora. link from fp.o does not even mention Package Maintainers or
>> Bug Zappers, yet has pretty pics/links of seemingly every other
>> role.
>
> Both Bug triage and Packaging are listed under OS Developer.

That's my point. With my background, OS stands for Operating System,
and I wouldn't consider for one second looking there to help with, say
"xeyes". (or anything else that is not kernel*, or is not in @core for
that matter...)
http://en.wikipedia.org/wiki/Operating_system

jerry

-- 
To be named later.



From jspaleta at gmail.com  Mon Dec 22 04:02:51 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 21 Dec 2008 19:02:51 -0900
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
Message-ID: <604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>

On Sun, Dec 21, 2008 at 6:55 PM, Jerry Amundson <jamundso at gmail.com> wrote:
> That's my point. With my background, OS stands for Operating System,
> and I wouldn't consider for one second looking there to help with, say
> "xeyes". (or anything else that is not kernel*, or is not in @core for
> that matter...)
> http://en.wikipedia.org/wiki/Operating_system


So what title would you use for the role in place of OS Developer? Is
there a better succinct definition that would be appealing to you that
encompasses the same skills,groups and tasks as listed here
http://fedoraproject.org/wiki/Join#OSDeveloper  ?


-jef



From mw_triad at users.sourceforge.net  Mon Dec 22 04:08:50 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Sun, 21 Dec 2008 22:08:50 -0600
Subject: rawhide report: 20081220 changes
In-Reply-To: <a9d183c80812210728r3856cadbx27d7e1c6a86a544b@mail.gmail.com>
References: <20081220104521.0499B1F8246@releng2.fedora.phx.redhat.com>	<1229770470.5584.1.camel@hughsie-work.lan>	<1229778828.14462.2.camel@arekh.okg>	<1229787602.4136.6.camel@hughsie-work.lan>	<1229788642.16655.12.camel@arekh.okg>	<20081220180913.45f62880@lain.camperquake.de>	<1229801171.24251.19.camel@arekh.okg>	<1229854269.3382.5.camel@hughsie-work.lan>	<494E18BB.8050005@gmail.com>	<1229869750.3209.6836.camel@beck.corsepiu.local>
	<a9d183c80812210728r3856cadbx27d7e1c6a86a544b@mail.gmail.com>
Message-ID: <gin3sj$ggm$1@ger.gmane.org>

Thomas Moschny wrote:
> Not that I'm not sympathizing in principle with people using the full
> unicode character set for their communications ?

That, however, looks hideous in a fixed-width font ;-). (You /do/ use 
fixed-width to view e-mail, right? ;-) )

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet



From jamundso at gmail.com  Mon Dec 22 04:14:52 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Sun, 21 Dec 2008 22:14:52 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
Message-ID: <6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>

On 12/21/08, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Sun, Dec 21, 2008 at 6:55 PM, Jerry Amundson <jamundso at gmail.com> wrote:
>> That's my point. With my background, OS stands for Operating System,
>> and I wouldn't consider for one second looking there to help with, say
>> "xeyes". (or anything else that is not kernel*, or is not in @core for
>> that matter...)
>> http://en.wikipedia.org/wiki/Operating_system
>
> So what title would you use for the role in place of OS Developer? Is
> there a better succinct definition that would be appealing to you that
> encompasses the same skills,groups and tasks as listed here
> http://fedoraproject.org/wiki/Join#OSDeveloper  ?

Never mind. It's perfect. Don't change a thing.

jerry

-- 
To be named later.



From jkeating at redhat.com  Mon Dec 22 04:34:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 20:34:13 -0800
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
Message-ID: <1229920453.3861.89.camel@localhost.localdomain>

On Sun, 2008-12-21 at 22:14 -0600, Jerry Amundson wrote:
> >
> > So what title would you use for the role in place of OS Developer? Is
> > there a better succinct definition that would be appealing to you that
> > encompasses the same skills,groups and tasks as listed here
> > http://fedoraproject.org/wiki/Join#OSDeveloper  ?
> 
> Never mind. It's perfect. Don't change a thing.

Please don't take that attitude.  Many of us are way too close to the
forest to see the trees, in fact we're in the forest.  We need the
opinions of those of you coming down the trail of how to describe this
part of the forest.  I don't believe Jef was trying to be condescending
or trying to brush you off, he was honestly asking your opinion for how
we should describe this, because if we're missing you, we're likely
missing other people too.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/2147229d/attachment.sig>

From jspaleta at gmail.com  Mon Dec 22 04:35:33 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 21 Dec 2008 19:35:33 -0900
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
Message-ID: <604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>

On Sun, Dec 21, 2008 at 7:14 PM, Jerry Amundson <jamundso at gmail.com> wrote:
> Never mind. It's perfect. Don't change a thing.

No I won't let you off the hook that easily.  There's no need to be
sarcastic.  It was a genuine question.  The existing titles for the
roles are a best effort.  If you have a suggestions that you feel is
more appealing, then please tell us. We aren't mind readers. At least
not until we all have the Google neural implant installed.  If I ruled
the world, I'd of called that role 'Code Monkey', but its way to
flippant a definition so I wouldn't seriously expect that to be
generally preferred over the existing 'OS Developer' title.

The goal of the Role definitions isn't to list every individual task
or subgroup. The idea is to draw rough circles around common
tasks,groups and skillsets. These circles overlap. You'll notice that
some groups appear under different roles.

All I am asking is to provide us with some more specific feedback on
how to rename the role that is currently titled OS Developer.  Its not
enough to know that your confused by the current title. We need to
know what would make sense to you as an alternative.

-jef



From jspaleta at gmail.com  Mon Dec 22 04:49:59 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 21 Dec 2008 19:49:59 -0900
Subject: performance test by Phoronix
In-Reply-To: <494ED817.50707@redhat.com>
References: <1229596333.3612.78.camel@eagle.danny.cz>
	<385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>
	<20081218131841.0726d6c0@brian.englab.brq.redhat.com>
	<494ED817.50707@redhat.com>
Message-ID: <604aa7910812212049o620cfc4en7b5fe34ba72975fd@mail.gmail.com>

On Sun, Dec 21, 2008 at 2:58 PM, Eric Sandeen <sandeen at redhat.com> wrote:
> But since it's on the internets it must be true, and this kind of crap
> will be taken as the gospel truth for the next decade.  Sigh.
>
> Anyway, I don't put much stock in phoronix test reports at this point.


We may not be able to do anything about this benchmark. But in general
I think its good to be public about methodology.  I think its
perfectly appropriate for someone to write up an independent effort to
verify phoronix results, showing what is different, what they did
wrong, and drawing some conclusions about pitfalls to avoid in
general.  No single benchmarks from a single source should ever be
trusted.

Getting an established set of best practices for benchmarking efforts
out there for the laypress to follow..and consistently banging the
drum to encourage the laypress to use those best practices will help
everyone in the long run.


-jef



From alsadi at gmail.com  Mon Dec 22 04:57:57 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 22 Dec 2008 06:57:57 +0200
Subject: performance test by Phoronix
In-Reply-To: <604aa7910812212049o620cfc4en7b5fe34ba72975fd@mail.gmail.com>
References: <1229596333.3612.78.camel@eagle.danny.cz>
	<385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>
	<20081218131841.0726d6c0@brian.englab.brq.redhat.com>
	<494ED817.50707@redhat.com>
	<604aa7910812212049o620cfc4en7b5fe34ba72975fd@mail.gmail.com>
Message-ID: <385866f0812212057u133ce498k4a3273926de033@mail.gmail.com>

good, so it's not SELinux

I guess it's not LVM because I guess the default in F10 is not use LVM



From jkeating at redhat.com  Mon Dec 22 05:06:26 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Dec 2008 21:06:26 -0800
Subject: performance test by Phoronix
In-Reply-To: <385866f0812212057u133ce498k4a3273926de033@mail.gmail.com>
References: <1229596333.3612.78.camel@eagle.danny.cz>
	<385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>
	<20081218131841.0726d6c0@brian.englab.brq.redhat.com>
	<494ED817.50707@redhat.com>
	<604aa7910812212049o620cfc4en7b5fe34ba72975fd@mail.gmail.com>
	<385866f0812212057u133ce498k4a3273926de033@mail.gmail.com>
Message-ID: <1229922386.3861.90.camel@localhost.localdomain>

On Mon, 2008-12-22 at 06:57 +0200, Muayyad AlSadi wrote:
> I guess it's not LVM because I guess the default in F10 is not use LVM

Incorrect.  LVM is still the default layout.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/ab503993/attachment.sig>

From sandeen at redhat.com  Mon Dec 22 05:20:03 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sun, 21 Dec 2008 23:20:03 -0600
Subject: performance test by Phoronix
In-Reply-To: <385866f0812212057u133ce498k4a3273926de033@mail.gmail.com>
References: <1229596333.3612.78.camel@eagle.danny.cz>	<385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>	<20081218131841.0726d6c0@brian.englab.brq.redhat.com>	<494ED817.50707@redhat.com>	<604aa7910812212049o620cfc4en7b5fe34ba72975fd@mail.gmail.com>
	<385866f0812212057u133ce498k4a3273926de033@mail.gmail.com>
Message-ID: <494F2383.3040303@redhat.com>

Muayyad AlSadi wrote:
> good, so it's not SELinux
> 
> I guess it's not LVM because I guess the default in F10 is not use LVM

Perhaps they tested over dm-crypt.  Hard to know, though; they don't say
how they installed (or even on which filesystem they tested, though we
can guess ext3 pretty safely.)

-Eric



From debarshi.ray at gmail.com  Mon Dec 22 07:29:07 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 22 Dec 2008 12:59:07 +0530
Subject: Remote access to a Fedora 10 machine
Message-ID: <3170f42f0812212329j33bb2be2l7bb3e66d14833156@mail.gmail.com>

Is there any way I could get access to a Fedora 10 (preferably 64-bit)
system for running the odd Mock build and some testing of
Review-O-Matic's [1] Mock related code? Preferred username would be
'rishi' and I can send you my SSH public key if needed.

Thanks,
Debarshi
----
[1] http://fedorahosted.org/review-o-matic/



From hedayat at grad.com  Mon Dec 22 08:39:31 2008
From: hedayat at grad.com (Hedayat Vatankhah)
Date: Mon, 22 Dec 2008 12:09:31 +0330
Subject: [Fedora Update] [stable] fakeroot-1.11-19.fc8
In-Reply-To: <1229904279.3861.84.camel@localhost.localdomain>
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>	<1229898973.3861.75.camel@localhost.localdomain>	<46a038f90812211558v559a3fcfpc3931b5c091b25a7@mail.gmail.com>
	<1229904279.3861.84.camel@localhost.localdomain>
Message-ID: <494F5243.5050602@grad.com>


/*Jesse Keating <jkeating at redhat.com>*/ wrote on ??/??/?? 03:34:39:
> On Sun, 2008-12-21 at 21:58 -0200, Martin Langhoff wrote:
>   
>> I won't speak for Axel, and I'm not sure about F8 criteria - the pkgs
>> were put in updates-testing months ago. The old fakeroot has a nasty
>> race condition that leads to dataloss. The delta is a pileup of fixes,
>> no new features to speak of.
>>     
>
> This would have all been good info to put in the update request.  What I
> see is a update request to go straight to stable, bypassing
> updates-testing all together, and no information for users about what
> they're going to consume.
>   
Currently, the Notes section in New Update page of Bodhi has this 
comment: "Some
optional details about this update that will appear in the notice". And 
there is nothing
about this section of Bodhi in the UpdatingPackageHowTo.
Personally, what I get is that it is good to put some useful info in the 
Notes: section, but
if you don't put anything, it is still OK.
But recently I found that this section is a little more important. I 
think there should be
a little more info about it, and some examples of when these comments 
are useful.


Good luck,
Hedayat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/44910403/attachment.htm>

From pertusus at free.fr  Mon Dec 22 09:05:42 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Dec 2008 10:05:42 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <604aa7910812211654y4b452ce8y9dc8462bf595e870@mail.gmail.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<604aa7910812211654y4b452ce8y9dc8462bf595e870@mail.gmail.com>
Message-ID: <20081222090542.GA2470@free.fr>

On Sun, Dec 21, 2008 at 03:54:21PM -0900, Jeff Spaleta wrote:
> >>
> >> Of course, but doing it within fedora (even not officially) is
> >> what FESCo can accept or reject.
> >
> > And why do you need to do it within Fedora - if the answer is "I can only do
> > it by piggybacking on Fedora resources" then that sounds to me like you don't
> 
> 
> You know what I find interesting, This particular idea wasn't in any
> of the candidate statements for any of the people running for FESCo.
> If this were really a problem with existing governance decision making
> I would have expected to see a candidate running for FESCo mention
> supporting this idea explicitly in their nomination wiki info. I don't
> remember seeing that.

I don't know exactly who you are answering to, but as far as I can 
tell nobody said that there were 'a problem with existing governance 
decision making'. The keep infra open stuff was lead by me and Kevin 
Kofler, Ralf, and Oron was also supportive, but none of these people 
ran for FESCo.

And you could also interpret it the other way (I am not saying that
it is my interpretation): there is a governance problem because nobody
supporting this idea explicitly ran for FESCo.

--
Pat



From emmanuel.seyman at club-internet.fr  Mon Dec 22 09:23:08 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 10:23:08 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494F0C07.1020707@gmail.com>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<494E942F.2000309@gmail.com>
	<20081221192640.GB21625@shell.devel.redhat.com>
	<494EA17F.6010708@gmail.com>
	<20081222015545.GA604@orient.maison.lan>
	<494F0C07.1020707@gmail.com>
Message-ID: <20081222092308.GA24499@orient.maison.lan>

* Les Mikesell [22/12/2008 09:52] :
>
> Better said as "any reduction in the fragmentation into incompatible  
> flavors is a win for everyone involved with unix-like operating  
> systems".  Or, "any effort to separately maintain fragmented  
> distributions is a wasted effort".

The cure for fragmentation is to keep as close to upstream as possible
and encourage other distributions to do the same. I fail to see how
planning "a smooth transition into the next Centos" has anything to do
with it.

Emmanuel



From kevin.kofler at chello.at  Mon Dec 22 09:55:57 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 10:55:57 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
Message-ID: <gino7d$o2f$1@ger.gmane.org>

Alan Cox wrote:
> Your infrastructure estimates are pretty ridiculous. If it takes you more
> than a week to kick start a basic build environment for doing security
> updates and you can't find a linux related site to host your stuff
> initially you are doing something wrong or don't have enough interested
> skilled people.

The time estimate is based on the time it took to get RPM Fusion up and
running.

        Kevin Kofler



From emmanuel.seyman at club-internet.fr  Mon Dec 22 10:02:07 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 11:02:07 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gino7d$o2f$1@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
Message-ID: <20081222100207.GA26945@orient.maison.lan>

* Kevin Kofler [22/12/2008 10:58] :
>
> The time estimate is based on the time it took to get RPM Fusion up and
> running.

RPM Fusion decided to duplicate the Fedora infrastructure. This goes
far above and beyond what you need to create a third-party repo.

Emmanuel



From rjones at redhat.com  Mon Dec 22 10:00:50 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 22 Dec 2008 10:00:50 +0000
Subject: Automatic BuildRequires
In-Reply-To: <870180fe0812211539g62e2687cgebb69845f27b7996@mail.gmail.com>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
	<20081109204946.GA12715@auslistsprd01.us.dell.com>
	<20081109210146.GA16833@auslistsprd01.us.dell.com>
	<494A44DD.2050701@redhat.com>
	<870180fe0812191442j74ed15c3hffbabde35c967bf3@mail.gmail.com>
	<20081220082552.GA21475@amd.home.annexia.org>
	<870180fe0812211539g62e2687cgebb69845f27b7996@mail.gmail.com>
Message-ID: <20081222100050.GA12869@amd.home.annexia.org>

On Sun, Dec 21, 2008 at 04:39:02PM -0700, Jerry James wrote:
> I would like to debug this.  That would be much easier if there was
> some way to tell the script to not "rm $logfile" when it is done.
> I'll cheat and edit the script for now, but please add an option to do
> that.

Yup, that would be a useful option.

> Okay, cheating done.  The gstreamer-devel dependency is being pulled
> in because /usr/lib/rpm/gstreamer.prov is being opened.  Since
> rpmbuild itself does that, it appears that the script will tell you
> that gstreamer-devel is a BuildRequires for every package, right?
> 
> This probably explains why the script is also telling me that both
> perl and python are BuildRequires for my Java package.

.. and Fortran too.  Most configure scripts look for it, but it's not
really used that often.

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  Mon Dec 22 10:04:19 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 11:04:19 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221200505.GB10113@amd.home.annexia.org>
Message-ID: <ginon3$sir$1@ger.gmane.org>

Richard W.M. Jones wrote:
> Alan's quite right.  I am hosting the MinGW RPMs temporarily on my own
> site (something like 700-800 MBs worth):
> 
> http://www.annexia.org/tmp/mingw/fedora-10/

But a single OO.o update alone is as large as all of your repo.

> But I spend under $30 / month on this server, and there is no
> noticable load from the 565 people[1] synching their development
> machines to it.

And there would be a lot more than 565 people updating their old Fedora
releases.

The infrastructure requirements for such a project would be several orders
of magnitude higher than those for your MinGW repo or my CalcForge repo.
There's no way a $30/month server would be able to provide the required
bandwidth, maybe not even the required storage (but the bandwidth is
proportional to size * download count, both of which are several orders of
magnitude higher than for a small repository, so I expect the bandwidth to
be the bigger issue, as it multiplies up, whereas the storage space is only
dependent on the size of the packages).

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec 22 10:10:17 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 11:10:17 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>
	<20081221192640.GB21625@shell.devel.redhat.com>
	<494EA17F.6010708@gmail.com>
Message-ID: <ginp29$sir$2@ger.gmane.org>

Les Mikesell wrote:
> backported updates.  Another which isn't really a long-term approach but
> could produce usably-stable versions that overlapped a bit would be to
> stop introducing new features in updates in one release by or before the
> beta of the next release and focus only on stability from that point to
> end of life.  Even if EOL is not extended you'd have a version that you
> could run until the next version reached that point - and people who
> want new features can jump to the next release instead.

No, we can't jump to the next release if it's only in beta. Just because we
want new features doesn't mean we want a beta distro! The earliest
a "stabilization" like that would be acceptable would be 1 month (time to
upgrade) after the next release is out.

And I don't see how the current system is not "usably-stable". Fedora just
works.

        Kevin Kofler



From rjones at redhat.com  Mon Dec 22 10:11:33 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 22 Dec 2008 10:11:33 +0000
Subject: Encrypted home directory
In-Reply-To: <20081221214630.669fbad3@lain.camperquake.de>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
Message-ID: <20081222101133.GB12869@amd.home.annexia.org>

On Sun, Dec 21, 2008 at 09:46:30PM +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Sun, 21 Dec 2008 20:15:23 +0000, Richard W.M. Jones wrote
> 
> > The other reason to _not_ encrypt the system directories is so that
> > system files can be easily mmapped into memory.
> 
> How would encrypting the system directories prevent you from doing that?

Yes, I'm wrong about this.  I thought the ESSIV scheme used made it so
that you couldn't just decrypt an arbitrary block (without decrypting
previous blocks), but that's not actually the case.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From rjones at redhat.com  Mon Dec 22 10:12:05 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 22 Dec 2008 10:12:05 +0000
Subject: Can we make it so that Bodhi runs automatically?
In-Reply-To: <d25f375f0812211222h1f6e5d7ew3ee3fb0d53b6df34@mail.gmail.com>
References: <20081221194844.GA10113@amd.home.annexia.org>
	<d25f375f0812211222h1f6e5d7ew3ee3fb0d53b6df34@mail.gmail.com>
Message-ID: <20081222101205.GC12869@amd.home.annexia.org>

On Sun, Dec 21, 2008 at 10:22:44PM +0200, Pavel Shevchuk wrote:
> Because it won't allow to update highly modular packages properly.
> Imaging gedit update being pushed before updated gnome-libs are built

I don't understand what this means - can you explain more?

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From kevin.kofler at chello.at  Mon Dec 22 10:12:58 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 11:12:58 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222100207.GA26945@orient.maison.lan>
Message-ID: <ginp7a$sir$3@ger.gmane.org>

Emmanuel Seyman wrote:
> RPM Fusion decided to duplicate the Fedora infrastructure. This goes
> far above and beyond what you need to create a third-party repo.

Providing updates for all of Fedora actually requires MORE infrastructure
than RPM Fusion. Just do the math.

        Kevin Kofler



From sundaram at fedoraproject.org  Mon Dec 22 10:20:47 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 22 Dec 2008 15:50:47 +0530
Subject: [Fwd: Broken dependencies: livecd-tools]
Message-ID: <494F69FF.3020105@fedoraproject.org>

Hi,

If I only involved in the EPEL branch, I don't want to be notified when 
the Fedora branch is broken. Does the script take branches into 
consideration?

Rahul
-------------- next part --------------
An embedded message was scrubbed...
From: buildsys at fedoraproject.org
Subject: Broken dependencies: livecd-tools
Date: Mon, 22 Dec 2008 10:16:18 +0000 (UTC)
Size: 2679
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/cb120d64/attachment.eml>

From emmanuel.seyman at club-internet.fr  Mon Dec 22 10:23:26 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 11:23:26 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <ginp7a$sir$3@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222100207.GA26945@orient.maison.lan>
	<ginp7a$sir$3@ger.gmane.org>
Message-ID: <20081222102326.GA28258@orient.maison.lan>

* Kevin Kofler [22/12/2008 11:18] :
>
> Providing updates for all of Fedora actually requires MORE infrastructure
> than RPM Fusion. Just do the math.

You're doing this backwards.
Build the community first then worry about the infrastructure.

Emmanuel



From rjones at redhat.com  Mon Dec 22 10:25:02 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 22 Dec 2008 10:25:02 +0000
Subject: Can we make it so that Bodhi runs automatically?
In-Reply-To: <1229898664.3861.73.camel@localhost.localdomain>
References: <20081221194844.GA10113@amd.home.annexia.org>
	<1229898664.3861.73.camel@localhost.localdomain>
Message-ID: <20081222102502.GD12869@amd.home.annexia.org>

On Sun, Dec 21, 2008 at 02:31:04PM -0800, Jesse Keating wrote:
> On Sun, 2008-12-21 at 19:48 +0000, Richard W.M. Jones wrote:
> > I know I should make a patch to do this, but ...
> 
> make build update 

Useful!  I didn't know about this.

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 arjan at infradead.org  Mon Dec 22 10:50:47 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Mon, 22 Dec 2008 11:50:47 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <200812181847.35253.ville.skytta@iki.fi>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172152.30869.ville.skytta@iki.fi>
	<20081218094440.3c13a7f3@infradead.org>
	<200812181847.35253.ville.skytta@iki.fi>
Message-ID: <20081222115047.0acb4cb6@infradead.org>

On Thu, 18 Dec 2008 18:47:34 +0200
Ville Skytt? <ville.skytta at iki.fi> wrote:

> On Thursday 18 December 2008, Arjan van de Ven wrote:
> > On Wed, 17 Dec 2008 21:52:30 +0200
> > Ville Skytt? <ville.skytta at iki.fi> wrote:
> 
> > > - shutdown: 28 sec
> > > - fresh boot: 66 sec
> >
> > see this is the problem; this can be 5 to 10 seconds, and should be.
> > that's the point of this discussion
> 
> Well, you said earlier:
> 
> > > > I suspect you will always be able to boot faster than you can
> > > > hibernate+resume.
> 
> Maybe I'm just having a problem parsing that.  Does "will" here mean
> that it will be like that in the future after $something gets done?

yeah assuming you optimize both. Right now neither are well optimized;
the boot part is known how to do ;)



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From rawhide at fedoraproject.org  Mon Dec 22 10:51:33 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 22 Dec 2008 10:51:33 +0000 (UTC)
Subject: rawhide report: 20081222 changes
Message-ID: <20081222105133.DB0D71F8257@releng2.fedora.phx.redhat.com>

Compose started at Mon Dec 22 06:01:07 UTC 2008

New package Judy
        General purpose dynamic array
New package NetworkManager-openconnect
        NetworkManager VPN integration for openconnect
New package gnubversion
        Gnome Interface to Subversion
New package hydrogen-drumkits
        Additional DrumKits for Hydrogen
New package hyphen-bg
        Bulgarian hyphenation rules
New package libicns
        Library for manipulating Macintosh icns files
New package metapost-metauml
        UML in LaTeX/MetaPost
New package mingw32-bzip2
        MinGW port of bzip2 file compression utility
New package mingw32-iconv
        GNU libraries and utilities for character set conversion
New package mingw32-termcap
        MinGW terminal feature database
New package mingw32-zlib
        MinGW Windows zlib compression library
New package pen
        Load balancer for "simple" tcp based protocols such as http or smtp
New package perl-Catalyst-Plugin-Authorization-Roles
        Role based authorization for Catalyst based on Catalyst::Plugin::Authentication
New package qedje
        A library combining the benefits of Edje and Qt
New package qzion
        A canvas abstraction
New package refmac-dictionary
        Refmac ligand dictionaries
New package tcl-tclxml
        XML parsing library for the Tcl scripting language
Updated Packages:

abyssinica-fonts-1.0-3.fc11
---------------------------
* Sun Dec 21 17:00:00 2008 Bernie Innocenti <bernie at codewiz.org> 1.0-3
- Updated to current Fedora font packaging guidelines


atlas-3.8.2-5.fc11
------------------
* Sun Dec 21 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.8.2-5
- Link in appropriate libs when creating shared libs, reported by Orcan 'oget' Ogetbil (BZ#475411)


conduit-0.3.15-4.fc11
---------------------
* Sun Dec 21 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.3.15-4
- Change buildreqs from pygoocanvas to pygoocanvas-devel


dejavu-fonts-2.28-1.fc11
------------------------
* Sun Dec 21 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 2.28-1
??? Update to latest release
??? Drop upstreamed fontconfig patch
??? Remove DejaVu from most summaries


ember-media-0.5.5-2
-------------------
* Sun Dec 21 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.5-2
- Requiring correct font package


fakeroot-1.11-19.fc11
---------------------
* Sat Nov 22 17:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 1.11-19
- Update to 1.11.


fedora-business-cards-0.2.4-1.fc11
----------------------------------
* Sun Dec 21 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.2.4-1
- Add CMYK PDF as an export option


feh-1.3.4-9.fc11
----------------
* Sun Dec 21 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 1.3.4-9
- Switch from included font to DejaVu Sans


firefox-3.1-0.4.beta2.fc11
--------------------------
* Sat Dec 20 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 3.1-0.4
- 3.1 beta 2


fontpackages-1.12-2.fc11
------------------------
* Sun Dec 21 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
- 1.12-2
??? Change homepage


ganyremote-5.5.1-1.fc11
-----------------------
* Sun Dec 21 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.5.1-1
- Fix upload from web feature


giblib-1.2.4-12
---------------
* Sun Dec 21 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.2.4-12
- Fix multilib conflict in the config script.


gnome-python2-2.22.3-4.fc11
---------------------------
* Sun Dec 21 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.22.3-4.fc11
- Don't require devel packages in a non-devel subpackage.
- gnome-python2 doesn't need gome-python2-gnomevfs (RH bug #477494).


gpp4-1.0.4-13.fc11
------------------
* Sun Dec 21 17:00:00 2008 Tim Fenn <fenn at stanford.edu> - 1.0.4-13
- remove latex files from doc, just include html (477392)


gwibber-0.7.2-3.165bzr.fc11
---------------------------
* Sun Dec 21 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.7.2-2.156bzr
- add missing Requires: pyxdg

* Sun Dec 21 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.7.2-3.165bzr
- Update upstream


hal-0.5.12-19.20081219git.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> - 0.5.12-19.20081219git
- hal-joystick.patch: init bitmask before checking it
- Add hal-tablet.patch: move tablet check out of questionable axis check
- Add hal-tablet-evdev.patch: if it's a tablet, use evdev


igraph-0.5.1-3.fc11
-------------------
* Sun Nov 16 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.5.1-2
- Remove igraph-cstdlib.patch
- Remove igraph-test.patch

* Sun Nov 16 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.5.1-1
- Update to 0.5.1


jd-2.1.0-0.4.svn2593_trunk.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2593


kanyremote-5.5.1-3.fc11
-----------------------
* Sun Dec 21 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.5.1-2
- Rebuild

* Sun Dec 21 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.5.1-1
- Fix upload from web feature


libcaca-0.99-0.6.beta16.fc11
----------------------------
* Sun Dec 21 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.99-0.6.beta16
- Add patch to share the same caca-config for 32 and 64bit (#341951).
- Don't include the pdf devel doc, only html (again, fixed multilib conflict).


libdrm-2.4.3-0.3.fc11
---------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.4.3-0.3
- radeon: make library name correct

* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.4.3-0.2
- radeon: update with fixes for reloc size


libmtp-0.3.5-1.fc11
-------------------
* Sun Dec 21 17:00:00 2008 Linus Walleij <triad at df.lth.se> 0.3.5-1
- New upstream bugfix release.
- Nuke documentation again. Multilib no like.


lua-lpeg-0.9-1.fc11
-------------------
* Mon Dec 22 17:00:00 2008 Tim Niemueller <tim at niemueller.de> - 0.9-1
- Update to 0.9


lua-posix-5.1.4-1.fc11
----------------------
* Mon Dec 22 17:00:00 2008 Tim Niemueller <tim at niemueller.de> - 5.1.4-1
- Update to 5.1.4


mercurial-1.1.1-2.fc11
----------------------
* Sun Dec 21 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 1.1.1-2
- Fix typo

* Sun Dec 21 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 1.1.1-1
- Update to 1.1.1


mtx-1.3.12-2.fc11
-----------------
* Sun Dec 21 17:00:00 2008 Dan Hor??k <dan[at]danny.cz> 1.3.12-2
- spec file cleanup for better compliance with the guidelines


nafees-web-naskh-fonts-1.0-4.fc11
---------------------------------
* Sun Dec 21 17:00:00 2008 Bernie Innocenti <bernie at codewiz.org> 1.0-4
- Builddep on fontpackages-devel

* Sun Dec 21 17:00:00 2008 Bernie Innocenti <bernie at codewiz.org> 1.0-3
- Typo: fontdir -> _fontdir

* Sun Dec 21 17:00:00 2008 Bernie Innocenti <bernie at codewiz.org> 1.0-2
- Updated to current Fedora font packaging guidelines


pari-2.3.4-1.fc11
-----------------
* Mon Dec 22 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 2.3.4-1
- new release 2.3.4


pdfedit-0.4.2-1.fc11
--------------------
* Sun Dec 21 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.4.2-1
- 0.4.2
- rediff patch from Makefile.in to Makefile


perl-Class-MOP-0.73-1.fc11
--------------------------
* Sun Dec 21 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.73-1
- update to 0.73


perl-DateTime-Format-Natural-0.74-1.fc11
----------------------------------------
* Sun Dec 21 17:00:00 2008 Iain Arnell <iarnell at gmail.com> 0.74-1
- update to 0.74


php-pear-Net-SMTP-1.3.2-1.fc11
------------------------------
* Sun Dec 21 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 1.3.2-1
- update to 1.3.2


php-pecl-ssh2-0.11.0-1.fc11
---------------------------
* Sat Dec 20 17:00:00 2008 Itamar Reis Peixoto <itamar at ispbrasil.com.br> 0.11.0-1
- convert package.xml to V2 format, update to 0.11.0 #BZ 476405


pigment-0.3.13-1.fc11
---------------------
* Thu Dec 18 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.3.13-1
- Update to 0.3.13.

* Tue Nov 11 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.3.12-1
- Update to 0.3.12.


pigment-python-0.3.9-1.fc11
---------------------------

player-2.1.1-8.fc11
-------------------
* Sun Dec 21 17:00:00 2008 Tim Niemueller <tim at niemueller.de> - 2.1.1-8
- Add patch for broken linux/serial.h (thanks to Caol??n McNamara)
- Add patch for GCC 4.4 (thanks to Caol??n McNamara)
- Rebuild for Python 2.6

* Sat Dec  6 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.1-7
- Fix libtool issue

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.1.1-6
- Rebuild for Python 2.6


presto-utils-0.3.4-1.fc11
-------------------------
* Sun Dec 21 17:00:00 2008 Jonathan Dieter <jdieter at gmail.com> - 0.3.4-1
- Change build system to standard python build system rather than make
- Update documentation (only about 18 months late)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.3.3-3
- Rebuild for Python 2.6


pygoocanvas-0.10.0-4.fc11
-------------------------
* Sun Dec 21 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.10.0-4
- break into main and -devel packages


python-pygments-1.0-3.fc11
--------------------------
* Sun Dec 21 17:00:00 2008 Steve 'Ashcrow' Milner <me at stevemilner.org> - 1.0-3
- Updated for release.


shadow-utils-4.1.2-9.fc11
-------------------------
* Sun Dec 21 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 2:4.1.2-9
- Add setup as a Requires. Perhaps this should be a files requires. (#477529)


smart-1.1-58.fc11
-----------------
* Sun Dec 21 17:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 1.1-58
- Use bugfix branch, remove already included patches.

* Sat Dec 13 17:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 1.1-57
- Fix rpm loop reordering.


splat-1.2.3-2.fc11
------------------
* Mon Dec 22 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 1.2.3-2
- Merge main and -utils package, #475009


sugar-0.83.3-6.fc11
-------------------
* Sun Dec 21 17:00:00 2008 Bernie Innocenti <bernie at codewiz.org> - 0.83.3-6
- Add missing dependencies on xorg-x11-utils, dbus-x11 and openssh

* Wed Dec 10 17:00:00 2008 Bernie Innocenti <bernie at codewiz.org> - 0.83.3-5
- Spec file cleanup and updates


svn2cl-0.11-1
-------------
* Sun Dec 21 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.11-1
- 0.11.


syck-0.61-6.fc10
----------------
* Fri Dec 19 17:00:00 2008 Oliver Falk <oliver at linux-kernel.at> - 0.61-6
- Rebuild for deps


vdr-osdteletext-0.7.0-1.fc11
----------------------------
* Sun Dec 21 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.7.0-1
- 0.7.0.


vips-7.16.3-1.fc11
------------------
* Sun Dec 21 17:00:00 2008 Adam Goode <adam at spicenitz.org> - 7.16.3-1
- New release
- Update description


warzone2100-2.1.0-1.fc11
------------------------
* Sun Dec 21 17:00:00 2008 Karol Trzcionka <karlikt at gmail.com> - 2.1.0-1
- Update to v2.1.0 stable


wgrib2-1.7.7.i-1.fc11
---------------------
* Sun Dec 21 17:00:00 2008 Orion Poplawski <orion at cora.nwra.com> - 1.7.7.i-1
- Update to 1.7.7.i

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.7.2b-2
- Fix Patch0:/%patch mismatch.


xastir-1.9.5-2.fc11
-------------------
* Sun Dec 21 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.9.5-2
- patch for new IM

* Sun Dec 21 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.9.5-1
- cleanup desktop file
- drop engunits patch (fixed upstream)
- upgrade to devel version (FTBS with previous version)

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.9.4-6
- Rebuild for Python 2.6


xdx-2.4.1-1.fc11
----------------
* Mon Dec 22 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> 2.4.1-1
- Upstream update


xorg-x11-drv-apm-1.2.1-1.fc11
-----------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.2.1-1
- upgrade to latest upstream release

* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.2.0-2
- rebuild for server API change


xorg-x11-drv-ast-0.87.0-1.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 0.87.0-1
- Latest upstream release

* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 0.85.0-2
- update for latest server API


xorg-x11-drv-ati-6.9.0-65.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-65
- fix rotate API

* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-64
- rebuild for new API


xorg-x11-drv-chips-1.2.1-1.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.2.1-1
- update for latest server API


xorg-x11-drv-cirrus-1.2.0-2.fc11
--------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.2.0-2
- bump for server API


xorg-x11-drv-evdev-2.1.0-3.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 2.1.0-2
- Rebuild for server 1.6.

* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.1.0-3
- Rebuild again - latest tag wasn't in buildroot


xorg-x11-drv-fbdev-0.4.0-3.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 0.4.0-3
- rebuild for latest server API

* Thu Oct 30 18:00:00 2008 Bill Nottingham <notting at redhat.com> 0.4.0-2
- set canDoBGNoneRoot on driver startup

* Thu Mar 20 18:00:00 2008 Dave Airlie <airlied at redhat.com> 0.4.0-1
- Update to latest upstream release


xorg-x11-drv-geode-2.11.0-2.fc11
--------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.11.0-2
- update for new server API


xorg-x11-drv-glint-1.2.2-1.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.2.2-1
- Latest upstream release


xorg-x11-drv-i740-1.2.0-2.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.2.0-2
- bump to rebuild against new server


xorg-x11-drv-i810-2.5.99.1-0.2.fc11
-----------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.5.99.1-0.2
- rebuild for new server API


xorg-x11-drv-keyboard-1.3.1-1.20081222git.fc11
----------------------------------------------
* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.3.1-1.20081222
- Today's git snapshot.

* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.3.1-1
- keyboard 1.3.1


xorg-x11-drv-mach64-6.8.0-2.fc11
--------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.8.0-2
- update for latest server API


xorg-x11-drv-mga-1.4.8-2.fc11
-----------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.4.8-2
- bump for server API change


xorg-x11-drv-mouse-1.3.0-1.20081222git.fc11
-------------------------------------------
* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.3.0-1.20081222
- Today's git snapshot.


xorg-x11-drv-neomagic-1.2.2-1.fc11
----------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.2.2-1
- Latest upstream release


xorg-x11-drv-nv-2.1.12-7.fc11
-----------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.1.12-7
- rebuild for new server API


xorg-x11-drv-r128-6.8.0-2.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.8.0-2
- rebuild for new server API


xorg-x11-drv-s3-0.6.1-1.fc11
----------------------------

xorg-x11-drv-s3virge-1.10.2-1.fc11
----------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.10.2-1
- Latest upstream release


xorg-x11-drv-savage-2.2.0-2.fc11
--------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.2.0-2
- new server API rebuild


xorg-x11-drv-sis-0.10.1-1.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 0.10.1-1
- Latest upstream release


xorg-x11-drv-synaptics-0.99.3-2.fc11
------------------------------------
* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 0.99.3-2
- Rebuild for server 1.6


xorg-x11-drv-tdfx-1.4.1-1.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.4.1-1
- Latest upstream release


xorg-x11-drv-trident-1.3.1-1.fc11
---------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.3.1-1
- new upstream release

* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.3.0-2
- new server API


xorg-x11-drv-tseng-1.2.1-1.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.2.1-1
- Latest upstream release


xorg-x11-drv-vesa-2.1.0-1.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.1.0-1
- Update to new upstream release

* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.0.0-2
- bump for new server API


xorg-x11-drv-vmmouse-12.6.3-1.fc11
----------------------------------
* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 12.6.3-1
- vmmouse 12.6.3


xorg-x11-server-1.5.99.3-1.fc11
-------------------------------
* Fri Dec 19 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.5.99.3-1
- xserver 1.5.99.3
- drop patches merged into master
- xserver-1.5.99.3-dmx-xcalloc.patch: avoid dmx Xcalloc build errors


xulrunner-1.9.1-0.4.beta2.fc11
------------------------------
* Sat Dec 20 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 1.9.1-0.4
- 1.9.1 beta 2

* Tue Dec  9 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 1.9.1-0.3
- Mark this as a pre-release

* Tue Dec  9 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 1.9.1-0.2
- Add needed -devel requires to the -devel package

* Thu Dec  4 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 1.9.1-0.1
- 1.9.1 beta 1


yelp-2.24.0-5.fc11
------------------
* Sun Dec 21 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.24.0-5
- Rebuild against newer gecko

* Sat Dec 20 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 2.24.0-4
- rebuild for gecko


Summary:
Added Packages: 17
Removed Packages: 0
Modified Packages: 82
Broken deps for i386
----------------------------------------------------------
	Miro-1.2.8-3.fc11.i386 requires gecko-libs = 0:1.9.0.4
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	cobbler-1.4.0-2.fc11.noarch requires python(abi)=2.6
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	e16-0.16.8.14-1.fc10.i386 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	feh-1.3.4-9.fc11.i386 requires dejavu-sans-fonts
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gnomedesktop-2.24.0-5.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gtkmozembed-2.19.1-26.fc11.i386 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mono-sharpcvslib-0.35-3.fc10.i386 requires mono(nunit.framework) = 0:2.2.0.0
	mozvoikko-0.9.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.i386 requires libpython2.5.so.1.0
	python-igraph-0.5-5.fc9.i386 requires igraph = 0:0.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.i386 requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-search-tool-0.6.6-4.fc11.i386 requires libgnome-desktop-2.so.10
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	Miro-1.2.8-3.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	banshee-1.4.1-1.fc11.x86_64 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	blam-1.8.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	cobbler-1.4.0-2.fc11.noarch requires python(abi)=2.6
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.x86_64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	feh-1.3.4-9.fc11.x86_64 requires dejavu-sans-fonts
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gtkmozembed-2.19.1-26.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.i386 requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.x86_64 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mono-sharpcvslib-0.35-3.fc10.x86_64 requires mono(nunit.framework) = 0:2.2.0.0
	mozvoikko-0.9.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.x86_64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.x86_64 requires igraph = 0:0.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-storm-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.i386 requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.x86_64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	Miro-1.2.8-3.fc11.ppc requires gecko-libs = 0:1.9.0.4
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	feh-1.3.4-9.fc11.ppc requires dejavu-sans-fonts
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-python2-gtkmozembed-2.19.1-26.fc11.ppc requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	koan-1.4.0-2.fc11.noarch requires python(abi)=2.6
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libprojectM-1.2.0-5.fc11.ppc requires bitstream-vera-fonts
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mozvoikko-0.9.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc requires libpython2.5.so.1.0
	python-igraph-0.5-5.fc9.ppc requires igraph = 0:0.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc requires libpython2.5.so.1.0
	python-storm-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-mysql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc requires libpython2.5.so.1.0
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc requires libgnome-desktop-2.so.10
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	Miro-1.2.8-3.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	feh-1.3.4-9.fc11.ppc64 requires dejavu-sans-fonts
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gtkmozembed-2.19.1-26.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libprojectM-1.2.0-5.fc11.ppc64 requires bitstream-vera-fonts
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mozvoikko-0.9.5-5.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	perl-Padre-0.20-1.fc11.noarch requires perl(Pod::Simple::XHTML)
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	pympdtouchgui-0.302-5.fc10.noarch requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-igraph-0.5-5.fc9.ppc64 requires python(abi) = 0:2.5
	python-igraph-0.5-5.fc9.ppc64 requires igraph = 0:0.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-0.13-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-storm-mysql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-postgresql-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	python-storm-sqlite-0.13-2.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires python(abi) = 0:2.5
	qgis-python-0.11.0-4.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts





From nicolas.mailhot at laposte.net  Mon Dec 22 11:16:40 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Dec 2008 12:16:40 +0100
Subject: Font package naming guidelines
Message-ID: <1229944600.20011.10.camel@arekh.okg>

Hi,

Since there has been no more remarks on the clarified font package
naming rules discussed as part of
http://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes_(2008-11-08)

I've queued the following for approval FPC-side:
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_(2008-12-22)

Except for the comps changes which seem not baked yet, that concludes
the fonts-related guidelines changes and clarifications that were
proposed for F11.

Sincerely,

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/5814e44f/attachment.sig>

From alan at redhat.com  Mon Dec 22 11:37:59 2008
From: alan at redhat.com (Alan Cox)
Date: Mon, 22 Dec 2008 06:37:59 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221210339.GK2448@free.fr>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
	<20081221210339.GK2448@free.fr>
Message-ID: <20081222113759.GA4645@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 10:03:39PM +0100, Patrice Dumas wrote:
> > But cost and risk dumped on the community not the people proposing the idea.
> 
> There was no risk, since it was explitcitly unofficial.

There is always risk including the risk you mis-estimated the cost

> > > It may be done otherwise, sure, it is free software, but I still
> > > think that it would be much less cost-effective.
> > 
> > Perhaps.. but the sooner you go do it the sooner it happens.
> 
> If the cost is higher, it may never happen. 

Which any economist would I think take as fairly conclusive evidence there
is insufficient demand. Especially as the "cost" is a corner of someones ftp
site (probably free) [1], a bit of developers disk and machine time (basically
free nowdays) and developers own time.

Alan
[1] Seriously show me five people planning to contribute to this and I'm happy
to sort out a corner in ftp.linux.org.uk.




From alan at redhat.com  Mon Dec 22 11:43:34 2008
From: alan at redhat.com (Alan Cox)
Date: Mon, 22 Dec 2008 06:43:34 -0500
Subject: FC9, "missing syscalls" kernel target,
	and Promise Fasttrak TX4650 controller
In-Reply-To: <6d06ce20812211852t12694524v6e0a3b4379ca373f@mail.gmail.com>
References: <494EF670.9040400@redfish-solutions.com>
	<6d06ce20812211852t12694524v6e0a3b4379ca373f@mail.gmail.com>
Message-ID: <20081222114334.GB4645@shell.devel.redhat.com>

On Sun, Dec 21, 2008 at 08:52:25PM -0600, Jerry Amundson wrote:
> On 12/21/08, Philip A. Prindeville <philipp_subx at redfish-solutions.com> wrote:
> > I was going to build an RPM for the modules for the Promise FastTrak
> > TX4650 PCI-e RAID controller for FC9.

Its a totally generic AHCI controller.

You may need FC9 update kernels or FC10 however.

Alan



From alan at redhat.com  Mon Dec 22 12:06:51 2008
From: alan at redhat.com (Alan Cox)
Date: Mon, 22 Dec 2008 07:06:51 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gino7d$o2f$1@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
Message-ID: <20081222120651.GE4645@shell.devel.redhat.com>

On Mon, Dec 22, 2008 at 10:55:57AM +0100, Kevin Kofler wrote:
> > updates and you can't find a linux related site to host your stuff
> > initially you are doing something wrong or don't have enough interested
> > skilled people.
> 
> The time estimate is based on the time it took to get RPM Fusion up and
> running.

Which was a large project based upon merging existing large projects and done
for the first time. It has complex dependancies and politics.

Thats a bit like saying "Well concorde was hard so my paper aeroplane will
take five years to fold"

I've been in the Free Software world for a fair number of years and I will
say this - there are the people who say it is too hard/costs too much/can't be
done and there are the people who just do it anyway. Do you think Linux would
exist if Linus had started from a costing analysis for MS Windows or 4BSD ?

Just do it, the rest will fall into place if there is any interest.

Alan



From alan at redhat.com  Mon Dec 22 12:08:01 2008
From: alan at redhat.com (Alan Cox)
Date: Mon, 22 Dec 2008 07:08:01 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <ginp7a$sir$3@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222100207.GA26945@orient.maison.lan>
	<ginp7a$sir$3@ger.gmane.org>
Message-ID: <20081222120801.GF4645@shell.devel.redhat.com>

On Mon, Dec 22, 2008 at 11:12:58AM +0100, Kevin Kofler wrote:
> Emmanuel Seyman wrote:
> > RPM Fusion decided to duplicate the Fedora infrastructure. This goes
> > far above and beyond what you need to create a third-party repo.
> 
> Providing updates for all of Fedora actually requires MORE infrastructure
> than RPM Fusion. Just do the math.

Are you planning to maintain every package or just do security updates ?



From stlwrt at gmail.com  Mon Dec 22 12:08:12 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Mon, 22 Dec 2008 14:08:12 +0200
Subject: Can we make it so that Bodhi runs automatically?
In-Reply-To: <20081222101205.GC12869@amd.home.annexia.org>
References: <20081221194844.GA10113@amd.home.annexia.org>
	<d25f375f0812211222h1f6e5d7ew3ee3fb0d53b6df34@mail.gmail.com>
	<20081222101205.GC12869@amd.home.annexia.org>
Message-ID: <d25f375f0812220408p7c6d79p30493f3d4777576d@mail.gmail.com>

If all built packages will go directly to update queue they may be
delivered to repositories too fast breaking stuff

On Mon, Dec 22, 2008 at 12:12 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Sun, Dec 21, 2008 at 10:22:44PM +0200, Pavel Shevchuk wrote:
>> Because it won't allow to update highly modular packages properly.
>> Imaging gedit update being pushed before updated gnome-libs are built
>
> I don't understand what this means - can you explain more?
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://et.redhat.com/~rjones/virt-df/
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
http://scwlab.com



From rc040203 at freenet.de  Mon Dec 22 12:23:25 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 22 Dec 2008 13:23:25 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222120651.GE4645@shell.devel.redhat.com>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
Message-ID: <1229948605.24768.1151.camel@beck.corsepiu.local>

On Mon, 2008-12-22 at 07:06 -0500, Alan Cox wrote:
> On Mon, Dec 22, 2008 at 10:55:57AM +0100, Kevin Kofler wrote:
> > > updates and you can't find a linux related site to host your stuff
> > > initially you are doing something wrong or don't have enough interested
> > > skilled people.
> > 
> > The time estimate is based on the time it took to get RPM Fusion up and
> > running.
> 
> Which was a large project based upon merging existing large projects and done
> for the first time. It has complex dependancies and politics.
>
> Thats a bit like saying "Well concorde was hard so my paper aeroplane will
> take five years to fold"
Wrong, it's like saying "there are easy and effective ways and there are
less effective ways to achieve something".

> I've been in the Free Software world for a fair number of years and I will
> say this - there are the people who say it is too hard/costs too much/can't be
> done and there are the people who just do it anyway. Do you think Linux would
> exist if Linus had started from a costing analysis for MS Windows or 4BSD ?
>
> Just do it, the rest will fall into place if there is any interest.
Right, implementing a fork is the last resort, when an opensource
project's leadership doesn't want listen.

Other options would exist if there was willingness amongst Fedora's
sponsors and amongst Fedora's leadership - Both apparently do not exist.

Ralf




From paskalis at di.uoa.gr  Mon Dec 22 12:56:42 2008
From: paskalis at di.uoa.gr (Sarantis Paskalis)
Date: Mon, 22 Dec 2008 14:56:42 +0200
Subject: New font packaging guidelines
In-Reply-To: <1229789615.16655.28.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
Message-ID: <20081222125642.GA20909@gallagher.di.uoa.gr>

On Sat, Dec 20, 2008 at 05:13:35PM +0100, Nicolas Mailhot wrote:
> Dear all,
> 
> As some of you may know, after more than a month of consultation,
> feedback and tweaking new font packaging guidelines have been approved
> by FESCO.
> 
> http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18)
> http://fedoraproject.org/wiki/Fedora_fonts_policy_package
> http://fedoraproject.org/wiki/Simple_fonts_spec_template
> http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts
> 
> New font packages in review must now conform to the new templates, and
> current packages be converted in rawhide by their maintainers. To track
> the conversion progress I will henceforth file tickets in bugzilla.

Hello,

Two of my packages are TeX fonts (tetex-font-kerkis and 
tetex-font-cm-lgc), which contain .pfb files (postscript type 1 from 
what I could find out).

My questions are:
- Should I place the .pfb files   ( e.g.  
  /usr/share/texmf/fonts/type1/kerkis/Kerkis-Bold.pfb)
  in /usr/share/fonts/kerkis/ and symlink them to their old (original) 
  place or the reverse.
- What about the other TeX relevant files?  Should I do something with 
  them or are they indifferent to the rest of the system.

If there is an example TeX font package switched to the new format, it 
is not obvious from the package names.

Please advise.

Thanks,

-- Sarantis



From aportal at univ-montp2.fr  Mon Dec 22 12:58:18 2008
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 22 Dec 2008 13:58:18 +0100
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <4943D18E.60107@BitWagon.com>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>
	<4943D18E.60107@BitWagon.com>
Message-ID: <200812221358.18689.aportal@univ-montp2.fr>

Le samedi 13 d?cembre 2008 ? 16:15, John Reiser a ?crit?:
> Chitlesh GOORAH wrote:
> > ... With a category "Electronics" in comps.xml, users
> > can easily identify the electronic specific rpms on kpackageki.
>
> Please list the existing packages which should be included
> in an Electronics category.

Non exhaustive list:
- alliance
- arm-*
- avarice
- avr-*
- dfu-programmer
- electric
- freehdl
- geda-*
- gerbv
- ghdl
- gnucap
- gpsim
- gputils
- gresistor
- gspiceui
- irsim
- iverilog
- kicad
- ktechlab
- magic
- ngspice
- netgen
- pcb
- piklab
- pikdev
- pikloops
- qucs
- sdcc
- toped
- uisp
- vhd2vl
- xcircuit


-- 
La version fran?aise des pages de manuel Linux
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/44718f0e/attachment.sig>

From paul at city-fan.org  Mon Dec 22 13:07:46 2008
From: paul at city-fan.org (Paul Howarth)
Date: Mon, 22 Dec 2008 13:07:46 +0000
Subject: comps.xml and a new category "Electronics"
In-Reply-To: <200812221358.18689.aportal@univ-montp2.fr>
References: <50baabb30812130343n51aa7fc9k248b099ddac38ce9@mail.gmail.com>	<4943D18E.60107@BitWagon.com>
	<200812221358.18689.aportal@univ-montp2.fr>
Message-ID: <494F9122.3070500@city-fan.org>

Alain PORTAL wrote:
> Le samedi 13 d?cembre 2008 ? 16:15, John Reiser a ?crit :
>> Chitlesh GOORAH wrote:
>>> ... With a category "Electronics" in comps.xml, users
>>> can easily identify the electronic specific rpms on kpackageki.
>> Please list the existing packages which should be included
>> in an Electronics category.
> 
> Non exhaustive list:
> - alliance
> - arm-*
> - avarice
> - avr-*
> - dfu-programmer
> - electric
> - freehdl
> - geda-*
> - gerbv
> - ghdl
> - gnucap
> - gpsim
> - gputils
> - gresistor
> - gspiceui
> - irsim
> - iverilog
> - kicad
> - ktechlab
> - magic
> - ngspice
> - netgen
> - pcb
> - piklab
> - pikdev
> - pikloops
> - qucs
> - sdcc
> - toped
> - uisp
> - vhd2vl
> - xcircuit

gtkwave can be added to that list.

Paul.



From wolfy at nobugconsulting.ro  Mon Dec 22 13:16:12 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Mon, 22 Dec 2008 15:16:12 +0200
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222113759.GA4645@shell.devel.redhat.com>
References: <20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<20081221175700.GI2448@free.fr>	<20081221192300.GA21625@shell.devel.redhat.com>	<20081221202110.GJ2448@free.fr>	<20081221203312.GA30301@shell.devel.redhat.com>	<20081221210339.GK2448@free.fr>
	<20081222113759.GA4645@shell.devel.redhat.com>
Message-ID: <494F931C.4010508@nobugconsulting.ro>

Alan Cox wrote:
> Alan
> [1] Seriously show me five people planning to contribute to this and I'm happy
> to sort out a corner in ftp.linux.org.uk.
>
>
>   
I am not much of a programmer any more (hence, without help from someone 
more experienced,  backporting would probably be out of my league ) but 
I would gladly contribute as a packaging monkey if fedora-legacy would 
be revived. I still have RH 7.2, RH 7.2, FC1, FC2,  FC6 and FC7 in 
production, so from time to time I have to recompile stuff anyway.
Not to mention that very often I compile stuff from Fedora for Centos 4 
and 5



From emmanuel.seyman at club-internet.fr  Mon Dec 22 13:28:28 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 14:28:28 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1229948605.24768.1151.camel@beck.corsepiu.local>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
Message-ID: <20081222132828.GB4934@orient.maison.lan>

* Ralf Corsepius [22/12/2008 13:51] :
>
> Right, implementing a fork is the last resort, when an opensource
> project's leadership doesn't want listen.

That's not true.

We've discussed this idea several times and, when people are told that
they need to show there's a group of contributors to this project before
infrastructure is dedicated to it, they don't fork the updates, they
start whining and making up a whole bunch of excuses to justify not
doing the work.

Emmanuel



From lesmikesell at gmail.com  Mon Dec 22 13:40:08 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 07:40:08 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <ginp29$sir$2@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>
	<ginp29$sir$2@ger.gmane.org>
Message-ID: <494F98B8.9080700@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> backported updates.  Another which isn't really a long-term approach but
>> could produce usably-stable versions that overlapped a bit would be to
>> stop introducing new features in updates in one release by or before the
>> beta of the next release and focus only on stability from that point to
>> end of life.  Even if EOL is not extended you'd have a version that you
>> could run until the next version reached that point - and people who
>> want new features can jump to the next release instead.
> 
> No, we can't jump to the next release if it's only in beta. Just because we
> want new features doesn't mean we want a beta distro! 

As long as you are adding new features, it is always the equivalent of 
beta - pretty much by definition.

> The earliest
> a "stabilization" like that would be acceptable would be 1 month (time to
> upgrade) after the next release is out.

OK, so now you are down to a 5 month stable life.  Still better than 
none like it has now.

> And I don't see how the current system is not "usably-stable". Fedora just
> works.

Except when it doesn't.  Would you bet your life on it working correctly 
  after every update?  You'd have lost several times on my machines, 
including an update very near the end of FC6's life - a point where 
there was no reason at all to be making changes likely to break things. 
And I'm not using it again for anything that matters until I have some 
reason to think it won't be repeated.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From rc040203 at freenet.de  Mon Dec 22 13:50:09 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 22 Dec 2008 14:50:09 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222132828.GB4934@orient.maison.lan>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
Message-ID: <1229953809.24768.1365.camel@beck.corsepiu.local>

On Mon, 2008-12-22 at 14:28 +0100, Emmanuel Seyman wrote:
> * Ralf Corsepius [22/12/2008 13:51] :
> >
> > Right, implementing a fork is the last resort, when an opensource
> > project's leadership doesn't want listen.
> 
> That's not true.
> 
> We've discussed this idea several times and, when people are told that
> they need to show there's a group of contributors to this project before
> infrastructure is dedicated to it, they don't fork the updates, they
> start whining and making up a whole bunch of excuses to justify not
> doing the work.

We are turning in circles - It's a hen and egg problem.

FESCo brushes off volunteers, the @RHs (here A.C) gun-down any
volunteers, ... what do you expect prospective volunteers to think?

Patrice already turned away from Fedora, I for one have significantly
cut down my involvement into Fedora and am considering to further cut it
down.

Ralf
 





From pertusus at free.fr  Mon Dec 22 13:59:39 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Dec 2008 14:59:39 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222132828.GB4934@orient.maison.lan>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
Message-ID: <20081222135939.GA2473@free.fr>

On Mon, Dec 22, 2008 at 02:28:28PM +0100, Emmanuel Seyman wrote:
> 
> We've discussed this idea several times and, when people are told that
> they need to show there's a group of contributors to this project before
> infrastructure is dedicated to it, they don't fork the updates, they
> start whining and making up a whole bunch of excuses to justify not
> doing the work.

At least Kevin Kofler, Ralf Cors?pius, Orion Paplowski, Manuel 
Wolfshant and myself were interested. And we didn't want 
'dedicated infrastructure' before doing anything, but an 
agreement that such a project had a future. Did you even read
the proposal?
https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL

--
Pat



From lesmikesell at gmail.com  Mon Dec 22 14:03:10 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 08:03:10 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222092308.GA24499@orient.maison.lan>
References: <20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>	<20081222015545.GA604@orient.maison.lan>	<494F0C07.1020707@gmail.com>
	<20081222092308.GA24499@orient.maison.lan>
Message-ID: <494F9E1E.3010509@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [22/12/2008 09:52] :
>> Better said as "any reduction in the fragmentation into incompatible  
>> flavors is a win for everyone involved with unix-like operating  
>> systems".  Or, "any effort to separately maintain fragmented  
>> distributions is a wasted effort".
> 
> The cure for fragmentation is to keep as close to upstream as possible
> and encourage other distributions to do the same.

No it isn't.  Upstream projects make wild and crazy changes every day 
that I want no part of until they've stabilized and are suitable to use 
for years unchanged.  The cure for fragmentation is to pick some 
standard interfaces and stick to them so the code on each side can be 
optimized separately without breaking the other.

> I fail to see how
> planning "a smooth transition into the next Centos" has anything to do
> with it.

The 'smooth transition' is to avoid breaking the user's machine or 
forcing a re-install. Maybe that's a foreign concept to fedora, but for 
me, the point of running any new code is to get it to the point where it 
will continue to serve you for years.  That is, the system should work 
for you instead of you working to continually change it to something 
that isn't quite reliable yet.

If you don't introduce any incompatibilities between the RHEL cut and 
that fedora version's EOL, it should be feasible to do a final 'yum 
update' that slides the stable code into place along with switching the 
update repositories.  The machine then continues to work with stable 
code and update support for the next 7 years with no additional burden 
on fedora resources and the user continues to be happy with his choice 
to start with fedora.  Historically this would have been feasible with 
minor changes from FC1->Centos3, FC3->Centos4, FC6->Centos5.  If planned 
ahead of time it should be even easier.

If you don't like the Centos 'brand' switch - or don't understand why 
the code follows a natural path this way, fedora could do it's own RHEL 
rebranding.  Or maybe Red Hat could wake up and realize that a free 
distro of their own would be a return to what made their name in the 
first place.  In any case there should be no need to duplicate the work 
of backporting security and bug fixes into otherwise stable code that is 
free for anyone to use.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From emmanuel.seyman at club-internet.fr  Mon Dec 22 14:04:01 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 15:04:01 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1229953809.24768.1365.camel@beck.corsepiu.local>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<1229953809.24768.1365.camel@beck.corsepiu.local>
Message-ID: <20081222140401.GA7625@orient.maison.lan>

* Ralf Corsepius [22/12/2008 14:56] :
>
> We are turning in circles - It's a hen and egg problem.

Agreed.
This is one of the reasons I'm getting very annoyed with the people
making this proposal.

> FESCo brushes off volunteers, the @RHs (here A.C) gun-down any
> volunteers, ... what do you expect prospective volunteers to think?

I expect them to setup a third-party repo and start publishing updates.
Do you seriously think that, were I in their shoes, I would allow anyone
or anything to stop me from doing so ?

Emmanuel



From nicolas.mailhot at laposte.net  Mon Dec 22 14:08:21 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Dec 2008 15:08:21 +0100
Subject: New font packaging guidelines
In-Reply-To: <20081222125642.GA20909@gallagher.di.uoa.gr>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
Message-ID: <1229954901.24585.44.camel@arekh.okg>

Le lundi 22 d?cembre 2008 ? 14:56 +0200, Sarantis Paskalis a ?crit :
> On Sat, Dec 20, 2008 at 05:13:35PM +0100, Nicolas Mailhot wrote:

Hi Sarantis,

> > As some of you may know, after more than a month of consultation,
> > feedback and tweaking new font packaging guidelines have been approved
> > by FESCO.

> Two of my packages are TeX fonts (tetex-font-kerkis and 
> tetex-font-cm-lgc), which contain .pfb files (postscript type 1 from 
> what I could find out).

We've known for quite a	while TEX had a problem with fonts installation
and licensing. However repoquery unearthed many non-font packages that
shipped fonts (not only TEX packages, and a lot more than I
expected :(), so I'm going to write a general answer if you permit.

1. The target font management stack on Fedora is fontconfig. It has
?near universal? support including emacs-side?.

2. If your app is fontconfig-aware you just need to package the fonts it
needs as a normal guidelines-compliant font package. Fontconfig will
then locate them for your app no matter on how the font files are named
or renamed. 

3. If your app is not fontconfig-aware, you should politely remind your
upstream it has a problem.

4. If your app is not fontconfig-aware, and there is no solution
upstream in the short term, you still need to package the fonts using
the normal Fedora fonts packaging guidelines. And then either patch your
app to look for its fonts in the guidelines-compliant location or
package a set of symlinks pointing to this location.

5. The preferred way to package fonts is to locate their original font
upstream and package the original font release in a separate fonts-only
package.

6. However, for fonts that are bundled in a software package with no
other form of release, or fonts which have some additional non-standard
stuff bundled with them (such as TEX packages), I don't think anyone
will complain too loudly if you package them as subpackage(s) of your
main package. As long as the subpackage(s) are clean,
guidelines-compliant, and can be used by Fedora users without dragging
with them your app or TEX or other non-general-purpose stuff.

For example, for a ?tex-foo? TEX package, you could have:

tex-foo-fonts-fontname1 (normal font subpackage #1)
tex-foo-fonts-fontname2 (normal font subpackage #2)
[?]
tex-foo-fonts-common    (common font subpackage that owns the fonts dirs
                         and the fonts-licensing files?)
tex-foo                 (main TEX package that depends on the
                         tex-foo-fonts packages, includes symlinks to
                         the font files in standard locations and
                         other TEX stuff)

The subpackaging logic is pretty much the same as in the
spectemplate-fonts-multi.spec template included in fontpackages-devel
http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

Please note that the current guidelines say that font packagers:
?SHOULD package each font family separately, and avoid font collections
that mix fonts of different history, licensing, or origin??

There is some wiggle room between SHOULD and MUST, and it has posed
problems in the past six months, so I've pushed the simpler
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21)#New_wording
FPC-side yesterday.

I hope that answers all your questions.

? After a period of ??utter luddites? shock? to quote a well-known xorg
contributor
http://thread.gmane.org/gmane.comp.freedesktop.xorg/34322/focus=34334

? of course if you're shipping a single font family, that requires a
single font subpackage, there's no need to separate directory and
licensing handling in a -common subpackage. Just create a single
tex-foo-fonts-fontname in that case.

?
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages

Sincerely,

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/2fab6e2e/attachment.sig>

From emmanuel.seyman at club-internet.fr  Mon Dec 22 14:09:40 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 15:09:40 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222135939.GA2473@free.fr>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
Message-ID: <20081222140940.GA7789@orient.maison.lan>

* Patrice Dumas [22/12/2008 15:05] :
>
> At least Kevin Kofler, Ralf Cors?pius, Orion Paplowski, Manuel 
> Wolfshant and myself were interested. And we didn't want 
> 'dedicated infrastructure' before doing anything, but an 
> agreement that such a project had a future. Did you even read
> the proposal?

Yes. I stopped reading after the first three bullet points when I
realized they were demands for dedicated infrastructure.

Emmanuel



From aportal at univ-montp2.fr  Mon Dec 22 14:13:05 2008
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 22 Dec 2008 15:13:05 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081205195914.GB3227@free.fr>
References: <20081205195914.GB3227@free.fr>
Message-ID: <200812221513.06197.aportal@univ-montp2.fr>

Hi,

Le vendredi 5 d?cembre 2008 ? 20:59, Patrice Dumas a ?crit?:
> Hello,
>
> I think that fcron should be the default scheduler in fedora.
> fcron, with the service fcron_watch_config activated should now be
> 100% compatible with vixie-cron (cronie). The fcron_watch_config stuff
> is a bit convoluted (3 scripts and one C program...) but should work.
>
> The advantages over cronie are the following:
> * it also does what anacron does
> * it has more features
> * instead of waking up every minutes to look at config files, like
>   cronie do, it uses inotify to watch the config. This should lead to
>   less awaking and certainly be interesting for power saving in some
>   situations
>
> I won't push this more, somebody else has to volunteer to make this
> happen. I think it could be done in F11 and it should be a feature.

Do you intend to package fcron for EPEL?

Regards,
Alain
-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From emmanuel.seyman at club-internet.fr  Mon Dec 22 14:14:53 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 15:14:53 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494F9E1E.3010509@gmail.com>
References: <20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<494E942F.2000309@gmail.com>
	<20081221192640.GB21625@shell.devel.redhat.com>
	<494EA17F.6010708@gmail.com>
	<20081222015545.GA604@orient.maison.lan>
	<494F0C07.1020707@gmail.com>
	<20081222092308.GA24499@orient.maison.lan>
	<494F9E1E.3010509@gmail.com>
Message-ID: <20081222141453.GA7906@orient.maison.lan>

* Les Mikesell [22/12/2008 15:11] :
>
> No it isn't.  Upstream projects make wild and crazy changes every day
> that I want no part of until they've stabilized and are suitable to use
> for years unchanged.  The cure for fragmentation is to pick some
> standard interfaces and stick to them so the code on each side can be
> optimized separately without breaking the other.

???
This is the LSB specification.

Emmanuel



From pertusus at free.fr  Mon Dec 22 14:15:13 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Dec 2008 15:15:13 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <200812221513.06197.aportal@univ-montp2.fr>
References: <20081205195914.GB3227@free.fr>
	<200812221513.06197.aportal@univ-montp2.fr>
Message-ID: <20081222141513.GB2473@free.fr>

On Mon, Dec 22, 2008 at 03:13:05PM +0100, Alain PORTAL wrote:
> 
> Do you intend to package fcron for EPEL?

I think so. But not immediately. You can do it if you want to.

--
Pat



From aportal at univ-montp2.fr  Mon Dec 22 14:16:24 2008
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 22 Dec 2008 15:16:24 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222135939.GA2473@free.fr>
References: <9020.1229838236@iinet.net.au>
	<20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
Message-ID: <200812221516.24644.aportal@univ-montp2.fr>

Le lundi 22 d?cembre 2008 ? 14:59, Patrice Dumas a ?crit?:
> On Mon, Dec 22, 2008 at 02:28:28PM +0100, Emmanuel Seyman wrote:
> > We've discussed this idea several times and, when people are told that
> > they need to show there's a group of contributors to this project before
> > infrastructure is dedicated to it, they don't fork the updates, they
> > start whining and making up a whole bunch of excuses to justify not
> > doing the work.
>
> At least Kevin Kofler, Ralf Cors?pius, Orion Paplowski, Manuel
> Wolfshant and myself were interested. And we didn't want
> 'dedicated infrastructure' before doing anything, but an
> agreement that such a project had a future. Did you even read
> the proposal?
> https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_E
>OL

+1

I always submit my packages in all the branches I could.

-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From wolfy at nobugconsulting.ro  Mon Dec 22 14:21:09 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Mon, 22 Dec 2008 16:21:09 +0200
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222140940.GA7789@orient.maison.lan>
References: <20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<gilugg$i5m$2@ger.gmane.org>	<20081221174256.GA9876@shell.devel.redhat.com>	<gino7d$o2f$1@ger.gmane.org>	<20081222120651.GE4645@shell.devel.redhat.com>	<1229948605.24768.1151.camel@beck.corsepiu.local>	<20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
Message-ID: <494FA255.3060309@nobugconsulting.ro>

Emmanuel Seyman wrote:
> * Patrice Dumas [22/12/2008 15:05] :
>   
>> At least Kevin Kofler, Ralf Cors?pius, Orion Paplowski, Manuel 
>> Wolfshant and myself were interested. And we didn't want 
>> 'dedicated infrastructure' before doing anything, but an 
>> agreement that such a project had a future. Did you even read
>> the proposal?
>>     
>
> Yes. I stopped reading after the first three bullet points when I
> realized they were demands for dedicated infrastructure.
>   
Read again. From the infrastructure point of view, all that is needed is 
to NOT kill koji building for older branches 1 month after a new release 
is out.




From kevin.kofler at chello.at  Mon Dec 22 14:25:52 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 15:25:52 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222100207.GA26945@orient.maison.lan>
	<ginp7a$sir$3@ger.gmane.org>
	<20081222120801.GF4645@shell.devel.redhat.com>
Message-ID: <gio81g$9n8$1@ger.gmane.org>

Alan Cox wrote:
> Are you planning to maintain every package or just do security updates ?

I'm really not planning anything, as the main driving force behind that
effort is leaving Fedora (and I think the way his proposals were met is
certainly part of the reason).

        Kevin Kofler



From emmanuel.seyman at club-internet.fr  Mon Dec 22 14:39:42 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 15:39:42 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FA255.3060309@nobugconsulting.ro>
References: <20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
Message-ID: <20081222143942.GA8592@orient.maison.lan>

* Manuel Wolfshant [22/12/2008 15:36] :
>
> Read again. From the infrastructure point of view, all that is needed is  
> to NOT kill koji building for older branches 1 month after a new release  
> is out.

This is dedicated infrastructure, IMHO.

Not to mention that it won't open all acls to packagers, nor will it
create a repo to which the packages are pushed.

Emmanuel



From kevin.kofler at chello.at  Mon Dec 22 14:43:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 15:43:47 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>
	<ginp29$sir$2@ger.gmane.org> <494F98B8.9080700@gmail.com>
Message-ID: <gio933$e9p$1@ger.gmane.org>

Les Mikesell wrote:
> As long as you are adding new features, it is always the equivalent of
> beta - pretty much by definition.

No it's not. Only features which are considered safe by their maintainers
are added.

> Except when it doesn't.  Would you bet your life on it working correctly
>   after every update?  You'd have lost several times on my machines,
> including an update very near the end of FC6's life - a point where
> there was no reason at all to be making changes likely to break things.

If an update is broken, I just revert it with rpm -Uvh --oldpackage, problem
solved. (This assumes you have the previous package still cached, but
that's what keepcache=1 in yum.conf is for. I don't understand why that's
not the default.) But this happens pretty rarely in my experience.

And what were you doing running FC6 very near the end of its life? You
should have upgraded to F7 or F8 by then. :-) The updates for old releases
get less testing because most packagers and most of the people running
updates-testing have long since moved on to a newer one by then.

> And I'm not using it again for anything that matters until I have some
> reason to think it won't be repeated.

I'm running Fedora on my machines (a desktop, a laptop and an old laptop
which I don't really use anymore because the new one is way faster) just
fine. I don't use any other OS.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec 22 14:57:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 15:57:37 +0100
Subject: Can we make it so that Bodhi runs automatically?
References: <20081221194844.GA10113@amd.home.annexia.org>
Message-ID: <gio9t6$gqb$1@ger.gmane.org>

Richard W.M. Jones wrote:
> Is there any reason why you _wouldn't_ want Bodhi to take an update
> automatically after a successful Koji build of a non-Rawhide package?

Grouped updates.

For example, a xulrunner security update can't just be pushed out as soon as
it's build, it requires building xulrunner, getting it tagged into the
buildroot, then building an updated firefox and rebuilding several other
xulrunner-using packages and then pushing everything as a grouped update.
Doing it any differently would break dependencies.

In some other cases, like KDE, it would be technically possible to push
first the libs, then each application module one by one, but this would be
much more chaotic than just pushing the new version out as a grouped update
as we're doing now. And people don't really test e.g.
kdebase-workspace-4.1.2 with kdelibs-4.1.3, it should work due to backwards
compatibility, but normally users are expected to update those modules to
4.1.3 together. And we need to support grouped updates anyway for the cases
where we don't have backwards compatibility, like xulrunner (for those apps
using the xulrunner-unstable interfaces, which include Firefox).

        Kevin Kofler



From pertusus at free.fr  Mon Dec 22 15:02:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Dec 2008 16:02:37 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gio81g$9n8$1@ger.gmane.org>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222100207.GA26945@orient.maison.lan>
	<ginp7a$sir$3@ger.gmane.org>
	<20081222120801.GF4645@shell.devel.redhat.com>
	<gio81g$9n8$1@ger.gmane.org>
Message-ID: <20081222150237.GC2473@free.fr>

On Mon, Dec 22, 2008 at 03:25:52PM +0100, Kevin Kofler wrote:
> 
> I'm really not planning anything, as the main driving force behind that
> effort is leaving Fedora (and I think the way his proposals were met is
> certainly part of the reason).

Only a part. It was certainly what made me really think whether fedora
was really the place for me or not (it was not the first time, the first
time was when static libs were banned). But I decided not to take this
event to seriously, since I was personally and emotionally implicated
it could have lead to a hasted decision. In the end I think that 
the ConsoleKit issue was more determining.

It is clear that it was determining, however, on the part about
me doing noise without any long-term good for fedora.

I am still doing it, to avoid misinterpretations of history and
other doing the same mistakes than me :-/

--
Pat



From kevin.kofler at chello.at  Mon Dec 22 15:01:50 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 16:01:50 +0100
Subject: [Fedora Update] [stable] fakeroot-1.11-19.fc8
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>	<1229898973.3861.75.camel@localhost.localdomain>	<46a038f90812211558v559a3fcfpc3931b5c091b25a7@mail.gmail.com>
	<1229904279.3861.84.camel@localhost.localdomain>
	<494F5243.5050602@grad.com>
Message-ID: <gioa4u$gqb$2@ger.gmane.org>

Hedayat Vatankhah wrote:
> Currently, the Notes section in New Update page of Bodhi has this 
> comment: "Some optional details about this update that will appear in the
> notice". 
[snip]
> But recently I found that this section is a little more important. I
> think there should be a little more info about it, and some examples of
> when these comments are useful.

I think the "optional" should be dropped, or even better, changed
to "required" (and Bodhi should actually reject updates with blank notes or
at least print out a warning - sometimes the Bugzilla references contain
all the information already, but usually, even in that case, something
useful can be filled into the Notes).

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec 22 15:05:13 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 16:05:13 +0100
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
Message-ID: <gioab9$gqb$3@ger.gmane.org>

Jerry Amundson wrote:
> How do I resolve the
> Todo queue:
> Download a client-side certificate
> always appearing at login?
> (yes, I've downloaded it, imported it, cast it in bronze...)

Just ignore it. If you already downloaded the client cert and it hasn't
expired yet, you should not download a new one, just keep the one you have.

        Kevin Kofler



From inode0 at gmail.com  Mon Dec 22 15:12:44 2008
From: inode0 at gmail.com (inode0)
Date: Mon, 22 Dec 2008 09:12:44 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
	<604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
Message-ID: <e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>

On Sun, Dec 21, 2008 at 10:35 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> The goal of the Role definitions isn't to list every individual task
> or subgroup. The idea is to draw rough circles around common
> tasks,groups and skillsets. These circles overlap. You'll notice that
> some groups appear under different roles.

The circle OS Developer conjures up is smaller than the group we are
trying to describe, but there isn't very much to those descriptions so
reading more than the big headings isn't asking very much from someone
who is looking for ways to contribute.

> All I am asking is to provide us with some more specific feedback on
> how to rename the role that is currently titled OS Developer.  Its not
> enough to know that your confused by the current title. We need to
> know what would make sense to you as an alternative.

The obvious thing to consider is simply dropping OS from the heading
but either way if the user isn't willing to read the following 7 lines
they aren't going to know what that means either.

John



From aportal at univ-montp2.fr  Mon Dec 22 15:17:46 2008
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 22 Dec 2008 16:17:46 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FA255.3060309@nobugconsulting.ro>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
Message-ID: <200812221617.46571.aportal@univ-montp2.fr>

Le lundi 22 d?cembre 2008 ? 15:21, Manuel Wolfshant a ?crit?:
> Emmanuel Seyman wrote:
> > * Patrice Dumas [22/12/2008 15:05] :
> >> At least Kevin Kofler, Ralf Cors?pius, Orion Paplowski, Manuel
> >> Wolfshant and myself were interested. And we didn't want
> >> 'dedicated infrastructure' before doing anything, but an
> >> agreement that such a project had a future. Did you even read
> >> the proposal?
> >
> > Yes. I stopped reading after the first three bullet points when I
> > realized they were demands for dedicated infrastructure.
>
> Read again. From the infrastructure point of view, all that is needed is
> to NOT kill koji building for older branches 1 month after a new release
> is out.

This is how I understood it.

-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From pertusus at free.fr  Mon Dec 22 15:35:12 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Dec 2008 16:35:12 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <200812221622.13942.aportal@univ-montp2.fr>
References: <20081205195914.GB3227@free.fr>
	<200812221513.06197.aportal@univ-montp2.fr>
	<20081222141513.GB2473@free.fr>
	<200812221622.13942.aportal@univ-montp2.fr>
Message-ID: <20081222153512.GA2445@free.fr>

On Mon, Dec 22, 2008 at 04:22:13PM +0100, Alain PORTAL wrote:
> 
> For the moment, I can't because old problem of cvs access.
> And I'm not sure I'll keep a box under Fedora, I intend to switch to Centos.

You can still contribute to EPEL even if you don't run a fedora box.
In fact I still contribute to EPEL though I have left fedora, and
right now I use a debian testing to submit the EPEL jobs with plague, 
works fine.

--
Pat



From dmalcolm at redhat.com  Mon Dec 22 15:36:51 2008
From: dmalcolm at redhat.com (David Malcolm)
Date: Mon, 22 Dec 2008 10:36:51 -0500
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <6e24a8e80812201205k34093d85v8c6fc5814c5ce825@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<604aa7910812201116v3cabbd47ue51abce7f218766e@mail.gmail.com>
	<6e24a8e80812201128q1e7017e1q2e6950648922f5df@mail.gmail.com>
	<604aa7910812201141y467ac246lcc02f9e28e3d9cc3@mail.gmail.com>
	<6e24a8e80812201153s53cfbdafmdce494e307f7bdb2@mail.gmail.com>
	<1229803043.4026.8.camel@matthiasc>
	<6e24a8e80812201205k34093d85v8c6fc5814c5ce825@mail.gmail.com>
Message-ID: <1229960211.7823.3.camel@localhost.localdomain>

On Sat, 2008-12-20 at 21:05 +0100, Mark wrote:
> On Sat, Dec 20, 2008 at 8:57 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> > On Sat, 2008-12-20 at 20:53 +0100, Mark wrote:
> >
> >> Btw your idea of "my spin idea" might very well be true ^_^ it's just
> >> that it sucks up so much time which i don't want to spend at it.
> >>
> >
> > Creating a sabayon profile with your favourite changes and storing it
> > away in some safe place would take ~10 minutes (including the time to
> > install sabayon). The time and energy you have invested in this thread
> > by now probably measures in days...
> 
> not really.
> It requires me to: download sabyon, install it, figure out in detail
> how the profile stuff works and if that fits my needs and it's not
> using the RPM package system. I might not agree with all of fedora and
> might find ubuntu better then fedora but i find RPM so much easyer
> then debs if you make want to edit existing rpm's and that's why i
> keep coming back to fedora.
He's referring to Sabayon, the tool for managing GConf preferences
across groups of users:
http://projects.gnome.org/sabayon/

rather than Sabayon, the Linux distribution:
http://www.sabayonlinux.org/

"?yum install sabayon" FTW





From aportal at univ-montp2.fr  Mon Dec 22 15:22:13 2008
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 22 Dec 2008 16:22:13 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <20081222141513.GB2473@free.fr>
References: <20081205195914.GB3227@free.fr>
	<200812221513.06197.aportal@univ-montp2.fr>
	<20081222141513.GB2473@free.fr>
Message-ID: <200812221622.13942.aportal@univ-montp2.fr>

Le lundi 22 d?cembre 2008 ? 15:15, Patrice Dumas a ?crit?:
> On Mon, Dec 22, 2008 at 03:13:05PM +0100, Alain PORTAL wrote:
> > Do you intend to package fcron for EPEL?
>
> I think so. But not immediately.

There is no emergency.

> You can do it if you want to. 

For the moment, I can't because old problem of cvs access.
And I'm not sure I'll keep a box under Fedora, I intend to switch to Centos.

-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From pertusus at free.fr  Mon Dec 22 15:38:00 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Dec 2008 16:38:00 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222143942.GA8592@orient.maison.lan>
References: <gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
Message-ID: <20081222153800.GB2445@free.fr>

On Mon, Dec 22, 2008 at 03:39:42PM +0100, Emmanuel Seyman wrote:
> 
> This is dedicated infrastructure, IMHO.
> 
> Not to mention that it won't open all acls to packagers, nor will it
> create a repo to which the packages are pushed.

The idea was to find volunteers, and assess the bandwidth and 
storage costs. I am sure you can read up to the end:
https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL
it can only lead to a more interesting conversation.

--
Pat



From notting at redhat.com  Mon Dec 22 15:42:06 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Dec 2008 10:42:06 -0500
Subject: Packages adding groups in %pre/post
In-Reply-To: <1229836519.3861.44.camel@localhost.localdomain>
References: <1229836519.3861.44.camel@localhost.localdomain>
Message-ID: <20081222154206.GD3104@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> I've noticed that in some situations, packages that add users/groups in
> %pre/post can fail.  What I most often see happening is while groupadd
> or useradd is installed, and properly requested by Requires(pre) or
> Requires(post) on shadow-utils, the /etc/group and /etc/passwd files
> themselves aren't in place.  These come from the setup package.
> 
> Should the shadow-utils package Require the setup package, or require it
> in such a way that it is in place before anything that calls
> shadow-utils?  Should the packages that need to add users/groups not
> only Requires(foo) on shadow-utils, but also setup?
> 
> Thoughts? 

How on earth do you get things installed w/o setup first?
glibc -> basesystem -> setup.

Bill



From notting at redhat.com  Mon Dec 22 15:43:32 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Dec 2008 10:43:32 -0500
Subject: rpms/hydrogen-drumkits/devel Classic-626.h2drumkit, NONE, 1.1
	Classic-808.h2drumkit, NONE, 1.1 ColomboAcousticDrumkit.h2drumkit,
	NONE, 1.1 ElectricEmpireKit.h2drumkit, NONE, 1.1
	HardElectro1.h2drumkit, NONE, 1.1 K-27_Trash_Kit.h2drumkit, NONE, 1.
In-Reply-To: <e76492710812202157p672c9bfeg66f25d3c32c94225@mail.gmail.com>
References: <e76492710812202157p672c9bfeg66f25d3c32c94225@mail.gmail.com>
Message-ID: <20081222154332.GE3104@nostromo.devel.redhat.com>

Orcan Ogetbil (oget.fedora at gmail.com) said: 
> I noticed. I used the cvs-import.sh script that the guidelines told
> me. The script identified these files as non-binary for some reason
> (bug?).

It's done by extension, not by calls to file(1).

Bill



From seg at haxxed.com  Mon Dec 22 15:51:16 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 22 Dec 2008 09:51:16 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
Message-ID: <1229961077.18082.25.camel@localhost.localdomain>

On Sun, 2008-12-21 at 19:02 -0900, Jeff Spaleta wrote:
> On Sun, Dec 21, 2008 at 6:55 PM, Jerry Amundson <jamundso at gmail.com> wrote:
> > That's my point. With my background, OS stands for Operating System,
> > and I wouldn't consider for one second looking there to help with, say
> > "xeyes". (or anything else that is not kernel*, or is not in @core for
> > that matter...)
> > http://en.wikipedia.org/wiki/Operating_system
> 
> 
> So what title would you use for the role in place of OS Developer? Is
> there a better succinct definition that would be appealing to you that
> encompasses the same skills,groups and tasks as listed here
> http://fedoraproject.org/wiki/Join#OSDeveloper  ?

"Software Engineer" seems like the obvious stodgy industry standard
title.

I'd prefer "UberHacker" but we've been over that one already... ;)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/e036f927/attachment.sig>

From alsadi at gmail.com  Mon Dec 22 16:10:13 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 22 Dec 2008 18:10:13 +0200
Subject: Encrypted home directory
In-Reply-To: <20081222101133.GB12869@amd.home.annexia.org>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
Message-ID: <385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>

I guess we should have an optional special directory inside each user's home
let's say it's named private

a trivial pygtk tool can call fuse to mount a file there into the same directory

what do you think ?

I guess I have 1000000s config files on my home, apps will start very
slow if they are encrypted (think firefox for example)



From lesmikesell at gmail.com  Mon Dec 22 16:11:39 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 10:11:39 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gio933$e9p$1@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>	<ginp29$sir$2@ger.gmane.org>
	<494F98B8.9080700@gmail.com> <gio933$e9p$1@ger.gmane.org>
Message-ID: <494FBC3B.8010200@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> As long as you are adding new features, it is always the equivalent of
>> beta - pretty much by definition.
> 
> No it's not. Only features which are considered safe by their maintainers
> are added.

I don't think you understand the concept of alpha/beta phases.  Alpha is 
when a developer 'thinks' something is ready.  Beta continues until this 
has been proven correct.  As far as I can tell, fedora updates _never_ 
reach the tested/proven phase and even if they did, any package set that 
has been tested together isn't repeatable on another machine because the 
repositories keep changing.

>> Except when it doesn't.  Would you bet your life on it working correctly
>>   after every update?  You'd have lost several times on my machines,
>> including an update very near the end of FC6's life - a point where
>> there was no reason at all to be making changes likely to break things.
> 
> If an update is broken, I just revert it with rpm -Uvh --oldpackage, problem
> solved. (This assumes you have the previous package still cached, but
> that's what keepcache=1 in yum.conf is for.

This was a kernel change, so the old one was there.  But, you had to be 
at the machine when it booted to fix it.  I wasn't - and don't want to 
be forced to be.

> I don't understand why that's
> not the default.) But this happens pretty rarely in my experience.

Rare isn't good enough, and it relates to the 'beta' quality.  If that 
had been tested on any similar machine before pushing the update it 
wouldn't have happened.  I just don't see the point of every having to 
deal with crap like that on a machine where I have real work - ever. 
And I don't see the point of maintaining a test machine when the updates 
aren't repeatable and keep adding new untested content during a release 
life.  There is no value in testing something that is just going to have 
new wild and crazy changes before you get any use out of the tested copy.

> And what were you doing running FC6 very near the end of its life? You
> should have upgraded to F7 or F8 by then. :-)

I'm not completely insane.  And the equivalent fedora versions that had 
previously been used for the RHEL cuts (FC1, FC3) had become fairly 
stable near their own end of life so I had at least some hope for FC6. 
Now even that is gone and I don't see a trend heading anywhere toward a 
stable version that would make a reasonable RHEL6 either.

The updates for old releases
> get less testing because most packagers and most of the people running
> updates-testing have long since moved on to a newer one by then.
> 
>> And I'm not using it again for anything that matters until I have some
>> reason to think it won't be repeated.
> 
> I'm running Fedora on my machines (a desktop, a laptop and an old laptop
> which I don't really use anymore because the new one is way faster) just
> fine. I don't use any other OS.

Good luck with that.  I hope you keep copies of your work on the spare 
machines.  Or your work isn't important enough that downtime matters. 
Also, think about how much time you spend re-installing and grooming 
fedora. I used to think that if you only had to do something to a 
machine once a year it was a good thing.  But, as soon as you manage 
more than a few hundred of them, that turns into having to deal with 
some problem every day and getting nothing else done.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From debarshi.ray at gmail.com  Mon Dec 22 16:11:56 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 22 Dec 2008 21:41:56 +0530
Subject: Glade(2/3) and Anjuta in comps-f9.xml
In-Reply-To: <1202307705.3034.9.camel@localhost.localdomain>
References: <3170f42f0802060600o19dae3b5i4a1f9c7c2d6f52e@mail.gmail.com>
	<1202306625.3034.0.camel@localhost.localdomain>
	<3170f42f0802060613g493c02e9n19e7fc4e2a688645@mail.gmail.com>
	<1202307705.3034.9.camel@localhost.localdomain>
Message-ID: <3170f42f0812220811o590c69b9r3d151681898caf2c@mail.gmail.com>

> I don't see any issue with letting glade2 and glade3 coexist for a
> while. And I don't expect there to be any explicit incompatibility, I
> just fear that there may be some issues when using glade3 on glade files
> that have been produced by glade2. Either way, I really hope that we
> will soon see a ui builder that supports the GtkBuilder format.

Now that we are starting to see GtkBuilder support [1] in Glade3 can
we finally push it as the "default on-media" package over Glade2?

Cheers,
Debarshi

----
[1]



From gnomeuser at gmail.com  Mon Dec 22 16:12:15 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Mon, 22 Dec 2008 17:12:15 +0100
Subject: Encrypted home directory
In-Reply-To: <385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
Message-ID: <1dedbbfc0812220812p5c2b5655je00742d77eb1b8cd@mail.gmail.com>

2008/12/22 Muayyad AlSadi <alsadi at gmail.com>

> I guess we should have an optional special directory inside each user's
> home
> let's say it's named private
>
> a trivial pygtk tool can call fuse to mount a file there into the same
> directory
>
> what do you think ?
>
> I guess I have 1000000s config files on my home, apps will start very
> slow if they are encrypted (think firefox for example)
>

If you have that many configuration files I would say you have other
problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/547568d7/attachment.htm>

From lesmikesell at gmail.com  Mon Dec 22 16:14:26 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 10:14:26 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222143942.GA8592@orient.maison.lan>
References: <20081221171438.GA6830@shell.devel.redhat.com>	<gilugg$i5m$2@ger.gmane.org>	<20081221174256.GA9876@shell.devel.redhat.com>	<gino7d$o2f$1@ger.gmane.org>	<20081222120651.GE4645@shell.devel.redhat.com>	<1229948605.24768.1151.camel@beck.corsepiu.local>	<20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
Message-ID: <494FBCE2.4050406@gmail.com>

Emmanuel Seyman wrote:
> * Manuel Wolfshant [22/12/2008 15:36] :
>> Read again. From the infrastructure point of view, all that is needed is  
>> to NOT kill koji building for older branches 1 month after a new release  
>> is out.
> 
> This is dedicated infrastructure, IMHO.
> 
> Not to mention that it won't open all acls to packagers, nor will it
> create a repo to which the packages are pushed.

"Create" a repo?  For a distribution that already exists?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From alsadi at gmail.com  Mon Dec 22 16:16:27 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 22 Dec 2008 18:16:27 +0200
Subject: Encrypted home directory
In-Reply-To: <1dedbbfc0812220812p5c2b5655je00742d77eb1b8cd@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<1dedbbfc0812220812p5c2b5655je00742d77eb1b8cd@mail.gmail.com>
Message-ID: <385866f0812220816m10983edcr49e8f46a19582f89@mail.gmail.com>

> If you have that many configuration files I would say you have other
> problems.

[alsadi at pc1 ~]$ find .* | wc -l
88108

this was on my gnome only machine
what if kde and other are installed



From emmanuel.seyman at club-internet.fr  Mon Dec 22 16:21:46 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 17:21:46 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FBCE2.4050406@gmail.com>
References: <20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
Message-ID: <20081222162146.GA10739@orient.maison.lan>

* Les Mikesell [22/12/2008 17:17] :
>
> "Create" a repo? For a distribution that already exists?

Yup. You can't just take over the fedora-updates repo changing the
conditions under which updates are released without informing the users.

Emmanuel



From mbarnes at redhat.com  Mon Dec 22 16:26:40 2008
From: mbarnes at redhat.com (Matthew Barnes)
Date: Mon, 22 Dec 2008 11:26:40 -0500
Subject: Need package reviews for Exchange 2007 support
Message-ID: <1229963200.17396.11.camel@localhost.localdomain>

Hey all,

I'm trying to push Fedora's OpenChange feature [1] forward so that
Evolution (and possibly KDE PIM) can talk to Exchange 2007 servers.
I'm looking for some kind souls to review a few packages:

Samba4:         https://bugzilla.redhat.com/show_bug.cgi?id=453083
OpenChange:     https://bugzilla.redhat.com/show_bug.cgi?id=453395
Evolution-MAPI: https://bugzilla.redhat.com/show_bug.cgi?id=476315

Note that for the moment, Samba4 is there primarily to support
OpenChange.  It's not really intended for general-purpose use yet.
The goal is for it to be parallel-installable with Samba3.

Thanks,
Matthew Barnes


[1] http://fedoraproject.org/wiki/Features/OpenChange
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/55c33ee3/attachment.sig>

From streeter at redhat.com  Mon Dec 22 16:29:03 2008
From: streeter at redhat.com (Guy Streeter)
Date: Mon, 22 Dec 2008 10:29:03 -0600
Subject: Encrypted home directory
In-Reply-To: <385866f0812220816m10983edcr49e8f46a19582f89@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>	<494E8B53.4050005@redhat.com>	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>	<20081221201523.GC10113@amd.home.annexia.org>	<20081221214630.669fbad3@lain.camperquake.de>	<20081222101133.GB12869@amd.home.annexia.org>	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>	<1dedbbfc0812220812p5c2b5655je00742d77eb1b8cd@mail.gmail.com>
	<385866f0812220816m10983edcr49e8f46a19582f89@mail.gmail.com>
Message-ID: <494FC04F.5050704@redhat.com>

Muayyad AlSadi wrote:
>> If you have that many configuration files I would say you have other
>> problems.
> 
> [alsadi at pc1 ~]$ find .* | wc -l
> 88108
> 
> this was on my gnome only machine
> what if kde and other are installed
> 

I think you want something like

find .[^.]* | wc -l

to avoid counting the files under '.' and '..'

Note also that most of the files you find that way are not config files.

Perhaps you wanted something like

ls -1 .[^.]* | wc -l
or
find . -name '.[^.]*' | wc -l

--Guy



From jkeating at redhat.com  Mon Dec 22 16:31:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 08:31:54 -0800
Subject: Packages adding groups in %pre/post
In-Reply-To: <20081222154206.GD3104@nostromo.devel.redhat.com>
References: <1229836519.3861.44.camel@localhost.localdomain>
	<20081222154206.GD3104@nostromo.devel.redhat.com>
Message-ID: <1229963514.3861.92.camel@localhost.localdomain>

On Mon, 2008-12-22 at 10:42 -0500, Bill Nottingham wrote:
> How on earth do you get things installed w/o setup first?
> glibc -> basesystem -> setup.

*shrug* it's just anaconda doing it's package install to build the
install image.  Given that shadow-utils doesn't mention setup at all,
rpm can't possibly know that setup should come before shadow-utils.  I
worked this down to a simple reproducer, just creating a fresh chroot
and asking yum to install NetworkManager will trigger the ordering issue
(at least on i386).  Giving rpm the hint that shadow-utils needs setup
fixes the ordering issue.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/64faed0d/attachment.sig>

From notting at redhat.com  Mon Dec 22 16:35:56 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Dec 2008 11:35:56 -0500
Subject: Packages adding groups in %pre/post
In-Reply-To: <1229963514.3861.92.camel@localhost.localdomain>
References: <1229836519.3861.44.camel@localhost.localdomain>
	<20081222154206.GD3104@nostromo.devel.redhat.com>
	<1229963514.3861.92.camel@localhost.localdomain>
Message-ID: <20081222163556.GB7710@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> > How on earth do you get things installed w/o setup first?
> > glibc -> basesystem -> setup.
> 
> *shrug* it's just anaconda doing it's package install to build the
> install image.  Given that shadow-utils doesn't mention setup at all,
> rpm can't possibly know that setup should come before shadow-utils.

Sure it does.

Package A has a Requires(pre) on shadow-utils. Hence, shadow-utils
must be installed *and functional* before A is installed. This means
shadow-utils and all its requirements.

>From there it's a simple dependency chain - shadow-utils -> glibc
-> basesystem -> setup.

So, if it's not getting installed right, rpm or yum is broken in some
way.

Bill



From stickster at gmail.com  Mon Dec 22 16:34:10 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Mon, 22 Dec 2008 11:34:10 -0500
Subject: Encrypted home directory
In-Reply-To: <385866f0812220816m10983edcr49e8f46a19582f89@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<1dedbbfc0812220812p5c2b5655je00742d77eb1b8cd@mail.gmail.com>
	<385866f0812220816m10983edcr49e8f46a19582f89@mail.gmail.com>
Message-ID: <20081222163410.GB25948@localhost.localdomain>

On Mon, Dec 22, 2008 at 06:16:27PM +0200, Muayyad AlSadi wrote:
> > If you have that many configuration files I would say you have other
> > problems.
> 
> [alsadi at pc1 ~]$ find .* | wc -l
> 88108
> 
> this was on my gnome only machine
> what if kde and other are installed

You're catching a lot with that command other than configuration
files, like browser cache, thumbnails, et al.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/6ee80a4b/attachment.sig>

From drago01 at gmail.com  Mon Dec 22 16:34:01 2008
From: drago01 at gmail.com (drago01)
Date: Mon, 22 Dec 2008 17:34:01 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081222115047.0acb4cb6@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172152.30869.ville.skytta@iki.fi>
	<20081218094440.3c13a7f3@infradead.org>
	<200812181847.35253.ville.skytta@iki.fi>
	<20081222115047.0acb4cb6@infradead.org>
Message-ID: <f6ca9fed0812220834x117458acoc9b6c1022a89b314@mail.gmail.com>

On Mon, Dec 22, 2008 at 11:50 AM, Arjan van de Ven <arjan at infradead.org> wrote:
> On Thu, 18 Dec 2008 18:47:34 +0200
> Ville Skytt? <ville.skytta at iki.fi> wrote:
>
>> On Thursday 18 December 2008, Arjan van de Ven wrote:
>> > On Wed, 17 Dec 2008 21:52:30 +0200
>> > Ville Skytt? <ville.skytta at iki.fi> wrote:
>>
>> > > - shutdown: 28 sec
>> > > - fresh boot: 66 sec
>> >
>> > see this is the problem; this can be 5 to 10 seconds, and should be.
>> > that's the point of this discussion
>>
>> Well, you said earlier:
>>
>> > > > I suspect you will always be able to boot faster than you can
>> > > > hibernate+resume.
>>
>> Maybe I'm just having a problem parsing that.  Does "will" here mean
>> that it will be like that in the future after $something gets done?
>
> yeah assuming you optimize both. Right now neither are well optimized;
> the boot part is known how to do ;)

what exactly are the changes that need to be done to get a 5-10 second boot?



From lesmikesell at gmail.com  Mon Dec 22 16:37:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 10:37:49 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222162146.GA10739@orient.maison.lan>
References: <20081221174256.GA9876@shell.devel.redhat.com>	<gino7d$o2f$1@ger.gmane.org>	<20081222120651.GE4645@shell.devel.redhat.com>	<1229948605.24768.1151.camel@beck.corsepiu.local>	<20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
Message-ID: <494FC25D.6020000@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [22/12/2008 17:17] :
>> "Create" a repo? For a distribution that already exists?
> 
> Yup. You can't just take over the fedora-updates repo changing the
> conditions under which updates are released without informing the users.

OK, inform the users.  But if they observed the guidelines they wouldn't 
be attempting any updates anyway, would they?  And why start being 
concerned about users now?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Mon Dec 22 16:42:24 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 08:42:24 -0800
Subject: [Fwd: Broken dependencies: livecd-tools]
In-Reply-To: <494F69FF.3020105@fedoraproject.org>
References: <494F69FF.3020105@fedoraproject.org>
Message-ID: <1229964144.3861.94.camel@localhost.localdomain>

On Mon, 2008-12-22 at 15:50 +0530, Rahul Sundaram wrote:
> If I only involved in the EPEL branch, I don't want to be notified
> when 
> the Fedora branch is broken. Does the script take branches into 
> consideration?

No, it just uses the generic <package>-owner at fedoraproject.org

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/8e5b9a38/attachment.sig>

From alsadi at gmail.com  Mon Dec 22 16:47:26 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 22 Dec 2008 18:47:26 +0200
Subject: Encrypted home directory
In-Reply-To: <20081222163410.GB25948@localhost.localdomain>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<1dedbbfc0812220812p5c2b5655je00742d77eb1b8cd@mail.gmail.com>
	<385866f0812220816m10983edcr49e8f46a19582f89@mail.gmail.com>
	<20081222163410.GB25948@localhost.localdomain>
Message-ID: <385866f0812220847p67c42e7dyfaf67837a4670ef4@mail.gmail.com>

> find .[^.]* | wc -l
no it's the same as find .* | wc -l
because * does not substitute leading dots

for example
rm -R delme/*
won't remove delme/../

> ls -1 .[^.]* | wc -l
this won't catch conf dirs like .gnome or .config/*

> You're catching a lot with that command other than configuration
> files, like browser cache, thumbnails, et al.
correct, but that was intentional Frields!

does any body want caches to be encrypted
aren't cache are supposed to speed things up



From nikolay at vladimiroff.com  Mon Dec 22 16:48:47 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Mon, 22 Dec 2008 18:48:47 +0200
Subject: Encrypted home directory
In-Reply-To: <385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
Message-ID: <a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>

2008/12/22 Muayyad AlSadi <alsadi at gmail.com>:
> I guess we should have an optional special directory inside each user's home
> let's say it's named private
>
> a trivial pygtk tool can call fuse to mount a file there into the same directory
>
> what do you think ?
>
> I guess I have 1000000s config files on my home, apps will start very
> slow if they are encrypted (think firefox for example)
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

It's good to have an option to do both encrypted home and dedicated
encrypted dir in home.
Sice it's normal to have programs that save your passwords in
plaintext in their configs. And yes,
most of them do that because they also send the passwords in plaintext
over the net,
and if someone watches your traffic it will be trivial to find them.
Also it's good to encrypt the cache of some programs since it's common
that you don't want
your browser history, cache, etc. to be visible.

However I find it simpler and safer to use hardware disk
encryption(from the BIOS config) and a bunch of other thinkpad
security stuff.
I'm not really sure if this kind of stuff is widely available on other
hardware. So this software encryption thing seems nice.






-- 
NV



From emmanuel.seyman at club-internet.fr  Mon Dec 22 16:55:28 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 22 Dec 2008 17:55:28 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FC25D.6020000@gmail.com>
References: <20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
Message-ID: <20081222165528.GA13110@orient.maison.lan>

* Les Mikesell [22/12/2008 17:48] :
>
> OK, inform the users.  But if they observed the guidelines they wouldn't  
> be attempting any updates anyway, would they?

???

>                                                And why start being  
> concerned about users now?

Whatever happens, the packages done after official EOL will almost
certaingly be of lesser quality than the ones pre-EOL. If you aren't
satisfied with the latter, you won't be satisfied with the former.

Emmanuel



From ivazqueznet at gmail.com  Mon Dec 22 16:57:54 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 22 Dec 2008 11:57:54 -0500
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <1229961077.18082.25.camel@localhost.localdomain>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<1229961077.18082.25.camel@localhost.localdomain>
Message-ID: <1229965075.17128.27.camel@ignacio.lan>

On Mon, 2008-12-22 at 09:51 -0600, Callum Lerwick wrote:
> On Sun, 2008-12-21 at 19:02 -0900, Jeff Spaleta wrote:
> > So what title would you use for the role in place of OS Developer? Is
> > there a better succinct definition that would be appealing to you that
> > encompasses the same skills,groups and tasks as listed here
> > http://fedoraproject.org/wiki/Join#OSDeveloper  ?
> 
> "Software Engineer" seems like the obvious stodgy industry standard
> title.

Let's not abuse that phrase here please. "Engineer" has various
implications for the person holding the title, which while desired
aren't required for membership. We should stick to "Software Developer"
or something equivalently nebulous.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/8a57367b/attachment.sig>

From lesmikesell at gmail.com  Mon Dec 22 17:02:48 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 11:02:48 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222141453.GA7906@orient.maison.lan>
References: <20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>	<20081222015545.GA604@orient.maison.lan>	<494F0C07.1020707@gmail.com>	<20081222092308.GA24499@orient.maison.lan>	<494F9E1E.3010509@gmail.com>
	<20081222141453.GA7906@orient.maison.lan>
Message-ID: <494FC838.7000303@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [22/12/2008 15:11] :
>> No it isn't.  Upstream projects make wild and crazy changes every day
>> that I want no part of until they've stabilized and are suitable to use
>> for years unchanged.  The cure for fragmentation is to pick some
>> standard interfaces and stick to them so the code on each side can be
>> optimized separately without breaking the other.
> 
> ???
> This is the LSB specification.

Except it isn't really useful either in what it specifies or how 
everyone implements it.   Can you, for example, NFS mount your /home 
from various OS's and run their apps, knowing that one of them won't 
make incompatible and irreversible changes to the formats of the 
dotfiles stored there, or even count on your python scripts to work 
across them?

On the other hand, there is a direct code lineage for most packages from 
a fedora cycle through RHEL and thus Centos, so unless someone 
explicitly breaks it there is no reason everything can't just keep working.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Mon Dec 22 17:06:35 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 11:06:35 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222165528.GA13110@orient.maison.lan>
References: <20081222120651.GE4645@shell.devel.redhat.com>	<1229948605.24768.1151.camel@beck.corsepiu.local>	<20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
Message-ID: <494FC91B.1020106@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [22/12/2008 17:48] :
>> OK, inform the users.  But if they observed the guidelines they wouldn't  
>> be attempting any updates anyway, would they?
> 
> ???
> 
>>                                                And why start being  
>> concerned about users now?
> 
> Whatever happens, the packages done after official EOL will almost
> certaingly be of lesser quality than the ones pre-EOL. If you aren't
> satisfied with the latter, you won't be satisfied with the former.

Errr, what?  The only updates that need to be made after EOL are to fix 
what was already wrong.  If pre-EOL quality is so good, you won't need 
any additional updates.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Mon Dec 22 17:17:10 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 18:17:10 +0100
Subject: Stability and Release Cycles - An Idea
References: <20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
Message-ID: <gioi2m$de3$1@ger.gmane.org>

Emmanuel Seyman wrote:

> * Les Mikesell [22/12/2008 17:48] :
>>
>> OK, inform the users.  But if they observed the guidelines they wouldn't
>> be attempting any updates anyway, would they?
> 
> ???

The distro is EOL and gets no updates, so why would they attempt to update
it?

> Whatever happens, the packages done after official EOL will almost
> certaingly be of lesser quality than the ones pre-EOL.

So what? It's EOL, users still using it deserve whatever they get.

And I think pushing out security updates, even if they're completely
untested, would still be better than no updates at all.

        Kevin Kofler



From gnomeuser at gmail.com  Mon Dec 22 17:19:38 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Mon, 22 Dec 2008 18:19:38 +0100
Subject: Encrypted home directory
In-Reply-To: <a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
Message-ID: <1dedbbfc0812220919u54a75923qae1739bef41b1466@mail.gmail.com>

2008/12/22 Nikolay Vladimirov <nikolay at vladimiroff.com>

> 2008/12/22 Muayyad AlSadi <alsadi at gmail.com>:
> > I guess we should have an optional special directory inside each user's
> home
> > let's say it's named private
> >
> > a trivial pygtk tool can call fuse to mount a file there into the same
> directory
> >
> > what do you think ?
> >
> > I guess I have 1000000s config files on my home, apps will start very
> > slow if they are encrypted (think firefox for example)
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>
> It's good to have an option to do both encrypted home and dedicated
> encrypted dir in home.
> Sice it's normal to have programs that save your passwords in
> plaintext in their configs. And yes,
> most of them do that because they also send the passwords in plaintext
> over the net,
> and if someone watches your traffic it will be trivial to find them.
> Also it's good to encrypt the cache of some programs since it's common
> that you don't want
> your browser history, cache, etc. to be visible.


Wouldn't saving passwords in plaintext (presumably also history and cache)
be a bug?

>
> However I find it simpler and safer to use hardware disk
> encryption(from the BIOS config) and a bunch of other thinkpad
> security stuff.
> I'm not really sure if this kind of stuff is widely available on other
> hardware. So this software encryption thing seems nice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/c47e302e/attachment.htm>

From alan at redhat.com  Mon Dec 22 17:26:22 2008
From: alan at redhat.com (Alan Cox)
Date: Mon, 22 Dec 2008 12:26:22 -0500
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gioi2m$de3$1@ger.gmane.org>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
	<gioi2m$de3$1@ger.gmane.org>
Message-ID: <20081222172622.GA13156@shell.devel.redhat.com>

On Mon, Dec 22, 2008 at 06:17:10PM +0100, Kevin Kofler wrote:
> And I think pushing out security updates, even if they're completely
> untested, would still be better than no updates at all.

No because you create the illusion of security which is more dangerous than
knowing a system is insecure - in the latter case people at least take
appropriate precautions.

If you've tested the security side then yes it probably is better than no
updates at all.

Alan



From seg at haxxed.com  Mon Dec 22 17:31:50 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 22 Dec 2008 11:31:50 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <1229965075.17128.27.camel@ignacio.lan>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<1229961077.18082.25.camel@localhost.localdomain>
	<1229965075.17128.27.camel@ignacio.lan>
Message-ID: <1229967110.18082.28.camel@localhost.localdomain>

On Mon, 2008-12-22 at 11:57 -0500, Ignacio Vazquez-Abrams wrote:
> On Mon, 2008-12-22 at 09:51 -0600, Callum Lerwick wrote:
> > On Sun, 2008-12-21 at 19:02 -0900, Jeff Spaleta wrote:
> > > So what title would you use for the role in place of OS Developer? Is
> > > there a better succinct definition that would be appealing to you that
> > > encompasses the same skills,groups and tasks as listed here
> > > http://fedoraproject.org/wiki/Join#OSDeveloper  ?
> > 
> > "Software Engineer" seems like the obvious stodgy industry standard
> > title.
> 
> Let's not abuse that phrase here please. "Engineer" has various
> implications for the person holding the title, which while desired
> aren't required for membership. We should stick to "Software Developer"
> or something equivalently nebulous.

Yeah I checked Wikipedia. I was unaware that "Software Engineering" was
controversial. :P
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/6a264ac2/attachment.sig>

From ascii79 at gmail.com  Mon Dec 22 17:35:14 2008
From: ascii79 at gmail.com (Sachin)
Date: Mon, 22 Dec 2008 11:35:14 -0600
Subject: Encrypted home directory
In-Reply-To: <1dedbbfc0812220919u54a75923qae1739bef41b1466@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<1dedbbfc0812220919u54a75923qae1739bef41b1466@mail.gmail.com>
Message-ID: <a3c040240812220935s315fc4b8m5af65b2269e9bb6b@mail.gmail.com>

I had never expected so much of discussion :), which is healthy.(I had never
thought of swap)
But shouldn't be discussion limited to whether we can provide this feature
or not and let the end user decide whether he wants to use it or not.

And if he faces the problem like scalability or umounting he/she log the bug
with upstream ..

I am believe fedora is about choices and freedom.


2008/12/22 David Nielsen <gnomeuser at gmail.com>

>
>
> 2008/12/22 Nikolay Vladimirov <nikolay at vladimiroff.com>
>
>> 2008/12/22 Muayyad AlSadi <alsadi at gmail.com>:
>> > I guess we should have an optional special directory inside each user's
>> home
>> > let's say it's named private
>> >
>> > a trivial pygtk tool can call fuse to mount a file there into the same
>> directory
>> >
>> > what do you think ?
>> >
>> > I guess I have 1000000s config files on my home, apps will start very
>> > slow if they are encrypted (think firefox for example)
>> >
>> > --
>> > fedora-devel-list mailing list
>> > fedora-devel-list at redhat.com
>> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>> >
>>
>> It's good to have an option to do both encrypted home and dedicated
>> encrypted dir in home.
>> Sice it's normal to have programs that save your passwords in
>> plaintext in their configs. And yes,
>> most of them do that because they also send the passwords in plaintext
>> over the net,
>> and if someone watches your traffic it will be trivial to find them.
>> Also it's good to encrypt the cache of some programs since it's common
>> that you don't want
>> your browser history, cache, etc. to be visible.
>
>
> Wouldn't saving passwords in plaintext (presumably also history and cache)
> be a bug?
>
>>
>> However I find it simpler and safer to use hardware disk
>> encryption(from the BIOS config) and a bunch of other thinkpad
>> security stuff.
>> I'm not really sure if this kind of stuff is widely available on other
>> hardware. So this software encryption thing seems nice.
>
>
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/eba00398/attachment.htm>

From lesmikesell at gmail.com  Mon Dec 22 17:39:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 11:39:24 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222172622.GA13156@shell.devel.redhat.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
Message-ID: <494FD0CC.5090109@gmail.com>

Alan Cox wrote:
> On Mon, Dec 22, 2008 at 06:17:10PM +0100, Kevin Kofler wrote:
>> And I think pushing out security updates, even if they're completely
>> untested, would still be better than no updates at all.
> 
> No because you create the illusion of security which is more dangerous than
> knowing a system is insecure - in the latter case people at least take
> appropriate precautions.
> 
> If you've tested the security side then yes it probably is better than no
> updates at all.

Can you really make an argument that ignoring a real, known 
vulnerability is always better than an attempt at a fix - especially in 
fedora where the pre-EOL updates don't get much testing either?

Personally, I think the correct approach is to replace such things with 
a rebuilt RHEL version where the fix will actually have some QA before 
dropping into users' laps, but...

-- 
   Les Mikesell
    lesmikesell at gmail.com



From rc040203 at freenet.de  Mon Dec 22 17:41:20 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 22 Dec 2008 18:41:20 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081222140401.GA7625@orient.maison.lan>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<1229953809.24768.1365.camel@beck.corsepiu.local>
	<20081222140401.GA7625@orient.maison.lan>
Message-ID: <1229967680.24768.1923.camel@beck.corsepiu.local>

On Mon, 2008-12-22 at 15:04 +0100, Emmanuel Seyman wrote:
> * Ralf Corsepius [22/12/2008 14:56] :
> >
> > We are turning in circles - It's a hen and egg problem.
> 
> Agreed.
> This is one of the reasons I'm getting very annoyed with the people
> making this proposal.
> 
> > FESCo brushes off volunteers, the @RHs (here A.C) gun-down any
> > volunteers, ... what do you expect prospective volunteers to think?
> 
> I expect them to setup a third-party repo and start publishing updates.
Well, one of the Fedora prime objectives had been to unite the 3rd party
repos, not to push around people to implement new ones.

> Do you seriously think that, were I in their shoes, I would allow anyone
> or anything to stop me from doing so ?
... "The Spirits that they called" ...

Ralf
 



From bpepple at fedoraproject.org  Mon Dec 22 17:46:52 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 22 Dec 2008 12:46:52 -0500
Subject: Package Review Stats for the week ending December 21, 2008
Message-ID: <1229968012.5289.4.camel@localhost.localdomain>

Top three  FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending December 21st, 2008
were Jason Tibbitts, Parag AN(????), and Peter Robinson.  Below is the
number of completed package reviews done.

Jason Tibbitts - 10
Parag AN(????) - 8
Peter Robinson - 6
manuel wolfshant - 5
Conrad Meyer - 4
Mamoru Tasaka - 4
Jesse Keating - 3
Dan Hor?k - 2
Dominik 'Rathann' Mierzejewski - 2
Lubomir Rintel - 2
Marcela Maslanova - 2
Orcan 'oget' Ogetbil - 2
Rex Dieter - 2
Richard W.M. Jones - 2
Adam Tkac - 1
Bryan Kearney - 1
David Woodhouse - 1
Erik van Pienbroek - 1
Fabian Affolter - 1
Jerry James - 1
Kevin Kofler - 1
Michael Schwendt - 1
Owen Taylor - 1
Patrice Dumas - 1
Robert Scheck - 1
Thorsten Leemhuis - 1
Xavier Lamien - 1

Merge Reviews: 3
Review Requests: 62
Total Reviews Completed: 67

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/45f8b169/attachment.sig>

From pmatilai at laiskiainen.org  Mon Dec 22 17:46:43 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 22 Dec 2008 19:46:43 +0200 (EET)
Subject: Packages adding groups in %pre/post
In-Reply-To: <20081222163556.GB7710@nostromo.devel.redhat.com>
References: <1229836519.3861.44.camel@localhost.localdomain>
	<20081222154206.GD3104@nostromo.devel.redhat.com>
	<1229963514.3861.92.camel@localhost.localdomain>
	<20081222163556.GB7710@nostromo.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0812221945480.19110@turre.koti.laiskiainen.org>

On Mon, 22 Dec 2008, Bill Nottingham wrote:

> Jesse Keating (jkeating at redhat.com) said:
>>> How on earth do you get things installed w/o setup first?
>>> glibc -> basesystem -> setup.
>>
>> *shrug* it's just anaconda doing it's package install to build the
>> install image.  Given that shadow-utils doesn't mention setup at all,
>> rpm can't possibly know that setup should come before shadow-utils.
>
> Sure it does.
>
> Package A has a Requires(pre) on shadow-utils. Hence, shadow-utils
> must be installed *and functional* before A is installed. This means
> shadow-utils and all its requirements.
>
>> From there it's a simple dependency chain - shadow-utils -> glibc
> -> basesystem -> setup.
>
> So, if it's not getting installed right, rpm or yum is broken in some
> way.

...or there's some funny new dependency loop somewhere, breaking the 
ordering.

 	- Panu -



From sundaram at fedoraproject.org  Mon Dec 22 17:52:27 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 22 Dec 2008 23:22:27 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FD0CC.5090109@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com>
Message-ID: <494FD3DB.9090501@fedoraproject.org>

Les Mikesell wrote:

> Personally, I think the correct approach is to replace such things with 
> a rebuilt RHEL version where the fix will actually have some QA before 
> dropping into users' laps, but...

Fedora is most cases, is way ahead in versions and that strategy won't 
work much. You could borrow a few fixes like Fedora Legacy used to but 
that is a small number.

Rahul



From jkeating at redhat.com  Mon Dec 22 17:53:03 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 09:53:03 -0800
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FD0CC.5090109@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com>
Message-ID: <1229968383.3861.98.camel@localhost.localdomain>

On Mon, 2008-12-22 at 11:39 -0600, Les Mikesell wrote:
> Personally, I think the correct approach is to replace such things with 
> a rebuilt RHEL version where the fix will actually have some QA before 
> dropping into users' laps, but...

That would often mean going backwards in version and features.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/1e3e3f8d/attachment.sig>

From lesmikesell at gmail.com  Mon Dec 22 17:58:35 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 11:58:35 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1229967680.24768.1923.camel@beck.corsepiu.local>
References: <20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<gilugg$i5m$2@ger.gmane.org>	<20081221174256.GA9876@shell.devel.redhat.com>	<gino7d$o2f$1@ger.gmane.org>	<20081222120651.GE4645@shell.devel.redhat.com>	<1229948605.24768.1151.camel@beck.corsepiu.local>	<20081222132828.GB4934@orient.maison.lan>	<1229953809.24768.1365.camel@beck.corsepiu.local>	<20081222140401.GA7625@orient.maison.lan>
	<1229967680.24768.1923.camel@beck.corsepiu.local>
Message-ID: <494FD54B.6080900@gmail.com>

Ralf Corsepius wrote:

>>> We are turning in circles - It's a hen and egg problem.
>> Agreed.
>> This is one of the reasons I'm getting very annoyed with the people
>> making this proposal.
>>
>>> FESCo brushes off volunteers, the @RHs (here A.C) gun-down any
>>> volunteers, ... what do you expect prospective volunteers to think?
>> I expect them to setup a third-party repo and start publishing updates.
> Well, one of the Fedora prime objectives had been to unite the 3rd party
> repos, not to push around people to implement new ones.

Talk about things going in circles... There was a pre-fedora time when 
freshrpms had Red Hat updates available via apt-get - and it was the 
handiest way to get them.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Mon Dec 22 18:09:37 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 12:09:37 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FD3DB.9090501@fedoraproject.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>
	<494FD3DB.9090501@fedoraproject.org>
Message-ID: <494FD7E1.1040503@gmail.com>

Rahul Sundaram wrote:
> Les Mikesell wrote:
> 
>> Personally, I think the correct approach is to replace such things 
>> with a rebuilt RHEL version where the fix will actually have some QA 
>> before dropping into users' laps, but...
> 
> Fedora is most cases, is way ahead in versions and that strategy won't 
> work much. You could borrow a few fixes like Fedora Legacy used to but 
> that is a small number.

It would only work in the versions where the code cycle continued into 
RHEL and would take some coordination even there, with the tradeoff that 
no duplicate work would ever need to be done on the development side and 
there would be no incompatible version jumps to cause trouble on the 
user side.

But, how many things have big security risks anyway?  In most cases the 
ones to worry about are just the kernel, network daemons, and suid 
programs - mostly things with standardized interfaces so backing up a 
version or two shouldn't break anything.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From tcallawa at redhat.com  Mon Dec 22 18:10:33 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 22 Dec 2008 13:10:33 -0500
Subject: Need package reviews for Exchange 2007 support
In-Reply-To: <1229963200.17396.11.camel@localhost.localdomain>
References: <1229963200.17396.11.camel@localhost.localdomain>
Message-ID: <1229969433.4528.12.camel@localhost.localdomain>

On Mon, 2008-12-22 at 11:26 -0500, Matthew Barnes wrote:
> Hey all,
> 
> I'm trying to push Fedora's OpenChange feature [1] forward so that
> Evolution (and possibly KDE PIM) can talk to Exchange 2007 servers.
> I'm looking for some kind souls to review a few packages:
> 
> Samba4:         https://bugzilla.redhat.com/show_bug.cgi?id=453083

It's worth noting that this is currently blocked by FE-Legal, before
anyone eagerly dives in.

~spot



From jkeating at redhat.com  Mon Dec 22 18:19:21 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 10:19:21 -0800
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FD7E1.1040503@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>
Message-ID: <1229969962.3861.100.camel@localhost.localdomain>

On Mon, 2008-12-22 at 12:09 -0600, Les Mikesell wrote:
> But, how many things have big security risks anyway?  In most cases the 
> ones to worry about are just the kernel, network daemons, and suid 
> programs - mostly things with standardized interfaces so backing up a 
> version or two shouldn't break anything.

The big ugly ones are browsers, or other network facing applications
that could leak your private data.  Those are also the ones that tend to
vary wildly between RHEL and Fedora, and even different releases of
Fedora.

Trying to do a ff update for F8 in 8 months time would be a real treat.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/fc1152bd/attachment.sig>

From sundaram at fedoraproject.org  Mon Dec 22 18:21:00 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 22 Dec 2008 23:51:00 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FD7E1.1040503@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>
Message-ID: <494FDA8C.3020207@fedoraproject.org>

Les Mikesell wrote:
> Rahul Sundaram wrote:
>> Les Mikesell wrote:
>>
>>> Personally, I think the correct approach is to replace such things 
>>> with a rebuilt RHEL version where the fix will actually have some QA 
>>> before dropping into users' laps, but...
>>
>> Fedora is most cases, is way ahead in versions and that strategy won't 
>> work much. You could borrow a few fixes like Fedora Legacy used to but 
>> that is a small number.
> 
> It would only work in the versions where the code cycle continued into 
> RHEL and would take some coordination even there, with the tradeoff that 
> no duplicate work would ever need to be done on the development side and 
> there would be no incompatible version jumps to cause trouble on the 
> user side.

RHEL mostly freezes on everything and backports fixes selectively with 
few version bumps in between. Fedora stays more close to upstream and 
rarely backports fixes. If a security issue affects the recent version 
of any component in Fedora, you just cannot borrow a fix from RHEL in 
most cases as a result.

> But, how many things have big security risks anyway?  In most cases the 
> ones to worry about are just the kernel, network daemons, and suid 
> programs - mostly things with standardized interfaces so backing up a 
> version or two shouldn't break anything.

You aren't considering things like Firefox which often requires security 
updates. You cannot just go back a few revisions and just hope to not 
break anything.  Doesn't work that way. You don't even have to be a 
developer to be aware of that. Any sys admin would be aware of how 
brittle things can be.

Rahul

Rahul



From seg at haxxed.com  Mon Dec 22 18:42:01 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 22 Dec 2008 12:42:01 -0600
Subject: Encrypted home directory
In-Reply-To: <385866f0812220847p67c42e7dyfaf67837a4670ef4@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<1dedbbfc0812220812p5c2b5655je00742d77eb1b8cd@mail.gmail.com>
	<385866f0812220816m10983edcr49e8f46a19582f89@mail.gmail.com>
	<20081222163410.GB25948@localhost.localdomain>
	<385866f0812220847p67c42e7dyfaf67837a4670ef4@mail.gmail.com>
Message-ID: <1229971321.18082.71.camel@localhost.localdomain>

On Mon, 2008-12-22 at 18:47 +0200, Muayyad AlSadi wrote:
> does any body want caches to be encrypted
> aren't cache are supposed to speed things up

The thing about disk encryption, (And disk compression...) is CPUs are
way faster than the disk. Reading from disk is by definition IO bound,
most likely the CPU is just sitting around waiting for the data anyway,
resulting in no real-world impact on performance in typical desktop
usage. It just takes up CPU time that would have otherwise been spent
sitting idle. (Which may, however, result in increased power usage...)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/af69134c/attachment.sig>

From vonbrand at inf.utfsm.cl  Mon Dec 22 18:42:44 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 22 Dec 2008 15:42:44 -0300
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1229953809.24768.1365.camel@beck.corsepiu.local>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<1229953809.24768.1365.camel@beck.corsepiu.local>
Message-ID: <200812221842.mBMIgiRi005792@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Mon, 2008-12-22 at 14:28 +0100, Emmanuel Seyman wrote:
> > * Ralf Corsepius [22/12/2008 13:51] :
> > >
> > > Right, implementing a fork is the last resort, when an opensource
> > > project's leadership doesn't want listen.
> > 
> > That's not true.
> > 
> > We've discussed this idea several times and, when people are told that
> > they need to show there's a group of contributors to this project before
> > infrastructure is dedicated to it, they don't fork the updates, they
> > start whining and making up a whole bunch of excuses to justify not
> > doing the work.
> 
> We are turning in circles - It's a hen and egg problem.

No...

> FESCo brushes off volunteers,

Haven't seen such.

>                               the @RHs (here A.C) gun-down any
> volunteers,

What I just saw was an _encouragement_ to go and just do it. That is not
"gun down".

>             ... what do you expect prospective volunteers to think?

That whining gets you nowhere fast. If you want to change something, ask.
If the answers you get don't convince you, find like-minded people and go
ahead and try it out. It doesn't need to be a full-fledged <whatever> at
first, just a prototype. If it (even modestly) succeeds, you have /very/
strong arguments for the next round of discussions. If they still don't
want to listen, you can go ahead and fork (that's the beauty of really open
source!). By then you will have the momentum and experience to do so behind
you.

> Patrice already turned away from Fedora, I for one have significantly
> cut down my involvement into Fedora and am considering to further cut it
> down.

Sorry to hear that.
-- 
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 nicolas.mailhot at laposte.net  Mon Dec 22 18:44:04 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Dec 2008 19:44:04 +0100
Subject: New font packaging guidelines
In-Reply-To: <1229954901.24585.44.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
Message-ID: <1229971444.28883.3.camel@arekh.okg>

Le lundi 22 d?cembre 2008 ? 15:08 +0100, Nicolas Mailhot a ?crit :
> Le lundi 22 d?cembre 2008 ? 14:56 +0200, Sarantis Paskalis a ?crit :
> > On Sat, Dec 20, 2008 at 05:13:35PM +0100, Nicolas Mailhot wrote:
> 
> Hi Sarantis,

> 6. However, for fonts that are bundled in a software package with no
> other form of release, or fonts which have some additional non-standard
> stuff bundled with them (such as TEX packages), I don't think anyone
> will complain too loudly if you package them as subpackage(s) of your
> main package. As long as the subpackage(s) are clean,
> guidelines-compliant, and can be used by Fedora users without dragging
> with them your app or TEX or other non-general-purpose stuff.
> 
> For example, for a ?tex-foo? TEX package, you could have:
> 
> tex-foo-fonts-fontname1 (normal font subpackage #1)
> tex-foo-fonts-fontname2 (normal font subpackage #2)
> [?]
> tex-foo-fonts-common    (common font subpackage that owns the fonts dirs
>                          and the fonts-licensing files?)
> tex-foo                 (main TEX package that depends on the
>                          tex-foo-fonts packages, includes symlinks to
>                          the font files in standard locations and
>                          other TEX stuff)
> 
> The subpackaging logic is pretty much the same as in the
> spectemplate-fonts-multi.spec template included in fontpackages-devel
> http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

Also, I'm pretty sure the other TEX packagers would be delighted if
someone documented this stuff from the TEX POW.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/8afc6193/attachment.sig>

From kevin.kofler at chello.at  Mon Dec 22 18:47:03 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 19:47:03 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>	<ginp29$sir$2@ger.gmane.org>
	<494F98B8.9080700@gmail.com> <gio933$e9p$1@ger.gmane.org>
	<494FBC3B.8010200@gmail.com>
Message-ID: <gionbc$4ga$1@ger.gmane.org>

Les Mikesell wrote:
> I don't think you understand the concept of alpha/beta phases.  Alpha is
> when a developer 'thinks' something is ready.  Beta continues until this
> has been proven correct.

That's what updates-testing is for.

> There is no value in testing something that is just going to have new
> wild and crazy changes before you get any use out of the tested copy.

You could keep a local mirror with the updates you're testing, then update
the non-test machine(s) to those, not to the very latest. But I don't see
that as being necessary at all.

>> And what were you doing running FC6 very near the end of its life? You
>> should have upgraded to F7 or F8 by then. :-)
> 
> I'm not completely insane.

;-)

Upgrading is the sane thing to do when your distro is nearing EOL...

> Now even that is gone and I don't see a trend heading anywhere toward a
> stable version that would make a reasonable RHEL6 either.

F10 is pretty stable, as is F9 with the current updates, the problems it had
when it was released are all fixed now. Rumors are that RHEL6 will be based
on F11, this should work out pretty well.

> Good luck with that.  I hope you keep copies of your work on the spare
> machines.  Or your work isn't important enough that downtime matters.

I do keep backup copies of my work (I have 3 copies of most stuff: on my
desktop, on my laptop and on a university machine or some other server),
it's always a sane thing to do no matter what OS you run. But I never had
Fedora destroy my data.

> Also, think about how much time you spend re-installing and grooming
> fedora. I used to think that if you only had to do something to a
> machine once a year it was a good thing.  But, as soon as you manage
> more than a few hundred of them, that turns into having to deal with
> some problem every day and getting nothing else done.

Don't worry, I'm not planning to buy 97 additional machines any time
soon. ;-) I'm not adminning a large installation.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec 22 18:49:52 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 19:49:52 +0100
Subject: Encrypted home directory
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<1dedbbfc0812220812p5c2b5655je00742d77eb1b8cd@mail.gmail.com>
	<385866f0812220816m10983edcr49e8f46a19582f89@mail.gmail.com>
	<20081222163410.GB25948@localhost.localdomain>
	<385866f0812220847p67c42e7dyfaf67837a4670ef4@mail.gmail.com>
Message-ID: <giongg$4ga$2@ger.gmane.org>

Muayyad AlSadi wrote:
> does any body want caches to be encrypted
> aren't cache are supposed to speed things up

Browser caches can contain a lot of sensitive data, e.g. credit card
numbers, and even the simple fact that you visited some site may be
sensitive.

        Kevin Kofler



From lesmikesell at gmail.com  Mon Dec 22 18:58:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 12:58:19 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FDA8C.3020207@fedoraproject.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>
	<494FDA8C.3020207@fedoraproject.org>
Message-ID: <494FE34B.1000906@gmail.com>

Rahul Sundaram wrote:
> 
>>> Fedora is most cases, is way ahead in versions and that strategy 
>>> won't work much. You could borrow a few fixes like Fedora Legacy used 
>>> to but that is a small number.
>>
>> It would only work in the versions where the code cycle continued into 
>> RHEL and would take some coordination even there, with the tradeoff 
>> that no duplicate work would ever need to be done on the development 
>> side and there would be no incompatible version jumps to cause trouble 
>> on the user side.
> 
> RHEL mostly freezes on everything and backports fixes selectively with 
> few version bumps in between. Fedora stays more close to upstream and 
> rarely backports fixes. If a security issue affects the recent version 
> of any component in Fedora, you just cannot borrow a fix from RHEL in 
> most cases as a result.

Yes, you'd have to coordinate this once the RHEL cut happens.  With the 
result being something actually useful instead of just another throwaway 
beta.   Fedora could just branch their next version at that point to 
satisfy people wanting fresh meat every day.

>> But, how many things have big security risks anyway?  In most cases 
>> the ones to worry about are just the kernel, network daemons, and suid 
>> programs - mostly things with standardized interfaces so backing up a 
>> version or two shouldn't break anything.
> 
> You aren't considering things like Firefox which often requires security 
> updates. You cannot just go back a few revisions and just hope to not 
> break anything.  Doesn't work that way. You don't even have to be a 
> developer to be aware of that. Any sys admin would be aware of how 
> brittle things can be.

How is that a particular issue?  Even RHEL jumped FF versions in an 
update, so whatever they do should be acceptable in fedora which doesn't 
seem to follow any particular policy regarding version stability.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From sundaram at fedoraproject.org  Mon Dec 22 19:04:02 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 00:34:02 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FE34B.1000906@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com>
Message-ID: <494FE4A2.5050604@fedoraproject.org>

Les Mikesell wrote:

> Yes, you'd have to coordinate this once the RHEL cut happens.  With the 
> result being something actually useful instead of just another throwaway 
> beta.   Fedora could just branch their next version at that point to 
> satisfy people wanting fresh meat every day.

Explain to me, how that would work. Would Fedora ever move to a new 
upstream version or stay with the same version that RHEL does?  If it 
moves to a new upstream version, how would you ensure that RHEL security 
fixes apply on Fedora? Don't use throw away words and explain it clearly.

> How is that a particular issue?  Even RHEL jumped FF versions in an 
> update, so whatever they do should be acceptable in fedora which doesn't 
> seem to follow any particular policy regarding version stability.

Firefox was just an example.  If you are not aware of how either side 
works, no point in discussing a comparison.

Rahul




From davej at redhat.com  Mon Dec 22 19:25:20 2008
From: davej at redhat.com (Dave Jones)
Date: Mon, 22 Dec 2008 14:25:20 -0500
Subject: FC9, "missing syscalls" kernel target, and Promise Fasttrak
	TX4650 controller
In-Reply-To: <494EF670.9040400@redfish-solutions.com>
References: <494EF670.9040400@redfish-solutions.com>
Message-ID: <20081222192520.GC23320@redhat.com>

On Sun, Dec 21, 2008 at 06:07:44PM -0800, Philip A. Prindeville wrote:
 > I was going to build an RPM for the modules for the Promise FastTrak 
 > TX4650 PCI-e RAID controller for FC9.
 > 
 > Their support website claims it's supported "in-box" in FC9, but it 
 > turns out that's not true:
 > 
 > $ lspci -v -s 02:00.0
 > 02:00.0 RAID bus controller: Promise Technology, Inc. Unknown device 3f20
 > 	Subsystem: Promise Technology, Inc. Unknown device 3f22
 > 	Flags: bus master, fast devsel, latency 0, IRQ 10

As Alan mentioned, the ahci driver drives this just fine.
To confirm, here's the entry for it from drivers/ata/ahci.c ..

        /* Promise */
        { PCI_VDEVICE(PROMISE, 0x3f20), board_ahci },   /* PDC42819 */

(I looked at 2.6.27 because it's what I had handy, so you may need to install
  the latest updates)

That lspci says 'unknown device' is irrelevant to the kernel.
There's no connection between the database lspci uses and the device IDs
in the driver modules.

	Dave

-- 
http://www.codemonkey.org.uk



From lesmikesell at gmail.com  Mon Dec 22 19:32:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 13:32:28 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FE4A2.5050604@fedoraproject.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>
	<494FE4A2.5050604@fedoraproject.org>
Message-ID: <494FEB4C.8020501@gmail.com>

Rahul Sundaram wrote:

>> Yes, you'd have to coordinate this once the RHEL cut happens.  With 
>> the result being something actually useful instead of just another 
>> throwaway beta.   Fedora could just branch their next version at that 
>> point to satisfy people wanting fresh meat every day.
> 
> Explain to me, how that would work. Would Fedora ever move to a new 
> upstream version or stay with the same version that RHEL does? 

The version where the RHEL cut happens would track whatever happens to 
RHEL to the point that the update repos could be repointed to Centos 
when it appears without breakage.  If it doesn't satisfy fedora 
developers to build towards stability even through one version out of 3 
or 4, fedora could just start it's next version early to absorb the new 
untested stuff.

> If it 
> moves to a new upstream version, how would you ensure that RHEL security 
> fixes apply on Fedora? Don't use throw away words and explain it clearly.

People claim to have done upgrades from the earlier corresponding 
fedora->Centos versions, perhaps manually tweaking a dozen or so 
packages so yum could do the rest.  If that can happen without any 
particular planning, I have to think it would be possible to plan it to 
work without tweaking.

>> How is that a particular issue?  Even RHEL jumped FF versions in an 
>> update, so whatever they do should be acceptable in fedora which 
>> doesn't seem to follow any particular policy regarding version stability.
> 
> Firefox was just an example.  If you are not aware of how either side 
> works, no point in discussing a comparison.

Given the FF and OOo jumps in RHEL, I don't think there is a specific 
'how' anymore.  But the point is that whatever RHEL does, I wish the 
fedora release that spawned it would do the same, even if the 
intermediate releases continue to be throwaway betas and even if it 
causes an odd jump in the release timing.  It would have to result in 
less work, less incompatibility, less fragmentation, and more usability 
all the way around.

-- 
    Les Mikesell
     lesmikesell at gmail.com




From lesmikesell at gmail.com  Mon Dec 22 19:40:17 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 13:40:17 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1229969962.3861.100.camel@localhost.localdomain>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>
	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>
	<1229969962.3861.100.camel@localhost.localdomain>
Message-ID: <494FED21.5040705@gmail.com>

Jesse Keating wrote:
> 
> The big ugly ones are browsers, or other network facing applications
> that could leak your private data.  Those are also the ones that tend to
> vary wildly between RHEL and Fedora, and even different releases of
> Fedora.
> 
> Trying to do a ff update for F8 in 8 months time would be a real treat.

Yes, that's one of several thousand reasons why it would be better to 
gracefully slide into a Centos or Centos-like update repo instead of 
duplicating the work to match it - and to not even consider it on 
releases like F8.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From rc040203 at freenet.de  Mon Dec 22 19:43:31 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 22 Dec 2008 20:43:31 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <200812221842.mBMIgiRi005792@laptop14.inf.utfsm.cl>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<gilugg$i5m$2@ger.gmane.org>
	<20081221174256.GA9876@shell.devel.redhat.com>
	<gino7d$o2f$1@ger.gmane.org>
	<20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<1229953809.24768.1365.camel@beck.corsepiu.local>
	<200812221842.mBMIgiRi005792@laptop14.inf.utfsm.cl>
Message-ID: <1229975011.24768.2223.camel@beck.corsepiu.local>

On Mon, 2008-12-22 at 15:42 -0300, Horst H. von Brand wrote:
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Mon, 2008-12-22 at 14:28 +0100, Emmanuel Seyman wrote:
> > > * Ralf Corsepius [22/12/2008 13:51] :
> > > >
> > > > Right, implementing a fork is the last resort, when an opensource
> > > > project's leadership doesn't want listen.
> > > 
> > > That's not true.
> > > 
> > > We've discussed this idea several times and, when people are told that
> > > they need to show there's a group of contributors to this project before
> > > infrastructure is dedicated to it, they don't fork the updates, they
> > > start whining and making up a whole bunch of excuses to justify not
> > > doing the work.
> > 
> > We are turning in circles - It's a hen and egg problem.
> 
> No...
... sssst ... bang ... a bullet ...

> > FESCo brushes off volunteers,
> 
> Haven't seen such.

> >                               the @RHs (here A.C) gun-down any
> > volunteers,
> 
> What I just saw was an _encouragement_ to go and just do it. That is not
> "gun down".
Well, to me these "just do it" read as "piss off, we (RH) are not
willing to support any such proposal".

> > Patrice already turned away from Fedora, I for one have significantly
> > cut down my involvement into Fedora and am considering to further cut it
> > down.
> 
> Sorry to hear that.
Yes. And ... rest assured, this mail of yours, as well as a similar
reply of yours in a preceding similar threat have further added to it.

Ralf




From sundaram at fedoraproject.org  Mon Dec 22 19:53:18 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 01:23:18 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FEB4C.8020501@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com>
Message-ID: <494FF02E.5060702@fedoraproject.org>

Les Mikesell wrote:

> The version where the RHEL cut happens would track whatever happens to 
> RHEL to the point that the update repos could be repointed to Centos 
> when it appears without breakage.  If it doesn't satisfy fedora 
> developers to build towards stability even through one version out of 3 
> or 4, fedora could just start it's next version early to absorb the new 
> untested stuff.

If I understand correctly, your idea is to base a longer update cycle of 
Fedora only on versions that Red Hat itself bases Red Hat Enterprise 
Linux on. However which release it is going to be, isn't known in 
advance since RHEL release schedules aren't known in advance.

Even if it is, RHEL is not always a snapshot of some Fedora release. 
Sometimes it is earlier than a release. There is also the case of Fedora 
updates moving past RHEL like FC6 updates did.

RHEL also makes a number of configuration changes and there are 
dependency differences between them as a result.  How do you account for 
all that differences in updates? Fedora includes about 5 times more 
software packages than RHEL. What about security updates for all those 
software that is in Fedora but not in RHEL ?  That gap continues to 
increase as well since the Fedora repository continues to grow at a 
rapid rate while RHEL repository size don't grow that much.

 > But the point is that whatever RHEL does, I wish the fedora release 
 >that spawned it would do the same

What the advantage of cloning the same thing twice?

Rahul



From jkeating at redhat.com  Mon Dec 22 19:56:20 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 11:56:20 -0800
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FF02E.5060702@fedoraproject.org>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com>  <494FF02E.5060702@fedoraproject.org>
Message-ID: <1229975780.3313.0.camel@localhost.localdomain>

On Tue, 2008-12-23 at 01:23 +0530, Rahul Sundaram wrote:
> 
> RHEL also makes a number of configuration changes and there are 
> dependency differences between them as a result.  How do you account for 
> all that differences in updates? Fedora includes about 5 times more 
> software packages than RHEL. What about security updates for all those 
> software that is in Fedora but not in RHEL ?  That gap continues to 
> increase as well since the Fedora repository continues to grow at a 
> rapid rate while RHEL repository size don't grow that much.

One such huge difference is the existence of mono or not.  Fedora has
mono, RHEL does not.  Lots of things do link against mono in Fedora, or
build mono subpackages, but don't in RHEL.  That's a whole can of worms
to get into when trying to do an update for something.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/0bb435f7/attachment.sig>

From rrankin at ihug.com.au  Mon Dec 22 20:34:02 2008
From: rrankin at ihug.com.au (Roy Rankin)
Date: Tue, 23 Dec 2008 07:34:02 +1100
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>	<20081222032535.GJ12325@inocybe.teonanacatl.org>	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>	<604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
	<e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>
Message-ID: <494FF9BA.5010506@ihug.com.au>


inode0 wrote:
> 
> The circle OS Developer conjures up is smaller than the group we are
> trying to describe, but there isn't very much to those descriptions so
> reading more than the big headings isn't asking very much from someone
> who is looking for ways to contribute.

As a relatively new package maintainer, I still have fairly fresh eyes. 
I find the term "OS Developer" miss-leading.

If I am scanning through documentation and I see a heading like "OS 
Developer" which seems to exclude my area of application developer, I 
will tend to skip reading the text(even if it is just 7 lines). However, 
if the title is slightly wider than what I am looking for, such as 
"Developer", then I would read the text to determine if this section is 
applicable to the area I am searching for.

Roy



From lesmikesell at gmail.com  Mon Dec 22 20:45:30 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 14:45:30 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FF02E.5060702@fedoraproject.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>
	<494FF02E.5060702@fedoraproject.org>
Message-ID: <494FFC6A.7040105@gmail.com>

Rahul Sundaram wrote:
>
>> The version where the RHEL cut happens would track whatever happens to 
>> RHEL to the point that the update repos could be repointed to Centos 
>> when it appears without breakage.  If it doesn't satisfy fedora 
>> developers to build towards stability even through one version out of 
>> 3 or 4, fedora could just start it's next version early to absorb the 
>> new untested stuff.
> 
> If I understand correctly, your idea is to base a longer update cycle of 
> Fedora only on versions that Red Hat itself bases Red Hat Enterprise 
> Linux on.

Yes, I think that is the only practical option since I don't foresee 
stability coming from fedora itself.  And realistically this is going to 
happen on the end users' computers that need stability anyway whether it 
is a planned and easy update or a harder wipe/re-install/re-configure. 
The difference being that a wipe/reinstall is also going to be a time to 
re-evaluate whether you care enough about the disto's sysadmin tools 
(that aren't serving you well since you have to start over) to stay on 
the same track or whether you want to jump to a different system that 
might be less trouble to deal with.

 > However which release it is going to be, isn't known in
> advance since RHEL release schedules aren't known in advance.
> 
> Even if it is, RHEL is not always a snapshot of some Fedora release. 

So far the surprises have been rare.

> Sometimes it is earlier than a release. There is also the case of Fedora 
> updates moving past RHEL like FC6 updates did.

That's something that could be fixed.  How hard is it to not update 
something?

> RHEL also makes a number of configuration changes and there are 
> dependency differences between them as a result.  How do you account for 
> all that differences in updates? Fedora includes about 5 times more 
> software packages than RHEL. What about security updates for all those 
> software that is in Fedora but not in RHEL ?  That gap continues to 
> increase as well since the Fedora repository continues to grow at a 
> rapid rate while RHEL repository size don't grow that much.

Aren't those mostly in EPEL?  Or, since we are talking about the next 
version, aren't they expected to be in EPEL?  Or should people not be 
using them when planning projects that will run on enterprise versions?

>  > But the point is that whatever RHEL does, I wish the fedora release 
>  >that spawned it would do the same
> 
> What the advantage of cloning the same thing twice?

There's no additional human effort in cloning.  What's the point of 
having software licenses that permit re-use if in fact you don't reuse 
it once you get it right?

-- 
    Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Mon Dec 22 20:50:13 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 14:50:13 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1229975780.3313.0.camel@localhost.localdomain>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>
	<494FF02E.5060702@fedoraproject.org>
	<1229975780.3313.0.camel@localhost.localdomain>
Message-ID: <494FFD85.5060904@gmail.com>

Jesse Keating wrote:
> On Tue, 2008-12-23 at 01:23 +0530, Rahul Sundaram wrote:
>> RHEL also makes a number of configuration changes and there are 
>> dependency differences between them as a result.  How do you account for 
>> all that differences in updates? Fedora includes about 5 times more 
>> software packages than RHEL. What about security updates for all those 
>> software that is in Fedora but not in RHEL ?  That gap continues to 
>> increase as well since the Fedora repository continues to grow at a 
>> rapid rate while RHEL repository size don't grow that much.
> 
> One such huge difference is the existence of mono or not.  Fedora has
> mono, RHEL does not.

Is that likely to continue to be the case for the next RHEL?

> Lots of things do link against mono in Fedora, or
> build mono subpackages, but don't in RHEL.  That's a whole can of worms
> to get into when trying to do an update for something.

I'd expect silverlight/moonlight to become something fairly essential 
within the life of the next enterprise release, especially if netflix 
streaming works on it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sundaram at fedoraproject.org  Mon Dec 22 21:02:39 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 02:32:39 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FFC6A.7040105@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>
	<494FFC6A.7040105@gmail.com>
Message-ID: <4950006F.6090808@fedoraproject.org>

Les Mikesell wrote:
> 
>  > However which release it is going to be, isn't known in
>> advance since RHEL release schedules aren't known in advance.
>>
>> Even if it is, RHEL is not always a snapshot of some Fedora release. 
> 
> So far the surprises have been rare.

That's not a real answer. Whether it is rare or not, is has occurred and 
you need to have a plan to deal with that.

>> Sometimes it is earlier than a release. There is also the case of 
>> Fedora updates moving past RHEL like FC6 updates did.
> 
> That's something that could be fixed.  How hard is it to not update 
> something?

Pretty hard actually. You can't stagnate a released distribution for 
obvious reasons. FC6 is released. It has to be updated to include 
security fixes, bug fixes ... RHEL 5 has branched off but it would take 
another six months (internal testing, alpha, beta, partner testing etc) 
  or so even before it is released. Remember, nobody in the Fedora world 
  know the exact schedule in advance so they can't plan for it.

>> RHEL also makes a number of configuration changes and there are 
>> dependency differences between them as a result.  How do you account 
>> for all that differences in updates? Fedora includes about 5 times 
>> more software packages than RHEL. What about security updates for all 
>> those software that is in Fedora but not in RHEL ?  That gap continues 
>> to increase as well since the Fedora repository continues to grow at a 
>> rapid rate while RHEL repository size don't grow that much.
> 
> Aren't those mostly in EPEL?  

You have completely ignored the point of configuration and dependency 
differences which means you can't just use the same stream of updates 
from RHEL in Fedora as you think you can.

Fedora and EPEL package count don't match at all. Go ahead and compare.

Or, since we are talking about the next
> version, aren't they expected to be in EPEL?  Or should people not be 
> using them when planning projects that will run on enterprise versions?

Fedora still has way more packages than RHEL + EPEL and since you have 
to find maintainers and the upstream versions might depend on newer 
versions of software only available in the latest Fedora (remember EPEL 
packages cannot conflict with what is available in base RHEL), some will 
not build for a earlier version available in RHEL and the problem gets 
progressively worse as more versions of Fedora get much ahead of RHEL.

>>  > But the point is that whatever RHEL does, I wish the fedora release 
>>  >that spawned it would do the same
>>
>> What the advantage of cloning the same thing twice?
> 
> There's no additional human effort in cloning.  What's the point of 
> having software licenses that permit re-use if in fact you don't reuse 
> it once you get it right?

That wasn't my question. My question is why not just use RHEL or CentOS 
if you just going to duplicate the same stream of updates for Fedora as 
well? It just seems busy work for no benefit.

Rahul



From jkeating at redhat.com  Mon Dec 22 21:25:04 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 13:25:04 -0800
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FFD85.5060904@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com> <494FF02E.5060702@fedoraproject.org>
	<1229975780.3313.0.camel@localhost.localdomain>
	<494FFD85.5060904@gmail.com>
Message-ID: <1229981104.3313.2.camel@localhost.localdomain>

On Mon, 2008-12-22 at 14:50 -0600, Les Mikesell wrote:
> Is that likely to continue to be the case for the next RHEL?

Yes, as far as I've seen.  Nothing has changed to lower the risk level
of mono.

> 
> > Lots of things do link against mono in Fedora, or
> > build mono subpackages, but don't in RHEL.  That's a whole can of worms
> > to get into when trying to do an update for something.
> 
> I'd expect silverlight/moonlight to become something fairly essential 
> within the life of the next enterprise release, especially if netflix 
> streaming works on it.

Given that silverlight/moonlight isn't even permissible in Fedora, there
is no way it'll wind up in RHEL.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/121c083d/attachment.sig>

From konrad at tylerc.org  Mon Dec 22 21:35:54 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 22 Dec 2008 13:35:54 -0800
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <20081220145752.GA12856@victor.nirvana>
References: <494A7A92.9020404@redhat.com>
	<1229619037.3472.26.camel@localhost.localdomain>
	<20081220145752.GA12856@victor.nirvana>
Message-ID: <200812221335.54257.konrad@tylerc.org>

On Saturday 20 December 2008 06:57:52 am Axel Thimm wrote:
> On Thu, Dec 18, 2008 at 11:50:37AM -0500, Tom spot Callaway wrote:
> > On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
> > > Wouldn't it be better to let rpm set _libdir/_lib to match noarch
> > > package requirements?
> >
> > What should it set it to? It has no knowledge of where the noarch rpm
> > package will eventually be installed. Should we assume that /usr/lib is
> > always correct (how Debian of me to even suggest this)?
>
> Isn't the norach equivalent of _libdir _datadir? Or phrased in another
> way: Shouldn't a noach package avoid both lib and lib64? I think we
> even have rules already set for this.
>
> I don't quite agree that rpm should start changing _libdir to point
> to _datadir, but the packagers should probably patch up the packages
> to use _datadir instead of _libdir if the package is indeed noarch.

All python noarch libraries go in /usr/lib.

-- 
Conrad Meyer <konrad at tylerc.org>




From kevin.kofler at chello.at  Mon Dec 22 21:35:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 22:35:59 +0100
Subject: Stability and Release Cycles - An Idea
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>
	<1229969962.3861.100.camel@localhost.localdomain>
Message-ID: <gip180$4o2$1@ger.gmane.org>

Jesse Keating wrote:
> Trying to do a ff update for F8 in 8 months time would be a real treat.

I'm pretty sure Remi Collet _will_ be doing Firefox updates for F8 8 months
from now, right now he's still building Firefox updates for FC4.

The secret there: just update it to the new version. Even RHEL 4 got updated
to Firefox 3. How to handle apps which are built against firefox-devel?
Remi just provides a firefox2 for those. It won't be ideal if Mozilla EOLs
Firefox 2 and nobody volunteers to backport security fixes, but at least
the browser can be updated. Alternatively, the apps could be rebuilt
against xulrunner, backporting the F9 packages where necessary. It could
even be decided on an app-by-app basis.

Now I think it's pretty pointless to provide updated Firefox builds for
Fedora releases which get no other updates, but it does prove that it's
possible.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec 22 21:40:21 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 22:40:21 +0100
Subject: Stability and Release Cycles - An Idea
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>
	<494FF02E.5060702@fedoraproject.org>
	<1229975780.3313.0.camel@localhost.localdomain>
	<494FFD85.5060904@gmail.com>
Message-ID: <gip1g5$4o2$2@ger.gmane.org>

Les Mikesell wrote:
> I'd expect silverlight/moonlight to become something fairly essential
> within the life of the next enterprise release, especially if netflix
> streaming works on it.

Silverlight/Moonlight isn't any more likely to appear in Fedora than MP3 is.
It's patent-encumbered, it cannot be included in Fedora.

        Kevin Kofler



From lesmikesell at gmail.com  Mon Dec 22 21:48:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 15:48:05 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <4950006F.6090808@fedoraproject.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>	<494FFC6A.7040105@gmail.com>
	<4950006F.6090808@fedoraproject.org>
Message-ID: <49500B15.60909@gmail.com>

Rahul Sundaram wrote:
> 
> That wasn't my question. My question is why not just use RHEL or CentOS 
> if you just going to duplicate the same stream of updates for Fedora as 
> well? It just seems busy work for no benefit.

That's precisely what I want to end up doing, but without the disruptive 
  need to re-install and figure out what all those differences you are 
describing as problems are.  And I'd rather not wait until the Centos 
release to start planning local development.  I suspect many others have 
a similar development cycle and need about as much time as fedora itself 
to arrive at something suitable for another long-term starting point.

So, the question is whether someone who understands all the internals 
can plan a clean transition path and do it once, or whether every end 
user that needs stability has to muddle through it separately.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From kevin.kofler at chello.at  Mon Dec 22 21:50:32 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 22:50:32 +0100
Subject: Stability and Release Cycles - An Idea
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>
	<494FFC6A.7040105@gmail.com> <4950006F.6090808@fedoraproject.org>
Message-ID: <gip23a$79o$1@ger.gmane.org>

Rahul Sundaram wrote:
> That wasn't my question. My question is why not just use RHEL or CentOS
> if you just going to duplicate the same stream of updates for Fedora as
> well? It just seems busy work for no benefit.

Les's idea is to be able to start with say (past example) FC2, then go to
FC3, FC4 and from there to CentOS 4, effectively starting with newer
software and gradually moving to the next CentOS release rather than being
stuck with (at the time) CentOS 3.

Now I don't think that idea is implementable in practice, at least not
without major changes to how both RHEL and Fedora are developed which I
don't think are ever going to happen. But it's the idea and I think Les
described it pretty clearly. I just disagree with it.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec 22 21:53:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 22:53:02 +0100
Subject: Stability and Release Cycles - An Idea
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com>
Message-ID: <gip27u$79o$2@ger.gmane.org>

Les Mikesell wrote:
> Personally, I think the correct approach is to replace such things with
> a rebuilt RHEL version where the fix will actually have some QA before
> dropping into users' laps, but...

We already explained dozens of times why that can't work, why do you have to
bring it up again and again? All you're going to get is more reasons why it
can't work, e.g. Jesse Keating's answers. The major changes to both RHEL
and Fedora which you're asking for are never going to happen.

        Kevin Kofler



From sundaram at fedoraproject.org  Mon Dec 22 21:58:51 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 03:28:51 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gip23a$79o$1@ger.gmane.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>	<494FFC6A.7040105@gmail.com>
	<4950006F.6090808@fedoraproject.org> <gip23a$79o$1@ger.gmane.org>
Message-ID: <49500D9B.2030409@fedoraproject.org>

Kevin Kofler wrote:
> Now I don't think that idea is implementable in practice, at least not
> without major changes to how both RHEL and Fedora are developed which I
> don't think are ever going to happen. But it's the idea and I think Les
> described it pretty clearly. I just disagree with it.

Right. Now I understand it better. A transition in between Fedora and 
EL, in a cycle. I don't think it is workable either. If RHEL was a 
strict subset of Fedora (the exact same binaries), even for a release, 
maybe. Currently it isn't and probably isn't feasible either considering 
how the development model works and the community (of contributors) in 
Fedora.

Rahul



From lesmikesell at gmail.com  Mon Dec 22 21:58:18 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 15:58:18 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gip1g5$4o2$2@ger.gmane.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>	<1229975780.3313.0.camel@localhost.localdomain>	<494FFD85.5060904@gmail.com>
	<gip1g5$4o2$2@ger.gmane.org>
Message-ID: <49500D7A.7030408@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> I'd expect silverlight/moonlight to become something fairly essential
>> within the life of the next enterprise release, especially if netflix
>> streaming works on it.
> 
> Silverlight/Moonlight isn't any more likely to appear in Fedora than MP3 is.
> It's patent-encumbered, it cannot be included in Fedora.

Fedora doesn't have to _include_ everything.  It just needs to provide 
working interfaces for 3rd party applications.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From konrad at tylerc.org  Mon Dec 22 21:59:34 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 22 Dec 2008 13:59:34 -0800
Subject: New font packaging guidelines
In-Reply-To: <1229789615.16655.28.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
Message-ID: <200812221359.34615.konrad@tylerc.org>

On Saturday 20 December 2008 08:13:35 am Nicolas Mailhot wrote:
> ...
> <Some list>:
> ? andika-fonts
> ...

What do spider webs have to do with enumerating a list?

-- 
Conrad Meyer <konrad at tylerc.org>





From gnomeuser at gmail.com  Mon Dec 22 21:55:23 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Mon, 22 Dec 2008 22:55:23 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gip1g5$4o2$2@ger.gmane.org>
References: <20081222132828.GB4934@orient.maison.lan>
	<494FD7E1.1040503@gmail.com> <494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com> <494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com> <494FF02E.5060702@fedoraproject.org>
	<1229975780.3313.0.camel@localhost.localdomain>
	<494FFD85.5060904@gmail.com> <gip1g5$4o2$2@ger.gmane.org>
Message-ID: <1dedbbfc0812221355k5032722bp80002dca45216f12@mail.gmail.com>

2008/12/22 Kevin Kofler <kevin.kofler at chello.at>

> Les Mikesell wrote:
> > I'd expect silverlight/moonlight to become something fairly essential
> > within the life of the next enterprise release, especially if netflix
> > streaming works on it.
>
> Silverlight/Moonlight isn't any more likely to appear in Fedora than MP3
> is.
> It's patent-encumbered, it cannot be included in Fedora.


I'll appriciate a list of the patents you believe are being infringed upon
on Moonlight.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/c28fc7ce/attachment.htm>

From kevin.kofler at chello.at  Mon Dec 22 21:57:26 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 22:57:26 +0100
Subject: Usage of {_libdir} or {_lib} in noarch packages
References: <494A7A92.9020404@redhat.com>
	<1229619037.3472.26.camel@localhost.localdomain>
	<20081220145752.GA12856@victor.nirvana>
	<200812221335.54257.konrad@tylerc.org>
Message-ID: <gip2g7$79o$3@ger.gmane.org>

Conrad Meyer wrote:
> All python noarch libraries go in /usr/lib.

Yes, and a few other interpreted languages do that too. That really ought to
be fixed, the sitelib (as opposed to sitearch) directories for interpreted
languages should be in /usr/share, not /usr/lib.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Dec 22 22:06:35 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 22 Dec 2008 23:06:35 +0100
Subject: Stability and Release Cycles - An Idea
References: <20081222132828.GB4934@orient.maison.lan>
	<494FD7E1.1040503@gmail.com> <494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com> <494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com> <494FF02E.5060702@fedoraproject.org>
	<1229975780.3313.0.camel@localhost.localdomain>
	<494FFD85.5060904@gmail.com> <gip1g5$4o2$2@ger.gmane.org>
	<1dedbbfc0812221355k5032722bp80002dca45216f12@mail.gmail.com>
Message-ID: <gip31b$79o$4@ger.gmane.org>

David Nielsen wrote:
> I'll appriciate a list of the patents you believe are being infringed upon
> on Moonlight.

Ask those who make the decision. As they say: don't shoot the messenger!

        Kevin Kofler



From lesmikesell at gmail.com  Mon Dec 22 22:07:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 16:07:51 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gip23a$79o$1@ger.gmane.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>	<494FFC6A.7040105@gmail.com>
	<4950006F.6090808@fedoraproject.org> <gip23a$79o$1@ger.gmane.org>
Message-ID: <49500FB7.7000602@gmail.com>

Kevin Kofler wrote:
> 
> Now I don't think that idea is implementable in practice, at least not
> without major changes to how both RHEL and Fedora are developed which I
> don't think are ever going to happen. But it's the idea and I think Les
> described it pretty clearly. I just disagree with it.

What is your optimal plan for someone to have local applications 
prepared and ready to take advantages of all the new developments in 
RHEL6 the day it is released?

The strategy I'm talking about is pretty much the way things worked 
before the RHEL/fedora split where RH X.0 and X.1 were equivalent to 
fedora versions with X.2 aging to stability, bringing with it the 
involvement of the community that worked through the development 
problems and tested their applications against the changes as they were 
made.

-- 
    Les Mikesell
     lesmikesell at gmail.com





From sundaram at fedoraproject.org  Mon Dec 22 22:07:54 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 03:37:54 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <49500D7A.7030408@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>	<1229975780.3313.0.camel@localhost.localdomain>	<494FFD85.5060904@gmail.com>	<gip1g5$4o2$2@ger.gmane.org>
	<49500D7A.7030408@gmail.com>
Message-ID: <49500FBA.6070708@fedoraproject.org>

Les Mikesell wrote:
> Kevin Kofler wrote:
>> Les Mikesell wrote:
>>> I'd expect silverlight/moonlight to become something fairly essential
>>> within the life of the next enterprise release, especially if netflix
>>> streaming works on it.
>>
>> Silverlight/Moonlight isn't any more likely to appear in Fedora than 
>> MP3 is.
>> It's patent-encumbered, it cannot be included in Fedora.
> 
> Fedora doesn't have to _include_ everything.  It just needs to provide 
> working interfaces for 3rd party applications.

You don't need "interfaces" in this case.  Download and run it from a 
Novell site since that's the only "legally safe" option according to

http://www.groklaw.net/article.php?story=20080528133529454

"It only covers 'direct' recipients from Novell, not 'indirect', which 
would likely exclude those who receive it directly from anyone other 
than Novell unless that third party is an 'authorized reseller'."

Rahul



From lesmikesell at gmail.com  Mon Dec 22 22:10:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 16:10:23 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gip27u$79o$2@ger.gmane.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>
	<gip27u$79o$2@ger.gmane.org>
Message-ID: <4950104F.5030904@gmail.com>

Kevin Kofler wrote:
> Les Mikesell wrote:
>> Personally, I think the correct approach is to replace such things with
>> a rebuilt RHEL version where the fix will actually have some QA before
>> dropping into users' laps, but...
> 
> We already explained dozens of times why that can't work, why do you have to
> bring it up again and again? All you're going to get is more reasons why it
> can't work, e.g. Jesse Keating's answers. The major changes to both RHEL
> and Fedora which you're asking for are never going to happen.

I bring it up again because it is the only hope I have of fedora being 
something that I'd have any use to run.  If it isn't clearly the track 
towards the next RHEL/Centos, what's the point?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sundaram at fedoraproject.org  Mon Dec 22 22:16:29 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 03:46:29 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <4950104F.5030904@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<gip27u$79o$2@ger.gmane.org>
	<4950104F.5030904@gmail.com>
Message-ID: <495011BD.9090208@fedoraproject.org>

Les Mikesell wrote:
> Kevin Kofler wrote:
>> Les Mikesell wrote:
>>> Personally, I think the correct approach is to replace such things with
>>> a rebuilt RHEL version where the fix will actually have some QA before
>>> dropping into users' laps, but...
>>
>> We already explained dozens of times why that can't work, why do you 
>> have to
>> bring it up again and again? All you're going to get is more reasons 
>> why it
>> can't work, e.g. Jesse Keating's answers. The major changes to both RHEL
>> and Fedora which you're asking for are never going to happen.
> 
> I bring it up again because it is the only hope I have of fedora being 
> something that I'd have any use to run.  If it isn't clearly the track 
> towards the next RHEL/Centos, what's the point?

People have pretty patient with you. It isn't that hard to realize that 
different people have different requirements. It is just easier to 
accept that, Fedora isn't suitable for your requirements and it is 
indeed suitable for those many, who are already using it and 
contributing to it for whatever reasons (many of which have nothing to 
EL) and move on. Your points are becoming very repetitive and doesn't 
accomplish anything new at all.

Rahul



From sundaram at fedoraproject.org  Mon Dec 22 22:17:55 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 03:47:55 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <49500FB7.7000602@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>	<494FFC6A.7040105@gmail.com>	<4950006F.6090808@fedoraproject.org>
	<gip23a$79o$1@ger.gmane.org> <49500FB7.7000602@gmail.com>
Message-ID: <49501213.2040102@fedoraproject.org>

Les Mikesell wrote:
> Kevin Kofler wrote:
>>
>> Now I don't think that idea is implementable in practice, at least not
>> without major changes to how both RHEL and Fedora are developed which I
>> don't think are ever going to happen. But it's the idea and I think Les
>> described it pretty clearly. I just disagree with it.
> 
> What is your optimal plan for someone to have local applications 
> prepared and ready to take advantages of all the new developments in 
> RHEL6 the day it is released?

This is really offtopic for this list and you should take it to a RHEL 
list instead but many do participate in Fedora and move on to RHEL beta 
releases and then to the GA release.  Take up further questions on EL to 
EL specific mailing lists. Thanks.

Rahul



From jkeating at redhat.com  Mon Dec 22 22:28:45 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 14:28:45 -0800
Subject: New font packaging guidelines
In-Reply-To: <200812221359.34615.konrad@tylerc.org>
References: <1229789615.16655.28.camel@arekh.okg>
	<200812221359.34615.konrad@tylerc.org>
Message-ID: <1229984925.3313.6.camel@localhost.localdomain>

On Mon, 2008-12-22 at 13:59 -0800, Conrad Meyer wrote:
> On Saturday 20 December 2008 08:13:35 am Nicolas Mailhot wrote:
> > ...
> > <Some list>:
> > ? andika-fonts
> > ...
> 
> What do spider webs have to do with enumerating a list?
> 
> -- 
> Conrad Meyer <konrad at tylerc.org>
> 
> 

I thought they were snowflakes.  Terrible inappropriate for our southern
hemisphere folks.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/f1226508/attachment.sig>

From markg85 at gmail.com  Mon Dec 22 22:28:44 2008
From: markg85 at gmail.com (Mark)
Date: Mon, 22 Dec 2008 23:28:44 +0100
Subject: [Usability] Call for vote: Nautilus use Browser view for fedora
	11
In-Reply-To: <cb822e20812221302k73a68f33ja00e78c1afda908@mail.gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<6e24a8e80812201050j2f2126b4x4472606058b2c6e@mail.gmail.com>
	<494D4C6B.7090604@gmail.com>
	<6e24a8e80812201156m3cea135fv29a8a9763b9508c@mail.gmail.com>
	<cb822e20812221302k73a68f33ja00e78c1afda908@mail.gmail.com>
Message-ID: <6e24a8e80812221428y7f8a0c0me4dfd671723536c4@mail.gmail.com>

On Mon, Dec 22, 2008 at 10:02 PM, Natan Yellin <aantny at gmail.com> wrote:
>
>
> On Sat, Dec 20, 2008 at 9:56 PM, Mark <markg85 at gmail.com> wrote:
>>
>> On Sat, Dec 20, 2008 at 8:50 PM, Les Mikesell <lesmikesell at gmail.com>
>> wrote:
>> > Mark wrote:
>> >>>
>> >> To all other ppl. please keep the usability list included since this
>> >> really is something they should be aware of.
>> >>
>> >
>> > Keep in mind that cross-posting to multiple lists sucks for everyone who
>> > is
>> > not a member of all of them because they'll get bounces pointing that
>> > out,
>> > and there's a fair chance that they won't get moderator approval and
>> > ever
>> > appear.
>>
>> True. and they are apparently afraid that my idea gets through because
>> i have been put on moderation.
>> feel free to do whatever you think is right. at this moment i'm sick of
>> gnome.
>
> As far as I can tell, you're disappointed with the way that the Fedora
> community has responded to your opinion. Instead of trying to create a fight
> or drag this issue upstream, why don't you just use another distribution?

Why did you mailed this to me only and not the lists.
O well, i said it in this thread but you probably didn't read it. I
don't blame you.. there are about 250 messages in this thread ^_^

To the subject. I said that i did find ubuntu better then fedora and
that i did use it but i prefer the RPM system and in those
distributions i like fedora the most. My top 2 list is:
1. Fedora
2. Ubuntu

And i keep swapping between those 2. Right now i need fedora because
of a development project and i'm more familiar with rpm then i am with
debs. specially on repairing an RPM issue. repairing a deb issue is a
lot more painful. That's why i use fedora and that's why i don't
switch to another os (for now). I also find rpm to be more flexible to
use then deb but that might be because i didn't do much deb devel
stuff and did rpm devel stuff (rebuilding and making rpms/debs).

The best case for me would be a ubuntu using the rpm structure instead of deb.

btw. lets NOT start flaming about the advantages and disadvantages of
rpm vs deb. i'm well aware of those!

So that's why.



From philipp_subx at redfish-solutions.com  Mon Dec 22 22:28:32 2008
From: philipp_subx at redfish-solutions.com (Philip A. Prindeville)
Date: Mon, 22 Dec 2008 14:28:32 -0800
Subject: FC9, "missing syscalls" kernel target,
 and Promise Fasttrak TX4650 controller
In-Reply-To: <6d06ce20812211924x69094475ue8bb37446c37a107@mail.gmail.com>
References: <494EF670.9040400@redfish-solutions.com>	<6d06ce20812211852t12694524v6e0a3b4379ca373f@mail.gmail.com>
	<6d06ce20812211924x69094475ue8bb37446c37a107@mail.gmail.com>
Message-ID: <49501490.70506@redfish-solutions.com>

Jerry Amundson wrote:
> On 12/21/08, Jerry Amundson <jamundso at gmail.com> wrote:
>   
>> On 12/21/08, Philip A. Prindeville <philipp_subx at redfish-solutions.com>
>> wrote:
>>     
>>> I was going to build an RPM for the modules for the Promise FastTrak
>>> TX4650 PCI-e RAID controller for FC9.
>>>
>>> Their support website claims it's supported "in-box" in FC9, but it
>>> turns out that's not true:
>>>
>>> $ lspci -v -s 02:00.0
>>> 02:00.0 RAID bus controller: Promise Technology, Inc. Unknown device 3f20
>>> 	Subsystem: Promise Technology, Inc. Unknown device 3f22
>>> 	Flags: bus master, fast devsel, latency 0, IRQ 10
>>> 	I/O ports at dc00 [size=128]
>>> 	I/O ports at d800 [size=256]
>>> 	Memory at fbeff000 (32-bit, non-prefetchable) [size=4K]
>>> 	Memory at fbec0000 (32-bit, non-prefetchable) [size=128K]
>>> 	Memory at fbefc000 (32-bit, non-prefetchable) [size=8K]
>>> 	Expansion ROM at fbe80000 [disabled] [size=256K]
>>> 	Capabilities: [50] Power Management version 2
>>> 	Capabilities: [70] Express Legacy Endpoint, MSI 00
>>> 	Capabilities: [94] SATA HBA <?>
>>> 	Capabilities: [100] Advanced Error Reporting <?>
>>> 	Capabilities: [140] Virtual Channel <?>
>>> 	Capabilities: [160] Device Serial Number 01-00-00-00-02-00-00-00
>>> 	Capabilities: [170] Power Budgeting <?>
>>>
>>>
>>> so...  I downloaded their drivers from their website:
>>>
>>> http://www.promise.com/upload/Support/Driver/FT%20TX4650-2650%20Linux%20Kernl%202.6%20PSC%20v1.1.0.12.tgz
>>>
>>> (Yes, I realize it will taint my kernel... and it doesn't include all of
>>> the
>>> source.)
>>>
>>> I tried to build it, but getting into the kernel directory:
>>>       
>> Don't start there. Start with the README of the source you downloaded.
>>     
>
> And it looks like you'll some code fixing to get it to compile...
> http://www.colinmackenzie.net/index.php?option=com_content&view=article&id=12:promise-satasas-driver-update-tx4650tx2650&catid=8:rotator&Itemid=7
>
> jerry
>
>   

I saw the more recent postings...

My understanding is that the TX4650 has the RAID-5 XOR ASICs to 
accelerate the reed-solomon code calculations... hence my wanting to use 
this driver.

I picked up the patches that you pointed me at (including "The Czar's", 
which was necessary to compile on 2.6.25 and subsequent)...

Then I looked at:

http://fedoraproject.org/wiki/Docs/CustomKernel?highlight=#Building_Only_Kernel_Modules


but had some questions about that.

The example is a little thin.  It doesn't explain what to do if you need 
to pass in extra C flags, extra include directories, or if your driver 
has several subdirectories that need to be compiled and linked together 
(or if it is a partial-source release, and has canned object files that 
also need to be linked in).

Anyone have a real-life example that they can point me at that does this?

Thanks,

-Philip




From jkeating at redhat.com  Mon Dec 22 22:30:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 14:30:06 -0800
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gip180$4o2$1@ger.gmane.org>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>
	<1229969962.3861.100.camel@localhost.localdomain>
	<gip180$4o2$1@ger.gmane.org>
Message-ID: <1229985006.3313.7.camel@localhost.localdomain>

On Mon, 2008-12-22 at 22:35 +0100, Kevin Kofler wrote:
> 
> I'm pretty sure Remi Collet _will_ be doing Firefox updates for F8 8 months
> from now, right now he's still building Firefox updates for FC4.
> 
> The secret there: just update it to the new version. Even RHEL 4 got updated
> to Firefox 3. How to handle apps which are built against firefox-devel?
> Remi just provides a firefox2 for those. It won't be ideal if Mozilla EOLs
> Firefox 2 and nobody volunteers to backport security fixes, but at least
> the browser can be updated. Alternatively, the apps could be rebuilt
> against xulrunner, backporting the F9 packages where necessary. It could
> even be decided on an app-by-app basis.
> 
> Now I think it's pretty pointless to provide updated Firefox builds for
> Fedora releases which get no other updates, but it does prove that it's
> possible.
> 

Will Remmi be building the 20 some odd other packages that will then
break when gecko library path changes?  What about the packages in 3rd
party repos that also depend on a gecko library path?  What if these
packages don't work with the new gecko?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/478fcfc0/attachment.sig>

From jkeating at redhat.com  Mon Dec 22 22:33:55 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 14:33:55 -0800
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <1dedbbfc0812221355k5032722bp80002dca45216f12@mail.gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>
	<494FD7E1.1040503@gmail.com> <494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com> <494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com> <494FF02E.5060702@fedoraproject.org>
	<1229975780.3313.0.camel@localhost.localdomain>
	<494FFD85.5060904@gmail.com> <gip1g5$4o2$2@ger.gmane.org>
	<1dedbbfc0812221355k5032722bp80002dca45216f12@mail.gmail.com>
Message-ID: <1229985235.3313.8.camel@localhost.localdomain>

On Mon, 2008-12-22 at 22:55 +0100, David Nielsen wrote:
> 
> I'll appriciate a list of the patents you believe are being infringed upon
> on Moonlight.

Ask Microsoft, as they're promising not to sue Novell or people who get
moonlight from Novell over those patents.

http://www.groklaw.net/article.php?story=20080528133529454

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/9e58c66a/attachment.sig>

From jkeating at redhat.com  Mon Dec 22 22:37:15 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Dec 2008 14:37:15 -0800
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <49500FB7.7000602@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>
	<494FFC6A.7040105@gmail.com> <4950006F.6090808@fedoraproject.org>
	<gip23a$79o$1@ger.gmane.org>  <49500FB7.7000602@gmail.com>
Message-ID: <1229985435.3313.10.camel@localhost.localdomain>

On Mon, 2008-12-22 at 16:07 -0600, Les Mikesell wrote:
> 
> What is your optimal plan for someone to have local applications 
> prepared and ready to take advantages of all the new developments in 
> RHEL6 the day it is released?

The likely strategy for RHEL6 would be:

Participate and consume F10, F11, and F12

Participate and consume RHEL6 Alphas and Betas (which may fall somewhere
between F11 and F12)

Be ready to go when RHEL6 arrives.  Basically once Alphas of RHEL start
showing up, jump off the Fedora train and get on the RHEL train.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/22c62800/attachment.sig>

From lesmikesell at gmail.com  Mon Dec 22 22:51:54 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Dec 2008 16:51:54 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <49501213.2040102@fedoraproject.org>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>	<494FFC6A.7040105@gmail.com>	<4950006F.6090808@fedoraproject.org>	<gip23a$79o$1@ger.gmane.org>
	<49500FB7.7000602@gmail.com> <49501213.2040102@fedoraproject.org>
Message-ID: <49501A0A.8050307@gmail.com>

Rahul Sundaram wrote:
> 
>> What is your optimal plan for someone to have local applications 
>> prepared and ready to take advantages of all the new developments in 
>> RHEL6 the day it is released?
> 
> This is really offtopic for this list and you should take it to a RHEL 
> list instead but many do participate in Fedora and move on to RHEL beta 
> releases and then to the GA release. 

It is only offtopic if fedora is never intended to be used by people 
planning to move their work to RHEL and clones when the corresponding 
release appears.  If that is a planned use case, then the discussion 
belongs here.

> Take up further questions on EL to 
> EL specific mailing lists. Thanks.

That doesn't make any sense.  How can EL know how/why to deal with 
fedora, or know anything about transitioning to a version that doesn't 
exist yet?

-- 
   Les Mikesell
    lesmikesell at gmail.com




From sundaram at fedoraproject.org  Mon Dec 22 23:02:41 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 04:32:41 +0530
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <49501A0A.8050307@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>	<494FA255.3060309@nobugconsulting.ro>	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>	<20081222172622.GA13156@shell.devel.redhat.com>	<494FD0CC.5090109@gmail.com>	<494FD3DB.9090501@fedoraproject.org>	<494FD7E1.1040503@gmail.com>	<494FDA8C.3020207@fedoraproject.org>	<494FE34B.1000906@gmail.com>	<494FE4A2.5050604@fedoraproject.org>	<494FEB4C.8020501@gmail.com>	<494FF02E.5060702@fedoraproject.org>	<494FFC6A.7040105@gmail.com>	<4950006F.6090808@fedoraproject.org>	<gip23a$79o$1@ger.gmane.org>	<49500FB7.7000602@gmail.com>
	<49501213.2040102@fedoraproject.org> <49501A0A.8050307@gmail.com>
Message-ID: <49501C91.9050702@fedoraproject.org>

Les Mikesell wrote:
> Rahul Sundaram wrote:
>>
>>> What is your optimal plan for someone to have local applications 
>>> prepared and ready to take advantages of all the new developments in 
>>> RHEL6 the day it is released?
>>
>> This is really offtopic for this list and you should take it to a RHEL 
>> list instead but many do participate in Fedora and move on to RHEL 
>> beta releases and then to the GA release. 
> 
> It is only offtopic if fedora is never intended to be used by people 
> planning to move their work to RHEL and clones when the corresponding 
> release appears.  If that is a planned use case, then the discussion 
> belongs here.

No. It doesn't. This is a Fedora specific development list.

>> Take up further questions on EL to EL specific mailing lists. Thanks.
> 
> That doesn't make any sense.  How can EL know how/why to deal with 
> fedora, or know anything about transitioning to a version that doesn't 
> exist yet?

You have subtly now changed your question but it is still offtopic in a 
Fedora development mailing list. Anyway your question has been answered 
by myself and Jesse Keating already. So no more EL specific questions 
here. Take it elsewhere.

Rahul



From nicolas.mailhot at laposte.net  Mon Dec 22 23:10:14 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Dec 2008 00:10:14 +0100
Subject: New font packaging guidelines
In-Reply-To: <1229984925.3313.6.camel@localhost.localdomain>
References: <1229789615.16655.28.camel@arekh.okg>
	<200812221359.34615.konrad@tylerc.org>
	<1229984925.3313.6.camel@localhost.localdomain>
Message-ID: <1229987414.31248.0.camel@arekh.okg>

Le lundi 22 d?cembre 2008 ? 14:28 -0800, Jesse Keating a ?crit :

> I thought they were snowflakes.  Terrible inappropriate for our southern
> hemisphere folks.

I'll remember to insert a some suns next time :)

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/6d868da3/attachment.sig>

From mw_triad at users.sourceforge.net  Mon Dec 22 23:27:47 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 22 Dec 2008 17:27:47 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>	<20081222032535.GJ12325@inocybe.teonanacatl.org>	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>	<604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
	<e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>
Message-ID: <gip7pj$j9l$2@ger.gmane.org>

inode0 wrote:
> On Sun, Dec 21, 2008 at 10:35 PM, Jeff Spaleta wrote:
>> All I am asking is to provide us with some more specific feedback on
>> how to rename the role that is currently titled OS Developer.  Its not
>> enough to know that your confused by the current title. We need to
>> know what would make sense to you as an alternative.
> 
> The obvious thing to consider is simply dropping OS from the heading
> but either way if the user isn't willing to read the following 7 lines
> they aren't going to know what that means either.

+1. And I think Roy was +1'ing it also.

My first thought was "Software Developer", but reading the description, 
"Software Developer" sounds to me more specific to writing code (i.e. 
not doc work)...

That said, I'd still prefer "Software Developer" over "OS Developer". I 
just prefer plain "Developer" to both.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
This message represents the official view of the voices in my head.
   -- Unknown
(found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)



From poelstra at redhat.com  Mon Dec 22 23:30:01 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 22 Dec 2008 15:30:01 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-12-22 
Message-ID: <495022F9.9040706@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-dec-22

== Summary ==
* see IRC log

== IRC Transcript ==



From jspaleta at gmail.com  Mon Dec 22 23:47:58 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 22 Dec 2008 14:47:58 -0900
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <gip7pj$j9l$2@ger.gmane.org>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
	<604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
	<e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>
	<gip7pj$j9l$2@ger.gmane.org>
Message-ID: <604aa7910812221547g1ad8ee9eo2aa62c70a7041911@mail.gmail.com>

On Mon, Dec 22, 2008 at 2:27 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> My first thought was "Software Developer", but reading the description,
> "Software Developer" sounds to me more specific to writing code (i.e. not
> doc work)...

Indeed... the attempt was to build a role definition that encompasses
the work necessary to put the bits out the door as a major endeavor.
Packaging is a big part of that. Triage is a big part of that. And so
is documentation writing.    The description linked to from the role
title I think holds together. But the role title may not 'sell' the
description as well as another title could.


-jef



From philipp_subx at redfish-solutions.com  Tue Dec 23 00:02:17 2008
From: philipp_subx at redfish-solutions.com (Philip A. Prindeville)
Date: Mon, 22 Dec 2008 16:02:17 -0800
Subject: Wiki section "Building Only Kernel Modules" incomplete (was: FC9,
 "missing syscalls" kernel target, and Promise Fasttrak TX4650 controller)
In-Reply-To: <49501490.70506@redfish-solutions.com>
References: <494EF670.9040400@redfish-solutions.com>	<6d06ce20812211852t12694524v6e0a3b4379ca373f@mail.gmail.com>	<6d06ce20812211924x69094475ue8bb37446c37a107@mail.gmail.com>
	<49501490.70506@redfish-solutions.com>
Message-ID: <49502A89.8000805@redfish-solutions.com>

Ok, so the below thread has changed tracks...  I started looking at:

http://fedoraproject.org/wiki/Docs/CustomKernel?highlight=#Building_Only_Kernel_Modules


And saw, "*This section needs to be updated and fleshed out".  Yes, 
indeed.  I'm trying to go by this section, but it's a little thin.

Who owns it?  I'd like to work with them on figuring out what needs to 
be added to make it useful.

Thanks,

-Philip

==== Original thread below ====

*Philip A. Prindeville wrote:
> Jerry Amundson wrote:
>> On 12/21/08, Jerry Amundson <jamundso at gmail.com> wrote:
>>  
>>> On 12/21/08, Philip A. Prindeville <philipp_subx at redfish-solutions.com>
>>> wrote:
>>>    
>>>> I was going to build an RPM for the modules for the Promise FastTrak
>>>> TX4650 PCI-e RAID controller for FC9.
>>>>
>>>> Their support website claims it's supported "in-box" in FC9, but it
>>>> turns out that's not true:
>>>>
>>>> $ lspci -v -s 02:00.0
>>>> 02:00.0 RAID bus controller: Promise Technology, Inc. Unknown 
>>>> device 3f20
>>>>     Subsystem: Promise Technology, Inc. Unknown device 3f22
>>>>     Flags: bus master, fast devsel, latency 0, IRQ 10
>>>>     I/O ports at dc00 [size=128]
>>>>     I/O ports at d800 [size=256]
>>>>     Memory at fbeff000 (32-bit, non-prefetchable) [size=4K]
>>>>     Memory at fbec0000 (32-bit, non-prefetchable) [size=128K]
>>>>     Memory at fbefc000 (32-bit, non-prefetchable) [size=8K]
>>>>     Expansion ROM at fbe80000 [disabled] [size=256K]
>>>>     Capabilities: [50] Power Management version 2
>>>>     Capabilities: [70] Express Legacy Endpoint, MSI 00
>>>>     Capabilities: [94] SATA HBA <?>
>>>>     Capabilities: [100] Advanced Error Reporting <?>
>>>>     Capabilities: [140] Virtual Channel <?>
>>>>     Capabilities: [160] Device Serial Number 01-00-00-00-02-00-00-00
>>>>     Capabilities: [170] Power Budgeting <?>
>>>>
>>>>
>>>> so...  I downloaded their drivers from their website:
>>>>
>>>> http://www.promise.com/upload/Support/Driver/FT%20TX4650-2650%20Linux%20Kernl%202.6%20PSC%20v1.1.0.12.tgz 
>>>>
>>>>
>>>> (Yes, I realize it will taint my kernel... and it doesn't include 
>>>> all of
>>>> the
>>>> source.)
>>>>
>>>> I tried to build it, but getting into the kernel directory:
>>>>       
>>> Don't start there. Start with the README of the source you downloaded.
>>>     
>>
>> And it looks like you'll some code fixing to get it to compile...
>> http://www.colinmackenzie.net/index.php?option=com_content&view=article&id=12:promise-satasas-driver-update-tx4650tx2650&catid=8:rotator&Itemid=7 
>>
>>
>> jerry
>>
>>   
>
> I saw the more recent postings...
>
> My understanding is that the TX4650 has the RAID-5 XOR ASICs to 
> accelerate the reed-solomon code calculations... hence my wanting to 
> use this driver.
>
> I picked up the patches that you pointed me at (including "The 
> Czar's", which was necessary to compile on 2.6.25 and subsequent)...
>
> Then I looked at:
>
> http://fedoraproject.org/wiki/Docs/CustomKernel?highlight=#Building_Only_Kernel_Modules 
>
>
>
> but had some questions about that.
>
> The example is a little thin.  It doesn't explain what to do if you 
> need to pass in extra C flags, extra include directories, or if your 
> driver has several subdirectories that need to be compiled and linked 
> together (or if it is a partial-source release, and has canned object 
> files that also need to be linked in).
>
> Anyone have a real-life example that they can point me at that does this?
>
> Thanks,
>
> -Philip
>
>



From jspaleta at gmail.com  Tue Dec 23 00:27:31 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 22 Dec 2008 15:27:31 -0900
Subject: Encrypted home directory
In-Reply-To: <1dedbbfc0812211235p7dfbc5aey9a8589d80100282b@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<1dedbbfc0812211235p7dfbc5aey9a8589d80100282b@mail.gmail.com>
Message-ID: <604aa7910812221627s5f536750mdffafbe1face771c@mail.gmail.com>

2008/12/21 David Nielsen <gnomeuser at gmail.com>:
> /home is seperate on all my boxes, so yes that solution would work. I do
> believe Ubuntu' solution is a seperate partition they map to a folder called
> Private in your home dir which is unlocked at login.

I dont think its a seperate partition, it was just a separate
encrypted directory.  It works very much like the fuse based stuff,
except its kernel space not userspace so it _may_ have a performance
boost by being in the kernel.  But that comes with a cost compared to
the fuse stuff in that userspace manipulation of the mount process is
now marginally harder.  Personally I'd much rather see a robust way to
interact with a fuse based filesystems generally in the Gnome UI than
to see a lot of effort to integrate this one kernel based approach
just for encryption.

The way it was implemented in Ubuntu server takes additional wrapper
logic to manipulate the mount process of the Private directory, and
from my reading all of that logic was driven into ecrypt-utils helper
applications...i think. The original Private directory feature as
introduced in Ubuntu was specific to their server edition and was not
turned on by default on the desktop edition specifically because of
common desktop case integration concerns.  There was a patch added to
Ubuntu to gnome-mount to hide these mountpoints from the UI.

The extension to an encrypted home is meant to address some of the
short comings of the pam based approach so normal desktop users can
use it without it being confusing. A fully encrypted home would never
expected to be unmounted while the person was logged in.  And it
significantly uncomplicates the problem of trying to use a Private
directory for files that applications expect to be in a certain
location in your home directory.

I also think Ubuntu is creating some glue scripts to help people who
upgrade transition from a non-encrypted home to an encrypted home as a
one-time transition.  And integrating an option in user creation ui.

> I have no idea of the
> security of that solution but it does seem that this way one could keep a
> few files secret while the machine is powered down so if it gets lost in the
> airport e.g. those few precious personal files don't fall into the wrong
> hands.

A private directory on a single user machine, the security is fine,
unless Ubuntu is caching the passphrase in your home directory
somewhere to enable login time mounting without having to use a
different passphrase from your login passphrase...that would be
security theater.  I'd have to look more closely at the scripted logic
to know if they are doing some sort of cached credentials in an
un-encrypted file.  I'm pretty sure this is NOT tied into the
gnome-keyring at all yet.

The private directory idea was not introduced as a target for that
sort of machine. The private directory feature was targeted as a
Server edition feature. Security on a multi-user machine...since the
files become viewable once the decrypted mountpoint is active, its no
more secure than any other mountpoint and relies on standard unix
permissions to keep people out.  So as a server feature, its security
theater to some extent.  And even on a single user machine with guest
account enabled fast user switching, like Ubuntu, security may easily
be compromised. If the decrypted private directory is not unmounted
when I guest user takes over the console, they have just as much
access to that mount point as if it were an un-encrypted directory.
There was some discussion i think about using apparmor support for
additional protection but I don't know if its in place yet.

-jef



From jamundso at gmail.com  Tue Dec 23 00:32:37 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Mon, 22 Dec 2008 18:32:37 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <604aa7910812221547g1ad8ee9eo2aa62c70a7041911@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
	<604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
	<e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>
	<gip7pj$j9l$2@ger.gmane.org>
	<604aa7910812221547g1ad8ee9eo2aa62c70a7041911@mail.gmail.com>
Message-ID: <6d06ce20812221632s1fef96b2r2e9250ab4e595e2f@mail.gmail.com>

On 12/22/08, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Mon, Dec 22, 2008 at 2:27 PM, Matthew Woehlke
> <mw_triad at users.sourceforge.net> wrote:
>> My first thought was "Software Developer", but reading the description,
>> "Software Developer" sounds to me more specific to writing code (i.e. not
>> doc work)...
>
> Indeed... the attempt was to build a role definition that encompasses
> the work necessary to put the bits out the door as a major endeavor.
> Packaging is a big part of that. Triage is a big part of that. And so
> is documentation writing.    The description linked to from the role
> title I think holds together. But the role title may not 'sell' the
> description as well as another title could.

Just brainstorming here. Software Analyst?
As you mention, many things are part of it, yet it's not entirely
Packaging, nor all Triage, and most of the time not much OS either...

jerry

-- 
To be named later.



From mw_triad at users.sourceforge.net  Tue Dec 23 00:34:57 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 22 Dec 2008 18:34:57 -0600
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <604aa7910812221547g1ad8ee9eo2aa62c70a7041911@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>	<20081222032535.GJ12325@inocybe.teonanacatl.org>	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>	<604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>	<e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>	<gip7pj$j9l$2@ger.gmane.org>
	<604aa7910812221547g1ad8ee9eo2aa62c70a7041911@mail.gmail.com>
Message-ID: <gipbnh$1ml$1@ger.gmane.org>

Jeff Spaleta wrote:
> On Mon, Dec 22, 2008 at 2:27 PM, Matthew Woehlke
> <mw_triad at too,much.spam> wrote:
/me coughs
>> My first thought was "Software Developer", but reading the description,
>> "Software Developer" sounds to me more specific to writing code (i.e. not
>> doc work)...
> 
> Indeed... the attempt was to build a role definition that encompasses
> the work necessary to put the bits out the door as a major endeavor.
> Packaging is a big part of that. Triage is a big part of that. And so
> is documentation writing.    The description linked to from the role
> title I think holds together. But the role title may not 'sell' the
> description as well as another title could.

What about "Development and Support"? Except it's not a noun...

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
This message represents the official view of the voices in my head.
   -- Unknown
(found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)



From ivazqueznet at gmail.com  Tue Dec 23 00:49:02 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 22 Dec 2008 19:49:02 -0500
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <gip2g7$79o$3@ger.gmane.org>
References: <494A7A92.9020404@redhat.com>
	<1229619037.3472.26.camel@localhost.localdomain>
	<20081220145752.GA12856@victor.nirvana>
	<200812221335.54257.konrad@tylerc.org>  <gip2g7$79o$3@ger.gmane.org>
Message-ID: <1229993342.17128.45.camel@ignacio.lan>

On Mon, 2008-12-22 at 22:57 +0100, Kevin Kofler wrote:
> Conrad Meyer wrote:
> > All python noarch libraries go in /usr/lib.
> 
> Yes, and a few other interpreted languages do that too. That really ought to
> be fixed, the sitelib (as opposed to sitearch) directories for interpreted
> languages should be in /usr/share, not /usr/lib.

I'll be the first to say that you're not wrong, but there are issues
with "mixed" packages regarding finding all the pieces, e.g., a native
package with a compiled module.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/c9046cd2/attachment.sig>

From jspaleta at gmail.com  Tue Dec 23 00:53:33 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 22 Dec 2008 15:53:33 -0900
Subject: New font packaging guidelines
In-Reply-To: <1229954901.24585.44.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
Message-ID: <604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>

2008/12/22 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> We've known for quite a while TEX had a problem with fonts installation
> and licensing. However repoquery unearthed many non-font packages that
> shipped fonts (not only TEX packages, and a lot more than I
> expected :(), so I'm going to write a general answer if you permit.

python-matplotlib is carrying its own fonts around, which I didn't
catch. My bad.  So thanks for doing the auto-review.

I think I can just nuke the fonts that are in the package.  There is
also an experimental fontconfig feature in matplotlib 0.98.1 that I
can try to enable.

One thing, can you look over the fonts included in matplotlib and see
if there are any fonts which are not-duplicates of existing packaged
fonts?

-jef



From lists at forevermore.net  Tue Dec 23 01:07:24 2008
From: lists at forevermore.net (Chris Petersen)
Date: Mon, 22 Dec 2008 17:07:24 -0800
Subject: Retiring lineakd and lineak*-plugin packages
Message-ID: <495039CC.1000308@forevermore.net>

This app has been dead upstream for at least a year, and has had compile
issues in Fedora for longer.  I'm considering it abandoned and have
retired/removed it as specified at
http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife

-Chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081222/528b65c9/attachment.sig>

From jarod at redhat.com  Tue Dec 23 02:03:11 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Mon, 22 Dec 2008 21:03:11 -0500
Subject: Wiki section "Building Only Kernel Modules" incomplete
In-Reply-To: <49502A89.8000805@redfish-solutions.com>
References: <494EF670.9040400@redfish-solutions.com>
	<49501490.70506@redfish-solutions.com>
	<49502A89.8000805@redfish-solutions.com>
Message-ID: <200812222103.11519.jarod@redhat.com>

On Monday 22 December 2008 19:02:17 Philip A. Prindeville wrote:
> Ok, so the below thread has changed tracks...  I started looking at:
>
> http://fedoraproject.org/wiki/Docs/CustomKernel?highlight=#Building_Only_Ke
>rnel_Modules
>
>
> And saw, "*This section needs to be updated and fleshed out".  Yes,
> indeed.  I'm trying to go by this section, but it's a little thin.
>
> Who owns it?  I'd like to work with them on figuring out what needs to
> be added to make it useful.

Some or any of the crew on fedora-kernel-list or in #fedora-kernel can 
probably help out here (myself included, time permitting). But beware, the Red 
Hat offices (US anyway, but I think all/most) are officially shut down for a 
week and a half as of the close of business Tuesday, so there may be some 
lag...

-- 
Jarod Wilson
jarod at redhat.com



From mike at cchtml.com  Tue Dec 23 02:41:48 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 22 Dec 2008 20:41:48 -0600
Subject: Retiring lineakd and lineak*-plugin packages
In-Reply-To: <495039CC.1000308@forevermore.net>
References: <495039CC.1000308@forevermore.net>
Message-ID: <49504FEC.8050105@cchtml.com>

Chris Petersen wrote:
> This app has been dead upstream for at least a year, and has had compile
> issues in Fedora for longer.  I'm considering it abandoned and have
> retired/removed it as specified at
> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife
>
> -Chris
>
>   

It's already obsolete since the multimedia keys are better handled 
now-a-days.



From nicolas.mailhot at laposte.net  Tue Dec 23 06:21:44 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Dec 2008 07:21:44 +0100
Subject: New font packaging guidelines
In-Reply-To: <604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
	<604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
Message-ID: <1230013304.8447.1.camel@arekh.okg>

Le lundi 22 d?cembre 2008 ? 15:53 -0900, Jeff Spaleta a ?crit :

> One thing, can you look over the fonts included in matplotlib and see
> if there are any fonts which are not-duplicates of existing packaged
> fonts?

Sure, just post the font names or filenames here or in the bug
(otherwise google and repoquery are your friends)

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/ec05d278/attachment.sig>

From bruno at wolff.to  Tue Dec 23 07:32:37 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 23 Dec 2008 01:32:37 -0600
Subject: Encrypted home directory
In-Reply-To: <a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
Message-ID: <20081223073237.GA3047@wolff.to>

On Mon, Dec 22, 2008 at 18:48:47 +0200,
  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> 
> It's good to have an option to do both encrypted home and dedicated
> encrypted dir in home.

What threat are you trying to counter by having a separate encrypted
directory in your home directory? I would expect selinux to be a better
solution for the kind of problem one might try to solve with an encrypted
directory in their home directory.



From pmatilai at laiskiainen.org  Tue Dec 23 07:33:09 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 23 Dec 2008 09:33:09 +0200 (EET)
Subject: Packages adding groups in %pre/post
In-Reply-To: <alpine.LFD.2.00.0812221945480.19110@turre.koti.laiskiainen.org>
References: <1229836519.3861.44.camel@localhost.localdomain>
	<20081222154206.GD3104@nostromo.devel.redhat.com>
	<1229963514.3861.92.camel@localhost.localdomain>
	<20081222163556.GB7710@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0812221945480.19110@turre.koti.laiskiainen.org>
Message-ID: <alpine.DEB.1.10.0812230909460.26343@gotcha.dreamhost.com>

On Mon, 22 Dec 2008, Panu Matilainen wrote:

> On Mon, 22 Dec 2008, Bill Nottingham wrote:
>
>> Jesse Keating (jkeating at redhat.com) said:
>>>> How on earth do you get things installed w/o setup first?
>>>> glibc -> basesystem -> setup.
>>> 
>>> *shrug* it's just anaconda doing it's package install to build the
>>> install image.  Given that shadow-utils doesn't mention setup at all,
>>> rpm can't possibly know that setup should come before shadow-utils.
>> 
>> Sure it does.
>> 
>> Package A has a Requires(pre) on shadow-utils. Hence, shadow-utils
>> must be installed *and functional* before A is installed. This means
>> shadow-utils and all its requirements.
>> 
>>> From there it's a simple dependency chain - shadow-utils -> glibc
>> -> basesystem -> setup.
>> 
>> So, if it's not getting installed right, rpm or yum is broken in some
>> way.
>
> ...or there's some funny new dependency loop somewhere, breaking the 
> ordering.

And yes there are nasty loops:
http://laiskiainen.org/tmp/fedora-rawhide-231208-loops.txt
For a reproducer try:
yum --disablerepo="*" --enablerepo=rawhide --installroot=<somewhere> install sed"

This is so not going to work:
[pmatilai at localhost badorder]$ rpm -qp --scripts 
setup-2.7.5-3.fc11.noarch.rpm
postinstall scriptlet (using /bin/sh):
if [ `grep -c video /etc/group` -eq 0 ] ; then
   groupadd -g 39 video
fi
if [ `grep -c audio /etc/group` -eq 0 ] ; then
   groupadd -g 63 audio
fi

[pmatilai at localhost badorder]$ rpm -qp --requires setup-2.7.5-3.fc11.noarch.rpm |grep -v rpmlib
/bin/sh
config(setup) = 2.7.5-3.fc11
grep


 	- Panu -



From nikolay at vladimiroff.com  Tue Dec 23 08:09:13 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Tue, 23 Dec 2008 10:09:13 +0200
Subject: Encrypted home directory
In-Reply-To: <20081223073237.GA3047@wolff.to>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
Message-ID: <a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>

2008/12/23 Bruno Wolff III <bruno at wolff.to>:
> On Mon, Dec 22, 2008 at 18:48:47 +0200,
>  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
>>
>> It's good to have an option to do both encrypted home and dedicated
>> encrypted dir in home.
>
> What threat are you trying to counter by having a separate encrypted
> directory in your home directory? I would expect selinux to be a better
> solution for the kind of problem one might try to solve with an encrypted
> directory in their home directory.
>

No, because selinux is useless if someone has physical access to my computer.
Booting another os(think live cds) or just doing "single selinux=0".



-- 
NV



From bruno at wolff.to  Tue Dec 23 08:13:30 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 23 Dec 2008 02:13:30 -0600
Subject: Encrypted home directory
In-Reply-To: <a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
Message-ID: <20081223081330.GA8132@wolff.to>

On Tue, Dec 23, 2008 at 10:09:13 +0200,
  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> 2008/12/23 Bruno Wolff III <bruno at wolff.to>:
> > On Mon, Dec 22, 2008 at 18:48:47 +0200,
> >  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> >>
> >> It's good to have an option to do both encrypted home and dedicated
> >> encrypted dir in home.
> >
> > What threat are you trying to counter by having a separate encrypted
> > directory in your home directory? I would expect selinux to be a better
> > solution for the kind of problem one might try to solve with an encrypted
> > directory in their home directory.
> >
> 
> No, because selinux is useless if someone has physical access to my computer.
> Booting another os(think live cds) or just doing "single selinux=0".

That's what full disk (well really partition) encryption is for and which
already works nicely. Being able to encrypt just some directories is an
inferior solution to that problem.



From rc040203 at freenet.de  Tue Dec 23 08:27:56 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 23 Dec 2008 09:27:56 +0100
Subject: Encrypted home directory
In-Reply-To: <20081223081330.GA8132@wolff.to>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
Message-ID: <1230020877.24768.3687.camel@beck.corsepiu.local>

On Tue, 2008-12-23 at 02:13 -0600, Bruno Wolff III wrote:
> On Tue, Dec 23, 2008 at 10:09:13 +0200,
>   Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> > 2008/12/23 Bruno Wolff III <bruno at wolff.to>:
> > > On Mon, Dec 22, 2008 at 18:48:47 +0200,
> > >  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> > >>
> > >> It's good to have an option to do both encrypted home and dedicated
> > >> encrypted dir in home.
> > >
> > > What threat are you trying to counter by having a separate encrypted
> > > directory in your home directory? I would expect selinux to be a better
> > > solution for the kind of problem one might try to solve with an encrypted
> > > directory in their home directory.
> > >
> > 
> > No, because selinux is useless if someone has physical access to my computer.
> > Booting another os(think live cds) or just doing "single selinux=0".
> 
> That's what full disk (well really partition) encryption is for and which
> already works nicely. Being able to encrypt just some directories is an
> inferior solution to that problem.
The rationale for wanting a completely encrypted system has always
escaped me, esp. when being on a multi-user system.

Ralf




From nikolay at vladimiroff.com  Tue Dec 23 08:30:31 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Tue, 23 Dec 2008 10:30:31 +0200
Subject: Encrypted home directory
In-Reply-To: <20081223081330.GA8132@wolff.to>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
Message-ID: <a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>

2008/12/23 Bruno Wolff III <bruno at wolff.to>:
> On Tue, Dec 23, 2008 at 10:09:13 +0200,
>  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
>> 2008/12/23 Bruno Wolff III <bruno at wolff.to>:
>> > On Mon, Dec 22, 2008 at 18:48:47 +0200,
>> >  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
>> >>
>> >> It's good to have an option to do both encrypted home and dedicated
>> >> encrypted dir in home.
>> >
>> > What threat are you trying to counter by having a separate encrypted
>> > directory in your home directory? I would expect selinux to be a better
>> > solution for the kind of problem one might try to solve with an encrypted
>> > directory in their home directory.
>> >
>>
>> No, because selinux is useless if someone has physical access to my computer.
>> Booting another os(think live cds) or just doing "single selinux=0".
>
> That's what full disk (well really partition) encryption is for and which
> already works nicely. Being able to encrypt just some directories is an
> inferior solution to that problem.
>

Ok. I'm not really sure about this but I think that full disk
encryption on a software level
with a key storng enough will bring some performance loss. And some
people just want
some confidential files to be encrypted.

-- 
NV



From dakingun at gmail.com  Tue Dec 23 08:38:09 2008
From: dakingun at gmail.com (Deji Akingunola)
Date: Tue, 23 Dec 2008 03:38:09 -0500
Subject: orphaning all my packages
In-Reply-To: <20081221134307.GA2791@free.fr>
References: <20081216094739.GA3877@free.fr>
	<b80014de0812202034s1af80a99md6bb18315834db80@mail.gmail.com>
	<20081221134307.GA2791@free.fr>
Message-ID: <b80014de0812230038r522ef174j5d0611f6de31df64@mail.gmail.com>

On Sun, Dec 21, 2008 at 8:43 AM, Patrice Dumas <pertusus at free.fr> wrote:
> On Sat, Dec 20, 2008 at 11:34:02PM -0500, Deji Akingunola wrote:
...
>>
>> I can take over looking after grads, I use it often. What are these
>> functionalities that you claimed were removed? I've not noticed any
>> yet.
>
> lat is not in. The removed files are:
> fgbds.c
> fgutil.c
> gagui.c
> gaimg.c
> gaimg.h
> gsgui.c
> gstmp.c
> lats.c
> latsgrib.c
> lats.h
> latsint.c
> latsint.h
> latsnc.c
> latsparm.h
> latsstat.c
> latstime.c
> latstime.h
> pcx11e.c
>
> But apart from lats, there is not much problematic left out.
>
Since the it (grads) is already packaged in Fedora without lats
support, its removal shouldn't be an issue for us then. And actually
some of the files above (gagui.c, gsgui.c, gstmp.c and pcx11e.c) are
still present in grads-2.0.a3

> Do you want all the branches?
>
Yes

> Also do you want libsx? It is a dependency though it isn't currently

I can be a co-maintainer for it.

Deji

> used because of at the time I packaged grads gagui.c was not under an
> acceptable license, but now it is, at least upstream.
>
> --
> Pat
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From bruno at wolff.to  Tue Dec 23 08:45:18 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 23 Dec 2008 02:45:18 -0600
Subject: Encrypted home directory
In-Reply-To: <a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
References: <1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
Message-ID: <20081223084518.GA13513@wolff.to>

On Tue, Dec 23, 2008 at 10:30:31 +0200,
  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> 
> Ok. I'm not really sure about this but I think that full disk
> encryption on a software level
> with a key storng enough will bring some performance loss. And some
> people just want
> some confidential files to be encrypted.

The performance loss is minimal. Even if you want just some files protected,
you are better off encrypting everything so that caches, swap, and other
copies unintentionally left around aren't left unencrypted.
This is already working well. It doesn't make sense to waste effort to
implement another way to do the same thing less well. Unless there is some
other use case that is better covered by encrypting just some directories,
I think Fedora shouldn't waste scarce resources doing this. If some group
wants to spend their own resources on the implementation, using only enough
of Fedora's time to make sure they are doing things in a way that will
eventually be accepted, then they should feel free to do so.



From bruno at wolff.to  Tue Dec 23 08:58:12 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 23 Dec 2008 02:58:12 -0600
Subject: Encrypted home directory
In-Reply-To: <1230020877.24768.3687.camel@beck.corsepiu.local>
References: <1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<1230020877.24768.3687.camel@beck.corsepiu.local>
Message-ID: <20081223085812.GA14197@wolff.to>

On Tue, Dec 23, 2008 at 09:27:56 +0100,
  Ralf Corsepius <rc040203 at freenet.de> wrote:
> The rationale for wanting a completely encrypted system has always
> escaped me, esp. when being on a multi-user system.

Full disk encryption isn't meant to protect the system from authorized
users. It's meant to protect the system from people who get their hands
on the hardware.
To protect against other users, you probably want to use selinux. However
I don't think the current policy is great for doing this. I played with
MCS for a while and it seemed pretty cumbersome. And different use cases
are going to want to allow different levels of interaction between users,
so a one size fits all policy for compartmentalizing users might need
a lot of booleans to make it widely suitable.
A simple start would be a boolean that made it so users could not access
files that were user_home_t or user_tmp_t owned by a user different from
that of the executing process. I am not sure if this can even be done
genericly. You might need to modify the policy after each user is created.



From pertusus at free.fr  Tue Dec 23 08:57:04 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Dec 2008 09:57:04 +0100
Subject: orphaning all my packages
In-Reply-To: <b80014de0812230038r522ef174j5d0611f6de31df64@mail.gmail.com>
References: <20081216094739.GA3877@free.fr>
	<b80014de0812202034s1af80a99md6bb18315834db80@mail.gmail.com>
	<20081221134307.GA2791@free.fr>
	<b80014de0812230038r522ef174j5d0611f6de31df64@mail.gmail.com>
Message-ID: <20081223085704.GB2418@free.fr>

On Tue, Dec 23, 2008 at 03:38:09AM -0500, Deji Akingunola wrote:
> >
> Since the it (grads) is already packaged in Fedora without lats
> support, its removal shouldn't be an issue for us then. And actually
> some of the files above (gagui.c, gsgui.c, gstmp.c and pcx11e.c) are
> still present in grads-2.0.a3

Indeed, the licensing issue was fixed.

Also the licensing issue for libgadap was also fixed, so it could become
possible to package it.

> I can be a co-maintainer for it.

Ok. So far nobody claimed it.

--
Pat



From rc040203 at freenet.de  Tue Dec 23 09:18:34 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 23 Dec 2008 10:18:34 +0100
Subject: Encrypted home directory
In-Reply-To: <20081223085812.GA14197@wolff.to>
References: <1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<1230020877.24768.3687.camel@beck.corsepiu.local>
	<20081223085812.GA14197@wolff.to>
Message-ID: <1230023914.24768.3748.camel@beck.corsepiu.local>

On Tue, 2008-12-23 at 02:58 -0600, Bruno Wolff III wrote:
> On Tue, Dec 23, 2008 at 09:27:56 +0100,
>   Ralf Corsepius <rc040203 at freenet.de> wrote:
> > The rationale for wanting a completely encrypted system has always
> > escaped me, esp. when being on a multi-user system.
> 
> Full disk encryption isn't meant to protect the system from authorized
> users. It's meant to protect the system from people who get their hands
> on the hardware.
I don't buy this. Even in this case, you actually will want to
protect/encrypt sensitive data, not the whole disk.

In most cases this would be passwds, ssh-keys and certain sensitive
files. 

Of cause, you can achieve this by "whole disk encryption", but I would
call this to be the "big hammer". Suitable for personal-laptops, but
widely silly on desktops.

> To protect against other users, you probably want to use selinux.
SELinux is aiming at shielding the system against mal-ware and against
applications misbehaving. 

It does not help against unauthorized access on personal data, such as
your personal on-line banking account access data, ssh-keys or
confidential documents and similar.

Similarly, encryption of supposed to be universally, globally accessable
files (such as much of the OS) is widely meaningless. It doesn't buy you
anything.

Ralf




From fedora at camperquake.de  Tue Dec 23 09:24:10 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 23 Dec 2008 10:24:10 +0100
Subject: Encrypted home directory
In-Reply-To: <1dedbbfc0812220919u54a75923qae1739bef41b1466@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<1dedbbfc0812220919u54a75923qae1739bef41b1466@mail.gmail.com>
Message-ID: <20081223102410.72d8c547@dhcp03.addix.net>

Hi.

On Mon, 22 Dec 2008 18:19:38 +0100, David Nielsen wrote:

> Wouldn't saving passwords in plaintext (presumably also history and
> cache) be a bug?

Not necessarily. Usually, if you're the client-end of an authentication
session (i.e. the one asking to be authenticated) you'll need the plain text
password. The server-end _may_ need the plain text password, depending on the
exact authentication scheme.

I'd expect a rather client-biased distribution of passwords in a users home
directory.



From fedora at camperquake.de  Tue Dec 23 09:27:13 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 23 Dec 2008 10:27:13 +0100
Subject: Encrypted home directory
In-Reply-To: <a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
Message-ID: <20081223102713.604b66cf@dhcp03.addix.net>

Hi.

On Tue, 23 Dec 2008 10:30:31 +0200, Nikolay Vladimirov wrote:

> Ok. I'm not really sure about this but I think that full disk
> encryption on a software level
> with a key storng enough will bring some performance loss. And some
> people just want
> some confidential files to be encrypted.

I'm running full-LV encryption for /home (and some other directories) in
my laptop, and the performance loss is nonexistant for me. Getting the
bits off the rotating rust takes quite longer then decrypting them.

After all, all the cores in that thing have to be good for something.

(Core Duo, 1.6GHz)



From fedora at matbooth.co.uk  Tue Dec 23 09:48:39 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 23 Dec 2008 09:48:39 +0000
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <604aa7910812221547g1ad8ee9eo2aa62c70a7041911@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
	<604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
	<e8a30f560812220712p1da8234aj41093dafb8ac42cf@mail.gmail.com>
	<gip7pj$j9l$2@ger.gmane.org>
	<604aa7910812221547g1ad8ee9eo2aa62c70a7041911@mail.gmail.com>
Message-ID: <9497e9990812230148n5645463ehf2b39965e74c37e5@mail.gmail.com>

On Mon, Dec 22, 2008 at 11:47 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Mon, Dec 22, 2008 at 2:27 PM, Matthew Woehlke
> <mw_triad at users.sourceforge.net> wrote:
>> My first thought was "Software Developer", but reading the description,
>> "Software Developer" sounds to me more specific to writing code (i.e. not
>> doc work)...
>
> Indeed... the attempt was to build a role definition that encompasses
> the work necessary to put the bits out the door as a major endeavor.
> Packaging is a big part of that. Triage is a big part of that. And so
> is documentation writing.

Then maybe the title needs to be slightly more verbose to encompass
all of those topics.

In fact, why not have seperate "Tester", "Developer" and "Technical
Writer" buttons? These are roles commonly found in the industry after
all, and they could all link to the same role description if you
want...

Regards,
Mat

-- 
Mat Booth
www.matbooth.co.uk



From rawhide at fedoraproject.org  Tue Dec 23 10:55:47 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 23 Dec 2008 10:55:47 +0000 (UTC)
Subject: rawhide report: 20081223 changes
Message-ID: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>

Compose started at Tue Dec 23 06:01:07 UTC 2008

New package ghc-paths
        Interface to GHC's installation directories
New package lv2core
        Audio Plugin Standard
New package perl-Devel-CheckOS
        Check what OS we're running on
New package sugar-speak
        Speak for Sugar
New package system-config-date-docs
        Documentation for setting the system date and time
New package system-config-nfs-docs
        Documentation for configuring an NFS server
New package system-config-samba-docs
        Documentation for configuring a Samba server
New package system-config-services-docs
        Documentation for configuring system services
New package system-config-users-docs
        Documentation for administering users and groups
Removed package lineak-defaultplugin
Removed package lineak-kdeplugins
Removed package lineak-xosdplugin
Removed package lineakd
Updated Packages:

E-1.0.002-3.fc11
----------------
* Mon Dec 22 17:00:00 2008 David A. Wheeler <dwheeler at, dwheeler.com> 1.0.002-3
- Work around local tags

* Mon Dec 22 17:00:00 2008 David A. Wheeler <dwheeler at, dwheeler.com> 1.0.002-2
- Repaired for python2 variations (different releases have different versions
  of python2)

* Mon Dec 22 17:00:00 2008 David A. Wheeler <dwheeler at, dwheeler.com> 1.0.002-1
- Added python2.5 as BuildRequires
- Update to E version 1.0 ("Temi").  This includes...
- Improved eproof script signal handling.
- Fixed a number of warnings with the latest gcc version.
- Updated proof objects to latest SZS ontology.


R-2.8.1-1.fc11
--------------
* Mon Dec 22 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 2.8.1-1
- update javareconf call in %post (bz 477076)
- 2.8.1


SDL_Pango-0.1.2-9
-----------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.1.2-9
- Include matrix declaraction patch (#475118), adapted in order to not
  create a regression from the "supress warning" patch.


bsd-games-2.17-26.fc11
----------------------
* Mon Dec 22 17:00:00 2008 Wart <wart at kobold.org> 2.17-26
- Minor tweaks to patches to get them to work with no fuzz


bzflag-2.0.12-4.fc11
--------------------
* Mon Dec 22 17:00:00 2008 Nils Philippsen <nils at redhat.com> 2.0.12-4
- use autoreconf -i


cairo-dock-2.0.0-0.3.svn1448_trunk.fc11
---------------------------------------
* Tue Dec 23 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1448


cobbler-1.4.0-4.fc11
--------------------

compat-wxGTK26-2.6.4-4
----------------------
* Mon Dec 22 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.6.4-4
- remove wxGTK{,-devel,-gl} Obsoletes since the wxGTK2 (2.8.x)
  pkg set in Fedora has been renamed to wxGTK


digikam-0.10.0-0.11.beta7.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.10.0-0.11.beta7
- BR: libkipi-devel >= 0.3.0


eclipse-gef-3.4.1-2.fc11
------------------------
* Mon Dec 22 17:00:00 2008 Mat Booth <fedora at matbooth.co.uk> 3.4.1-2
- Rebuild GCJ DB during post and postun in sub-packages.


esorex-3.6.12-1.fc11
--------------------
* Mon Dec 22 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> 3.6.12-1
- New upstream source

* Sat Nov 22 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> 3.6.8-2
- Summary rewritten


feh-1.3.4-10.fc11
-----------------
* Mon Dec 22 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 1.3.4-10
- Fix thinko in DejaVu package name


fillets-ng-0.8.0-2.fc11
-----------------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.8.0-2
- Add coreutils requirement for scriplets (#475931).
- Enclose gtk-update-icon-cache scriplet calls in "ifs".


fillets-ng-data-0.8.0-2
-----------------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.8.0-2
- Replace the 3 identical bundled copies of the FreeSansBold font with symlinks
  to the original and require the freefont package (#477385).


fontpackages-1.13-1.fc11
------------------------
* Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
- 1.13-1
??? Add another directory to avoid depending on unowned stuff
??? use it to put the fontconfig examples in a better place


freedoom-0.6.2-2.fc11
---------------------
* Mon Dec 22 17:00:00 2008 Wart <wart at kobold.org> 0.6.2-2
- Add coreutils requirement for rpm post scripts


geda-symbols-20081220-1.fc11
----------------------------
* Sun Dec 21 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release
- stripped off contents that upstream accepted from us.


gnome-applets-2.25.2-4.fc11
---------------------------
* Sat Dec 20 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.2-4
- Update to 2.25.2


gnucash-2.2.8-2.fc11
--------------------
* Mon Dec 22 17:00:00 2008 Bill Nottingham <notting at redhat.com> - 2.2.8-2
- fix crash resulting from earlier crash fix (#474511, <jik at kamens.brookline.ma.us>)


gyachi-1.1.60-1.fc11
--------------------
* Mon Dec 22 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.60.1
- Fixed plugin obsoletes.


haddock-2.4.1-2.fc11
--------------------
* Tue Dec 23 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 2.4.1-2
- buildrequire ghc-paths
- no longer need haddock-2.4.1-no-ghc-paths.patch


hamster-applet-2.25.3-3.fc11
----------------------------
* Mon Dec 22 17:00:00 2008 Mads Villadsen <maxx at krakoa.dk> - 2.25.3-3
- Update to latest upstream release


igraph-0.5.1-4.fc11
-------------------
* Mon Dec 22 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.5.1-4
- Bump tag


kannel-1.4.1-8
--------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.4.1-8
- Include patch to fix openssl detection on 64bit.
- Include gw-config wrapper script to fix multilib conflicts (#341701).
- Include patch to remove definitions of types which never happen on Linux.


kazehakase-0.5.6-2.fc11
-----------------------
* Tue Dec 23 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Rebuild against xulrunner 1.9.1


kdebase-runtime-4.1.85-2.fc11
-----------------------------
* Mon Dec 22 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.85-2
- include %_bindir/kdesu symlink


kdebase-workspace-4.1.85-6.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Rex Dieter 4.1.85-6
- (re)enable edje, google-gadget support


kdebase3-3.5.10-4.fc11
----------------------
* Mon Dec 22 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.5.10-4
- omit (nonfunctional) kdesu (F9+)


kdegraphics-4.1.85-4.fc11
-------------------------
* Mon Dec 22 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 4.1.85-4
- -devel: Provides: libkipi-devel = 0.3.0


kipi-plugins-0.2.0-0.10.beta5.fc11
----------------------------------
* Mon Dec 22 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.2.0-0.10.beta5
- tighten BR's (libkipi >= 0.3.0 mostly)


koan-1.4.0-4444.fc11
--------------------
* Mon Dec 22 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.4.0-4
- Fix python(abi) requirement some more

* Mon Dec 22 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.4.0-3
- Fix python(abi) requirement


kvm-81-1.fc11
-------------
* Mon Dec 22 17:00:00 2008 Glauber Costa <glommer at redhat.com> - 81-1
- Updated to kvm-81.
- kvm-fix-pc-bios-make-install-missing-files.patch not needed anymore
  replaced by disable-blobs option.


libchewing-0.3.2-2.fc11
-----------------------
* Tue Dec 23 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 0.3.2-2
- [Bug 477690] libchewing multilib conflict
  Move /usr/share/chewing/fonetree.dat to corresponding libdir.


libgeda-20081220-1.fc11
-----------------------
* Mon Dec 22 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release
- stripped off contents that upstream accepted from us.


libprojectM-1.2.0-6.fc11
------------------------
* Mon Dec 22 17:00:00 2008 Jameson Pugh (imntreal at gmail.com) - 1.2.0-6
- Updated font package names


lighttpd-1.4.20-3.fc11
----------------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.4.20-3
- Rename spawn-fastcgi to lighttpd-spawn-fastcgi to avoid clash with other
  packages providing it for their own needs (#472749). It's not used as-is
  by lighttpd, so it shouldn't be a problem... at worst, some custom scripts
  will need to be updated.

* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.4.20-2
- Include conf.d/*.conf configuration snippets (#444953).
- Mark the default index.html in order to not loose changes upon upgrade if it
  was edited or replaced with a different file (#438564).
- Include patch to add the INIT INFO block to the init script (#246973).


linuxwacom-0.8.0.3-6.fc11
-------------------------
* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 0.8.0.3-6
- Rebuild for server 1.6
  add build-fixes.patch: protect against XINPUT ABI 3, and other build
  issues


mesa-7.3-0.4.fc11
-----------------
* Mon Dec 22 17:00:00 2008 Dave Airlie <airlied at redhat.com> 7.3-0.4
- r300-bufmgr.patch: remove start/end offset properly + r500 FP


monit-4.10.1-8.fc11
-------------------
* Mon Dec 22 17:00:00 2008 Stewart Adam <s.adam at diffingo.com> 4.10.1-8
- Tweak configuration defaults: include /etc/monit.d/*, log to /var/log/monit
  and set daemon time to 60s
- Don't use $desc in initscript
- Add patch to search for monit.conf by default (#475044)
- Add patch to remove redundant startup message


nrpe-2.12-4.fc11
----------------
* Sun Dec 21 17:00:00 2008 Mike McGrath <mmcgrath at redhat.com> - 2.12-4
- Added some doc lines for ticket 477527


ntfs-3g-1.5222-0.1.RC.fc11
--------------------------
* Mon Dec 22 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2:1.5222-0.1.RC
- 1.5222-RC


perl-5.10.0-53.fc11
-------------------
* Mon Dec 22 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 4:5.10.0-53
- add missing XHTML.pm into Pod::Simple


perl-Pugs-Compiler-Rule-0.37-1.fc11
-----------------------------------
* Mon Dec 22 17:00:00 2008 Steven Pritchard <steve at kspei.com> 0.37-1
- Update to 0.37.


php-eaccelerator-0.9.5.3-1.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1:0.9.5.3-1
- Update to 0.9.5.3.
- Include daily cleanup cron job (#470460).


pigment-0.3.13-2.fc11
---------------------
* Sun Dec 21 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.3.13-2
- Disable gtk-doc to fix multilib conflicts (#342871).


portaudio-19-7.fc11
-------------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 19-7
- Add Doxyfile patch to remove date in footer and fix multilib (#342931).


powermanga-0.90-4
-----------------
* Wed Oct 22 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.90-4
- Add coreutils requirement for scriplets (#475928).
- Enclose gtk-update-icon-cache scriplet calls in "ifs".


pympdtouchgui-0.302-6.fc11
--------------------------
* Mon Dec 22 17:00:00 2008 Sven Lankes <sven at lank.es> - 0.302-6
- rebuild for python 2.6


python-igraph-0.5.1-3.fc11
--------------------------
* Sun Dec 21 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.5.1-3
- Bump tag

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.1-2
- Rebuild for Python 2.6

* Sun Nov 16 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.5.1-1
- Update to 0.5.1


python-numdisplay-1.5.3-1.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> - 1.5.3-1
- New upstream version
- Docs aren't in the tarball, removed


python-storm-0.13-4.fc11
------------------------
* Mon Dec 22 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.13-4
- Temporarily disable the check to fix broken deps 
  (opened #477591 to track this)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.13-3
- Rebuild for Python 2.6


python-tag-0.94.5-1.fc11
------------------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.94.5-1
- Update to 0.94.5.
- Remove no longer needed gcc43 patch.
- Update configvars patch, patch setup.py and call it boostpython.
- Add python-setuptools-devel build requirement.


qgis-0.11.0-8.fc11
------------------
* Mon Dec 22 17:00:00 2008 Douglas E. Warner <silfreed at silfreed.net> - 0.11.0-8
- cleaning up patch

* Mon Dec 22 17:00:00 2008 Douglas E. Warner <silfreed at silfreed.net> - 0.11.0-7
- bump to add patch

* Thu Dec 18 17:00:00 2008 Douglas E. Warner <silfreed at silfreed.net> - 0.11.0-6
- adding patch to fix typedef problems in python build

* Thu Dec 18 17:00:00 2008 Douglas E. Warner <silfreed at silfreed.net> - 0.11.0-5
- Rebuild for Python 2.6


rpy-1.0.3-6.fc11
----------------
* Mon Dec 22 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.3-6
- rebuild for R 2.8.1


rss-glx-0.8.2.p-1.fc11
----------------------
* Mon Dec 22 17:00:00 2008 Nils Philippsen <nils at redhat.com> 0.8.2.p-1
- use autoreconf to avoid using non-matching ltmain.sh

* Wed Dec 17 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- correct KDE desktop files so that they work with KDE 4.1
- remove encoding lines from desktop files as they're deprecated

* Tue Dec 16 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- version 0.8.2.p
- remove obsolete freealut patch
- update flags, gcc43 patches


scapy-2.0.0.10-1.fc11
---------------------
* Mon Dec 22 17:00:00 2008 Devan Goodwin <dgoodwin at dangerouslyinc.com> 2.0.0.10-1
- Update to Scapy 2.0.0.10.

* Sun Dec  7 17:00:00 2008 Devan Goodwin <dgoodwin at dangerouslyinc.com> 2.0.0.9-2
- Update for Scapy 2.0.0.9.


seahorse-2.25.3-1.fc11
----------------------
* Mon Dec 22 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> 2.25.3-1
- Update to 2.25.3


selinux-policy-3.6.1-13.fc11
----------------------------
* Mon Dec 22 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-13
- Fix dbus reading /proc information

* Thu Dec 18 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-12
- Add missing alias for home directory content


sugar-presence-service-0.83.2-1.fc11
------------------------------------
* Mon Dec 22 17:00:00 2008 Morgan Collett <morgan.collett at gmail.com> - 0.83.2-1
- Remove NM 0.7 patch - included in release
- Update to 0.83.2
- pylint fixes
- dev.laptop.org #6248: Port NetworkManager watcher code to NM 0.7's D-Bus API


suitesparse-3.2.0-4.fc11
------------------------
* Sat Dec 20 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 3.2.0-4
- Also build SPQR
- Further fixes for BZ #475411


system-config-date-1.9.36-1.fc11
--------------------------------
* Mon Dec 22 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.9.36-1
- fix typo in Source0 URL

* Mon Dec 15 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- remove obsolete "dynamic" keyword (#476046)

* Thu Nov 27 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.9.35-1
- add source URL

* Wed Nov 26 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- obsolete and conflict with system-config-date < 1.9.35 (docs split)

* Tue Nov 25 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- prune online documentation


system-config-nfs-1.3.43-1.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.3.43-1
- fix typo in Source0 URL


system-config-samba-1.2.69-1.fc11
---------------------------------
* Thu Dec 11 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.2.69-1
- new smb.conf template file (#474811)

* Tue Dec  9 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- allow anyone to invoke dbus methods (#475524)

* Thu Dec  4 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- fix parser, dbus wrapper to allow non-ASCII characters in configuration


system-config-services-0.99.30-1.fc11
-------------------------------------
* Mon Dec 22 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 0.99.30-1
- fix typo in Source0 URL

* Tue Dec  9 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- allow anyone to invoke dbus methods (#475203)


system-config-users-1.2.83-1.fc11
---------------------------------
* Mon Dec 22 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.2.83-1
- fix typo in Source0 URL


tasque-0.1.7-5.fc11
-------------------
* Mon Dec 22 17:00:00 2008 Maxime Carron <mxcarron at fedoraproject.org> - 0.1.7-4
- Enable sqlite backend for standalone mode

* Mon Dec 22 17:00:00 2008 David Kaylor<dkaylor at gmail.com> - 0.1.7-5
- Add mono-data-sqlite dep for sqlite backend


util-linux-ng-2.14.2-0.1.fc11
-----------------------------
* Mon Dec 22 17:00:00 2008 Karel Zak <kzak at redhat.com> 2.14.2-0.1
- upgrade to 2.14.2-rc1
- refresh old patches


xorg-x11-drv-radeonhd-1.2.4-1.2.20081212git.fc11
------------------------------------------------
* Mon Dec 22 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.2.4-1.2.20081212git
- Force rebuild on rawhide aka F-11.
- Change obsolete gitweb references to valid cgit references.


xorg-x11-server-1.5.99.3-2.fc11
-------------------------------
* Mon Dec 22 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.5.99.3-2
- Update to today's server-1.6  branch tip.


xulrunner-1.9.1-0.5.beta2.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 1.9.1-0.5
- Typo fix


zziplib-0.13.49-6.fc11
----------------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.13.49-6
- Patch _config.h to make it identical for 32bit and 64bit archs (#343521).


Summary:
Added Packages: 9
Removed Packages: 4
Modified Packages: 71
Broken deps for i386
----------------------------------------------------------
	Miro-1.2.8-3.fc11.i386 requires gecko-libs = 0:1.9.0.4
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	e16-0.16.8.14-1.fc10.i386 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gnomedesktop-2.24.0-5.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gtkmozembed-2.19.1-26.fc11.i386 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mono-sharpcvslib-0.35-3.fc10.i386 requires mono(nunit.framework) = 0:2.2.0.0
	mozvoikko-0.9.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.i386 requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-search-tool-0.6.6-4.fc11.i386 requires libgnome-desktop-2.so.10
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	Miro-1.2.8-3.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	banshee-1.4.1-1.fc11.x86_64 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	blam-1.8.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.x86_64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gtkmozembed-2.19.1-26.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mono-sharpcvslib-0.35-3.fc10.x86_64 requires mono(nunit.framework) = 0:2.2.0.0
	mozvoikko-0.9.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.x86_64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.i386 requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	Miro-1.2.8-3.fc11.ppc requires gecko-libs = 0:1.9.0.4
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-python2-gtkmozembed-2.19.1-26.fc11.ppc requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mozvoikko-0.9.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.3.722557-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-0.8.so.0
	swfdec-gnome-2.24.0-2.fc10.ppc requires libswfdec-gtk-0.8.so.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	tracker-0.6.6-4.fc11.ppc requires libgmime-2.0.so.2
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc requires libgnome-desktop-2.so.10
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	Miro-1.2.8-3.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gnomedesktop-2.24.0-5.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gtkmozembed-2.19.1-26.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mozvoikko-0.9.5-5.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.3.722557-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.3.722557-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	rubygem-actionpack-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-activeresource-2.1.1-1.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activerecord) = 0:2.1.1
	rubygem-rails-2.1.1-2.fc10.noarch requires rubygem(activesupport) = 0:2.1.1
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-gtk-0.8.so.0()(64bit)
	swfdec-gnome-2.24.0-2.fc10.ppc64 requires libswfdec-0.8.so.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	tracker-0.6.6-4.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	tracker-search-tool-0.6.6-4.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts





From kevin.kofler at chello.at  Tue Dec 23 11:04:39 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 23 Dec 2008 12:04:39 +0100
Subject: Usage of {_libdir} or {_lib} in noarch packages
References: <494A7A92.9020404@redhat.com>
	<1229619037.3472.26.camel@localhost.localdomain>
	<20081220145752.GA12856@victor.nirvana>
	<200812221335.54257.konrad@tylerc.org> <gip2g7$79o$3@ger.gmane.org>
	<1229993342.17128.45.camel@ignacio.lan>
Message-ID: <giqgk7$hv7$1@ger.gmane.org>

Ignacio Vazquez-Abrams wrote:
> I'll be the first to say that you're not wrong, but there are issues
> with "mixed" packages regarding finding all the pieces, e.g., a native
> package with a compiled module.

How does it work on lib64 arches then? Those also have sitelib != sitearch.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Dec 23 11:07:24 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 23 Dec 2008 12:07:24 +0100
Subject: Stability and Release Cycles - An Idea
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>
	<1229969962.3861.100.camel@localhost.localdomain>
	<gip180$4o2$1@ger.gmane.org>
	<1229985006.3313.7.camel@localhost.localdomain>
Message-ID: <giqgpc$hv7$2@ger.gmane.org>

Jesse Keating wrote:
> Will Remmi be building the 20 some odd other packages that will then
> break when gecko library path changes?

He does rebuild them when he updates the firefox2 compat package.

        Kevin Kofler



From adam.huffman at gmail.com  Tue Dec 23 11:14:56 2008
From: adam.huffman at gmail.com (Adam Huffman)
Date: Tue, 23 Dec 2008 11:14:56 +0000
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494F98B8.9080700@gmail.com>
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>	<ginp29$sir$2@ger.gmane.org>
	<494F98B8.9080700@gmail.com>
Message-ID: <4950C830.8040909@gmail.com>

Les Mikesell wrote:
>> works.
> And I don't see how the current system is not "usably-stable". Fedora 
> just
>
> Except when it doesn't.  Would you bet your life on it working 
> correctly  after every update?  You'd have lost several times on my 
> machines, including an update very near the end of FC6's life - a 
> point where there was no reason at all to be making changes likely to 
> break things. And I'm not using it again for anything that matters 
> until I have some reason to think it won't be repeated.
>

You seem to expend a remarkable amount of energy on something you will 
"never use again for anything that matters".



From paskalis at di.uoa.gr  Tue Dec 23 11:58:18 2008
From: paskalis at di.uoa.gr (Sarantis Paskalis)
Date: Tue, 23 Dec 2008 13:58:18 +0200
Subject: New font packaging guidelines
In-Reply-To: <1229954901.24585.44.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
Message-ID: <20081223115818.GA29743@gallagher.di.uoa.gr>

On Mon, Dec 22, 2008 at 03:08:21PM +0100, Nicolas Mailhot wrote:
> Le lundi 22 d?cembre 2008 ? 14:56 +0200, Sarantis Paskalis a ?crit :
> > On Sat, Dec 20, 2008 at 05:13:35PM +0100, Nicolas Mailhot wrote:
> 
> Hi Sarantis,
> 
> > > As some of you may know, after more than a month of consultation,
> > > feedback and tweaking new font packaging guidelines have been approved
> > > by FESCO.
> 
> > Two of my packages are TeX fonts (tetex-font-kerkis and 
> > tetex-font-cm-lgc), which contain .pfb files (postscript type 1 from 
> > what I could find out).
> 
> We've known for quite a	while TEX had a problem with fonts installation
> and licensing. However repoquery unearthed many non-font packages that
> shipped fonts (not only TEX packages, and a lot more than I
> expected :(), so I'm going to write a general answer if you permit.
> 
> 1. The target font management stack on Fedora is fontconfig. It has
> ?near universal? support including emacs-side?.
> 
> 2. If your app is fontconfig-aware you just need to package the fonts it
> needs as a normal guidelines-compliant font package. Fontconfig will
> then locate them for your app no matter on how the font files are named
> or renamed. 
> 
> 3. If your app is not fontconfig-aware, you should politely remind your
> upstream it has a problem.
> 
> 4. If your app is not fontconfig-aware, and there is no solution
> upstream in the short term, you still need to package the fonts using
> the normal Fedora fonts packaging guidelines. And then either patch your
> app to look for its fonts in the guidelines-compliant location or
> package a set of symlinks pointing to this location.
> 
> 5. The preferred way to package fonts is to locate their original font
> upstream and package the original font release in a separate fonts-only
> package.
> 
> 6. However, for fonts that are bundled in a software package with no
> other form of release, or fonts which have some additional non-standard
> stuff bundled with them (such as TEX packages), I don't think anyone
> will complain too loudly if you package them as subpackage(s) of your
> main package. As long as the subpackage(s) are clean,
> guidelines-compliant, and can be used by Fedora users without dragging
> with them your app or TEX or other non-general-purpose stuff.
> 
> For example, for a ?tex-foo? TEX package, you could have:
> 
> tex-foo-fonts-fontname1 (normal font subpackage #1)
> tex-foo-fonts-fontname2 (normal font subpackage #2)
> [?]
> tex-foo-fonts-common    (common font subpackage that owns the fonts dirs
>                          and the fonts-licensing files?)
> tex-foo                 (main TEX package that depends on the
>                          tex-foo-fonts packages, includes symlinks to
>                          the font files in standard locations and
>                          other TEX stuff)
> 
> The subpackaging logic is pretty much the same as in the
> spectemplate-fonts-multi.spec template included in fontpackages-devel
> http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts
> 
> Please note that the current guidelines say that font packagers:
> ?SHOULD package each font family separately, and avoid font collections
> that mix fonts of different history, licensing, or origin??
> 
> There is some wiggle room between SHOULD and MUST, and it has posed
> problems in the past six months, so I've pushed the simpler
> http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21)#New_wording
> FPC-side yesterday.
> 
> I hope that answers all your questions.
> 
> ? After a period of ??utter luddites? shock? to quote a well-known xorg
> contributor
> http://thread.gmane.org/gmane.comp.freedesktop.xorg/34322/focus=34334
> 
> ? of course if you're shipping a single font family, that requires a
> single font subpackage, there's no need to separate directory and
> licensing handling in a -common subpackage. Just create a single
> tex-foo-fonts-fontname in that case.
> 
> ?
> http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages

Thanks for the really detailed guidelines.  My packages are just TeX 
fonts (and their TeX related configuration), so my actions boil down to 
moving the actual font files under /usr/share/fonts and symlink them to 
their original directory.

(I also have to rename the package but that is orthogonal to fonts and 
more related to TeX stuff after tetex EOL.)
  
Thanks again,

-- Sarantis



From eric at christensenplace.us  Tue Dec 23 12:29:13 2008
From: eric at christensenplace.us (Eric Christensen)
Date: Tue, 23 Dec 2008 07:29:13 -0500
Subject: Encrypted home directory
In-Reply-To: <a3c040240812220935s315fc4b8m5af65b2269e9bb6b@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>	<494E8B53.4050005@redhat.com>	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>	<20081221201523.GC10113@amd.home.annexia.org>	<20081221214630.669fbad3@lain.camperquake.de>	<20081222101133.GB12869@amd.home.annexia.org>	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>	<1dedbbfc0812220919u54a75923qae1739bef41b1466@mail.gmail.com>
	<a3c040240812220935s315fc4b8m5af65b2269e9bb6b@mail.gmail.com>
Message-ID: <4950D999.1080806@christensenplace.us>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Don't we already provide a solution for this?  All you have to do is
check the block when installing Fedora (ever since 9) and it will
encrypt your entire hard drive (except /boot) at AES-128 using LUKS.

The decrypting at boot up was a little clunky in F9 but F10 made it
looks nice.

Thanks,
Eric Christensen
E-Mail: sparks at fedoraproject.org
GPG Key: D74908ED



Sachin wrote:
> I had never expected so much of discussion :), which is healthy.(I had
> never thought of swap)
> But shouldn't be discussion limited to whether we can provide this
> feature or not and let the end user decide whether he wants to use it or
> not.
> 
> And if he faces the problem like scalability or umounting he/she log the
> bug with upstream ..
> 
> I am believe fedora is about choices and freedom.
> 
> 
> 2008/12/22 David Nielsen <gnomeuser at gmail.com <mailto:gnomeuser at gmail.com>>
> 
> 
> 
>     2008/12/22 Nikolay Vladimirov <nikolay at vladimiroff.com
>     <mailto:nikolay at vladimiroff.com>>
> 
>         2008/12/22 Muayyad AlSadi <alsadi at gmail.com
>         <mailto:alsadi at gmail.com>>:
>         > I guess we should have an optional special directory inside
>         each user's home
>         > let's say it's named private
>         >
>         > a trivial pygtk tool can call fuse to mount a file there into
>         the same directory
>         >
>         > what do you think ?
>         >
>         > I guess I have 1000000s config files on my home, apps will
>         start very
>         > slow if they are encrypted (think firefox for example)
>         >
>         > --
>         > fedora-devel-list mailing list
>         > fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>         > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>         >
> 
>         It's good to have an option to do both encrypted home and dedicated
>         encrypted dir in home.
>         Sice it's normal to have programs that save your passwords in
>         plaintext in their configs. And yes,
>         most of them do that because they also send the passwords in
>         plaintext
>         over the net,
>         and if someone watches your traffic it will be trivial to find them.
>         Also it's good to encrypt the cache of some programs since it's
>         common
>         that you don't want
>         your browser history, cache, etc. to be visible.
> 
> 
>     Wouldn't saving passwords in plaintext (presumably also history and
>     cache) be a bug?  
> 
> 
>         However I find it simpler and safer to use hardware disk
>         encryption(from the BIOS config) and a bunch of other thinkpad
>         security stuff.
>         I'm not really sure if this kind of stuff is widely available on
>         other
>         hardware. So this software encryption thing seems nice.
> 
> 
> 
>     --
>     fedora-devel-list mailing list
>     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklQ2ZgACgkQL5V8yddJCO1ztwCeIVrU011xFwMGwb+c/xO2q1J4
uDEAnA5m+jpAGpOAA/MGF/J2Si9LsHoZ
=BOjR
-----END PGP SIGNATURE-----



From nicolas.mailhot at laposte.net  Tue Dec 23 12:35:32 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Dec 2008 13:35:32 +0100 (CET)
Subject: New font packaging guidelines
In-Reply-To: <604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
	<604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
Message-ID: <bde9bd3070e4c8aa2d2d78165dd820ff.squirrel@arekh.dyndns.org>



Le Mar 23 d?cembre 2008 01:53, Jeff Spaleta a ?crit :

> python-matplotlib is carrying its own fonts around, which I didn't
> catch. My bad. So thanks for doing the auto-review.

We don't have any check to catch non-fonts packages that bundle fonts,
even though we know that causes problems later, so really we are a bit
under-tooled here :(

Anyway, I'd like to remind every packager that decides to drop the TTF
fonts he shipped in his non-font-package, that's it's a good idea to
add a dep on the appropriate DejaVu family, and not on freefonts or
bitstream vera (unless the package has specific style or metric
requirements).

DejaVu is in the default install set, the others aren't, so adding
them as deps will result in more resource use mirror and user side
(also freefonts will probably be renamed/reorganised before the end of
the cycle).

In Rawhide dejavu has been split in three packages so you only need to
depend on the font family you actually need, not the full set.

Sincerely,

-- 
Nicolas Mailhot



From eric at christensenplace.us  Tue Dec 23 12:42:00 2008
From: eric at christensenplace.us (Eric Christensen)
Date: Tue, 23 Dec 2008 07:42:00 -0500
Subject: Encrypted home directory
In-Reply-To: <20081223102713.604b66cf@dhcp03.addix.net>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>	<20081221201523.GC10113@amd.home.annexia.org>	<20081221214630.669fbad3@lain.camperquake.de>	<20081222101133.GB12869@amd.home.annexia.org>	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>	<20081223073237.GA3047@wolff.to>	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>	<20081223081330.GA8132@wolff.to>	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
	<20081223102713.604b66cf@dhcp03.addix.net>
Message-ID: <4950DC98.2070804@christensenplace.us>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralf Ertzinger wrote:
> Hi.
> 
> On Tue, 23 Dec 2008 10:30:31 +0200, Nikolay Vladimirov wrote:
> 
>> Ok. I'm not really sure about this but I think that full disk
>> encryption on a software level
>> with a key storng enough will bring some performance loss. And some
>> people just want
>> some confidential files to be encrypted.
> 
> I'm running full-LV encryption for /home (and some other directories) in
> my laptop, and the performance loss is nonexistant for me. Getting the
> bits off the rotating rust takes quite longer then decrypting them.
> 
> After all, all the cores in that thing have to be good for something.
> 
> (Core Duo, 1.6GHz)
> 
I've been running full disk encryption via LUKS since F8 with a 6 year
old laptop.  I don't see any noticeable performance loss.

Just to comment on the whole disk versus just a folder in the /home,
Windows did the same thing a number of years ago on XP (and since I
believe but I don't know).  You could select a folder and "encrypt" it.
 The crypto implementation was horrible and when people actually used it
they never realized that they weren't getting ALL the sensitive data
encrypted.  There will always be a cache or tmp file laying around in
the clear that will contain sensitive information.

The DoD didn't like the use of the folder level encryption and has sense
mandated full disk encryption for all portable devices.  It saves the
user from trying to figure out what is sensitive and what needs to be
encrypted and breaking their storage schema just to put a specific file
into a specific folder.  The user will ALWAYS miss something and will
ALWAYS be left vulnerable.

Thanks,
Eric Christensen
E-Mail: sparks at fedoraproject.org
GPG Key: D74908ED

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklQ3JYACgkQL5V8yddJCO15uwCeP5YxqNlEwleCzl824t70Slq6
8/oAn1wwTK4AkWaYHje5PjCzYvn7JVHe
=VI4A
-----END PGP SIGNATURE-----



From hughsient at gmail.com  Tue Dec 23 13:12:51 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 23 Dec 2008 13:12:51 +0000
Subject: rawhide report: 20081223 changes
In-Reply-To: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
Message-ID: <1230037971.3558.38.camel@hughsie-work.lan>

On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
> fontpackages-1.13-1.fc11
> ------------------------
> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
> - 1.13-1
> ? Add another directory to avoid depending on unowned stuff
> ? use it to put the fontconfig examples in a better place

Two new symbols! L33t.

Richard.




From fedora at matbooth.co.uk  Tue Dec 23 14:05:09 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 23 Dec 2008 14:05:09 +0000
Subject: rawhide report: 20081223 changes
In-Reply-To: <1230037971.3558.38.camel@hughsie-work.lan>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
Message-ID: <9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>

On Tue, Dec 23, 2008 at 1:12 PM, Richard Hughes <hughsient at gmail.com> wrote:
> On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
>> fontpackages-1.13-1.fc11
>> ------------------------
>> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
>> - 1.13-1
>> ? Add another directory to avoid depending on unowned stuff
>> ? use it to put the fontconfig examples in a better place
>
> Two new symbols! L33t.
>

The first one does not display for me.  :-(  All I see is a square
with 27c3 inside.

Am I missing a font or something? I'm using the latest Firefox 3 in F10.


-- 
Mat Booth
www.matbooth.co.uk



From nikolay at vladimiroff.com  Tue Dec 23 14:15:06 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Tue, 23 Dec 2008 16:15:06 +0200
Subject: Encrypted home directory
In-Reply-To: <4950DC98.2070804@christensenplace.us>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
	<20081223102713.604b66cf@dhcp03.addix.net>
	<4950DC98.2070804@christensenplace.us>
Message-ID: <a2e85ed0812230615l2fa3e7cbs754e486bbe45bfb5@mail.gmail.com>

2008/12/23 Eric Christensen <eric at christensenplace.us>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ralf Ertzinger wrote:
>> Hi.
>>
>> On Tue, 23 Dec 2008 10:30:31 +0200, Nikolay Vladimirov wrote:
>>
>>> Ok. I'm not really sure about this but I think that full disk
>>> encryption on a software level
>>> with a key storng enough will bring some performance loss. And some
>>> people just want
>>> some confidential files to be encrypted.
>>
>> I'm running full-LV encryption for /home (and some other directories) in
>> my laptop, and the performance loss is nonexistant for me. Getting the
>> bits off the rotating rust takes quite longer then decrypting them.
>>
>> After all, all the cores in that thing have to be good for something.
>>
>> (Core Duo, 1.6GHz)
>>
> I've been running full disk encryption via LUKS since F8 with a 6 year
> old laptop.  I don't see any noticeable performance loss.
>
> Just to comment on the whole disk versus just a folder in the /home,
> Windows did the same thing a number of years ago on XP (and since I
> believe but I don't know).  You could select a folder and "encrypt" it.
>  The crypto implementation was horrible and when people actually used it
> they never realized that they weren't getting ALL the sensitive data
> encrypted.  There will always be a cache or tmp file laying around in
> the clear that will contain sensitive information.
>
> The DoD didn't like the use of the folder level encryption and has sense
> mandated full disk encryption for all portable devices.  It saves the
> user from trying to figure out what is sensitive and what needs to be
> encrypted and breaking their storage schema just to put a specific file
> into a specific folder.  The user will ALWAYS miss something and will
> ALWAYS be left vulnerable.
>
> Thanks,
> Eric Christensen
> E-Mail: sparks at fedoraproject.org
> GPG Key: D74908ED
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklQ3JYACgkQL5V8yddJCO15uwCeP5YxqNlEwleCzl824t70Slq6
> 8/oAn1wwTK4AkWaYHje5PjCzYvn7JVHe
> =VI4A
> -----END PGP SIGNATURE-----
>

That seems reasonable. I really see two good paths to this data security thing:
1) Some hardware level encryption. Like in my thingpad I have some
trusted something thingie
and another hard drive security thing. This way there will be no
software complications.
2) Encrypted /home since all of the user's sensitive data should be there.

 It's good to have some notice like "Full disk encryption is more
secure" and "Note that some cache saved outside of the /home dir may
be visible ( swap, /tmp, stuff)" and "Using some BIOS setting stuff is
more secure".
Some benchmarks of encrypted stuff vs non encrypted will be nice to
know for sure about the performance loss.
And some info in the installation media about this stuff maybe taken
from "Security Guide" in the wiki will be nice.

Note: I'm not very competent in this whole encryption stuff. I'm just
offering some user point of view on this.



-- 
NV



From nicolas.mailhot at laposte.net  Tue Dec 23 14:21:19 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Dec 2008 15:21:19 +0100 (CET)
Subject: rawhide report: 20081223 changes
In-Reply-To: <9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
Message-ID: <c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>



Le Mar 23 d?cembre 2008 15:05, Mat Booth a ?crit :
>
> On Tue, Dec 23, 2008 at 1:12 PM, Richard Hughes <hughsient at gmail.com>
> wrote:
>> On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
>>> fontpackages-1.13-1.fc11
>>> ------------------------
>>> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject
>>> dot org>
>>> - 1.13-1
>>> ? Add another directory to avoid depending on unowned stuff
>>> ? use it to put the fontconfig examples in a better place
>>
>> Two new symbols! L33t.
>>
>
> The first one does not display for me.  :-(  All I see is a square
> with 27c3 inside.
>
> Am I missing a font or something? I'm using the latest Firefox 3 in
> F10.

It's a math symbol so you're probably missing one of the optional
distro math fonts.

-- 
Nicolas Mailhot



From Matt_Domsch at dell.com  Tue Dec 23 14:29:38 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Tue, 23 Dec 2008 08:29:38 -0600
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <1229767216.3616.17.camel@eagle.danny.cz>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
	<1229767216.3616.17.camel@eagle.danny.cz>
Message-ID: <20081223142938.GA30670@auslistsprd01.us.dell.com>

On Sat, Dec 20, 2008 at 11:00:16AM +0100, Dan Hor?k wrote:
> > wxGTK-2.8.9-3.fc11 (build/make) mattdm,sharkcz
> 
> probably broken rawhide used as buildroot, it couldn't find gstreamer
> via pkg-config
> 
> it builds fine now in mock with recent rawhide

Wierd, as both gstreamer and gstreamer-devel did get installed, so the
.pc file was there.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From tim.lauridsen at googlemail.com  Tue Dec 23 14:39:47 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Tue, 23 Dec 2008 15:39:47 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <20081221140507.GD2791@free.fr>
References: <9020.1229838236@iinet.net.au> <494DE827.3020006@googlemail.com>
	<20081221140507.GD2791@free.fr>
Message-ID: <4950F833.7000103@googlemail.com>

Patrice Dumas wrote:
> On Sun, Dec 21, 2008 at 07:54:31AM +0100, Tim Lauridsen wrote:
>   
>>> So, over to the experts who actually build Fedora. Does the idea have merit?
>>>
>>>   
>>>       
>> This has been discussed many time on the list, the problem is that you  
>> cant have it both ways, you cant have a LTS release with the latest and  
>> greatest.
>> The only way a LTS release make sence is to freeze the code, test, test  
>> and test. And then backport security related fixes.
>> RHEL/Centos does this well and Fedora does  the latest and greatest part.
>>     
>
> It is untrue. You can have a distribution which begins with the latest 
> and greatest but is gradually stabilizing. You didn't read this proposal, 
> did you? It has been retired, but you saw the discussions, don't you?
> https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL
>
> --
> Pat
>
>   
No, i did not read then proposal and i read just read some of the 
discussion, these kind of threads quickly turns into a long pissing 
contest and I loose interest.
IMO you have 2 nice choices in Fedora and Centos/RHEL and trying to put 
something in the middle is just wasting limited resources.
But it is just my opion, you have another one, that is you right :)

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/60653502/attachment.htm>

From sgrubb at redhat.com  Tue Dec 23 14:45:54 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Tue, 23 Dec 2008 09:45:54 -0500
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <200812221513.06197.aportal@univ-montp2.fr>
References: <20081205195914.GB3227@free.fr>
	<200812221513.06197.aportal@univ-montp2.fr>
Message-ID: <200812230945.54638.sgrubb@redhat.com>

On Monday 22 December 2008 09:13:05 am Alain PORTAL wrote:
> > I think that fcron should be the default scheduler in fedora.
> > fcron, with the service fcron_watch_config activated should now be
> > 100% compatible with vixie-cron (cronie). The fcron_watch_config stuff
> > is a bit convoluted (3 scripts and one C program...) but should work.
> >
> > The advantages over cronie are the following:
> > * it also does what anacron does
> > * it has more features
> > * instead of waking up every minutes to look at config files, like
> >   cronie do, it uses inotify to watch the config. This should lead to
> >   less awaking and certainly be interesting for power saving in some
> >   situations

There are some disadvantages, too.

1) it does not support polyinstantiation - needed for MLS
2) It also does not send audit events based on denying a cron job. 
3) Its pam settings do not support the audit system out of the box. 
4) Its default pam settings need alignment with vixie-cron in general.

It would appear to not have had security reviews like vixie-cron has. In a few 
minutes I found what appears to be a potentially serious security problem. 
I've reported it upstream last week and no reply at all. I have not done a 
full code review like I would for our cert efforts, so there may be more 
problems waiting.


> Do you intend to package fcron for EPEL?

You have to be careful switching out core pieces of software that performs a 
security sensitive role. The lack of attacks on most of Fedora is due to 
years of review and feedback on code.

-Steve



From sundaram at fedoraproject.org  Tue Dec 23 14:52:04 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Dec 2008 20:22:04 +0530
Subject: rawhide report: 20081223 changes
In-Reply-To: <c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>	<1230037971.3558.38.camel@hughsie-work.lan>	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
Message-ID: <4950FB14.5030305@fedoraproject.org>

Nicolas Mailhot wrote:
> 
> It's a math symbol so you're probably missing one of the optional
> distro math fonts.

What's the benefit of using a particular non-standard math symbol in the 
spec file? It just makes it unreadable for a lot of people.  This is not 
some kind of sport.

Rahul



From fedora at matbooth.co.uk  Tue Dec 23 14:57:07 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 23 Dec 2008 14:57:07 +0000
Subject: rawhide report: 20081223 changes
In-Reply-To: <c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
Message-ID: <9497e9990812230657u2c231a16u3e537fda9cad37a@mail.gmail.com>

On Tue, Dec 23, 2008 at 2:21 PM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
>
>
> Le Mar 23 d?cembre 2008 15:05, Mat Booth a ?crit :
>>
>> On Tue, Dec 23, 2008 at 1:12 PM, Richard Hughes <hughsient at gmail.com>
>> wrote:
>>> On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
>>>> fontpackages-1.13-1.fc11
>>>> ------------------------
>>>> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject
>>>> dot org>
>>>> - 1.13-1
>>>> ? Add another directory to avoid depending on unowned stuff
>>>> ? use it to put the fontconfig examples in a better place
>>>
>>> Two new symbols! L33t.
>>>
>>
>> The first one does not display for me.  :-(  All I see is a square
>> with 27c3 inside.
>>
>> Am I missing a font or something? I'm using the latest Firefox 3 in
>> F10.
>
> It's a math symbol so you're probably missing one of the optional
> distro math fonts.
>
> --
> Nicolas Mailhot
>

I see. Seems silly to me to use symbols that you can't read with
whatever default fonts are installed (I'm not into typography, but I
like to read changelogs), but hey ho, it's your package.


-- 
Mat Booth
www.matbooth.co.uk



From marc_schwartz at comcast.net  Tue Dec 23 15:01:28 2008
From: marc_schwartz at comcast.net (Marc Schwartz)
Date: Tue, 23 Dec 2008 09:01:28 -0600
Subject: Encrypted home directory
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
	<20081223102713.604b66cf@dhcp03.addix.net>
	<4950DC98.2070804@christensenplace.us>
	<a2e85ed0812230615l2fa3e7cbs754e486bbe45bfb5@mail.gmail.com>
Message-ID: <m3skoflyuv.fsf@comcast.net>

"Nikolay Vladimirov" <nikolay at vladimiroff.com> writes:

> 2008/12/23 Eric Christensen <eric at christensenplace.us>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ralf Ertzinger wrote:
>>> Hi.
>>>
>>> On Tue, 23 Dec 2008 10:30:31 +0200, Nikolay Vladimirov wrote:
>>>
>>>> Ok. I'm not really sure about this but I think that full disk
>>>> encryption on a software level
>>>> with a key storng enough will bring some performance loss. And some
>>>> people just want
>>>> some confidential files to be encrypted.
>>>
>>> I'm running full-LV encryption for /home (and some other directories) in
>>> my laptop, and the performance loss is nonexistant for me. Getting the
>>> bits off the rotating rust takes quite longer then decrypting them.
>>>
>>> After all, all the cores in that thing have to be good for something.
>>>
>>> (Core Duo, 1.6GHz)
>>>
>> I've been running full disk encryption via LUKS since F8 with a 6 year
>> old laptop.  I don't see any noticeable performance loss.
>>
>> Just to comment on the whole disk versus just a folder in the /home,
>> Windows did the same thing a number of years ago on XP (and since I
>> believe but I don't know).  You could select a folder and "encrypt" it.
>>  The crypto implementation was horrible and when people actually used it
>> they never realized that they weren't getting ALL the sensitive data
>> encrypted.  There will always be a cache or tmp file laying around in
>> the clear that will contain sensitive information.
>>
>> The DoD didn't like the use of the folder level encryption and has sense
>> mandated full disk encryption for all portable devices.  It saves the
>> user from trying to figure out what is sensitive and what needs to be
>> encrypted and breaking their storage schema just to put a specific file
>> into a specific folder.  The user will ALWAYS miss something and will
>> ALWAYS be left vulnerable.
>>
>> Thanks,
>> Eric Christensen
>>
>
> That seems reasonable. I really see two good paths to this data security thing:
> 1) Some hardware level encryption. Like in my thingpad I have some
> trusted something thingie
> and another hard drive security thing. This way there will be no
> software complications.
> 2) Encrypted /home since all of the user's sensitive data should be there.
>
>  It's good to have some notice like "Full disk encryption is more
> secure" and "Note that some cache saved outside of the /home dir may
> be visible ( swap, /tmp, stuff)" and "Using some BIOS setting stuff is
> more secure".
> Some benchmarks of encrypted stuff vs non encrypted will be nice to
> know for sure about the performance loss.
> And some info in the installation media about this stuff maybe taken
> from "Security Guide" in the wiki will be nice.
>
> Note: I'm not very competent in this whole encryption stuff. I'm just
> offering some user point of view on this.


I am using dm-crypt/LUKS on F10 and have been doing so for several
releases.

Since F9, when Anaconda began supporting encrypted partitions during
installation, as opposed to the PITA manual set up previously, I have
been using LVM to configure my disk. So '/', '/home' and swap are all
encrypted as separate partitions within the LVM group configuration.

I have a separate /boot partition outside the LVM, since that cannot be
encrypted.

Using hdparm to test sequential reads on the encrypted and unencrypted
partitions, I get 30 MB/Sec on the former and 36 MB/Sec on the latter.
So I am looking at a 15-20% hit on throughput and that has been pretty
consistent over several releases.

This is on a 4 year old Dell Inspiron laptop, with a 3.2Ghz P4 and a
7200 rpm HD.

HTH,

Marc Schwartz




From nikolay at vladimiroff.com  Tue Dec 23 14:47:00 2008
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Tue, 23 Dec 2008 16:47:00 +0200
Subject: rawhide report: 20081223 changes
In-Reply-To: <c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
Message-ID: <a2e85ed0812230647w338dcbddp26f7a73d7ae4068a@mail.gmail.com>

2008/12/23 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>
>
> Le Mar 23 d?cembre 2008 15:05, Mat Booth a ?crit :
>>
>> On Tue, Dec 23, 2008 at 1:12 PM, Richard Hughes <hughsient at gmail.com>
>> wrote:
>>> On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
>>>> fontpackages-1.13-1.fc11
>>>> ------------------------
>>>> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject
>>>> dot org>
>>>> - 1.13-1
>>>> ? Add another directory to avoid depending on unowned stuff
>>>> ? use it to put the fontconfig examples in a better place
>>>
>>> Two new symbols! L33t.
>>>
>>
>> The first one does not display for me.  :-(  All I see is a square
>> with 27c3 inside.
>>
>> Am I missing a font or something? I'm using the latest Firefox 3 in
>> F10.
>
> It's a math symbol so you're probably missing one of the optional
> distro math fonts.
>
> --
> Nicolas Mailhot
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Ok, It's normal to post in the mail list about that stuff. But this is
getting annoying.
Why don't you use the same changelog convention as YOU did for the
previous package releases?
And going for an optional font package is also not fun. This whole
thing is not fun. Using random symbols proves nothing.
You're not the only one that will ever use or maintain that package.



-- 
NV



From bruno at wolff.to  Tue Dec 23 15:29:35 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 23 Dec 2008 09:29:35 -0600
Subject: Encrypted home directory
In-Reply-To: <a2e85ed0812230615l2fa3e7cbs754e486bbe45bfb5@mail.gmail.com>
References: <20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
	<20081223102713.604b66cf@dhcp03.addix.net>
	<4950DC98.2070804@christensenplace.us>
	<a2e85ed0812230615l2fa3e7cbs754e486bbe45bfb5@mail.gmail.com>
Message-ID: <20081223152935.GA9161@wolff.to>

On Tue, Dec 23, 2008 at 16:15:06 +0200,
  Nikolay Vladimirov <nikolay at vladimiroff.com> wrote:
> 
> That seems reasonable. I really see two good paths to this data security thing:
> 1) Some hardware level encryption. Like in my thingpad I have some
> trusted something thingie
> and another hard drive security thing. This way there will be no
> software complications.

Becareful, some of these implementations are very poor. It might keep a
typical individual out, but not someone willing to spend a little money.

> 2) Encrypted /home since all of the user's sensitive data should be there.

That is a bad assumption.

>  It's good to have some notice like "Full disk encryption is more
> secure" and "Note that some cache saved outside of the /home dir may
> be visible ( swap, /tmp, stuff)" and "Using some BIOS setting stuff is
> more secure".

What is the point? Someone has to do work to implement this. It is a poorer
solution than what already exists for at least most people.

> Some benchmarks of encrypted stuff vs non encrypted will be nice to
> know for sure about the performance loss.

It's not that high since the cpu calculations generally take less time
than pulling the info off the disk. And on modern cpus it's not that
taxing on the cpu.

> And some info in the installation media about this stuff maybe taken
> from "Security Guide" in the wiki will be nice.

There is a check box for encryption when you do an install.

> Note: I'm not very competent in this whole encryption stuff. I'm just
> offering some user point of view on this.



From notting at redhat.com  Tue Dec 23 15:30:21 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 23 Dec 2008 10:30:21 -0500
Subject: Packages adding groups in %pre/post
In-Reply-To: <alpine.DEB.1.10.0812230909460.26343@gotcha.dreamhost.com>
References: <1229836519.3861.44.camel@localhost.localdomain>
	<20081222154206.GD3104@nostromo.devel.redhat.com>
	<1229963514.3861.92.camel@localhost.localdomain>
	<20081222163556.GB7710@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0812221945480.19110@turre.koti.laiskiainen.org>
	<alpine.DEB.1.10.0812230909460.26343@gotcha.dreamhost.com>
Message-ID: <20081223153021.GA13138@nostromo.devel.redhat.com>

Panu Matilainen (pmatilai at laiskiainen.org) said: 
> And yes there are nasty loops:
> http://laiskiainen.org/tmp/fedora-rawhide-231208-loops.txt
> For a reproducer try:
> yum --disablerepo="*" --enablerepo=rawhide --installroot=<somewhere> install sed"
>
> This is so not going to work:
> [pmatilai at localhost badorder]$ rpm -qp --scripts  
> setup-2.7.5-3.fc11.noarch.rpm
> postinstall scriptlet (using /bin/sh):
> if [ `grep -c video /etc/group` -eq 0 ] ; then
>   groupadd -g 39 video
> fi
> if [ `grep -c audio /etc/group` -eq 0 ] ; then
>   groupadd -g 63 audio
> fi
>
> [pmatilai at localhost badorder]$ rpm -qp --requires setup-2.7.5-3.fc11.noarch.rpm |grep -v rpmlib
> /bin/sh
> config(setup) = 2.7.5-3.fc11
> grep

Bug 477769 filed.

Bill



From lesmikesell at gmail.com  Tue Dec 23 15:38:26 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 23 Dec 2008 09:38:26 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <4950C830.8040909@gmail.com>
References: <9020.1229838236@iinet.net.au>	<20081221155323.GC23993@shell.devel.redhat.com>	<20081221163526.GA2448@free.fr>	<20081221171438.GA6830@shell.devel.redhat.com>	<20081221173057.GG2448@free.fr>	<20081221174450.GB9876@shell.devel.redhat.com>	<494E942F.2000309@gmail.com>	<20081221192640.GB21625@shell.devel.redhat.com>	<494EA17F.6010708@gmail.com>	<ginp29$sir$2@ger.gmane.org>	<494F98B8.9080700@gmail.com>
	<4950C830.8040909@gmail.com>
Message-ID: <495105F2.1060008@gmail.com>

Adam Huffman wrote:
> 
>> And I don't see how the current system is not "usably-stable". Fedora 
>> just
>>
>> Except when it doesn't.  Would you bet your life on it working 
>> correctly  after every update?  You'd have lost several times on my 
>> machines, including an update very near the end of FC6's life - a 
>> point where there was no reason at all to be making changes likely to 
>> break things. And I'm not using it again for anything that matters 
>> until I have some reason to think it won't be repeated.
>>
> 
> You seem to expend a remarkable amount of energy on something you will 
> "never use again for anything that matters".

A lot of good engineering happens in fedora.  Eventually it affects 
other distributions where it does matter.  Unfortunately there seems to 
be an executive fiat keeping fedora itself from becoming usable in the 
way the RH development worked before fedora existed - back when people 
were attracted to Red Hat in the first place and the community that 
helped develop, test, and debug a release ended up with something that 
worked for some length of time at the end.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From dan at danny.cz  Tue Dec 23 15:42:17 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 23 Dec 2008 16:42:17 +0100
Subject: Fedora rawhide rebuild in mock status 2008-12-17 x86_64
In-Reply-To: <20081223142938.GA30670@auslistsprd01.us.dell.com>
References: <20081220030055.GA22944@mock.linuxdev.us.dell.com>
	<1229767216.3616.17.camel@eagle.danny.cz>
	<20081223142938.GA30670@auslistsprd01.us.dell.com>
Message-ID: <1230046937.3602.30.camel@eagle.danny.cz>

Matt Domsch p??e v ?t 23. 12. 2008 v 08:29 -0600:
> On Sat, Dec 20, 2008 at 11:00:16AM +0100, Dan Hor?k wrote:
> > > wxGTK-2.8.9-3.fc11 (build/make) mattdm,sharkcz
> > 
> > probably broken rawhide used as buildroot, it couldn't find gstreamer
> > via pkg-config
> > 
> > it builds fine now in mock with recent rawhide
> 
> Wierd, as both gstreamer and gstreamer-devel did get installed, so the
> .pc file was there.

Yea, but without the actual buildroot the real cause is hard to find.


		Dan




From bruno at wolff.to  Tue Dec 23 15:45:13 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 23 Dec 2008 09:45:13 -0600
Subject: Encrypted home directory
In-Reply-To: <1230023914.24768.3748.camel@beck.corsepiu.local>
References: <20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<1230020877.24768.3687.camel@beck.corsepiu.local>
	<20081223085812.GA14197@wolff.to>
	<1230023914.24768.3748.camel@beck.corsepiu.local>
Message-ID: <20081223154513.GA16521@wolff.to>

On Tue, Dec 23, 2008 at 10:18:34 +0100,
  Ralf Corsepius <rc040203 at freenet.de> wrote:
> I don't buy this. Even in this case, you actually will want to
> protect/encrypt sensitive data, not the whole disk.

Except that knowing where the sensitive data is isn't easy. Once you start
worrying about where stuff might have ended up, it's easier to encrypt the
whole disk.

> In most cases this would be passwds, ssh-keys and certain sensitive
> files. 
> 
> Of cause, you can achieve this by "whole disk encryption", but I would
> call this to be the "big hammer". Suitable for personal-laptops, but
> widely silly on desktops.

That depends on what your threats are. Laptops are more prone to becoming
available to people you don't want to have access than desktops. For
a lot of people encrypting a desktop is going to be unneccesary.

> 
> > To protect against other users, you probably want to use selinux.
> SELinux is aiming at shielding the system against mal-ware and against
> applications misbehaving. 
> 
> It does not help against unauthorized access on personal data, such as
> your personal on-line banking account access data, ssh-keys or
> confidential documents and similar.

It can be used to do that. By limiting what applications have access to
individual pieces of data you can make it harder for people to inadvertantly
give it out to the applications. Support for this is still pretty
rudimentary in current policies. But work is being done on confining
firefox.

> Similarly, encryption of supposed to be universally, globally accessable
> files (such as much of the OS) is widely meaningless. It doesn't buy you
> anything.

I agree . But it can be a pain to sort stuff out. If you keep home, etc, tmp
and var on separate partitions (or do some bind mounting tricks), then there
isn't a need to encrypt the rest of /.



From pertusus at free.fr  Tue Dec 23 15:54:54 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Dec 2008 16:54:54 +0100
Subject: use fcron as default scheduler in Fedora?
In-Reply-To: <200812230945.54638.sgrubb@redhat.com>
References: <20081205195914.GB3227@free.fr>
	<200812221513.06197.aportal@univ-montp2.fr>
	<200812230945.54638.sgrubb@redhat.com>
Message-ID: <20081223155454.GA2476@free.fr>

On Tue, Dec 23, 2008 at 09:45:54AM -0500, Steve Grubb wrote:
> 
> There are some disadvantages, too.
> 
> 1) it does not support polyinstantiation - needed for MLS

Is there something explaining polyinstantiation in the context of 
a cron scheduler?

> 2) It also does not send audit events based on denying a cron job. 

Right. I'll have a look at what cronie does and contact upstream on 
that, but I don't expect to be able to do that soon.

> 3) Its pam settings do not support the audit system out of the box. 
> 4) Its default pam settings need alignment with vixie-cron in general.

I had a look at the pam crond file, and indeed it looks good
while the fcron one is quite bad. I won't be able to change it, 
though for I don't have a fedora anymore.

I think it would be nice to have examples of pam files for fedora
for the different types of applications. Last time I had a look
there was a complete lack of consistency.

> It would appear to not have had security reviews like vixie-cron has. In a few 
> minutes I found what appears to be a potentially serious security problem. 
> I've reported it upstream last week and no reply at all. I have not done a 
> full code review like I would for our cert efforts, so there may be more 
> problems waiting.

In general upstream is rather reactive...

It looks like there was some security audit in 2004 since 4 vulnerabilities
were discovered.
 
> You have to be careful switching out core pieces of software that performs a 
> security sensitive role. The lack of attacks on most of Fedora is due to 
> years of review and feedback on code.

Is it a general statement or a statement about the cron scheduler?
It seems to me that some part of fedora are very young (though maybe 
they were audited a lot), like dbus, consolekit, hald, and have system-wide
security implications that are certainly as problematic as those of 
a cron scheduler.


In any case I can do some work on those issues, but so far nobody 
took fcron when I orphaned it. A maintainer in fedora would be a 
prerequisite for moving that issue along.

--
Pat



From vonbrand at inf.utfsm.cl  Tue Dec 23 16:31:49 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 23 Dec 2008 13:31:49 -0300
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <ginon3$sir$1@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221200505.GB10113@amd.home.annexia.org>
	<ginon3$sir$1@ger.gmane.org>
Message-ID: <200812231631.mBNGVnxX011068@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> Richard W.M. Jones wrote:
> > Alan's quite right.  I am hosting the MinGW RPMs temporarily on my own
> > site (something like 700-800 MBs worth):
> > 
> > http://www.annexia.org/tmp/mingw/fedora-10/
> 
> But a single OO.o update alone is as large as all of your repo.

Right.

> > But I spend under $30 / month on this server, and there is no
> > noticable load from the 565 people[1] synching their development
> > machines to it.

> And there would be a lot more than 565 people updating their old Fedora
> releases.

Says who?

> The infrastructure requirements for such a project would be several orders
> of magnitude higher than those for your MinGW repo or my CalcForge repo.
> There's no way a $30/month server would be able to provide the required
> bandwidth, maybe not even the required storage (but the bandwidth is
> proportional to size * download count, both of which are several orders of
> magnitude higher than for a small repository, so I expect the bandwidth to
> be the bigger issue, as it multiplies up, whereas the storage space is only
> dependent on the size of the packages).

Sorry but "I can't make it work because it uses too much resources" doesn't
jibe with "the resource requirements from Fedora infrastructure would be
minimal"
-- 
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 vonbrand at inf.utfsm.cl  Tue Dec 23 16:36:19 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 23 Dec 2008 13:36:19 -0300
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494F931C.4010508@nobugconsulting.ro>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
	<20081221210339.GK2448@free.fr>
	<20081222113759.GA4645@shell.devel.redhat.com>
	<494F931C.4010508@nobugconsulting.ro>
Message-ID: <200812231636.mBNGaJCH011101@laptop14.inf.utfsm.cl>

Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:
> Alan Cox wrote:
> > Alan
> > [1] Seriously show me five people planning to contribute to this and I'm happy
> > to sort out a corner in ftp.linux.org.uk.
> >
> >
> >
> I am not much of a programmer any more (hence, without help from
> someone more experienced,  backporting would probably be out of my
> league ) but I would gladly contribute as a packaging monkey if
> fedora-legacy would be revived. I still have RH 7.2, RH 7.2, FC1, FC2,
> FC6 and FC7 in production, so from time to time I have to recompile
> stuff anyway.

Why not move on?

> Not to mention that very often I compile stuff from Fedora for Centos
> 4 and 5

Integrate in EPEL?
-- 
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 vonbrand at inf.utfsm.cl  Tue Dec 23 16:43:08 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 23 Dec 2008 13:43:08 -0300
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gioi2m$de3$1@ger.gmane.org>
References: <20081222120651.GE4645@shell.devel.redhat.com>
	<1229948605.24768.1151.camel@beck.corsepiu.local>
	<20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
	<gioi2m$de3$1@ger.gmane.org>
Message-ID: <200812231643.mBNGh8qF011137@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:

[...]

> And I think pushing out security updates, even if they're completely
> untested, would still be better than no updates at all.

"Please don't make me move to a new set of packages" vs "dumping completely
untested packages that perhaps fix a security problem are OK"... something
sounds wrong here to me.

Also note that new developemt (and bug fixing, etc) in upstream projects
happens at the development tips (which there is usually only one), finding
and backporting security fixes only is a lot of work, and is /not/ trivial.
I'd say the risk of breakage (or bad or missed fixes) is a lot higher than
when just following upstream.
-- 
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 vonbrand at inf.utfsm.cl  Tue Dec 23 16:45:55 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 23 Dec 2008 13:45:55 -0300
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <494FD7E1.1040503@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>
Message-ID: <200812231645.mBNGjtF5011156@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:

[...]

> But, how many things have big security risks anyway?  In most cases
> the ones to worry about are just the kernel, network daemons, and suid
> programs - mostly things with standardized interfaces so backing up a
> version or two shouldn't break anything.

Any program that could be run by a privileged account (or even just any
local account) to process data from an untrusted source is a security risk.

I.e., most everything in Fedora.
-- 
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 lesmikesell at gmail.com  Tue Dec 23 16:54:33 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 23 Dec 2008 10:54:33 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <200812231645.mBNGjtF5011156@laptop14.inf.utfsm.cl>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>
	<200812231645.mBNGjtF5011156@laptop14.inf.utfsm.cl>
Message-ID: <495117C9.3070408@gmail.com>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
> [...]
> 
>> But, how many things have big security risks anyway?  In most cases
>> the ones to worry about are just the kernel, network daemons, and suid
>> programs - mostly things with standardized interfaces so backing up a
>> version or two shouldn't break anything.
> 
> Any program that could be run by a privileged account (or even just any
> local account) to process data from an untrusted source is a security risk.
> 
> I.e., most everything in Fedora.

Are you suggesting that it is feasible to eliminate that risk?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From vonbrand at inf.utfsm.cl  Tue Dec 23 17:02:52 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 23 Dec 2008 14:02:52 -0300
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <49501A0A.8050307@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com> <494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com> <494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com> <494FF02E.5060702@fedoraproject.org>
	<494FFC6A.7040105@gmail.com> <4950006F.6090808@fedoraproject.org>
	<gip23a$79o$1@ger.gmane.org> <49500FB7.7000602@gmail.com>
	<49501213.2040102@fedoraproject.org> <49501A0A.8050307@gmail.com>
Message-ID: <200812231702.mBNH2qdw011267@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:
> Rahul Sundaram wrote:
> >
> >> What is your optimal plan for someone to have local applications
> >> prepared and ready to take advantages of all the new developments
> >> in RHEL6 the day it is released?
> > This is really offtopic for this list and you should take it to a
> > RHEL list instead but many do participate in Fedora and move on to
> > RHEL beta releases and then to the GA release.
> 
> It is only offtopic if fedora is never intended to be used by people
> planning to move their work to RHEL and clones when the corresponding
> release appears.  If that is a planned use case, then the discussion
> belongs here.

"Move work" != "move all the distribution"

I've moved work from Fedora to CentOS, even from rawhide Fedora to
next-to-last CentOS, no big problem really.

Moving our servers from Fedora to CentOS required reinstall from scratch,
and porting some data from backups. Did take a lot of work, but was done
once. Since we just updated the operating systems when we were ready for it
(mostly had time to check it out, and do any required changes, and test).

If you need stability, go for RHEL or CentOS + EPEL. If you want a
technology preview, go for Fedora (even rawhide). If you need both at the
same time on the same machine...
-- 
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 jspaleta at gmail.com  Tue Dec 23 17:04:41 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 23 Dec 2008 08:04:41 -0900
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <495117C9.3070408@gmail.com>
References: <20081222132828.GB4934@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com>
	<200812231645.mBNGjtF5011156@laptop14.inf.utfsm.cl>
	<495117C9.3070408@gmail.com>
Message-ID: <604aa7910812230904o3afbea32l5486c2245aedda58@mail.gmail.com>

On Tue, Dec 23, 2008 at 7:54 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Are you suggesting that it is feasible to eliminate that risk?

The outright elimination of risk is never the true goal of a mature
risk management process.

Risk management is about defining what minimum acceptable levels of
risk are and then implementing a mix of engineering and policy
solutions which bring the risk inline with that acceptable level.
Sometimes that acceptable risk is zero, sometimes its not.  But you
never assume at the beginning.

-jef



From seg at haxxed.com  Tue Dec 23 17:43:53 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 23 Dec 2008 11:43:53 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <a2e85ed0812230647w338dcbddp26f7a73d7ae4068a@mail.gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<a2e85ed0812230647w338dcbddp26f7a73d7ae4068a@mail.gmail.com>
Message-ID: <1230054234.18082.180.camel@localhost.localdomain>

On Tue, 2008-12-23 at 16:47 +0200, Nikolay Vladimirov wrote:
> > It's a math symbol so you're probably missing one of the optional
> > distro math fonts.
> >
> > --
> > Nicolas Mailhot
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> 
> Ok, It's normal to post in the mail list about that stuff. But this is
> getting annoying.
> Why don't you use the same changelog convention as YOU did for the
> previous package releases?
> And going for an optional font package is also not fun. This whole
> thing is not fun. Using random symbols proves nothing.
> You're not the only one that will ever use or maintain that package.

It's all fun and games until someone busts out with 0x534D.

?????????????????????????????

(Though that's backwards, 0x5350 is the one that induces Godwin.)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/f9d8ad19/attachment.sig>

From jkeating at redhat.com  Tue Dec 23 17:46:49 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Dec 2008 09:46:49 -0800
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <giqgk7$hv7$1@ger.gmane.org>
References: <494A7A92.9020404@redhat.com>
	<1229619037.3472.26.camel@localhost.localdomain>
	<20081220145752.GA12856@victor.nirvana>
	<200812221335.54257.konrad@tylerc.org> <gip2g7$79o$3@ger.gmane.org>
	<1229993342.17128.45.camel@ignacio.lan>  <giqgk7$hv7$1@ger.gmane.org>
Message-ID: <1230054409.3313.21.camel@localhost.localdomain>

On Tue, 2008-12-23 at 12:04 +0100, Kevin Kofler wrote:
> How does it work on lib64 arches then? Those also have sitelib !=
> sitearch.

With python, if one part of a module is arch specific, but the rest is
noarch, the entire bundle goes into the arch specific directory, which
could be /usr/lib or /usr/lib64 depending on the arch.  Python doesn't
allow parts of a module to be in one path (/usr/share) and the other
part be in an arch specific path (/usr/lib64).

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/1dbb88fd/attachment.sig>

From drago01 at gmail.com  Tue Dec 23 17:47:07 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 23 Dec 2008 18:47:07 +0100
Subject: rawhide report: 20081223 changes
In-Reply-To: <c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
Message-ID: <f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>

On Tue, Dec 23, 2008 at 3:21 PM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
>
>
> Le Mar 23 d?cembre 2008 15:05, Mat Booth a ?crit :
>>
>> On Tue, Dec 23, 2008 at 1:12 PM, Richard Hughes <hughsient at gmail.com>
>> wrote:
>>> On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
>>>> fontpackages-1.13-1.fc11
>>>> ------------------------
>>>> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject
>>>> dot org>
>>>> - 1.13-1
>>>> ? Add another directory to avoid depending on unowned stuff
>>>> ? use it to put the fontconfig examples in a better place
>>>
>>> Two new symbols! L33t.
>>>
>>
>> The first one does not display for me.  :-(  All I see is a square
>> with 27c3 inside.
>>
>> Am I missing a font or something? I'm using the latest Firefox 3 in
>> F10.
>
> It's a math symbol so you're probably missing one of the optional
> distro math fonts.

Sorry but this starts to become annoying using weird symbols in the
spec file has no added value.
Why can't you just write a readable spec file like all other maintainers do?
Using some non default fonts makes it even worse.
Even when the fonts are displayed this makes the specfile "harder" to
read than using simple "-".



From mike at cchtml.com  Tue Dec 23 18:02:18 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Tue, 23 Dec 2008 12:02:18 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>	<1230037971.3558.38.camel@hughsie-work.lan>	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
Message-ID: <495127AA.9000207@cchtml.com>

-------- Original Message --------
Subject: Re: rawhide report: 20081223 changes
From: drago01 <drago01 at gmail.com>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 12/23/2008 11:47 AM

> 
> Sorry but this starts to become annoying using weird symbols in the
> spec file has no added value.
> Why can't you just write a readable spec file like all other maintainers do?
> Using some non default fonts makes it even worse.
> Even when the fonts are displayed this makes the specfile "harder" to
> read than using simple "-".
> 

How about an enhancement to RPM for changelog text format checking? I 
know RPM checks the date to make sure it is incremented, so why not 
expand that to read the changelog contents? ASCII-only text? This 
shouldn't add too much overhead or be that difficult to implement.

Better yet, since Fedora/Red Hat are not the only users of RPM, is there 
a policy file that RPM could read that could enable/disable changelog 
checking? Just my usual rambling.



From cra at WPI.EDU  Tue Dec 23 18:03:41 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 23 Dec 2008 13:03:41 -0500
Subject: rawhide report: 20081223 changes
In-Reply-To: <f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
Message-ID: <20081223180341.GD2925@angus.ind.WPI.EDU>

On Tue, Dec 23, 2008 at 06:47:07PM +0100, drago01 wrote:
> On Tue, Dec 23, 2008 at 3:21 PM, Nicolas Mailhot
> <nicolas.mailhot at laposte.net> wrote:
> >
> >
> > Le Mar 23 d?cembre 2008 15:05, Mat Booth a ?crit :
> >>
> >> On Tue, Dec 23, 2008 at 1:12 PM, Richard Hughes <hughsient at gmail.com>
> >> wrote:
> >>> On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
> >>>> fontpackages-1.13-1.fc11
> >>>> ------------------------
> >>>> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject
> >>>> dot org>
> >>>> - 1.13-1
> >>>> ? Add another directory to avoid depending on unowned stuff
> >>>> ? use it to put the fontconfig examples in a better place
> >>>
> >>> Two new symbols! L33t.
> >>>
> >>
> >> The first one does not display for me.  :-(  All I see is a square
> >> with 27c3 inside.
> >>
> >> Am I missing a font or something? I'm using the latest Firefox 3 in
> >> F10.
> >
> > It's a math symbol so you're probably missing one of the optional
> > distro math fonts.
> 
> Sorry but this starts to become annoying using weird symbols in the
> spec file has no added value.
> Why can't you just write a readable spec file like all other maintainers do?
> Using some non default fonts makes it even worse.
> Even when the fonts are displayed this makes the specfile "harder" to
> read than using simple "-".

I agree.  Consistency is key to readability.  I guess we'll have to go 
make a Packaging Guideline now that says what characters are 
appropriate for use as bullets in changelogs.



From cra at WPI.EDU  Tue Dec 23 18:04:06 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 23 Dec 2008 13:04:06 -0500
Subject: rawhide report: 20081223 changes
In-Reply-To: <495127AA.9000207@cchtml.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
	<495127AA.9000207@cchtml.com>
Message-ID: <20081223180406.GE2925@angus.ind.WPI.EDU>

On Tue, Dec 23, 2008 at 12:02:18PM -0600, Michael Cronenworth wrote:
> -------- Original Message --------
> Subject: Re: rawhide report: 20081223 changes
> From: drago01 <drago01 at gmail.com>
> To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
> Date: 12/23/2008 11:47 AM
>
>>
>> Sorry but this starts to become annoying using weird symbols in the
>> spec file has no added value.
>> Why can't you just write a readable spec file like all other maintainers do?
>> Using some non default fonts makes it even worse.
>> Even when the fonts are displayed this makes the specfile "harder" to
>> read than using simple "-".
>>
>
> How about an enhancement to RPM for changelog text format checking? I  
> know RPM checks the date to make sure it is incremented, so why not  
> expand that to read the changelog contents? ASCII-only text? This  
> shouldn't add too much overhead or be that difficult to implement.

rpmlint would be better for this kind of thing.



From drago01 at gmail.com  Tue Dec 23 18:06:35 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 23 Dec 2008 19:06:35 +0100
Subject: rawhide report: 20081223 changes
In-Reply-To: <20081223180341.GD2925@angus.ind.WPI.EDU>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
	<20081223180341.GD2925@angus.ind.WPI.EDU>
Message-ID: <f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>

On Tue, Dec 23, 2008 at 7:03 PM, Chuck Anderson <cra at wpi.edu> wrote:
> On Tue, Dec 23, 2008 at 06:47:07PM +0100, drago01 wrote:
>> On Tue, Dec 23, 2008 at 3:21 PM, Nicolas Mailhot
>> <nicolas.mailhot at laposte.net> wrote:
>> >
>> >
>> > Le Mar 23 d?cembre 2008 15:05, Mat Booth a ?crit :
>> >>
>> >> On Tue, Dec 23, 2008 at 1:12 PM, Richard Hughes <hughsient at gmail.com>
>> >> wrote:
>> >>> On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
>> >>>> fontpackages-1.13-1.fc11
>> >>>> ------------------------
>> >>>> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject
>> >>>> dot org>
>> >>>> - 1.13-1
>> >>>> ? Add another directory to avoid depending on unowned stuff
>> >>>> ? use it to put the fontconfig examples in a better place
>> >>>
>> >>> Two new symbols! L33t.
>> >>>
>> >>
>> >> The first one does not display for me.  :-(  All I see is a square
>> >> with 27c3 inside.
>> >>
>> >> Am I missing a font or something? I'm using the latest Firefox 3 in
>> >> F10.
>> >
>> > It's a math symbol so you're probably missing one of the optional
>> > distro math fonts.
>>
>> Sorry but this starts to become annoying using weird symbols in the
>> spec file has no added value.
>> Why can't you just write a readable spec file like all other maintainers do?
>> Using some non default fonts makes it even worse.
>> Even when the fonts are displayed this makes the specfile "harder" to
>> read than using simple "-".
>
> I agree.  Consistency is key to readability.  I guess we'll have to go
> make a Packaging Guideline now that says what characters are
> appropriate for use as bullets in changelogs.

yeah if common sense does not work we need a guideline.



From jkeating at redhat.com  Tue Dec 23 18:22:52 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Dec 2008 10:22:52 -0800
Subject: rawhide report: 20081223 changes
In-Reply-To: <f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
	<20081223180341.GD2925@angus.ind.WPI.EDU>
	<f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>
Message-ID: <1230056572.3313.22.camel@localhost.localdomain>

On Tue, 2008-12-23 at 19:06 +0100, drago01 wrote:
> > I agree.  Consistency is key to readability.  I guess we'll have to go
> > make a Packaging Guideline now that says what characters are
> > appropriate for use as bullets in changelogs.
> 
> yeah if common sense does not work we need a guideline.

Seems like that was his goal all along.  Terrorize us into forcing a
policy on what is or is not allowed there.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/614f1408/attachment.sig>

From pertusus at free.fr  Tue Dec 23 18:24:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Dec 2008 19:24:15 +0100
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <1230054409.3313.21.camel@localhost.localdomain>
References: <494A7A92.9020404@redhat.com>
	<1229619037.3472.26.camel@localhost.localdomain>
	<20081220145752.GA12856@victor.nirvana>
	<200812221335.54257.konrad@tylerc.org> <gip2g7$79o$3@ger.gmane.org>
	<1229993342.17128.45.camel@ignacio.lan>
	<giqgk7$hv7$1@ger.gmane.org>
	<1230054409.3313.21.camel@localhost.localdomain>
Message-ID: <20081223182415.GA3132@free.fr>

On Tue, Dec 23, 2008 at 09:46:49AM -0800, Jesse Keating wrote:
> 
> With python, if one part of a module is arch specific, but the rest is
> noarch, the entire bundle goes into the arch specific directory, which
> could be /usr/lib or /usr/lib64 depending on the arch.  Python doesn't
> allow parts of a module to be in one path (/usr/share) and the other
> part be in an arch specific path (/usr/lib64).

Indeed, but even fully noarch modules go in /usr/lib instead of 
/usr/share. 

It is fine for mixed arch/noarch to be in %_libdir, but noarch
should be in %_datadir.

--
Pat



From kevin.kofler at chello.at  Tue Dec 23 18:26:08 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 23 Dec 2008 19:26:08 +0100
Subject: Stability and Release Cycles - An Idea
References: <9020.1229838236@iinet.net.au>
	<20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221200505.GB10113@amd.home.annexia.org>
	<ginon3$sir$1@ger.gmane.org>
	<200812231631.mBNGVnxX011068@laptop14.inf.utfsm.cl>
Message-ID: <girag0$n3$1@ger.gmane.org>

Horst H. von Brand wrote:

> Kevin Kofler <kevin.kofler at chello.at> wrote:
>> And there would be a lot more than 565 people updating their old Fedora
>> releases.
> 
> Says who?

Common sense. Just look at the amount of times this idea comes up. Or at the
amount of people still running F8.

        Kevin Kofler



From jspaleta at gmail.com  Tue Dec 23 18:26:51 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 23 Dec 2008 09:26:51 -0900
Subject: New font packaging guidelines
In-Reply-To: <bde9bd3070e4c8aa2d2d78165dd820ff.squirrel@arekh.dyndns.org>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
	<604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
	<bde9bd3070e4c8aa2d2d78165dd820ff.squirrel@arekh.dyndns.org>
Message-ID: <604aa7910812231026h1f0c1a90x72d0fbd23ee6ffca@mail.gmail.com>

On Tue, Dec 23, 2008 at 3:35 AM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> In Rawhide dejavu has been split in three packages so you only need to
> depend on the font family you actually need, not the full set.

I'll have to look at the default settings as shipped in the
matplotibrc file and add the corresponding dep.

-jef



From jkeating at redhat.com  Tue Dec 23 18:34:23 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Dec 2008 10:34:23 -0800
Subject: Usage of {_libdir} or {_lib} in noarch packages
In-Reply-To: <20081223182415.GA3132@free.fr>
References: <494A7A92.9020404@redhat.com>
	<1229619037.3472.26.camel@localhost.localdomain>
	<20081220145752.GA12856@victor.nirvana>
	<200812221335.54257.konrad@tylerc.org> <gip2g7$79o$3@ger.gmane.org>
	<1229993342.17128.45.camel@ignacio.lan> <giqgk7$hv7$1@ger.gmane.org>
	<1230054409.3313.21.camel@localhost.localdomain>
	<20081223182415.GA3132@free.fr>
Message-ID: <1230057263.3313.23.camel@localhost.localdomain>

On Tue, 2008-12-23 at 19:24 +0100, Patrice Dumas wrote:
> On Tue, Dec 23, 2008 at 09:46:49AM -0800, Jesse Keating wrote:
> > 
> > With python, if one part of a module is arch specific, but the rest is
> > noarch, the entire bundle goes into the arch specific directory, which
> > could be /usr/lib or /usr/lib64 depending on the arch.  Python doesn't
> > allow parts of a module to be in one path (/usr/share) and the other
> > part be in an arch specific path (/usr/lib64).
> 
> Indeed, but even fully noarch modules go in /usr/lib instead of 
> /usr/share. 
> 
> It is fine for mixed arch/noarch to be in %_libdir, but noarch
> should be in %_datadir.

I wasn't arguing for/against that, just explaining what was meant by
keeping modules together.  I'm sure upstream would have a lovely
conversation about putting things in /usr/share/ 

Even more fun to do that for Perl.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/34942d40/attachment.sig>

From lesmikesell at gmail.com  Tue Dec 23 17:17:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 23 Dec 2008 11:17:28 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <200812231702.mBNH2qdw011267@laptop14.inf.utfsm.cl>
References: <20081222132828.GB4934@orient.maison.lan>
	<20081222135939.GA2473@free.fr>
	<20081222140940.GA7789@orient.maison.lan>
	<494FA255.3060309@nobugconsulting.ro>
	<20081222143942.GA8592@orient.maison.lan>
	<494FBCE2.4050406@gmail.com>
	<20081222162146.GA10739@orient.maison.lan>
	<494FC25D.6020000@gmail.com>
	<20081222165528.GA13110@orient.maison.lan>
	<gioi2m$de3$1@ger.gmane.org>
	<20081222172622.GA13156@shell.devel.redhat.com>
	<494FD0CC.5090109@gmail.com> <494FD3DB.9090501@fedoraproject.org>
	<494FD7E1.1040503@gmail.com> <494FDA8C.3020207@fedoraproject.org>
	<494FE34B.1000906@gmail.com> <494FE4A2.5050604@fedoraproject.org>
	<494FEB4C.8020501@gmail.com> <494FF02E.5060702@fedoraproject.org>
	<494FFC6A.7040105@gmail.com> <4950006F.6090808@fedoraproject.org>
	<gip23a$79o$1@ger.gmane.org> <49500FB7.7000602@gmail.com>
	<49501213.2040102@fedoraproject.org> <49501A0A.8050307@gmail.com>
	<200812231702.mBNH2qdw011267@laptop14.inf.utfsm.cl>
Message-ID: <49511D28.4090901@gmail.com>

Horst H. von Brand wrote:
>
>> It is only offtopic if fedora is never intended to be used by people
>> planning to move their work to RHEL and clones when the corresponding
>> release appears.  If that is a planned use case, then the discussion
>> belongs here.
> 
> "Move work" != "move all the distribution"
> 
> I've moved work from Fedora to CentOS, even from rawhide Fedora to
> next-to-last CentOS, no big problem really.

So you weren't actually using any of the features that differentiate fedora?

> Moving our servers from Fedora to CentOS required reinstall from scratch,
> and porting some data from backups. Did take a lot of work, but was done
> once.

Once = once per user.  A lot of work for every user.

> If you need stability, go for RHEL or CentOS + EPEL. If you want a
> technology preview, go for Fedora (even rawhide). If you need both at the
> same time on the same machine...

Not both at the same time.  A development cycle where the community 
input during development results in features that end up being usable.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Tue Dec 23 18:40:27 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 23 Dec 2008 09:40:27 -0900
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <girag0$n3$1@ger.gmane.org>
References: <9020.1229838236@iinet.net.au>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221200505.GB10113@amd.home.annexia.org>
	<ginon3$sir$1@ger.gmane.org>
	<200812231631.mBNGVnxX011068@laptop14.inf.utfsm.cl>
	<girag0$n3$1@ger.gmane.org>
Message-ID: <604aa7910812231040m32ade6ccg81cdb218e6f942c7@mail.gmail.com>

On Tue, Dec 23, 2008 at 9:26 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Common sense. Just look at the amount of times this idea comes up. Or at the
> amount of people still running F8.

I myself am shackled with using a legacy Fc5 system that I can't
easily replace.  Did I just hear you wince?

Would I love to be able to get updates for it... sure. Would I be
helping to provide those updates. No.  Do I think its reasonable to
expect Fedora project to expend resources to provide those
updates..no.

-jef



From mike.cloaked at gmail.com  Tue Dec 23 20:58:43 2008
From: mike.cloaked at gmail.com (Mike)
Date: Tue, 23 Dec 2008 20:58:43 +0000 (UTC)
Subject: Encrypted home directory
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>	<494E8B53.4050005@redhat.com>	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<494EA7A6.6020009@sapience.com>
Message-ID: <loom.20081223T204914-268@post.gmane.org>

Mail Lists <lists <at> sapience.com> writes:

>   Remember also /tmp, /var/tmp and swap - where much a lovely secret can
> be found!
> 
>   I encrypt /home and /swap and I bind mount /tmp and /var/tmp from
> /home/tmp and /home/var/tmp for completeness. If you run certain
> services you may want to bind mount /var out of the encrypted partition
> as well.

Exactly so - I was running F9 on one machine using pretty much this scheme as a
test. Performance loss is hardly noticable, and security very much enhanced.

One thing that did frustrate me was that I ran the encryption from the install
but an option to keep the passphrase the same for the root and /opt partitions
was not available. It would be nice if the machine would boot up and request the
luks passphrase for the root partition but that the passphrase for the other
encrypted partitions was then stored on the root partition avoiding the need to
enter a passphrase twice. I have not tried the standard encrypted install on F10
yet so I don't know if such niceties have already been implemented?

Equally I had to manually change the system to put the swap partition passphrase
somewhere and not have it requested at boot time - which would have made for
three passphrase requests during boot!

One other issue with fully encrypted systems is that when updating to the next
version of Fedora the new DVD iso cannot be stored on the HD unless it is placed
in /boot unencrypted and sufficiently large to hold it. If not then presumably a
hard drive install cannot read the iso from an encrypted partition?

However given the number of laptop thefts in the news in the UK, and the bad
publicity that the availability of tens of millions of personal details
including passport numbers, bank account details etc can be easily obtained by
criminals from such stolen laptops is something worth protecting in encrypted
systems. Additionally to encrypting the filesystems easy creation (and
decryption with suitable passphrase) of encrypted usbkeys and CD/DVD would be
very nice to have available.

I have tested creating encrypted usbkeys in F9 and this worked well. CD
decryption for luks encrypted CDs was a little awkward in F9 - I don't know if
this is much different in F10?



From kevin at scrye.com  Tue Dec 23 22:07:42 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Tue, 23 Dec 2008 15:07:42 -0700
Subject: Remote access to a Fedora 10 machine
In-Reply-To: <3170f42f0812212329j33bb2be2l7bb3e66d14833156@mail.gmail.com>
References: <3170f42f0812212329j33bb2be2l7bb3e66d14833156@mail.gmail.com>
Message-ID: <20081223150742.059a670c@ohm.scrye.com>

On Mon, 22 Dec 2008 12:59:07 +0530
"Debarshi Ray" <debarshi.ray at gmail.com> wrote:

> Is there any way I could get access to a Fedora 10 (preferably 64-bit)
> system for running the odd Mock build and some testing of
> Review-O-Matic's [1] Mock related code? Preferred username would be
> 'rishi' and I can send you my SSH public key if needed.

I can probibly arrange that on a virtual. I might need  to take it down
to use the memory at times however. Would that be acceptable? 
(ie, if it's down, you would need to ping me to bring it up). 

If so, feel free to drop me a ssh key and I can add your account. 

> Thanks,
> Debarshi
> ----
> [1] http://fedorahosted.org/review-o-matic/

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/7ab3a882/attachment.sig>

From jspaleta at gmail.com  Tue Dec 23 22:30:54 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 23 Dec 2008 13:30:54 -0900
Subject: New font packaging guidelines
In-Reply-To: <604aa7910812231026h1f0c1a90x72d0fbd23ee6ffca@mail.gmail.com>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
	<604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
	<bde9bd3070e4c8aa2d2d78165dd820ff.squirrel@arekh.dyndns.org>
	<604aa7910812231026h1f0c1a90x72d0fbd23ee6ffca@mail.gmail.com>
Message-ID: <604aa7910812231430u69b22963pb1ee7be17433d613@mail.gmail.com>

On Tue, Dec 23, 2008 at 9:26 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> I'll have to look at the default settings as shipped in the
> matplotibrc file and add the corresponding dep.


It looks like its pre-configured to prefer bitstream fonts in its font
search algorithm. I can easily patch the default config to search for
the dejavu version instead.

thanks for the heads up. I should have this cleared up in rawhide in
the next couple of days.

Is policy compliance something which demands an update in f10 and f9?
I'm sensitive to the update churn rate issue, so I'm not planning on
updating f10 and f9 packages with this policy change unless a more
significant bug shows up as well that requires patching.  Unless of
course people feel strongly enough that f10 and f9 need to become
compliant asap.

-jef



From SteveD at redhat.com  Tue Dec 23 23:02:43 2008
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 23 Dec 2008 18:02:43 -0500
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <4947D751.7000806@cora.nwra.com>
References: <1229389958.3518.21.camel@localhost.localdomain>
	<4947D751.7000806@cora.nwra.com>
Message-ID: <49516E13.6070104@RedHat.com>

Sorry for coming to this discussion late... I still recovering from
5 days w/out power... 

Orion Poplawski wrote:
> Jesse Keating wrote:
>> Here is another example where maintainers need to coordinate more and
>> pay attention.
>>
>> https://admin.fedoraproject.org/updates/F9/FEDORA-2008-10000
>> (rpcbind-0.1.7-1.fc9) went into Fedora 9 updates testing on 11-22.  On
>> the 25th bodhi feedback showed that this requires selinux changes.
>>
>> https://admin.fedoraproject.org/updates/F9/FEDORA-2008-11122
>> (selinux-policy-3.3.1-115.fc9) went into Fedora 9 updates testing on
>> 12-10.  This was the build to fix rpcbind.
>>
>> On 12-10 rpcbind was submitted for stable.  On the same day, bodhi
>> feedback requested that this update not go out until the matching
>> selinux-policy went out to stable.
>>
>> On 12-11 rpcbind went into stable.
> 
> Yeah, this is what prompted my earlier post.  This also makes me wonder
> why I bother running updates-testing on some of my machines.  Seems like
> half the time I report an issue, the update gets pushed to stable anyways.
The reason I moved rpcbind to stable was I saw the selinux-policy-3.3.1-115
had been built and pushed to testing... So I guess I just assumed selinux-policy
would be push to stable as soon as I pushed rpcbind.... as soon as I realized
that was not the case, I started to lobbing the selinux-policy maintainer to
get the package pushed...

Another caveat was the people needing the new rpcbind package don't need or 
use selinux so I was getting pressure make the release.. After a number of 
days of waiting, seeing the fixed selinux package was available plus it
truly was an selinux bug (all rpcbind was wanted to so as a setuid() to a
non-root user) I decide to make the release... Pissing some people off and
pleasing others... (the story of my life! ;-) )

Is there really a clean way of handling something like this? It was
not apparent to me... 

steved.



From jkeating at redhat.com  Tue Dec 23 23:19:23 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Dec 2008 15:19:23 -0800
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <49516E13.6070104@RedHat.com>
References: <1229389958.3518.21.camel@localhost.localdomain>
	<4947D751.7000806@cora.nwra.com>  <49516E13.6070104@RedHat.com>
Message-ID: <1230074363.3513.7.camel@localhost.localdomain>

On Tue, 2008-12-23 at 18:02 -0500, Steve Dickson wrote:
> Is there really a clean way of handling something like this? It was
> not apparent to me... 

Multiple packages can be added to a single bodhi update request,
ensuring that they are pushed in unison.

Failing that, you could have waited until the policy package was
requested to go stable, so that they would be pushed together.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/613d6856/attachment.sig>

From dwmw2 at infradead.org  Tue Dec 23 23:20:26 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 23 Dec 2008 23:20:26 +0000
Subject: Becoming a co-maintainer.  How? (proftpd)
In-Reply-To: <20081219193853.GC2283@free.fr>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
Message-ID: <1230074426.12010.73.camel@macbook.infradead.org>

On Fri, 2008-12-19 at 20:38 +0100, Patrice Dumas wrote:
> 
> >   - As a 'provenpackager' would it be acceptable for me to push a
> new
> >     release of proftpd if I have commit access even though I'm not
> >     officially a maintainer?
> 
> This is also covered by a policy:
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages

Policy is a poor man's substitute for common sense. In response to the
original question -- I'd suggest that if there's a good reason for
wanting to ship a newer version, and if you've made a genuine attempt to
contact the maintainer, there's no reason not to go ahead and update it.

I would be very disappointed in any maintainer who got 'territorial'
about his/her packages for purely emotional reasons, rather than real
technical objections to your changes.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From jonstanley at gmail.com  Wed Dec 24 00:47:22 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Tue, 23 Dec 2008 19:47:22 -0500
Subject: Becoming a co-maintainer. How? (proftpd)
In-Reply-To: <20081220121718.GC2506@free.fr>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr> <20081219194825.GA16284@bludgeon.org>
	<494BFECE.4050003@gmail.com> <20081220004829.GB10679@free.fr>
	<494CC439.4070503@gmail.com> <20081220121718.GC2506@free.fr>
Message-ID: <da159fda0812231647k7b59f3f6s9da1163530ca3a3b@mail.gmail.com>

On Sat, Dec 20, 2008 at 7:17 AM, Patrice Dumas <pertusus at free.fr> wrote:

> Maybe the idea was to replace "Experienced packagers" by provenpackager
> group members? If so it should really be done. And it is not a small
> change, because the provenpackagers group is much bigger than the
> "Experienced packagers" group (though the SIG stuff allows for
> interpretation here, and there could be people considered to be
> "Experienced packagers" because they are in a SIG, though they are not
> provenpackagers).

So the discussion of the size of 'provenpackager' has come up many
times to FESCo.  What we were considering (but AFAIK haven't done yet)
is calling for voluntary removal of folks from 'provenpackager' who
were seeded in the group but don't need the access. There are 281
people in the group today. I'm prepared to send a group e-mail out to
this effect.

I'd like to try the first option and see where it gets us, but are
there any other options in the eyes of the community that would work?
We really want provenpackager to work the way that it was originally
intended.

Another option has been re-seeding the group with only sponsors as was
originally proposed, however I'm sorta on the fence about that one.
What do folks think?



From pertusus at free.fr  Wed Dec 24 00:59:45 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 24 Dec 2008 01:59:45 +0100
Subject: Becoming a co-maintainer. How? (proftpd)
In-Reply-To: <da159fda0812231647k7b59f3f6s9da1163530ca3a3b@mail.gmail.com>
References: <20081219192058.GA15838@bludgeon.org>
	<20081219193853.GC2283@free.fr>
	<20081219194825.GA16284@bludgeon.org>
	<494BFECE.4050003@gmail.com> <20081220004829.GB10679@free.fr>
	<494CC439.4070503@gmail.com> <20081220121718.GC2506@free.fr>
	<da159fda0812231647k7b59f3f6s9da1163530ca3a3b@mail.gmail.com>
Message-ID: <20081224005945.GD3132@free.fr>

On Tue, Dec 23, 2008 at 07:47:22PM -0500, Jon Stanley wrote:
> 
> So the discussion of the size of 'provenpackager' has come up many
> times to FESCo.  What we were considering (but AFAIK haven't done yet)
> is calling for voluntary removal of folks from 'provenpackager' who
> were seeded in the group but don't need the access. There are 281
> people in the group today. I'm prepared to send a group e-mail out to
> this effect.
> 
> I'd like to try the first option and see where it gets us, but are
> there any other options in the eyes of the community that would work?

I think that sending a mail to all the provenpackagers who are not
sponsors (nor release managers if it is easy, but since there are few 
and they are likely to be sponsor already) would indeed be right. In 
the mail I think that some emphasis should also be put on security.

--
Pat



From jspaleta at gmail.com  Wed Dec 24 01:26:27 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 23 Dec 2008 16:26:27 -0900
Subject: New font packaging guidelines
In-Reply-To: <604aa7910812231430u69b22963pb1ee7be17433d613@mail.gmail.com>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
	<604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
	<bde9bd3070e4c8aa2d2d78165dd820ff.squirrel@arekh.dyndns.org>
	<604aa7910812231026h1f0c1a90x72d0fbd23ee6ffca@mail.gmail.com>
	<604aa7910812231430u69b22963pb1ee7be17433d613@mail.gmail.com>
Message-ID: <604aa7910812231726u166a79dcx1f5bcf7eef15c582@mail.gmail.com>

On Tue, Dec 23, 2008 at 1:30 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> It looks like its pre-configured to prefer bitstream fonts in its font
> search algorithm. I can easily patch the default config to search for
> the dejavu version instead.

Okay looking more closely DejaVu fonts are in the default search for
several font families
The default font family is sans.  It does support serif and mono optionally.

Do I need to just dep on dejavu-fonts-sans? Or should I dep on all the
optional DejaVu fonts as well?

-jef



From rdieter at math.unl.edu  Wed Dec 24 01:32:29 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 23 Dec 2008 19:32:29 -0600
Subject: rawhide report: 20081223 changes
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
	<20081223180341.GD2925@angus.ind.WPI.EDU>
	<f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>
	<1230056572.3313.22.camel@localhost.localdomain>
Message-ID: <gis3dj$4sp$1@ger.gmane.org>

Jesse Keating wrote:

> On Tue, 2008-12-23 at 19:06 +0100, drago01 wrote:
>> > I agree.  Consistency is key to readability.  I guess we'll have to go
>> > make a Packaging Guideline now that says what characters are
>> > appropriate for use as bullets in changelogs.
>> 
>> yeah if common sense does not work we need a guideline.
> 
> Seems like that was his goal all along.  Terrorize us into forcing a
> policy on what is or is not allowed there.

The existing guidelines seem to cover this case (ie, the changelog as discussed doesn't follow any of the suggested formats):
http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

That doesn't prevent concoction of something that technically does follow the format to introduce more odd stuff.

-- Rex



From mw_triad at users.sourceforge.net  Wed Dec 24 02:31:22 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 23 Dec 2008 20:31:22 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>	<1230037971.3558.38.camel@hughsie-work.lan>	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
Message-ID: <gis6tq$bnm$1@ger.gmane.org>

(Raw e-mail addresses removed, PLEASE don't add your own when replying; 
I get enough spam already.)

drago01 wrote:
> On Tue, Dec 23, 2008 at 3:21 PM, Nicolas Mailhot wrote:
>> Le Mar 23 d?cembre 2008 15:05, Mat Booth a ?crit :
>>> On Tue, Dec 23, 2008 at 1:12 PM, Richard Hughes wrote:
>>>> On Tue, 2008-12-23 at 10:55 +0000, Rawhide Report wrote:
>>>>> fontpackages-1.13-1.fc11
>>>>> ------------------------
>>>>> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject
>>>>> dot org>
>>>>> - 1.13-1
>>>>> ? Add another directory to avoid depending on unowned stuff
>>>>> ? use it to put the fontconfig examples in a better place
>>>> Two new symbols! L33t.
>>>>
>>> The first one does not display for me.  :-(  All I see is a square
>>> with 27c3 inside.
>>>
>>> Am I missing a font or something? I'm using the latest Firefox 3 in
>>> F10.
>> It's a math symbol so you're probably missing one of the optional
>> distro math fonts.
> 
> Sorry but this starts to become annoying using weird symbols in the
> spec file has no added value.

Starting? It's been annoying for some time now, and adds no value. If it 
was consistently the utf-8 bullet, well, maybe. As is, I'm sorry, but I 
have to agree with Richard Hughes classification of this behavior?.

1: http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/101291

> Why can't you just write a readable spec file like all other maintainers do?
> Using some non default fonts makes it even worse.
> Even when the fonts are displayed this makes the specfile "harder" to
> read than using simple "-".

+1.

-- 
Matthew
???????????????????????



From jamundso at gmail.com  Wed Dec 24 02:38:29 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Tue, 23 Dec 2008 20:38:29 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
Message-ID: <6d06ce20812231838r290c7e72g376b6e81ef3ff8ee@mail.gmail.com>

On 12/23/08, Rawhide Report <rawhide at fedoraproject.org> wrote:
...
> fontpackages-1.13-1.fc11
> ------------------------
> * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
> - 1.13-1
> ? Add another directory to avoid depending on unowned stuff
> ? use it to put the fontconfig examples in a better place

Please follow established guidelines at
http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
which clearly show the consistent use of the same leading character
for all sub-items.

When the approved guidelines also specify usage of only the "-"
character for sub-items, I will request you adjust your practices
accordingly.

Thank you for your cooperation in this matter.
jerry

-- 
To be named later.



From wolfy at nobugconsulting.ro  Wed Dec 24 04:13:57 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Wed, 24 Dec 2008 06:13:57 +0200
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <200812231636.mBNGaJCH011101@laptop14.inf.utfsm.cl>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
	<20081221210339.GK2448@free.fr>
	<20081222113759.GA4645@shell.devel.redhat.com>
	<494F931C.4010508@nobugconsulting.ro>
	<200812231636.mBNGaJCH011101@laptop14.inf.utfsm.cl>
Message-ID: <4951B705.5030000@nobugconsulting.ro>

On 12/23/2008 06:36 PM, Horst H. von Brand wrote:
> Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:
>   
>> Alan Cox wrote:
>>     
>>> Alan
>>> [1] Seriously show me five people planning to contribute to this and I'm happy
>>> to sort out a corner in ftp.linux.org.uk.
>>>
>>>
>>>
>>>       
>> I am not much of a programmer any more (hence, without help from
>> someone more experienced,  backporting would probably be out of my
>> league ) but I would gladly contribute as a packaging monkey if
>> fedora-legacy would be revived. I still have RH 7.2, RH 7.2, FC1, FC2,
>> FC6 and FC7 in production, so from time to time I have to recompile
>> stuff anyway.
>>     
>
> Why not move on?
>   
Because they do their job just fine as they are. For instance my 
workstation in F7 behaves much better that a F-10 which fails to see 
it's DNS servers and 2-3 times a month I regret that I have installed F9 
instead of Centos 5 on the workstation used by my 70+ yrs old mother


>> Not to mention that very often I compile stuff from Fedora for Centos
>> 4 and 5
>>     
>
> Integrate in EPEL?
>   
When it makes sense and I have the time, I suggest the respective 
package maintainers to do that. Or I volunteer for co-maint. for EPEL 
branches. But sometimes my packages cannot be integrated in EPEL.
Generally speaking, I try to verify if any package I review is an EPEL 
candidate and/ or suggest the fixes needed (if / when I know how to, as 
I might have said in a previous life I was a programmer but a) I've 
never been a very good programmer b) I was using Borland C++ c) this 
happened a very long time ago).But I have compiled nedit for instance 
way before it landed in EPEL, it's one of the favorite editors in the 
company I work for and EL-5 missing it was a reason for many cryings and 
tears.
Anyway, I do not think that this thread should focus on EPEL, The 
problem from my point of view is "

Fedora 8 will be
end-of-life and no further updates, including security updates, will
be released at that time, and new builds will not be allowed in the buildsystem"

I fail to see why no update at all is a better policy than "we update what we can when we can, but we no longer officially support this vesion of the distribution. Please understand that you are in uncharted territory, we'll try to help as much as we can but you might be better by simply upgrading to a newer distro."



From debarshi.ray at gmail.com  Wed Dec 24 04:15:48 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 24 Dec 2008 09:45:48 +0530
Subject: Remote access to a Fedora 10 machine
In-Reply-To: <20081223150742.059a670c@ohm.scrye.com>
References: <3170f42f0812212329j33bb2be2l7bb3e66d14833156@mail.gmail.com>
	<20081223150742.059a670c@ohm.scrye.com>
Message-ID: <3170f42f0812232015j60a6100asc19908293ce83be5@mail.gmail.com>

> I can probibly arrange that on a virtual. I might need  to take it down
> to use the memory at times however. Would that be acceptable?
> (ie, if it's down, you would need to ping me to bring it up).

Okay, fine. Sending you the keys separately.

Thanks,
Debarshi



From fedoraproject at cyberpear.com  Wed Dec 24 04:29:34 2008
From: fedoraproject at cyberpear.com (James Cassell)
Date: Tue, 23 Dec 2008 23:29:34 -0500
Subject: Encrypted home directory
In-Reply-To: <m3skoflyuv.fsf@comcast.net>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
	<20081223102713.604b66cf@dhcp03.addix.net>
	<4950DC98.2070804@christensenplace.us>
	<a2e85ed0812230615l2fa3e7cbs754e486bbe45bfb5@mail.gmail.com>
	<m3skoflyuv.fsf@comcast.net>
Message-ID: <op.umnf16yi4bfjir@localhost.localdomain>

On Tue, 23 Dec 2008 10:01:28 -0500, Marc Schwartz  
<marc_schwartz at comcast.net> wrote:

>
> I have a separate /boot partition outside the LVM, since that cannot be
> encrypted.
> Using hdparm to test sequential reads on the encrypted and unencrypted
> partitions, I get 30 MB/Sec on the former and 36 MB/Sec on the latter.
> So I am looking at a 15-20% hit on throughput and that has been pretty
> consistent over several releases.

Could the performance difference here be due to the partitions being on  
different parts of the disk?  Throughput is higher on the outside of the  
disk (which is the logical beginning of the disk.)  I don't think you have  
done a fair benchmark.

-- 
James Cassell



From jamundso at gmail.com  Wed Dec 24 04:33:51 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Tue, 23 Dec 2008 22:33:51 -0600
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <4951B705.5030000@nobugconsulting.ro>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
	<20081221210339.GK2448@free.fr>
	<20081222113759.GA4645@shell.devel.redhat.com>
	<494F931C.4010508@nobugconsulting.ro>
	<200812231636.mBNGaJCH011101@laptop14.inf.utfsm.cl>
	<4951B705.5030000@nobugconsulting.ro>
Message-ID: <6d06ce20812232033g7539d750y78c2654cb11c16a5@mail.gmail.com>

On 12/23/08, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:
> I fail to see why no update at all is a better policy than "we update what
> we can when we can, but we no longer officially support this vesion of the
> distribution. Please understand that you are in uncharted territory, we'll
> try to help as much as we can but you might be better by simply upgrading to
> a newer distro."

Correct, you "fail to see". Take a broader, more open-minded, look at
what defines "we", and "what", and "when" in the above statement.
I'd really rather find "Upgrade to the latest", as opposed to finding
"Here's our wishy-washy state, hope for the best".

jerry

-- 
To be named later.



From seg at haxxed.com  Wed Dec 24 04:47:35 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 23 Dec 2008 22:47:35 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <6d06ce20812231838r290c7e72g376b6e81ef3ff8ee@mail.gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<6d06ce20812231838r290c7e72g376b6e81ef3ff8ee@mail.gmail.com>
Message-ID: <1230094056.18082.192.camel@localhost.localdomain>

On Tue, 2008-12-23 at 20:38 -0600, Jerry Amundson wrote:
> On 12/23/08, Rawhide Report <rawhide at fedoraproject.org> wrote:
> ...
> > fontpackages-1.13-1.fc11
> > ------------------------
> > * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot org>
> > - 1.13-1
> > ? Add another directory to avoid depending on unowned stuff
> > ? use it to put the fontconfig examples in a better place
> 
> Please follow established guidelines at
> http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
> which clearly show the consistent use of the same leading character
> for all sub-items.
> 
> When the approved guidelines also specify usage of only the "-"
> character for sub-items, I will request you adjust your practices
> accordingly.
> 
> Thank you for your cooperation in this matter.
> jerry

A lot of pissed in cornflakes in this thread. (And that other thread.
And a lot of threads lately...)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081223/d81892a5/attachment.sig>

From jamundso at gmail.com  Wed Dec 24 05:21:09 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Tue, 23 Dec 2008 23:21:09 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <1230094056.18082.192.camel@localhost.localdomain>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<6d06ce20812231838r290c7e72g376b6e81ef3ff8ee@mail.gmail.com>
	<1230094056.18082.192.camel@localhost.localdomain>
Message-ID: <6d06ce20812232121o28c95ed4y4f1d289d1c6ce146@mail.gmail.com>

On 12/23/08, Callum Lerwick <seg at haxxed.com> wrote:
> On Tue, 2008-12-23 at 20:38 -0600, Jerry Amundson wrote:
>> On 12/23/08, Rawhide Report <rawhide at fedoraproject.org> wrote:
>> ...
>> > fontpackages-1.13-1.fc11
>> > ------------------------
>> > * Mon Dec 22 17:00:00 2008 Nicolas Mailhot <nim at fedoraproject dot
>> > org>
>> > - 1.13-1
>> > ? Add another directory to avoid depending on unowned stuff
>> > ? use it to put the fontconfig examples in a better place
>>
>> Please follow established guidelines at
>> http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
>> which clearly show the consistent use of the same leading character
>> for all sub-items.
>>
>> When the approved guidelines also specify usage of only the "-"
>> character for sub-items, I will request you adjust your practices
>> accordingly.
>>
>> Thank you for your cooperation in this matter.
>> jerry
>
> A lot of pissed in cornflakes in this thread. (And that other thread.
> And a lot of threads lately...)

And "the beatings will continue, until moral improves". :-)

jerry

p.s. Safe and happy holidays to all!

-- 
To be named later.



From kevin.kofler at chello.at  Wed Dec 24 08:48:36 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 24 Dec 2008 09:48:36 +0100
Subject: Stability and Release Cycles - An Idea
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
	<20081221210339.GK2448@free.fr>
	<20081222113759.GA4645@shell.devel.redhat.com>
	<494F931C.4010508@nobugconsulting.ro>
	<200812231636.mBNGaJCH011101@laptop14.inf.utfsm.cl>
	<4951B705.5030000@nobugconsulting.ro>
Message-ID: <gist14$jf1$1@ger.gmane.org>

Manuel Wolfshant wrote:
> I fail to see why no update at all is a better policy than "we update what
> we can when we can, but we no longer officially support this vesion of the
> distribution. Please understand that you are in uncharted territory, we'll
> try to help as much as we can but you might be better by simply upgrading
> to a newer distro."

+1

        Kevin Kofler



From emmanuel.seyman at club-internet.fr  Wed Dec 24 09:04:05 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Wed, 24 Dec 2008 10:04:05 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <4951B705.5030000@nobugconsulting.ro>
References: <20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
	<20081221210339.GK2448@free.fr>
	<20081222113759.GA4645@shell.devel.redhat.com>
	<494F931C.4010508@nobugconsulting.ro>
	<200812231636.mBNGaJCH011101@laptop14.inf.utfsm.cl>
	<4951B705.5030000@nobugconsulting.ro>
Message-ID: <20081224090405.GA1450@orient.maison.lan>

* Manuel Wolfshant [24/12/2008 08:56] :
>
> I fail to see why no update at all is a better policy than "we update
> what we can when we can, but we no longer officially support this
> vesion of the distribution. Please understand that you are in uncharted
> territory, we'll try to help as much as we can but you might be better
> by simply upgrading to a newer distro."

The problem isn't so much deciding on a policy as it is making that
policy known to the users and allowing them to opt-in/opt-out to
whatever you're proposing.

Emmanuel



From aportal at univ-montp2.fr  Wed Dec 24 09:44:25 2008
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Wed, 24 Dec 2008 10:44:25 +0100
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <gist14$jf1$1@ger.gmane.org>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<4951B705.5030000@nobugconsulting.ro> <gist14$jf1$1@ger.gmane.org>
Message-ID: <200812241044.25933.aportal@univ-montp2.fr>

Le mercredi 24 d?cembre 2008 ? 09:48, Kevin Kofler a ?crit?:
> Manuel Wolfshant wrote:
> > I fail to see why no update at all is a better policy than "we update
> > what we can when we can, but we no longer officially support this vesion
> > of the distribution. Please understand that you are in uncharted
> > territory, we'll try to help as much as we can but you might be better by
> > simply upgrading to a newer distro."
>
> +1
>
>         Kevin Kofler

+1

Alain
-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From rjones at redhat.com  Wed Dec 24 09:44:28 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 24 Dec 2008 09:44:28 +0000
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <4951B705.5030000@nobugconsulting.ro>
References: <20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
	<20081221210339.GK2448@free.fr>
	<20081222113759.GA4645@shell.devel.redhat.com>
	<494F931C.4010508@nobugconsulting.ro>
	<200812231636.mBNGaJCH011101@laptop14.inf.utfsm.cl>
	<4951B705.5030000@nobugconsulting.ro>
Message-ID: <20081224094404.GA22578@amd.home.annexia.org>

On Wed, Dec 24, 2008 at 06:13:57AM +0200, Manuel Wolfshant wrote:
> But sometimes my packages cannot be integrated in EPEL.

This is the point.  It's lots of extra, unsexy work to backport newer
packages, updates and security fixes to EPEL.  That's what people pay
good money to Red Hat to do to get RHEL (or use CentOS).  Any 'Fedora
Legacy II' project will have to do the same thing, at the very least
with security patches.

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  Wed Dec 24 10:09:18 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 24 Dec 2008 10:09:18 +0000 (UTC)
Subject: rawhide report: 20081224 changes
Message-ID: <20081224100918.E3C3B1B8001@releng2.fedora.phx.redhat.com>

Compose started at Wed Dec 24 06:01:12 UTC 2008

New package frysk
        Frysk execution analysis and debugging tools
New package ldtp
        Desktop testing framework
New package libnetdude
        Management framework for pcap packet traces
New package libpcapnav
        Wrapper library for libpcap offering navigation inside of a tracefile
New package lua-rex
        Regular expression handling library for Lua
New package maatkit
        Essential command-line utilities for MySQL
New package nload
        Monitor Network Traffic and Bandwidth usage in real time
New package perl-Test-Compile
        Check whether Perl module files compile correctly
Removed package tcl-tile
Removed package tcldom
Removed package tclxml
Updated Packages:

Miro-1.2.8-4.fc11
-----------------
* Tue Dec 23 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1.2.8-4
- Rebuild against newer gecko 1.9.1


amqp-1.0.728142-2.fc11
----------------------
* Tue Dec 23 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0:1.0.728142-2
- Rebased to svn rev 728142


anaconda-11.5.0.3-1
-------------------
* Tue Dec 23 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.5.0.3-1
- Initialize domainname to None (#477831) (dcantrell)
- Do not import unused modules. (dcantrell)
- Call '/sbin/udevadm settle' instead of /sbin/udevsettle (dcantrell)

* Tue Dec 23 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.5.0.2-1
- Require latest pykickstart for repo command (clumens)
- Remove libdhcp* from scripts/upd-instroot (dcantrell)
- methodstr -> self.methodstr (dcantrell)
- Rewrite iface_ip2str() to use libnm-glib (dcantrell)
- Fix a few syntax error caugh by pychecker (hdegoede)
- Remove isys.e2fslabel() and isys.getraidsb() (dcantrell)


apt-0.5.15lorg3.95-0.git416.1.fc11
----------------------------------
* Tue Dec 23 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 0.5.15lorg3.95-0.git416.1
- Update to upstream snapshot to get something remotely working...
- Link to external Lua to match what rpm uses (#470728)
- Support varying filenames in repomd (#469805)

* Mon Dec 15 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.5.15lorg3.94-6
- Fix internal lua crash, link against system lua 5.1


bouml-doc-4.8.3-1
-----------------
* Mon Dec 15 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 4.8.3-1
- Version bump to 4.8.3. Closes Red Hat Bugzilla bug #472415.


cronie-1.2-5.fc11
-----------------
* Tue Dec 23 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 1.2-5
- 477100 NO_FOLLOW was removed, reload after change in symlinked
  crontab is needed, man updated.


db4-4.7.25-9.fc11
-----------------
* Tue Dec 23 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 4.7.25-9
- remove dual tcl-devel requirement
- nuke useless libtool hacks

* Mon Dec 22 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 4.7.25-8
- DB_ENV->lock_get may self deadlock if user defined locks
  are used and there is only one lock partition defined
  (upstream bz#16415)
- fix for dd segfaults (upstream bz#16541)
- reorder patches


dbus-1.2.4-2.fc11
-----------------

dstat-0.6.9-3.fc11
------------------
* Tue Dec 23 17:00:00 2008 Zdenek Prikryl <zprikryl at redhat.com> - 0.6.9-3
- Fixed wrong total disk counts (#476935)


electric-8.08-1.fc11
--------------------
* Tue Dec 23 17:00:00 2008 Chitlesh GOORAH <chitlesh [AT] fedoraproject DOT org> - 8.08-1
- new upstream release


gajim-0.12.1-1.fc11
-------------------
* Tue Dec 23 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.12.1-1
- Version bump to 0.12.1.
- /usr/share/gajim/src/gajim-{remote}.py need not contain shebangs nor have the
  executable bits.


geda-docs-20081220-1.fc11
-------------------------
* Sun Dec 21 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release


geda-examples-20081220-1.fc11
-----------------------------
* Sun Dec 21 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release


geda-gattrib-20081220-1.fc11
----------------------------
* Sun Dec 21 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release
- stripped off contents that upstream accepted from us.


geda-gnetlist-20081220-1.fc11
-----------------------------
* Sun Dec 21 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release


geda-gschem-20081220-1.fc11
---------------------------
* Sun Dec 21 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release
- stripped off contents that upstream accepted from us.


geda-gsymcheck-20081220-1.fc11
------------------------------
* Sun Dec 21 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release


geda-utils-20081220-1.fc11
--------------------------
* Sun Dec 21 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081220-1
- new upstream release


gmp-4.2.4-4.fc11
----------------
* Tue Dec 23 17:00:00 2008 Ivana Varekova <varekova at redhat.com> 4.2.4-4
- fix spec file


gnome-python2-desktop-2.24.1-2.fc11
-----------------------------------
* Tue Dec 23 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 2.24.1-2.fc11
- make build

* Fri Dec 19 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.24.1-1.fc11
- Update to 2.24.1
- Add patch for GNOME bug #564525 (build failure).

* Wed Dec 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.0-6
- Rebuild for new libgnome-desktop


gnome-python2-extras-2.19.1-27.fc11
-----------------------------------
* Tue Dec 23 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 2.19.1-27
- Another rebuild against new gecko


gnome-utils-2.25.0-3.fc11
-------------------------
* Mon Dec 22 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.0-3
- Update to 2.25.0


gtk-qt-engine-1.1-4.fc11
------------------------
* Tue Dec 23 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1:1.1-4
- SAL_GTK_USE_PIXMAPPAINT=1 (#450414, #475007)
- uninstalling gtk-qt-engine leaves gtk apps in ugly state (#473471)


gutenprint-5.2.3-1.fc11
-----------------------
* Tue Dec 23 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 5.2.3-1
- 5.2.3.


homebank-4.0.1-1.fc11
---------------------
* Wed Dec 24 17:00:00 2008 Johan Cwiklinski <johan AT x-tnd DOT be> 4.0.1-1
- 4.0.1


hplip-2.8.12-1.fc11
-------------------
* Tue Dec 23 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 2.8.12-1
- 2.8.12.


jd-2.1.0-0.5.rc081223.fc11
--------------------------
* Tue Dec 23 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.1.0-0.5.rc081223
- 2.1.0 rc 081223


kdebase-workspace-4.1.85-7.fc11
-------------------------------
* Tue Dec 23 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.85-7
- Obsoletes: kpowersave (kpowersave -> powerdevil upgrade path, F-11+)


kphotoalbum-3.2-0.7.20081007svn.fc11
------------------------------------
* Mon Dec 22 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.2-0.7.20081007svn
- BR: libkipi-devel >= 0.3.0


libsilc-1.1.8-2.fc11
--------------------
* Tue Dec 23 17:00:00 2008 Stu Tomlinson <stu at nosnilmot.com> 1.1.8-2
- Fix building with libtool 2.2

* Wed Dec  3 17:00:00 2008 Stu Tomlinson <stu at nosnilmot.com> 1.1.8-1
- Update to 1.1.8


libtranslate-0.99-17.fc11
-------------------------
* Mon Dec 22 17:00:00 2008 Dmitry Butskoy <Dmitry at Butskoy.name> - 0.99-17
- update fix-modules patch, more autotools to run
  (by Dwayne Bailey <dwayne at translate.org.za>)


lincity-ng-1.97-0.1.beta.fc11
-----------------------------
* Tue Dec 23 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.97-0.1.beta
- update to 1.97.beta


mail-notification-5.4-7.fc11
----------------------------
* Mon Dec 22 17:00:00 2008 Dmitry Butskoy <Dmitry at Butskoy.name> - 5.4-7
- rebuild with new gmime-2.4


mediawiki-1.13.3-42.fc11
------------------------
* Tue Dec 23 17:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 1.13.3-42
- Update to 1.13.3, closes RH bug #476621 (CVE-2008-5249,
  CVE-2008-5250, CVE-2008-5252 and CVE-2008-5687, CVE-2008-5688)


mono-sharpcvslib-0.35-7.fc11
----------------------------
* Tue Dec 23 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.35-7
- copy the right nunit22 lib

* Thu Dec 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.35-6
- Added BR mono-nunit22-devel instead of mono-nunit

* Thu Dec 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.35-5
- Fix BR for mono-nunit-devel and mono-devel
- Remove empty debug package

* Mon Dec 15 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.35-4
- rebuild


mythes-de-0.20081223-1.fc11
---------------------------
* Tue Dec 23 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081223-1
- latest version


nant-0.85-23.fc11
-----------------
* Tue Dec 23 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1:0.85-23
- undo bootstrapping hack
- readd BR mono-sharpcvslib-devel (yes, it is circular, mono is a mess)

* Tue Dec 23 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1:0.85-22.1
- bootstrapping hack
- don't monkey with patches, bad form

* Thu Dec 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 1:0.85-22
- rebuild
- removed BR mono-sharpcvslib-devel (circular dep with mono-sharpcvslib)


netpbm-10.35.57-3.fc11
----------------------
* Tue Dec 23 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 10.35.57-3
- unbreak ppmshadow and ppmrainbow (#476989)
- pnmmontage won't crash because of uninitialized memory usage


ochusha-0.6-1.fc11
------------------
* Wed Dec 24 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.6-1
- 0.6


p7zip-4.61-1.fc11
-----------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 4.61-1
- Update to 4.61.
- Update norar patch.
- Use asm for x86 too (nasm).


perl-HTML-Tagset-3.20-1.fc11
----------------------------
* Tue Dec 23 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 3.20-1
- update to 3.20


pidgin-guifications-2.16-2.fc11
-------------------------------
* Tue Dec 23 17:00:00 2008 Stu Tomlinson <stu at nosnilmot.com> 2.16-2
- Fix building with libtool 2.2


pykickstart-1.48-1.fc11
-----------------------
* Tue Dec 23 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 1.48-1
- Allow ignoring group metadata from repos, using a '--ignoregroups'
  boolean. (notting)
- Add initial support for F11.
- Specify the command versions in the handlers instead of making copies.
- Remove empty and pointless __init__ methods.
- Pass arguments to superclasses via *args and **kwargs, all the way up.
- Add removedKeywords and removedAttrs lists on Commands and Data.
- Fix version regexes to handle double digits and minor releases (jlaska).


python-matplotlib-0.98.5.2-1.fc11
---------------------------------
* Mon Dec 22 17:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> - 0.98.5-1
- Latest upstream release
- Strip out included fonts


python-qpid-0.4.728142-2.fc11
-----------------------------
* Tue Dec 23 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.4.728142-1
- Rebased to svn rev 728142


python-twisted-8.1.0-2.fc11
---------------------------
* Wed Jul 16 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Update to 8.1.0.
- Minor spec file cleanups.
- Merge back changes from Paul Howarth.


python-twisted-conch-8.1.0-2.fc11
---------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Update to 8.1.0.
- Merge back changes from Paul Howarth.
- Make sure the scriplets never return a non-zero exit status.
- Add tkinter requirement for tkconch (#440385).


python-twisted-core-8.1.0-2.fc11
--------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Re-introduce the python macro for parallel installable packages.
- Make sure the scriplet never returns a non-zero exit status.
- Remove dropin.cache file upon package removal.
- Merge back changes from Paul Howarth.


python-twisted-lore-8.1.0-2.fc11
--------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Update to 8.1.0.
- Merge back changes from Paul Howarth.
- Make sure the scriplets never return a non-zero exit status.


python-twisted-mail-8.1.0-2.fc11
--------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Update to 8.1.0.
- Merge back changes from Paul Howarth.
- Make sure the scriplets never return a non-zero exit status.


python-twisted-names-8.1.0-2.fc11
---------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Update to 8.1.0.
- Merge back changes from Paul Howarth.
- Make sure the scriplets never return a non-zero exit status.


python-twisted-news-8.1.0-2.fc11
--------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Update to 8.1.0.
- Merge back changes from Paul Howarth.
- Make sure the scriplets never return a non-zero exit status.


python-twisted-runner-8.0.0-2.fc11
----------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.0.0-2
- Update to 8.1.0.
- Merge back changes from Paul Howarth.


python-twisted-web-8.1.0-2.fc11
-------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Update to 8.1.0.
- Merge back changes from Paul Howarth.
- Make sure the scriplets never return a non-zero exit status.


python-twisted-words-8.1.0-2.fc11
---------------------------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.1.0-2
- Update to 8.1.0.
- Merge back changes from Paul Howarth.
- Make sure the scriplets never return a non-zero exit status.


qlandkarte-0.7.4-1.fc11
-----------------------
* Tue Dec 23 17:00:00 2008 Dan Horak <dan[at]danny.cz> 0.7.4-1
- upgrade to 0.7.4, the final version


qlandkartegt-0.9.2-1.fc11
-------------------------
* Tue Dec 23 17:00:00 2008 Dan Horak <dan[at]danny.cz> 0.9.2-1
- update to 0.9.2


qpidc-0.4.728142-1.fc10
-----------------------
* Tue Dec 23 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.4.728142-1
- Rebased to svn rev 728142
- Re-enable cluster, now using corosync


rhm-0.4.3030-1.fc10
-------------------
* Tue Dec 23 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.4.3030-1
- Rebased to svn rev 3030/728142


ruby-qpid-0.4.728142-1.fc11
---------------------------
* Tue Dec 23 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.4.728142-1
- Rebased to svn rev 728142


rubygem-actionmailer-2.2.2-1.fc11
---------------------------------
* Tue Dec 23 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 2.2.2-1
- New version


rubygem-actionpack-2.2.2-1.fc11
-------------------------------
* Tue Dec 23 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 2.2.2-1
- New version


rubygem-activeresource-2.2.2-1.fc11
-----------------------------------
* Tue Dec 23 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 2.2.2-1
- New version


rubygem-rails-2.2.2-1.fc11
--------------------------
* Tue Dec 23 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 2.2.2-1
- New version


swfdec-gnome-2.24.0-4.fc11
--------------------------
* Tue Dec 23 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 2.24.0-4
- Add patch to fix build. (#477771)

* Thu Nov 13 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.0-3
- Rebuild


system-config-kickstart-2.7.21-1.fc11
-------------------------------------
* Tue Dec 23 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 2.7.21-1
- Add "make bumpver" target from pykickstart.
- Translate spaces in timezones to underscores when reading and writing (#475129).


tcl-tclxml-3.2-4.fc11
---------------------
* Tue Dec 23 17:00:00 2008 Wart <wart at kobold.org> - 3.2-4
- Add additional Provides: and Obsoletes: to properly replace the old
  tclxml/tcldom packages


tcl-tileqt-0.4-0.3.b1.fc11
--------------------------
* Tue Dec 23 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.4-0.3.b1
- build against tile bits in tk 8.5


tracker-0.6.6-10.fc11
---------------------
* Tue Dec 23 17:00:00 2008 - Caol??n McNamara <caolanm at redhat.com> - 0.6.6-10
- make build

* Mon Dec 15 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.6.6-9
- Add libtool BR

* Mon Dec 15 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.6.6-8
- Update patch to actually apply, way to do releases often

* Mon Dec 15 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.6.6-7
- Add patch to port to GMime 2.4

* Wed Dec 10 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.6.6-6
- Rebuild for gmime dependency

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.6-5
- Rebuild for Python 2.6


xar-1.5.2-1.fc11
----------------
* Tue Dec 23 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.5.2-1
- Update to 1.5.2.
- Remove no longer needed install and memset patches.
- Disable newly built-by-default static lib and remove useless .la file.


xorg-x11-server-1.5.99.3-4.fc11
-------------------------------
* Wed Dec 24 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.5.99.3-4
- xserver-1.5.99.3-ddx-rules.patch: enable the DDX to set the rules for the
  core devices (#477712)
- Require xorg-x11-drv-evdev 2.1.0-3 for ABI.


Summary:
Added Packages: 8
Removed Packages: 3
Modified Packages: 71
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	e16-0.16.8.14-1.fc10.i386 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gtkmozembed-2.19.1-27.fc11.i386 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	ldtp-1.3.0-2.fc11.i386 requires python-statgrab
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	maatkit-2582-1.fc11.noarch requires perl(DBD::MySQL) >= 0:1.0
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mozvoikko-0.9.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	banshee-1.4.1-1.fc11.x86_64 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	blam-1.8.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.x86_64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gtkmozembed-2.19.1-27.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	ldtp-1.3.0-2.fc11.x86_64 requires python-statgrab
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	maatkit-2582-1.fc11.noarch requires perl(DBD::MySQL) >= 0:1.0
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mozvoikko-0.9.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.i386 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.i386 requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.x86_64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-python2-gtkmozembed-2.19.1-27.fc11.ppc requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	ldtp-1.3.0-2.fc11.ppc requires python-statgrab
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	maatkit-2582-1.fc11.noarch requires perl(DBD::MySQL) >= 0:1.0
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mozvoikko-0.9.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc requires libpython2.5.so.1.0
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gtkmozembed-2.19.1-27.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	ldtp-1.3.0-2.fc11.ppc64 requires python-statgrab
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	maatkit-2582-1.fc11.noarch requires perl(DBD::MySQL) >= 0:1.0
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mozvoikko-0.9.5-5.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	python-snack-2.2.10-6.fc10.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	rekall-python-2.4.6-5.fc10.ppc64 requires python(abi) = 0:2.5
	rekall-python-2.4.6-5.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts





From snecklifter at gmail.com  Wed Dec 24 12:50:23 2008
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 24 Dec 2008 12:50:23 +0000
Subject: Need package reviews for Exchange 2007 support
In-Reply-To: <1229969433.4528.12.camel@localhost.localdomain>
References: <1229963200.17396.11.camel@localhost.localdomain>
	<1229969433.4528.12.camel@localhost.localdomain>
Message-ID: <364d303b0812240450j54e4b8e9ta7b9cd54d94b90fe@mail.gmail.com>

2008/12/22 Tom spot Callaway <tcallawa at redhat.com>:
> On Mon, 2008-12-22 at 11:26 -0500, Matthew Barnes wrote:
>> Hey all,
>>
>> I'm trying to push Fedora's OpenChange feature [1] forward so that
>> Evolution (and possibly KDE PIM) can talk to Exchange 2007 servers.
>> I'm looking for some kind souls to review a few packages:
>>
>> Samba4:         https://bugzilla.redhat.com/show_bug.cgi?id=453083
>
> It's worth noting that this is currently blocked by FE-Legal, before
> anyone eagerly dives in.

It would be good to have the legal concerns raised added to the bug or
on the wiki page instead of just having FE-LEGAL put against it. I'm
really excited about having this support in F11 and only recently
Linux Format here in the U.K. noted that its omission in F10 was a
disappointment. I understand completely about the need for clearance
through legal but the next version of Samba alone is huge - if this
could be expedited I believe this would be of huge benefit.

Regards

-- 
Christopher Brown



From SteveD at redhat.com  Wed Dec 24 13:37:07 2008
From: SteveD at redhat.com (Steve Dickson)
Date: Wed, 24 Dec 2008 08:37:07 -0500
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <1230074363.3513.7.camel@localhost.localdomain>
References: <1229389958.3518.21.camel@localhost.localdomain>	<4947D751.7000806@cora.nwra.com>
	<49516E13.6070104@RedHat.com>
	<1230074363.3513.7.camel@localhost.localdomain>
Message-ID: <49523B03.9090103@RedHat.com>



Jesse Keating wrote:
> On Tue, 2008-12-23 at 18:02 -0500, Steve Dickson wrote:
>> Is there really a clean way of handling something like this? It was
>> not apparent to me... 
> 
> Multiple packages can be added to a single bodhi update request,
> ensuring that they are pushed in unison.
hmm... I did look for something like that but didn't see it...
I'll take another look...

> 
> Failing that, you could have waited until the policy package was
> requested to go stable, so that they would be pushed together.
I waited 4 or 5 days which annoyed people that didn't need
that policy package... so I pushed the packaged and started lobbying...
I thought that was a good compromise.

steved.



From Axel.Thimm at ATrpms.net  Wed Dec 24 13:46:14 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 24 Dec 2008 15:46:14 +0200
Subject: Updates to F8 (was: [Fedora Update] [stable] fakeroot-1.11-19.fc8)
In-Reply-To: <1229898973.3861.75.camel@localhost.localdomain>
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>
	<1229898973.3861.75.camel@localhost.localdomain>
Message-ID: <20081224134614.GB8769@victor.nirvana>

Hi,

On Sun, Dec 21, 2008 at 02:36:13PM -0800, Jesse Keating wrote:
> On Sun, 2008-12-21 at 21:54 +0000, updates at fedoraproject.org wrote:
> > athimm has requested the pushing of the following update stable:
> > 
> > ================================================================================
> >      fakeroot-1.11-19.fc8
> > ================================================================================
> >     Release: Fedora 8
> >      Status: pending
> >        Type: enhancement
> >       Karma: 0
> >     Request: stable
> >   Submitter: athimm
> >   Submitted: 2008-12-21 21:54:06
> >    Comments: athimm - 2008-12-21 21:54:07 (karma 0)
> >              This update has been submitted for stable
> > 
> >   http://admin.fedoraproject.org/updates/fakeroot-1.11-19.fc8
> > 
> 
> Why is there a major version change (1.9.7 -> 1.11.19) going directly
> into stable on F8 (which has days to live) without any information for
> users what so ever that this update is providing.  Please provide some
> details for users and reconsider if this update is really suitable for
> F8.

As others wrote, the comment part would be either bloated with miriads
of uninteresting bug fixes, or a trivial one like "updated to latest
upstream release".

There isn't anything significant standing out, yet some dependent
projects would like an upgrade. Mentioning this in the update notes
could flesh it out, but would be uninteresting to the non-consumers of
these projects. Anyway I'll try to make a better comment next time.

> http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users

Some projects are still based on F8, and of course we will drop
support for it, but until its EOL F8 is supposed to be well supported,
and F8 consumers are begging to push out fixes before it goes EOL -
obviously they do intend to remain longer on F8, something we don't
actively encourage, but if people are asking for this shortly before
Xmas I'm too soft to say nay. ;)

Otherwise we should consider an offcial two phase support scheme where
functionality/enhancements/minor bugs are phased out earlier than the
final EOL. That way packagers would have a target line of what makes
sense to backpackage and when to not. Currently everyone draws this
line arbitrary from the release of the next Fedora release to the
actual EOL date.

E.g. it boils down to different interpretations of what people
consider a live/supported release, and what that support means in
what proximity of the EOL date.

BTW having said all that there is indeed very high demand to keep F8
running longer than the usual Fedora release. Just noting and passing
on the observation.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/db274e20/attachment.sig>

From marc_schwartz at comcast.net  Wed Dec 24 14:07:36 2008
From: marc_schwartz at comcast.net (Marc Schwartz)
Date: Wed, 24 Dec 2008 08:07:36 -0600
Subject: Encrypted home directory
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
	<20081223102713.604b66cf@dhcp03.addix.net>
	<4950DC98.2070804@christensenplace.us>
	<a2e85ed0812230615l2fa3e7cbs754e486bbe45bfb5@mail.gmail.com>
	<m3skoflyuv.fsf@comcast.net> <op.umnf16yi4bfjir@localhost.localdomain>
Message-ID: <m3fxkdr7iv.fsf@comcast.net>

"James Cassell" <fedoraproject at cyberpear.com> writes:

> On Tue, 23 Dec 2008 10:01:28 -0500, Marc Schwartz
> <marc_schwartz at comcast.net> wrote:
>
>>
>> I have a separate /boot partition outside the LVM, since that cannot be
>> encrypted.
>> Using hdparm to test sequential reads on the encrypted and unencrypted
>> partitions, I get 30 MB/Sec on the former and 36 MB/Sec on the latter.
>> So I am looking at a 15-20% hit on throughput and that has been pretty
>> consistent over several releases.
>
> Could the performance difference here be due to the partitions being
> on different parts of the disk?  Throughput is higher on the outside
> of the  disk (which is the logical beginning of the disk.)  I don't
> think you have  done a fair benchmark.

Fair point and it is possible, but under prior releases (pre-F9), when I
had to do a manual config and I did not have all partitions other than
/boot encrypted, I got pretty similar results in throughput changes
across the partitions. There was a period of time when I did not have
'/' encrypted, but did have /home, swap, /tmp and /var encrypted as
separate partitions without using LVM.

Clearly a better comparison would compare the same partitions in an
unencrypted and encrypted configuration. Without going through some
config gyrations that's easier said than done.

I don't think that it is unreasonable to expect some level of
performance hit, albeit with multi-core systems, that should be lessened
and perhaps those who do not experience a notable reduction in throughput
are using such systems. I'll have one next year... :-)

Thanks James,

Marc





From mmcgrath at redhat.com  Wed Dec 24 14:16:43 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 24 Dec 2008 08:16:43 -0600 (CST)
Subject: Outage Notification - 2008-12-24 14:00 UTC
Message-ID: <alpine.LFD.2.00.0812240809400.3138@laptop.mmcgrath.net>

There will be an outage starting at 2008-12-24 14:00 UTC UTC, which will
last approximately ? hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2008-12-24 14:00 UTC'

Affected Services:

Buildsystem
DNS
Fedora Talk
Collaboration services (Gobby)

Unaffected Services:

CVS / Source Control
Database
Fedora Hosted
Fedora People
Mail
Mirror System
Torrent
Translation Services
Websites

Ticket Link:

https://fedorahosted.org/fedora-infrastructure/ticket/1090

Reason for Outage:

serverbeach1-3 went out this morning.  This happened a month ago from
electrical issues but there's no word on if this is the same thing or
related to that in any way.  Nigel has submitted a ticket to them to get
it looked at, generally they are very quick about fixing this, I'd be
surprised if this took more then an hour.  Having said that, we have no
information so the whole building might have fallen into a sink hole or
something.

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 vonbrand at inf.utfsm.cl  Wed Dec 24 15:38:50 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 24 Dec 2008 12:38:50 -0300
Subject: Join Fedora. Learn cartwheels. Jump through hoops.
In-Reply-To: <604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
References: <6d06ce20812211522n121e21baucc3609075a9eed1d@mail.gmail.com>
	<20081222032535.GJ12325@inocybe.teonanacatl.org>
	<6d06ce20812211955l431f3773i8e65a678967ad042@mail.gmail.com>
	<604aa7910812212002h57f56090j7ce64f3b4ee44fcc@mail.gmail.com>
	<6d06ce20812212014g7405d16fgcd6c893c13ff562@mail.gmail.com>
	<604aa7910812212035p6d9c4b31i1114f834b732a9cf@mail.gmail.com>
Message-ID: <200812241538.mBOFcoxc018648@laptop14.inf.utfsm.cl>

Jeff Spaleta <jspaleta at gmail.com> wrote:

[...]

> All I am asking is to provide us with some more specific feedback on
> how to rename the role that is currently titled OS Developer.  Its not
> enough to know that your confused by the current title. We need to
> know what would make sense to you as an alternative.

"Fedora Developer"? (here "Fedora" is the OS refered to, not just the kernel)
-- 
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 hughsient at gmail.com  Wed Dec 24 16:05:37 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 24 Dec 2008 16:05:37 +0000
Subject: rawhide report: 20081223 changes
In-Reply-To: <4950FB14.5030305@fedoraproject.org>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<4950FB14.5030305@fedoraproject.org>
Message-ID: <1230134737.30521.2.camel@hughsie-work.lan>

On Tue, 2008-12-23 at 20:22 +0530, Rahul Sundaram wrote:
> What's the benefit of using a particular non-standard math symbol in the 
> spec file? It just makes it unreadable for a lot of people.  This is not 
> some kind of sport.

Right, I think I can summarise this thread by saying that the vast
majority of people want Nicholas to use - as the bullet like everyone
else.

Nicholas, can you please stick to - in the future, and then I'll say no
more about it. I'll even buy you a beer. Thanks.

Richard.




From jkeating at redhat.com  Wed Dec 24 16:37:11 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Dec 2008 08:37:11 -0800
Subject: Updates to F8 (was: [Fedora Update] [stable]
 fakeroot-1.11-19.fc8)
In-Reply-To: <20081224134614.GB8769@victor.nirvana>
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>
	<1229898973.3861.75.camel@localhost.localdomain>
	<20081224134614.GB8769@victor.nirvana>
Message-ID: <1230136631.17296.13.camel@localhost.localdomain>

On Wed, 2008-12-24 at 15:46 +0200, Axel Thimm wrote:
> 
> As others wrote, the comment part would be either bloated with miriads
> of uninteresting bug fixes, or a trivial one like "updated to latest
> upstream release".

A link to where you can find the upstream release notes would actually
help here.

> There isn't anything significant standing out, yet some dependent
> projects would like an upgrade. Mentioning this in the update notes
> could flesh it out, but would be uninteresting to the non-consumers of
> these projects. Anyway I'll try to make a better comment next time.
> 
> >
> http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users
> 
> Some projects are still based on F8, and of course we will drop
> support for it, but until its EOL F8 is supposed to be well supported,
> and F8 consumers are begging to push out fixes before it goes EOL -
> obviously they do intend to remain longer on F8, something we don't
> actively encourage, but if people are asking for this shortly before
> Xmas I'm too soft to say nay. ;)

Having lots of user requests for the update is reasonable, and could
also be mentioned in the notes.  I just want to avoid people doing every
update on every branch whenever they can, even without user demand.

> Otherwise we should consider an offcial two phase support scheme where
> functionality/enhancements/minor bugs are phased out earlier than the
> final EOL. That way packagers would have a target line of what makes
> sense to backpackage and when to not. Currently everyone draws this
> line arbitrary from the release of the next Fedora release to the
> actual EOL date.

I support the general idea of this, a loose guideline, letting
maintainers make their own judgment.

> E.g. it boils down to different interpretations of what people
> consider a live/supported release, and what that support means in
> what proximity of the EOL date.
> 
> BTW having said all that there is indeed very high demand to keep F8
> running longer than the usual Fedora release. Just noting and passing
> on the observation.

Thanks for that.  One thing you didn't address though, why is this going
directly to stable?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/e2c1a1bb/attachment.sig>

From jkeating at redhat.com  Wed Dec 24 16:40:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Dec 2008 08:40:53 -0800
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <49523B03.9090103@RedHat.com>
References: <1229389958.3518.21.camel@localhost.localdomain>
	<4947D751.7000806@cora.nwra.com> <49516E13.6070104@RedHat.com>
	<1230074363.3513.7.camel@localhost.localdomain>
	<49523B03.9090103@RedHat.com>
Message-ID: <1230136853.17296.15.camel@localhost.localdomain>

On Wed, 2008-12-24 at 08:37 -0500, Steve Dickson wrote:
> I waited 4 or 5 days which annoyed people that didn't need
> that policy package... so I pushed the packaged and started lobbying...
> I thought that was a good compromise.

In that situation, you should comment in bodhi as to why you're going to
push it along even with negative karma sitting there.  Without doing
that, the people providing feedback to you feel like their feedback is
being ignored, and will have less motivation to do any testing/feedback
at all in the future.

Our testers are a precious precious resource, and should be treated as
such.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/1bdf4083/attachment.sig>

From bpepple at fedoraproject.org  Sun Dec 21 14:43:43 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Sun, 21 Dec 2008 09:43:43 -0500
Subject: December 2008 FESCo Election Results
Message-ID: <1229870623.2847.3.camel@localhost.localdomain>

Election Results for FESCo - Fedora 10 Cycle

Voting Period: 07 December 2008 00:00:00 UTC to 20 December 2008
23:59:59 UTC

Nominations:

* Dan Hor?k (sharkcz)
* Dominik Mierzejewski (rathann)
* Jarod Wilson (jwilson)
* Jon Stanley (jds2001)
* Josh Boyer (jwb)

Outcomes:

As defined in the election text, the four (4) candidate(s) with the
greatest number of votes will be elected for a full, 2 release term.

Information:

At close of voting there were:
169 valid ballots

Using the Fedora Range Voting method, each candidate could attain a
maximum of
845 votes (5*169).

Results:

1. Josh Boyer (jwb)			489
2. Dan Hor?k (sharkcz)			485
3. Jarod Wilson (jwilson)		485
4. Jon Stanley (jds2001)		453
*****
5. Dominik Mierzejewski (rathann)	396

As such, Josh Boyer, Dan Hor?k, Jarod Wilson and Jon Stanley are elected
to FESCo for a 2 release term as of January 7, 2009.

Btw, I would like to thank Matt Domsch and Nigel Jones for all the work
they did in setting up and running this election.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081221/28f37317/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From ivazqueznet at gmail.com  Wed Dec 24 17:09:35 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 24 Dec 2008 12:09:35 -0500
Subject: rpms/frysk/devel Makefile, 1.3, 1.4 README, 1.2, 1.3
	frysk.spec, 1.137, 1.138 sources, 1.55, 1.56 dead.package, 1.1, NONE
In-Reply-To: <20081224170338.C82AD70107@cvs1.fedora.phx.redhat.com>
References: <20081224170338.C82AD70107@cvs1.fedora.phx.redhat.com>
Message-ID: <1230138575.17128.105.camel@ignacio.lan>

On Wed, 2008-12-24 at 17:03 +0000, Andrew Cagney wrote:
> Author: cagney
> 
> Update of /cvs/pkgs/rpms/frysk/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19574
> 
> Added Files:
> 	Makefile README frysk.spec sources 
> Removed Files:
> 	dead.package 
> Log Message:
> * Tue Dec 23 2008 Andrew Cagney <andrew.cagney at gmail.com> - 0.4-4
> - Improve summaries.

You turn this package into a zombie, and the best commit message you can
think of is "Improve summaries"?

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/215cd172/attachment.sig>

From seg at haxxed.com  Wed Dec 24 17:16:42 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 24 Dec 2008 11:16:42 -0600
Subject: Encrypted home directory
In-Reply-To: <a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
Message-ID: <1230139002.18082.908.camel@localhost.localdomain>

On Mon, 2008-12-22 at 18:48 +0200, Nikolay Vladimirov wrote:
> However I find it simpler and safer to use hardware disk
> encryption(from the BIOS config) and a bunch of other thinkpad
> security stuff.

And what makes you think it's safer? 

The best info I can dig up is this:

http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-69621

So it seems the encryption is handled completely within the drive
itself. This means it can vary from manufacturer to manufacturer and
even drive to drive. More specifically, it could range from "quite solid
encryption" to "total crap" to "the drive is not encrypting at all and
is just lying to you". Do you have the source code to your drive
firmware?

No matter how good the encryption is, there is still the big unavoidable
hole called the passphrase. How long is your passphrase? What mechanisms
does the drive have to prevent brute forcing the passphrase? Does it
rate limit unlock attempts? Does it self destruct after N failures?

It appears some thinkpads can unlock with a finger scan. Just a finger
scan? Well that's a crock. Your biometric data is just sitting in the
CMOS somewhere, along with the key, waiting to be stolen. Your security
is only as good as its weakest link.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/3f0c9b9c/attachment.sig>

From jkeating at redhat.com  Wed Dec 24 17:33:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Dec 2008 09:33:07 -0800
Subject: rpms/frysk/devel Makefile, 1.3, 1.4 README, 1.2, 1.3
 frysk.spec, 1.137, 1.138 sources, 1.55, 1.56 dead.package, 1.1, NONE
In-Reply-To: <1230138575.17128.105.camel@ignacio.lan>
References: <20081224170338.C82AD70107@cvs1.fedora.phx.redhat.com>
	<1230138575.17128.105.camel@ignacio.lan>
Message-ID: <1230139987.17296.20.camel@localhost.localdomain>

On Wed, 2008-12-24 at 12:09 -0500, Ignacio Vazquez-Abrams wrote:
> 
> You turn this package into a zombie, and the best commit message you can
> think of is "Improve summaries"?

Frysk was accidentally dead packaged, andrew is bringing it back, and
while doing so, improving the old summaries (:

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/f16d8795/attachment.sig>

From seg at haxxed.com  Wed Dec 24 17:36:58 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 24 Dec 2008 11:36:58 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <1230134737.30521.2.camel@hughsie-work.lan>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<4950FB14.5030305@fedoraproject.org>
	<1230134737.30521.2.camel@hughsie-work.lan>
Message-ID: <1230140218.18082.917.camel@localhost.localdomain>

On Wed, 2008-12-24 at 16:05 +0000, Richard Hughes wrote:
> On Tue, 2008-12-23 at 20:22 +0530, Rahul Sundaram wrote:
> > What's the benefit of using a particular non-standard math symbol in the 
> > spec file? It just makes it unreadable for a lot of people.  This is not 
> > some kind of sport.
> 
> Right, I think I can summarise this thread by saying that the vast
> majority of people want Nicholas to use - as the bullet like everyone
> else.

Noisy minority fallacy. I for one don't think it really matters and if
anything has been an excellent exercise of our internationalization
capability. Look what it has done, it's tested the data flow from the
developers text editor, through CVS, through our build system, our
reporting tools, the mailing list, everyone's mail clients, RPM, yum,
PackageKit...

Testing IS a sport. Un-displayable characters means we should examine
our font support, not ban unicode.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/d2542f8e/attachment.sig>

From jkeating at redhat.com  Wed Dec 24 17:39:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Dec 2008 09:39:35 -0800
Subject: rawhide report: 20081223 changes
In-Reply-To: <1230140218.18082.917.camel@localhost.localdomain>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<4950FB14.5030305@fedoraproject.org>
	<1230134737.30521.2.camel@hughsie-work.lan>
	<1230140218.18082.917.camel@localhost.localdomain>
Message-ID: <1230140375.17296.21.camel@localhost.localdomain>

On Wed, 2008-12-24 at 11:36 -0600, Callum Lerwick wrote:
> Noisy minority fallacy. I for one don't think it really matters and if
> anything has been an excellent exercise of our internationalization
> capability. Look what it has done, it's tested the data flow from the
> developers text editor, through CVS, through our build system, our
> reporting tools, the mailing list, everyone's mail clients, RPM, yum,
> PackageKit...

Which could have easily been accomplished by the unicode bullet point.
Or maybe the existing unicode chars in the developer names.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/3c8ed3f4/attachment.sig>

From cmadams at hiwaay.net  Wed Dec 24 17:43:29 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 24 Dec 2008 11:43:29 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <1230140218.18082.917.camel@localhost.localdomain>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<4950FB14.5030305@fedoraproject.org>
	<1230134737.30521.2.camel@hughsie-work.lan>
	<1230140218.18082.917.camel@localhost.localdomain>
Message-ID: <20081224174329.GA1079254@hiwaay.net>

Once upon a time, Callum Lerwick <seg at haxxed.com> said:
> On Wed, 2008-12-24 at 16:05 +0000, Richard Hughes wrote:
> > On Tue, 2008-12-23 at 20:22 +0530, Rahul Sundaram wrote:
> > > What's the benefit of using a particular non-standard math symbol in the 
> > > spec file? It just makes it unreadable for a lot of people.  This is not 
> > > some kind of sport.
> > 
> > Right, I think I can summarise this thread by saying that the vast
> > majority of people want Nicholas to use - as the bullet like everyone
> > else.
> 
> Noisy minority fallacy.

In this particular case, I wouldn't necessarily say it is a minority.
It might be a majority of the people that regularly read changelog
entries that are complaining.

There is a de facto standard: use a "-" (ASCII 0x2D) as the "bullet" in
a RPM spec file changelog entry.  Is there any valid reason to use
anything else (especially characters that most people won't even be able
to see)?  Does there have to be a defined standard for every little
thing, or can people just exercise a little common sense and follow the
common practice (unless there is a good reason to do otherwise)?

This whole thing seems a little childish to me.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From tibbs at math.uh.edu  Wed Dec 24 19:10:24 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 24 Dec 2008 13:10:24 -0600
Subject: rawhide report: 20081224 changes
In-Reply-To: <20081224100918.E3C3B1B8001@releng2.fedora.phx.redhat.com>
References: <20081224100918.E3C3B1B8001@releng2.fedora.phx.redhat.com>
Message-ID: <ufabpv14cf3.fsf@epithumia.math.uh.edu>

> New package frysk
>         Frysk execution analysis and debugging tools

This was originally in Core, then it went out of the distro for a
while and it seems to be back in now.  It was never reviewed; its
merge review was closed because it was no longer in the distro.  It
probably should have been reviewed before being added back.

 - J<



From jkeating at redhat.com  Wed Dec 24 20:56:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Dec 2008 12:56:35 -0800
Subject: [Fedora Update] [stable] poker-engine-1.3.1-1.fc8
In-Reply-To: <20081224175640.8FB5320876F@bastion.fedora.phx.redhat.com>
References: <20081224175640.8FB5320876F@bastion.fedora.phx.redhat.com>
Message-ID: <1230152195.17296.25.camel@localhost.localdomain>

On Wed, 2008-12-24 at 17:56 +0000, updates at fedoraproject.org wrote:
> xulchris has requested the pushing of the following update stable:
> 
> ================================================================================
>      poker-engine-1.3.1-1.fc8
> ================================================================================
>     Release: Fedora 8
>      Status: pending
>        Type: enhancement
>       Karma: 0
>     Request: stable
>   Submitter: xulchris
>   Submitted: 2008-12-24 17:56:40
>    Comments: xulchris - 2008-12-24 17:56:40 (karma 0)
>              This update has been submitted for stable
> 
>   http://admin.fedoraproject.org/updates/poker-engine-1.3.1-1.fc8
> 

Why is this update, without any real information as to the version
upgrade, going directly to Stable, on Fedora 8 which only has a week or
so of life left.  What is so critical about this update that it has to
be rushed out?  Can you please provide some details and rational for the
update?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/c62b759b/attachment.sig>

From rodrigopadula at projetofedora.org  Wed Dec 24 21:11:35 2008
From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira)
Date: Wed, 24 Dec 2008 19:11:35 -0200
Subject: /*MerryChristmas.c*/
Message-ID: <4952A587.5000400@projetofedora.org>

/*MerryChristmas.c*/
void main (int argc, char* argv[])
{
    printf("\n Merry Christmas! \n");
    if (strcmp(argv[1],"girl") == 0)    /*general idea*/
        printf("Kisses! \n");
    else
        printf("Hugs! \n");
}

-- 

Rodrigo Padula de Oliveira
M.Sc. Student - COPPE/UFRJ
Fedora Community Manager - Latin America
http://www.proyectofedora.org





From paul at all-the-johnsons.co.uk  Wed Dec 24 23:53:30 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 24 Dec 2008 23:53:30 +0000
Subject: /*MerryChristmas.c*/
In-Reply-To: <4952A587.5000400@projetofedora.org>
References: <4952A587.5000400@projetofedora.org>
Message-ID: <1230162810.22690.4.camel@PB3.Linux>

Hi,

> /*MerryChristmas.c*/
> void main (int argc, char* argv[])

main has never and will never return anything other than an int. It's in
the standard!!!!

> {
>     printf("\n Merry Christmas! \n");
>     if (strcmp(argv[1],"girl") == 0)    /*general idea*/
>         printf("Kisses! \n");
>     else
>         printf("Hugs! \n");
> }

Ouch! What happens though if argv[1] is "Girl" or "gIrl" (you get the
idea). Surely something like

if (strcmp(tolower(argv[1])),"girl)

would make more sense and catch the problems. However, we don't take
into account here if argv[1] is null, so a catch is required..

Oh dear. I need sleep.

MERRY CHRISTMAS FOLKS!!!!!

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081224/0953ac90/attachment.sig>

From pemboa at gmail.com  Thu Dec 25 00:16:28 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 24 Dec 2008 18:16:28 -0600
Subject: /*MerryChristmas.c*/
In-Reply-To: <4952A587.5000400@projetofedora.org>
References: <4952A587.5000400@projetofedora.org>
Message-ID: <16de708d0812241616p45e4fab2xc1817c507d0020ec@mail.gmail.com>

On Wed, Dec 24, 2008 at 3:11 PM, Rodrigo Padula de Oliveira
<rodrigopadula at projetofedora.org> wrote:
> /*MerryChristmas.c*/
> void main (int argc, char* argv[])
> {
>    printf("\n Merry Christmas! \n");
>    if (strcmp(argv[1],"girl") == 0)    /*general idea*/
>        printf("Kisses! \n");
>    else
>        printf("Hugs! \n");
> }


#i!/bin/env python
import sys
print 'Kisses!' if len(sys.argv) == 2 and sys.argv[1].lower() ==
'girl' else 'Hugs!'

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From konrad at tylerc.org  Thu Dec 25 00:24:42 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 24 Dec 2008 16:24:42 -0800
Subject: /*MerryChristmas.c*/
In-Reply-To: <1230162810.22690.4.camel@PB3.Linux>
References: <4952A587.5000400@projetofedora.org>
	<1230162810.22690.4.camel@PB3.Linux>
Message-ID: <200812241624.42975.konrad@tylerc.org>

On Wednesday 24 December 2008 03:53:30 pm Paul wrote:
> Hi,
>
> > /*MerryChristmas.c*/
> > void main (int argc, char* argv[])
>
> main has never and will never return anything other than an int. It's in
> the standard!!!!
>
> > {
> >     printf("\n Merry Christmas! \n");
> >     if (strcmp(argv[1],"girl") == 0)    /*general idea*/
> >         printf("Kisses! \n");
> >     else
> >         printf("Hugs! \n");
> > }
>
> Ouch! What happens though if argv[1] is "Girl" or "gIrl" (you get the
> idea). Surely something like
>
> if (strcmp(tolower(argv[1])),"girl)

More like:
if (!strcasecmp(argv[1], "girl"))

> would make more sense and catch the problems. However, we don't take
> into account here if argv[1] is null, so a catch is required..

This is C, no catches. Check argc >= 2.

> Oh dear. I need sleep.
>
> MERRY CHRISTMAS FOLKS!!!!!
>
> TTFN
>
> Paul

Yup :).

-- 
Conrad Meyer <konrad at tylerc.org>




From rodrigopadula at projetofedora.org  Thu Dec 25 02:42:10 2008
From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira)
Date: Thu, 25 Dec 2008 00:42:10 -0200
Subject: /*MerryChristmas.c*/
In-Reply-To: <200812241624.42975.konrad@tylerc.org>
References: <4952A587.5000400@projetofedora.org>	<1230162810.22690.4.camel@PB3.Linux>
	<200812241624.42975.konrad@tylerc.org>
Message-ID: <4952F302.9000407@projetofedora.org>

Conrad Meyer escreveu:
> On Wednesday 24 December 2008 03:53:30 pm Paul wrote:
>> Hi,
>>
>>> /*MerryChristmas.c*/
>>> void main (int argc, char* argv[])
>> main has never and will never return anything other than an int. It's in
>> the standard!!!!
>>
>>> {
>>>     printf("\n Merry Christmas! \n");
>>>     if (strcmp(argv[1],"girl") == 0)    /*general idea*/
>>>         printf("Kisses! \n");
>>>     else
>>>         printf("Hugs! \n");
>>> }
>> Ouch! What happens though if argv[1] is "Girl" or "gIrl" (you get the
>> idea). Surely something like
>>
>> if (strcmp(tolower(argv[1])),"girl)
> 
> More like:
> if (!strcasecmp(argv[1], "girl"))
> 
>> would make more sense and catch the problems. However, we don't take
>> into account here if argv[1] is null, so a catch is required..
> 
> This is C, no catches. Check argc >= 2.
> 
>> Oh dear. I need sleep.
>>
>> MERRY CHRISTMAS FOLKS!!!!!
>>
>> TTFN
>>
>> Paul
> 
> Yup :).
> 


Nerds hehehe!!

Best regards!

-- 

Rodrigo Padula de Oliveira
M.Sc. Student - COPPE/UFRJ
Fedora Community Manager - Latin America
http://www.proyectofedora.org





From SteveD at redhat.com  Thu Dec 25 02:57:28 2008
From: SteveD at redhat.com (Steve Dickson)
Date: Wed, 24 Dec 2008 21:57:28 -0500
Subject: Coordination of updates and reading of bodhi comments
In-Reply-To: <1230136853.17296.15.camel@localhost.localdomain>
References: <1229389958.3518.21.camel@localhost.localdomain>	<4947D751.7000806@cora.nwra.com>
	<49516E13.6070104@RedHat.com>	<1230074363.3513.7.camel@localhost.localdomain>	<49523B03.9090103@RedHat.com>
	<1230136853.17296.15.camel@localhost.localdomain>
Message-ID: <4952F698.9090400@RedHat.com>



Jesse Keating wrote:
> On Wed, 2008-12-24 at 08:37 -0500, Steve Dickson wrote:
>> I waited 4 or 5 days which annoyed people that didn't need
>> that policy package... so I pushed the packaged and started lobbying...
>> I thought that was a good compromise.
> 
> In that situation, you should comment in bodhi as to why you're going to
> push it along even with negative karma sitting there.  Without doing
> that, the people providing feedback to you feel like their feedback is
> being ignored, and will have less motivation to do any testing/feedback
> at all in the future.
Obviously you have not check the log... I did make a comment about what
needed to be done.. 

> 
> Our testers are a precious precious resource, and should be treated as
> such.
I can't agree with you more... 

steved.



From rawhide at fedoraproject.org  Thu Dec 25 10:28:44 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 25 Dec 2008 10:28:44 +0000 (UTC)
Subject: rawhide report: 20081225 changes
Message-ID: <20081225102844.EC44B1F8259@releng2.fedora.phx.redhat.com>

Compose started at Thu Dec 25 06:01:10 UTC 2008

New package gxmms2
        A graphical audio player
New package perl-Hardware-Vhdl-Lexer
        Split VHDL code into lexical tokens
New package stun
        Implements a simple Stun Client
Updated Packages:

PyXML-0.8.4-12
--------------
* Wed Dec 24 17:00:00 2008 Johan Cwiklinski <johan AT x-tnd DOT be> - 0.8.4-12
- Patch for 'as' reserved keyword (bug #477783)


alt-ergo-0.8-4.fc11
-------------------
* Wed Dec 24 17:00:00 2008 Alan Dunn <amdunn at gmail.com> 0.8-4
- Rebuild: Source upstream appears to have changed even with same version number
  (seems like bug fix from examination of changes)
- Changed hardcoded version number in source string


augeas-0.3.5-1.fc11
-------------------
* Tue Dec 23 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 0.3.5-1
- New version


cairo-dock-2.0.0-0.3.svn1451_trunk.fc11
---------------------------------------
* Thu Dec 25 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1451
- Remove icons maybe under non-free copyright/license from Cairo-Penguin plugin
  (need ask)


enigma-1.01-6.3
---------------
* Wed Dec 24 17:00:00 2008 Wart <wart at kobold.org> - 1.01-6.3
- Replace bundled font with a symlink to an identical system font (BZ #477381)


frysk-0.4-4.fc11
----------------
* Tue Dec 23 17:00:00 2008 Andrew Cagney <andrew.cagney at gmail.com> - 0.4-4
- Improve summaries.


geeqie-1.0-0.11.alpha2.1307svn.fc11
-----------------------------------
* Wed Dec 24 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.0-0.11.alpha2.1307svn
- update to svn 1307 for "Safe delete"


hanazono-fonts-20081012-6.fc11
------------------------------
* Wed Dec 24 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 20081012-6
- Update the spec file to fit into new guideline. (#477395)


ipvsadm-1.25-2
--------------
* Wed Dec 24 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.25-2
- Fork the included init script to be (mostly) LSB compliant (#246955).

* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.25-1
- Prepare update to 1.25 for when devel will update to kernel 2.6.28.
- Build require libnl-devel and popt-devel (+ patch to fix popt detection).


keepalived-1.1.15-6.fc11
------------------------
* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.1.15-6
- Fork the init script to be (mostly for now) LSB compliant (#246966).


kernel-2.6.28-1.fc11
--------------------
* Wed Dec 24 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc9-git4

* Wed Dec 24 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28
  Drop gspca-git temporarily.

* Mon Dec 22 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-rc9-git3

* Mon Dec 22 17:00:00 2008 Bill Nottingham <notting at redhat.com>
- Fix linux/serial.h so it can be included from userspace (#476327)


ldtp-1.3.0-3.fc11
-----------------
* Wed Dec 24 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 1.3.0-3
- Replaced 'Requires: python-statgrab' with 'Requires: pystatgrab'.


libconfig-1.3.1-2.fc11
----------------------
* Wed Dec 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.3.1-2
- prevent multilib conflicts with the generated pdf


libev-3.51-1.fc11
-----------------
* Wed Dec 24 17:00:00 2008 Michal Nowak <mnowak at redhat.com> - 3.51-1
- 3.51


libgdiplus-2.2-4.RC1.20081224svn122059.fc11
-------------------------------------------
* Wed Dec 24 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-4.RC1.20081224svn122059
- Bump to RC1 branched svn


liblicense-0.8.1-1
------------------
* Tue Dec 23 17:00:00 2008 Asheesh Laroia <asheesh at creativecommons.org> - 0.8.1-1
- liblicense 0.8.1 upstream


lighttpd-1.4.20-6.fc11
----------------------
* Wed Dec 24 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.4.20-6
- Partially revert last change by creating a "spawn-fastcgi" symlink, so that
  nothing breaks currently (especially for EL).
- Install empty poweredby image on RHEL since the symlink's target is missing.
- Split spawn-fcgi off in its own sub-package, have fastcgi package require it
  to provide backwards compatibility.


maatkit-2582-2.fc11
-------------------
* Wed Dec 24 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 2582-2
- Fix DBD driver dependency


mediawiki-ParserFunctions-1.1.1-3.svn45003.fc11
-----------------------------------------------
* Wed Dec 24 17:00:00 2008 Ian Weller <ianweller at gmail.com> 1.1.1-3.svn45003
- Update to MediaWiki 1.13 compatible code
- Merry Christmas

* Wed May 21 18:00:00 2008 Ian Weller <ianweller at gmail.com> 1.1.1-2.20080521svn35164
- Update to mediawiki 1.11 compatible code


mono-2.2-14.RC1.20081223svn122032.fc11
--------------------------------------
* Tue Dec 23 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-14.RC1.20081223svn122032
- Remove ppc self-build parts and ppc reordering patch
- Update from svm
- Minor spec file cleanups


mono-tools-2.2-9.RC1.20081224svn122098.fc11
-------------------------------------------
* Wed Dec 24 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> -.2.2-9.RC1.20081224svn122098
- Bump to RC1 svn branch

* Fri Dec 19 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-8.pre3.20081219svn121827
- Update from svn
- Re-enable ppc build


monodevelop-1.9.1-6.pre1.20081224svn122090.fc11
-----------------------------------------------
* Wed Dec 24 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-7.pre1.20081224svn122090
- Update from svn

* Fri Dec 19 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-7.pre1.20081219svn121787
- Update from svn


neverball-1.4.0-12.fc11
-----------------------
* Tue Dec 23 17:00:00 2008 Wart <wart at kobold.org> - 1.4.0-12
- Replace bundled font with a symlink to an identical system font (BZ #477432)


ochusha-0.6-3.fc11
------------------

openoffice.org-3.0.1-14.2.fc11
------------------------------
* Tue Dec 23 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-14.2
- Workaround: rhbz#477174 recover metacity workarounds without hanging in
  gdk_x11_get_server_time
- add hyphen-bg
- Resolves: rhbz#477435 package opensymbol in a rpm of its own
- add openoffice.org-3.0.1.oooXXXXX.extensions.npapi.patch for new
  xulrunner headers


php-eaccelerator-0.9.5.3-2.fc11
-------------------------------
* Wed Dec 24 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1:0.9.5.3-2
- Update default cache dir to be ghosted and take care of creating it and
  changing default ownership in the %post scriplet (fixes #443407).


poker-engine-1.3.1-1.fc11
-------------------------
* Wed Dec 24 17:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.3.1-1
- Upstream sync


rekall-2.4.6-7.fc11
-------------------
* Wed Dec 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.4.6-7
- manually tell it where to find python includedir based on what we have
- enable support for mdb (thanks to mdbtools)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.4.6-6
- Rebuild for Python 2.6


sazanami-fonts-0.20040629-5.20061016.fc11
-----------------------------------------
* Thu Dec 25 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 0.20040629-5.20061016
- Update the spec file to fit into new guideline. (#477453)


tcl-snack-2.2.10-8.fc11
-----------------------
* Wed Dec 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.2.10-8
- fix missing BR: libXft-devel

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2.10-7
- Rebuild for Python 2.6


why-2.17-1.fc11
---------------
* Wed Dec 24 17:00:00 2008 Alan Dunn <amdunn at gmail.com> 2.17-1
- Upgrade to version 2.17 (bz: 477790)
- Add ownership of two directories common with Coq, but neither program requires the other (bz: 474016)
- Minor filename change in 2.17 (GPL -> LICENSE)
- Added back Coq .v files to match policy for Coq
- Changed directory structure re: jessie and krakatoa to match new structure in 2.17
- Minor changes to patches to ensure they still work in 2.17
- Corrected package location gwhy-icon.png (should only be in gwhy)

* Tue Aug  5 18:00:00 2008 Alan Dunn <amdunn at gmail.com> 2.14-2.1
- ExcludeArch ppc64 on Fedora 8 due to no ocaml.


wormux-0.8.2-2.fc11
-------------------
* Wed Dec 24 17:00:00 2008 Wart <wart at kobold.org> 0.8.2-2
- Add coreutils requirement for rpm post scripts
- Replace bundled font with a symlink to an identical system font (BZ #477484)


xmms-skins-1.2.10-19
--------------------
* Wed Dec 24 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1:1.2.10-19
- Don't copy zip files unnecessarily during build.


xorg-x11-drv-vmware-10.16.0-2.fc11
----------------------------------
* Wed Dec 24 17:00:00 2008 Dave Airlie <airlied at redhat.com> 10.16.0-2
- bump build for new server API


xsp-2.2-6.RC1.20081224svn122055.fc11
------------------------------------
* Wed Dec 24 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-6.RC1.20081224svn122055
- x86_64 libdir fix

* Wed Dec 24 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-5.RC1.20081224svn122055
- Added additional BRs

* Wed Dec 24 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-4.RC1.20081224svn122055
- Bump to RC1 branched svn
- Minor specfile changes

* Wed Dec 17 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-3.pre3.20081217svn121604
- bump to 2.2 preview 3
- move to svn for bug fixes

* Sat Dec  6 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-2.pre2
- bump to 2.2 preview 2
- use sed instead of patches


yasm-0.7.2-1.fc11
-----------------
* Wed Dec 24 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.7.2-1
- Update to 0.7.2.
- Remove useless /sbin/ldconfig calls, as we don't ship any shared library.
- Update summary.


Summary:
Added Packages: 3
Removed Packages: 0
Modified Packages: 36
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	e16-0.16.8.14-1.fc10.i386 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.i386 requires bitstream-vera-fonts
	enigma-1.01-6.3.i386 requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-python2-gtkmozembed-2.19.1-27.fc11.i386 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	maatkit-2582-2.fc11.noarch requires perl(DBD::MySQL) >= 0:1.0
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mozvoikko-0.9.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	neverball-1.4.0-12.fc11.i386 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts
	wormux-0.8.2-2.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.i386 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	banshee-1.4.1-1.fc11.x86_64 requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	blam-1.8.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.x86_64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.x86_64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.x86_64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gtkmozembed-2.19.1-27.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	maatkit-2582-2.fc11.noarch requires perl(DBD::MySQL) >= 0:1.0
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mozvoikko-0.9.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	neverball-1.4.0-12.fc11.x86_64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts
	wormux-0.8.2-2.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-1.4.1-1.fc11.ppc requires mono(Mono.Zeroconf) = 0:1.0.0.75
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc requires bitstream-vera-fonts
	enigma-1.01-6.3.ppc requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-python2-gtkmozembed-2.19.1-27.fc11.ppc requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	maatkit-2582-2.fc11.noarch requires perl(DBD::MySQL) >= 0:1.0
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mozvoikko-0.9.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	neverball-1.4.0-12.fc11.ppc requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts
	wormux-0.8.2-2.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	e16-0.16.8.14-1.fc10.ppc64 requires bitstream-vera-fonts
	e16-docs-0.16.8.0.1-2.fc10.noarch requires bitstream-vera-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.ppc64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-python2-gtkmozembed-2.19.1-27.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	maatkit-2582-2.fc11.noarch requires perl(DBD::MySQL) >= 0:1.0
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mozvoikko-0.9.5-5.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	neverball-1.4.0-12.fc11.ppc64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts
	wormux-0.8.2-2.fc11.ppc64 requires dejavu-fonts





From Axel.Thimm at ATrpms.net  Thu Dec 25 10:58:03 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 25 Dec 2008 12:58:03 +0200
Subject: Updates to F8 (was: [Fedora Update] [stable]
	fakeroot-1.11-19.fc8)
In-Reply-To: <1230136631.17296.13.camel@localhost.localdomain>
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>
	<1229898973.3861.75.camel@localhost.localdomain>
	<20081224134614.GB8769@victor.nirvana>
	<1230136631.17296.13.camel@localhost.localdomain>
Message-ID: <20081225105803.GA3403@victor.nirvana>

On Wed, Dec 24, 2008 at 08:37:11AM -0800, Jesse Keating wrote:
> On Wed, 2008-12-24 at 15:46 +0200, Axel Thimm wrote:
> A link to where you can find the upstream release notes would actually
> help here.

Indeed, but the project doesn't provide anything useful in that
respect. It is quite astonishing, that some intergral tools in the
Debian toolchain have rather litte public interfaces.

> > Otherwise we should consider an offcial two phase support scheme where
> > functionality/enhancements/minor bugs are phased out earlier than the
> > final EOL. That way packagers would have a target line of what makes
> > sense to backpackage and when to not. Currently everyone draws this
> > line arbitrary from the release of the next Fedora release to the
> > actual EOL date.
> 
> I support the general idea of this, a loose guideline, letting
> maintainers make their own judgment.

Probably the most important part is where to set this fuzzy date
between full support and maintenance support, so packagers have a
common notion of when to stop pushing updates to certain releases.

> Thanks for that.  One thing you didn't address though, why is this going
> directly to stable?

Previous updates (not only for fakeroot) showed that there isn't much
happening in testing, I have to do most of the testing locally or with
direct coordination with the other interested parties. Adding that a
later push from testing to stable a few days before EOL would be even
more alarming I became stable-trigger-happy. Turns out to be a bad
thing as any modification requests to bodhi (like ones resulting from
this thread) didn't get a chance to be molded in. I'll get back to
normal testing/stable procedures (I get more often complaints that the
packages remain too long in stable, now i ballanced it off :).

Happy Xmas!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081225/54385d20/attachment.sig>

From arjan at infradead.org  Thu Dec 25 11:23:06 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Thu, 25 Dec 2008 12:23:06 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <f6ca9fed0812220834x117458acoc9b6c1022a89b314@mail.gmail.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<200812172152.30869.ville.skytta@iki.fi>
	<20081218094440.3c13a7f3@infradead.org>
	<200812181847.35253.ville.skytta@iki.fi>
	<20081222115047.0acb4cb6@infradead.org>
	<f6ca9fed0812220834x117458acoc9b6c1022a89b314@mail.gmail.com>
Message-ID: <20081225122306.28c146c9@infradead.org>

On Mon, 22 Dec 2008 17:34:01 +0100
drago01 <drago01 at gmail.com> wrote:

> >
> > yeah assuming you optimize both. Right now neither are well
> > optimized; the boot part is known how to do ;)
> 
> what exactly are the changes that need to be done to get a 5-10
> second boot?
> 

the biggest thing that needs to be done is that a budget needs to be set
for the various pieces of the boot, that then has the desired target.

The rest is a consequence of that budget, and usually very local.
Yes sendmail needs to be sorted, cups, the selinux thing and a few
others.. but the time budget will make it very clear which these pieces
are.
In my experience, the individual pieces are not rocket science once the
budget is in place, there's no more excuses "but that other piece"... 

resource scheduling is a well understood thing too, be it sreadahead or
the readahead that fedora has right now. 

Yes parallel boot needs to be ignored (people who were at the plumbers
conference know that already)... it's counter productive. Asynchronous
actions are useful, but pure parallel is not.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From tcallawa at redhat.com  Thu Dec 25 14:05:33 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 25 Dec 2008 09:05:33 -0500
Subject: Need package reviews for Exchange 2007 support
In-Reply-To: <364d303b0812240450j54e4b8e9ta7b9cd54d94b90fe@mail.gmail.com>
References: <1229963200.17396.11.camel@localhost.localdomain>
	<1229969433.4528.12.camel@localhost.localdomain>
	<364d303b0812240450j54e4b8e9ta7b9cd54d94b90fe@mail.gmail.com>
Message-ID: <1230213933.24440.8.camel@localhost.localdomain>

On Wed, 2008-12-24 at 12:50 +0000, Christopher Brown wrote:

> It would be good to have the legal concerns raised added to the bug or
> on the wiki page instead of just having FE-LEGAL put against it. I'm
> really excited about having this support in F11 and only recently
> Linux Format here in the U.K. noted that its omission in F10 was a
> disappointment. I understand completely about the need for clearance
> through legal but the next version of Samba alone is huge - if this
> could be expedited I believe this would be of huge benefit.

There is a post on fedora-legal-list discussing this, I'm waiting to
hear back from Andrew Bartlett.

~spot



From henriquecsj at gmail.com  Thu Dec 25 17:30:18 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Thu, 25 Dec 2008 15:30:18 -0200
Subject: /*MerryChristmas.c*/
In-Reply-To: <4952F302.9000407@projetofedora.org>
References: <4952A587.5000400@projetofedora.org>
	<1230162810.22690.4.camel@PB3.Linux>
	<200812241624.42975.konrad@tylerc.org>
	<4952F302.9000407@projetofedora.org>
Message-ID: <4f629b520812250930u186a0d33rc6cd7287ef1b52c0@mail.gmail.com>

haha
Merry Xmas. =)

2008/12/25 Rodrigo Padula de Oliveira <rodrigopadula at projetofedora.org>

> Conrad Meyer escreveu:
> > On Wednesday 24 December 2008 03:53:30 pm Paul wrote:
> >> Hi,
> >>
> >>> /*MerryChristmas.c*/
> >>> void main (int argc, char* argv[])
> >> main has never and will never return anything other than an int. It's in
> >> the standard!!!!
> >>
> >>> {
> >>>     printf("\n Merry Christmas! \n");
> >>>     if (strcmp(argv[1],"girl") == 0)    /*general idea*/
> >>>         printf("Kisses! \n");
> >>>     else
> >>>         printf("Hugs! \n");
> >>> }
> >> Ouch! What happens though if argv[1] is "Girl" or "gIrl" (you get the
> >> idea). Surely something like
> >>
> >> if (strcmp(tolower(argv[1])),"girl)
> >
> > More like:
> > if (!strcasecmp(argv[1], "girl"))
> >
> >> would make more sense and catch the problems. However, we don't take
> >> into account here if argv[1] is null, so a catch is required..
> >
> > This is C, no catches. Check argc >= 2.
> >
> >> Oh dear. I need sleep.
> >>
> >> MERRY CHRISTMAS FOLKS!!!!!
> >>
> >> TTFN
> >>
> >> Paul
> >
> > Yup :).
> >
>
>
> Nerds hehehe!!
>
> Best regards!
>
> --
>
> Rodrigo Padula de Oliveira
> M.Sc. Student - COPPE/UFRJ
> Fedora Community Manager - Latin America
> http://www.proyectofedora.org
>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081225/af6033e8/attachment.htm>

From vonbrand at inf.utfsm.cl  Fri Dec 26 01:59:01 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 25 Dec 2008 22:59:01 -0300
Subject: Stability and Release Cycles - An Idea
In-Reply-To: <4951B705.5030000@nobugconsulting.ro>
References: <20081221155323.GC23993@shell.devel.redhat.com>
	<20081221163526.GA2448@free.fr>
	<20081221171438.GA6830@shell.devel.redhat.com>
	<20081221173057.GG2448@free.fr>
	<20081221174450.GB9876@shell.devel.redhat.com>
	<20081221175700.GI2448@free.fr>
	<20081221192300.GA21625@shell.devel.redhat.com>
	<20081221202110.GJ2448@free.fr>
	<20081221203312.GA30301@shell.devel.redhat.com>
	<20081221210339.GK2448@free.fr>
	<20081222113759.GA4645@shell.devel.redhat.com>
	<494F931C.4010508@nobugconsulting.ro>
	<200812231636.mBNGaJCH011101@laptop14.inf.utfsm.cl>
	<4951B705.5030000@nobugconsulting.ro>
Message-ID: <200812260159.mBQ1x1oJ011028@laptop14.inf.utfsm.cl>

Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:

[...]

> I fail to see why no update at all is a better policy than "we update
> what we can when we can, but we no longer officially support this vesion
> of the distribution. Please understand that you are in uncharted
> territory, we'll try to help as much as we can but you might be better by
> simply upgrading to a newer distro."

Because upgrading gives you some assurance that the stuff you depend on
_will_ be maintained. "Perhaps glaring problems will be fixed. Probably
not. If your box gets broken into, tough luck" is _not_ what I would like
people to take home as "Linux experience". Because "But I got it from
Fedora's site! They even shipped an update last month!!" /makes/ Fedora (at
least morally) liable if it goes bad.

Besides, keeping old stuff around for ages /is/ a resource commitment. For
no good reason, even.
-- 
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 peter at thecodergeek.com  Fri Dec 26 05:30:43 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Thu, 25 Dec 2008 21:30:43 -0800
Subject: Offline: Dec. 26 Through Dec. 29
Message-ID: <1230269443.3217.16.camel@localhost.localdomain>

Hi, all.

Apologies for the severely short notice, but I'm spending the entirety
of this weekend with family out-of-state, so I'll be offline from
tomorrow (Dec. 26) through Monday of next week (Dec. 29). 

Regards and Happy Holidays!
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081225/537b7efd/attachment.sig>

From huzaifas at redhat.com  Fri Dec 26 05:34:13 2008
From: huzaifas at redhat.com (Huzaifa Sidhpurwala)
Date: Fri, 26 Dec 2008 11:04:13 +0530
Subject: Rekeying and vpnc
Message-ID: <49546CD5.1020100@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi All,
I am using the latest vpnc in fedora and it seems two config options
namely Rekey Inteval and NAT-Keepalive packet interval 60
has disappeared.
It seems from :
http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2007-March/001385.html

that this is already active, any idea if one can specify a Rekeying
interval in this or there is a default rekeying inteval.

Any help is greatly appreciated.


- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)

GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFJVGzVzHDc8tpb2uURAqyHAJ9pAX3X4aL6PuyLQRTvR1cJVl/4EwCdGspL
L12LE8f+XolJTBt+efMivVs=
=ViQ7
-----END PGP SIGNATURE-----



From rawhide at fedoraproject.org  Fri Dec 26 09:57:49 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 26 Dec 2008 09:57:49 +0000 (UTC)
Subject: rawhide report: 20081226 changes
Message-ID: <20081226095749.138181F8259@releng2.fedora.phx.redhat.com>

Compose started at Fri Dec 26 06:01:08 UTC 2008

New package hyphen-sk
        Slovak hyphenation rules
New package kBuild
        A cross-platform build enviroment
New package mitter
        A maemo/GTK+ client for twitter
New package python-imdb
        Retrieve and manage the data of the IMDb movie database
Updated Packages:

asio-1.2.0-1.fc11
-----------------
* Thu Dec 25 17:00:00 2008 Marc Maurer <uwog at uwog.net> 1.2.0-1
- New upstream release


banshee-1.4.1-2.fc11
--------------------
* Thu Dec 25 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.4.1-2
- rebuild to fix broken deps


cairo-dock-2.0.0-0.3.svn1453_trunk.fc11
---------------------------------------
* Fri Dec 26 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1453


crypto-utils-2.4.1-3
--------------------
* Wed Dec 24 17:00:00 2008 Elio Maldonado <emaldona at redhat.com> - 2.4.1-4
- Fix certwatch time calculations for expiring certificates (#473860)

* Mon Nov  3 17:00:00 2008 Elio Maldonado <emaldona at redhat.com> - 2.4.1-3
- preauthenticate to modules using specially formatted password file


e16-0.16.8.14-2.fc11
--------------------
* Thu Dec 25 17:00:00 2008 Terje Rosten <terjeros at phys.ntnu.no> - 0.16.8.14-2
- Fix bz #473646
- Move font req.


e16-docs-0.16.8.0.1-3.fc11
--------------------------
* Thu Dec 25 17:00:00 2008 Terje Rosten <terjeros at phys.ntnu.no> - 0.16.8.0.1-3
- Move font req.


gnome-python2-extras-2.19.1-28.fc11
-----------------------------------
* Wed Dec 24 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 2.19.1-28
- Fix the gecko-lib version


kernel-2.6.28-2.fc11
--------------------
* Thu Dec 25 17:00:00 2008 Dave Jones <davej at redhat.com>
- Enable BOOT_TRACER during testing.


maatkit-2582-3.fc11
-------------------
* Thu Dec 25 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 2582-3
- Really fix the DBD dependency...


mediawiki-ParserFunctions-1.1.1-4.svn45003.fc11
-----------------------------------------------
* Thu Dec 25 17:00:00 2008 Ian Weller <ianweller at gmail.com> 1.1.1-4.svn45003
- Missed a few files


mono-zeroconf-0.7.6-7.fc11
--------------------------
* Thu Dec 25 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.7.6-7
- add ppc


mozvoikko-0.9.5-5.fc11
----------------------
* Fri Dec 26 17:00:00 2008 Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> - 0.9.5-5
- Rebuild against gecko 1.9.1
- Bump Release so that it's at least as high as in F10 and F9


ochusha-0.6.0.1-0.1.cvs20081226T1200.fc11
-----------------------------------------
* Fri Dec 26 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- 2008-12-26 12:00
- Hopely fix the issue on /linux/1148809116/612


python-virtualenv-1.3.2-1.fc11
------------------------------
* Thu Dec 25 17:00:00 2008 Steve 'Ashcrow' Milner <me at stevemilner.org> - 1.3.2-1
- Updated for upstream release.


ruby-gnome2-0.18.1-3.fc11
-------------------------
* Fri Dec 26 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.18.1-3
- Bump release
- Patch to compile panel-applet
- Take care of directory owership (bug 474608)


sysklogd-1.5-6.fc11
-------------------
* Thu Dec 25 17:00:00 2008 Jeroen van Meeuwen <kanarip at fedoraproject.org> - 1.5-6
- XMas build
- Fix chkconfig service syslog -> chkconfig service sysklogd


vdr-skins-20081124-2.fc11
-------------------------
* Thu Dec 25 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 20081124-2
- Use DejaVu fonts for Aluminium and Enigma (#477478).


zfs-fuse-0.5.0-6.20081221.fc11
------------------------------
* Sun Dec 28 17:00:00 2008 Uwe Kubosh <uwe at kubosch.no> - 0.5.0-6.20081221
- Updated etc/init.d/zfs-fuse init script after feedback from Rudd-O at
  http://groups.google.com/group/zfs-fuse/browse_thread/thread/da94aa803bceef52
- Adds better wait at startup before mounting filesystems.
- Add OOM kill protection.
- Adds syncing of disks at shutdown.
- Adds pool status when asking for service status.
- Changed to start zfs-fuse at boot as default.
- Changed to start zfs-fise right after installation.
- Cleanup of /var/run/zfs and /var/lock/zfs after uninstall.

* Wed Dec 24 17:00:00 2008 Uwe Kubosh <uwe at kubosch.no> - 0.5.0-5.20081221
- Development tag.

* Sun Dec 21 17:00:00 2008 Uwe Kubosh <uwe at kubosch.no> - 0.5.0-4.20081221
- Updated to upstream trunk of 2008-12-21
- Added config file in /etc/sysconfig/zfs
- Added config option ZFS_AUTOMOUNT=0|1 to mount filesystems at boot


Summary:
Added Packages: 4
Removed Packages: 0
Modified Packages: 18
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	blam-1.8.5-5.fc10.i386 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.i386 requires bitstream-vera-fonts
	enigma-1.01-6.3.i386 requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.i386 requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	neverball-1.4.0-12.fc11.i386 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.i386 requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.i386 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts
	wormux-0.8.2-2.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	banshee-devel-1.4.1-2.fc11.x86_64 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	blam-1.8.5-5.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.x86_64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.x86_64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.i386 requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.x86_64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.x86_64 requires libboost_program_options-mt.so.3()(64bit)
	neverball-1.4.0-12.fc11.x86_64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.x86_64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts
	wormux-0.8.2-2.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.ppc requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	blam-1.8.5-5.fc10.ppc requires gecko-libs = 0:1.9.0.5
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc requires bitstream-vera-fonts
	enigma-1.01-6.3.ppc requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_thread-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libltdl.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_regex-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc requires libboost_filesystem-mt.so.3
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires libboost_python-mt.so.3
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc requires python(abi) = 0:2.5
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_program_options-mt.so.3
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc requires libboost_iostreams-mt.so.3
	neverball-1.4.0-12.fc11.ppc requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.ppc requires libgmime-2.0.so.2
	protobuf-python-2.0.2-5.fc11.ppc requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts
	wormux-0.8.2-2.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.ppc64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_thread-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_regex-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires dejavu-fonts
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_filesystem-mt.so.3()(64bit)
	mapnik-0.5.2-0.7.svn738.fc10.ppc64 requires libltdl.so.3()(64bit)
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires python(abi) = 0:2.5
	mapnik-python-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_python-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_iostreams-mt.so.3()(64bit)
	mapnik-utils-0.5.2-0.7.svn738.fc10.ppc64 requires libboost_program_options-mt.so.3()(64bit)
	neverball-1.4.0-12.fc11.ppc64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pinot-0.89-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	protobuf-python-2.0.2-5.fc11.ppc64 requires python(abi) = 0:2.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-openid-2.2.1-1.fc10.noarch requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts
	wormux-0.8.2-2.fc11.ppc64 requires dejavu-fonts





From debarshi.ray at gmail.com  Fri Dec 26 11:36:31 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 26 Dec 2008 17:06:31 +0530
Subject: CompsXml, make validate, etc.
Message-ID: <3170f42f0812260336ub60204ds40193df1a92ed51b@mail.gmail.com>

I chanced upon a new Makefile target called 'validate' in the comps
module which is not mentioned in
http://fedoraproject.org/wiki/PackageMaintainers/CompsXml Might be
good to have it on the Wiki.

Also I found that some of my packages are not in the comps-fn.xml.ins.
So am I allowed to edit the files for Fedora 9 and 10, or should I
restrict myself to updating comps-f11.xml.in only?

Thanks,
Debarshi



From mschwendt at gmail.com  Fri Dec 26 13:50:44 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 26 Dec 2008 14:50:44 +0100
Subject: F9 and F8 broken deps report to be phased out
Message-ID: <20081226145044.1dd4ff97.mschwendt@gmail.com>

With Fedora 8 reaching EOL soon, I will stop running Extras repoclosure [1]
for F8 _and_ (!) F9.

If anybody likes to take over and continue with creating reports for F9,
feel free to get back to me in case there are any questions. Contrary to
some rumours, it's not a process that takes hours.

With a distribution getting older, there are more and more updates which
are published for it without enough prior testing. It isn't any fun to see
how some packages with broken dependencies are not being fixed for a long
time, although the package maintainer receives a new report by email
regularly. Among them are updates and upgrades which have been pushed
directly into the "stable" repo. F9 now even contains orphaned packages
which are affected by incompatible dependencies.

-- 
[1] http://mschwendt.fedorapeople.org/extras-repoclosure-modified-latest.tgz



From jwboyer at gmail.com  Fri Dec 26 14:04:10 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 26 Dec 2008 09:04:10 -0500
Subject: F9 and F8 broken deps report to be phased out
In-Reply-To: <20081226145044.1dd4ff97.mschwendt@gmail.com>
References: <20081226145044.1dd4ff97.mschwendt@gmail.com>
Message-ID: <20081226140410.GA10864@zod.rchland.ibm.com>

On Fri, Dec 26, 2008 at 02:50:44PM +0100, Michael Schwendt wrote:
>With Fedora 8 reaching EOL soon, I will stop running Extras repoclosure [1]
>for F8 _and_ (!) F9.
>
>If anybody likes to take over and continue with creating reports for F9,
>feel free to get back to me in case there are any questions. Contrary to
>some rumours, it's not a process that takes hours.

I'll take a look at keeping this going.  I've always found the reports
to be very useful.

>With a distribution getting older, there are more and more updates which
>are published for it without enough prior testing. It isn't any fun to see
>how some packages with broken dependencies are not being fixed for a long
>time, although the package maintainer receives a new report by email
>regularly. Among them are updates and upgrades which have been pushed
>directly into the "stable" repo. F9 now even contains orphaned packages
>which are affected by incompatible dependencies.
>
>-- 
>[1] http://mschwendt.fedorapeople.org/extras-repoclosure-modified-latest.tgz

Thanks, I'll take a look at this.

josh



From promac at gmail.com  Fri Dec 26 16:32:48 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Fri, 26 Dec 2008 14:32:48 -0200
Subject: New symbols in kernel 2.6.27.9-159
Message-ID: <68720af30812260832k4e86d84dy82322b7639fa45c0@mail.gmail.com>

I am not being able to compile the latest alsa driver tarball
with the new F10 kernel.

Some new symbols just appeared,  and are causing problems, such as:

static inline ktime_t hrtimer_get_expires(const struct hrtimer *timer)

in include/linux/hrtimer.h

or

typedef unsigned __bitwise__ fmode_t;

in include/linux/types.h


Is this a 2.6.27 or a 2.6.28 kernel?

fmode_t is supposed to be defined in kernel 2.6.28 not in 2.6.27.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081226/dcab1ca8/attachment.htm>

From drago01 at gmail.com  Fri Dec 26 17:55:09 2008
From: drago01 at gmail.com (drago01)
Date: Fri, 26 Dec 2008 18:55:09 +0100
Subject: New symbols in kernel 2.6.27.9-159
In-Reply-To: <68720af30812260832k4e86d84dy82322b7639fa45c0@mail.gmail.com>
References: <68720af30812260832k4e86d84dy82322b7639fa45c0@mail.gmail.com>
Message-ID: <f6ca9fed0812260955s25ad8afx3b06adc2dae67d87@mail.gmail.com>

2008/12/26 Paulo Cavalcanti <promac at gmail.com>:
>
> I am not being able to compile the latest alsa driver tarball
> with the new F10 kernel.
>
> Some new symbols just appeared,  and are causing problems, such as:
>
> static inline ktime_t hrtimer_get_expires(const struct hrtimer *timer)
>
> in include/linux/hrtimer.h
>
> or
>
> typedef unsigned __bitwise__ fmode_t;
>
> in include/linux/types.h
>
>
> Is this a 2.6.27 or a 2.6.28 kernel?
>
> fmode_t is supposed to be defined in kernel 2.6.28 not in 2.6.27.

The kernel already has the alsa 1.0.18a drivers included.



From promac at gmail.com  Fri Dec 26 18:04:28 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Fri, 26 Dec 2008 16:04:28 -0200
Subject: New symbols in kernel 2.6.27.9-159
In-Reply-To: <f6ca9fed0812260955s25ad8afx3b06adc2dae67d87@mail.gmail.com>
References: <68720af30812260832k4e86d84dy82322b7639fa45c0@mail.gmail.com>
	<f6ca9fed0812260955s25ad8afx3b06adc2dae67d87@mail.gmail.com>
Message-ID: <68720af30812261004k4f8f4242y54e0b132157e4a60@mail.gmail.com>

On Fri, Dec 26, 2008 at 3:55 PM, drago01 <drago01 at gmail.com> wrote:

> 2008/12/26 Paulo Cavalcanti <promac at gmail.com>:
> >
> > I am not being able to compile the latest alsa driver tarball
> > with the new F10 kernel.
> >
> > Some new symbols just appeared,  and are causing problems, such as:
> >
> > static inline ktime_t hrtimer_get_expires(const struct hrtimer *timer)
> >
> > in include/linux/hrtimer.h
> >
> > or
> >
> > typedef unsigned __bitwise__ fmode_t;
> >
> > in include/linux/types.h
> >
> >
> > Is this a 2.6.27 or a 2.6.28 kernel?
> >
> > fmode_t is supposed to be defined in kernel 2.6.28 not in 2.6.27.
>
> The kernel already has the alsa 1.0.18a drivers included.
>
>
I know that. I am talking about the latest tarball, with a lot of fixes.
I spent a lot of time to get my card working .... I need these updates.

ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz



-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081226/13278a4d/attachment.htm>

From martin.langhoff at gmail.com  Fri Dec 26 20:55:43 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 26 Dec 2008 18:55:43 -0200
Subject: Updates to F8 (was: [Fedora Update] [stable]
	fakeroot-1.11-19.fc8)
In-Reply-To: <20081225105803.GA3403@victor.nirvana>
References: <20081221215407.5999A208979@bastion.fedora.phx.redhat.com>
	<1229898973.3861.75.camel@localhost.localdomain>
	<20081224134614.GB8769@victor.nirvana>
	<1230136631.17296.13.camel@localhost.localdomain>
	<20081225105803.GA3403@victor.nirvana>
Message-ID: <46a038f90812261255j31a5af72s791994de3803d33e@mail.gmail.com>

2008/12/25 Axel Thimm <Axel.Thimm at atrpms.net>:
> On Wed, Dec 24, 2008 at 08:37:11AM -0800, Jesse Keating wrote:
>> On Wed, 2008-12-24 at 15:46 +0200, Axel Thimm wrote:
>> A link to where you can find the upstream release notes would actually
>> help here.
>
> Indeed, but the project doesn't provide anything useful in that
> respect. It is quite astonishing, that some intergral tools in the
> Debian toolchain have rather litte public interfaces.

As Axel is saying, Debian=upstream. The most useful page for packages,
IMHO, is the somewhat hidden 'qa page', aka "developer information";
for fakeroot it is here

   http://packages.qa.debian.org/f/fakeroot.html

on its right-hand-side there's changelog link

  http://packages.debian.org/changelogs/pool/main/f/fakeroot/current/changelog

hth!



martin

-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From seg at haxxed.com  Sat Dec 27 07:25:47 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 27 Dec 2008 01:25:47 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
Message-ID: <1230362747.21895.11.camel@localhost.localdomain>

On Wed, 2008-12-17 at 15:39 -0500, Yaakov Nemoy wrote:
> /boot is a 100-200 MB partition on many machines. Unless Grub can
> safely handled an encrypted partition on top of a Logical Volume
> running on an encrypted Volume Group running on an encrypted Physical
> Volume on an encrypted hard drive, with levels of Software RAID in
> between each step, there's just no sense supporting /boot on anything
> other than a 100-200 MB ext2 or ext3 volume.

Why do we even waste 128mb on an ext3 journal for /boot? It changes
rarely and such a small filesystem with only a handful of files takes 0
time to fsck. On all my machines /boot is a 256mb (plenty of room for
the upcoming rescue image in /boot...) ext2 partition set to fsck on
every boot. Every time I upgrade, anaconda nags me to "upgrade" /boot to
ext3...
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081227/a4e7c445/attachment.sig>

From rawhide at fedoraproject.org  Sat Dec 27 10:31:31 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 27 Dec 2008 10:31:31 +0000 (UTC)
Subject: rawhide report: 20081227 changes
Message-ID: <20081227103132.0F5E71F8259@releng2.fedora.phx.redhat.com>

Compose started at Sat Dec 27 06:01:06 UTC 2008

New package wordxtr
        Create hunspell dictionary from given plain text input data files
Updated Packages:

blam-1.8.5-5.fc11
-----------------
* Thu Dec 25 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.8.5-5
- Rebuild against new gecko and mono


crypto-utils-2.4.1-4
--------------------

egoboo-data-2.7.5-2.fc11
------------------------
* Fri Dec 26 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.7.5-2
- Remove some non free fonts, replace with symlinks to dejavu (rh 477379)


g-wrap-1.9.11-1.fc11
--------------------
* Fri Dec 26 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 1.9.11-1
- Update to 1.9.11
- Use system libffi (bug #433083)


gstreamermm-0.9.8-1.fc11
------------------------
* Fri Dec 26 17:00:00 2008 Denis Leroy <denis at poolshark.org> - 0.9.8-1
- Update to upstream 0.9.8
- Disabled parallel make


hedgewars-0.9.7-2.fc11
----------------------
* Fri Dec 26 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.9.7-2
- Replace private dejavu copy with symlink to system version (rh 477396)


kernel-2.6.28-3.fc11
--------------------
* Fri Dec 26 17:00:00 2008 Hans de Goede <hdegoede at redhat.com>
- Rebase gspca git patch to latest gspca git
- Re-enable gspca git patch
- Add gscpa-stv06xx (qc-usb replacement) driver from its own git tree


lxterminal-0.1.4-1.fc11
-----------------------
* Fri Dec 26 17:00:00 2008 Christoph Wickert <fedora christoph-wickert de> - 0.1.4-1
- Update to 0.1.4.


mapnik-0.5.2-0.9.svn738.fc11
----------------------------
* Sun Dec  7 17:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 0.5.2-0.9.svn738
- fix fonts for F11

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.5.2-0.8.svn738
- Rebuild for Python 2.6


ochusha-0.6.0.1-0.2.cvs20081226T1200.fc11
-----------------------------------------

pidgin-2.5.3-1.fc11
-------------------
* Fri Dec 26 17:00:00 2008 Warren Togami <wtogami at redhat.com> 2.5.3-1
- 2.5.3


pinot-0.89-3.fc11
-----------------
* Fri Dec 26 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.89-3
- Port to gmime-2.4 api

* Mon Dec  1 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.89-2
- Rebuild for Python 2.6


protobuf-2.0.2-6.fc11
---------------------
* Tue Dec 23 17:00:00 2008 Lev Shamardin <shamardin at gmail.com> - 2.0.2-6
- Small fixes for python 2.6 eggs.
- Temporarily disabled java subpackage due to build problems, will be fixed and
  turned back on in future.


purple-facebookchat-1.45-1.fc11
-------------------------------
* Fri Dec 26 17:00:00 2008 Ismael Olea <ismael at olea.org> 1.45-1
- removing strip command (#477902)
- updating to 1.45


python-openid-2.2.1-3.fc11
--------------------------
* Fri Dec 26 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 2.2.1-3
- Temporarily disable tests to fix broken deps (#477947)

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.2.1-2
- Rebuild for Python 2.6


rpmdevtools-7.0-1.fc11
----------------------
* Fri Dec 26 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 7.0-1
- 7.0.
- Drop fonts spec template, adapt to new ones from Fedora fonts SIG (#477055).
- Add man page for rpmdev-newspec.

* Tue Dec 16 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Add imake and intltool to internal list of devel packages in rmdevelrpms.

* Sat Dec 13 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Add rpmdev-sha*/*sum companions to rpmdev-md5 (ticket #7).

* Wed Nov 26 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Add vamp-plugin-sdk to internal list of non-devel packages in rmdevelrpms
  (#472641, Michael Schwendt).

* Thu Nov 20 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Drop "minimal buildroot" dependencies.
- Drop fedora-rpmdevtools Obsoletes.

* Mon Oct 13 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Show available types in rpmdev-newspec --help (ticket #6, Todd Zullinger).

* Fri Sep 26 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Add -r/--rightmost option to rpmdev-bumpspec (ticket #1, Thorsten Leemhuis).
- Add %packager from rpm config to the set of defaults for rpmdev-bumpspec's
  user string.

* Thu Sep 25 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Bring rpmdev-bumpspec copyright holder closer to truth (Michael Schwendt).

* Mon Sep 22 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Switch to lzma compressed tarball.

* Sun Sep  7 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- Improve arch specific %files in perl spec template (#461177, Chris Weyl).


sarai-fonts-1.0-5.fc11
----------------------
* Fri Dec 26 17:00:00 2008 Parag Nemade <paragn at fedoraproject.org> - 1.0-5
Changed spec according to new fonts packaging guildelines(rh#477452)


scons-1.2.0-1.fc11
------------------
* Thu Dec 25 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.2.0-1
- Update to 1.2.0 to fix problems with Python 2.6 (#475903)
  (currently causing broken deps with other packages)


splat-1.2.3-3.fc11
------------------
* Fri Dec 26 17:00:00 2008 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 1.2.3-3
- fix broken obsoletes


ssmtp-2.61-11.8.fc11
--------------------
* Fri Dec 26 17:00:00 2008 Manuel "lonely wolf" Wolfshant <wolfy at nobugconsulting.ro> 2.61-11.8
- integrate patch adding support for aliases; initial version received from Tako 
  Schotanus <tako at codejive.org>, who adapted it from "eatnumber1"
- README and the man page now reflect that aliases are expanded and used


teamgit-0.0.8-2.20081226.fc11
-----------------------------
* Fri Dec 26 17:00:00 2008 Terje Rosten <terje.rosten at ntnu.no> - 0.0.8-2.20081226
- add git to req.
- update to git snapshot 2008-12-26


w3c-libwww-5.4.1-0.13.20060206cvs.fc11
--------------------------------------
* Fri Dec 26 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 5.4.1-0.13.20060206cvs
- Fixed linkage problems to reduce the number of undefined non-weak symbols.


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 22
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	egoboo-data-2.7.5-2.fc11.noarch requires dejavu-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.i386 requires bitstream-vera-fonts
	enigma-1.01-6.3.i386 requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.i386 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	guile-gnome-platform-2.15.93-8.fc10.i386 requires libffi.so.4
	gwave-2-11.20070514snap.fc10.i386 requires libffi.so.4
	hedgewars-0.9.7-2.fc11.i386 requires dejavu-fonts
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	neverball-1.4.0-12.fc11.i386 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.i386 requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts
	wormux-0.8.2-2.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	banshee-devel-1.4.1-2.fc11.x86_64 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	egoboo-data-2.7.5-2.fc11.noarch requires dejavu-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.x86_64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.x86_64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.x86_64 requires /usr/bin/python2.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-1.fc11.x86_64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.x86_64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	guile-gnome-platform-2.15.93-8.fc10.i386 requires libffi.so.4
	guile-gnome-platform-2.15.93-8.fc10.x86_64 requires libffi.so.4()(64bit)
	gwave-2-11.20070514snap.fc10.x86_64 requires libffi.so.4()(64bit)
	hedgewars-0.9.7-2.fc11.x86_64 requires dejavu-fonts
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.x86_64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.x86_64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	padevchooser-0.9.4-0.7.svn20070925.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts
	wormux-0.8.2-2.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.ppc requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	egoboo-data-2.7.5-2.fc11.noarch requires dejavu-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc requires bitstream-vera-fonts
	enigma-1.01-6.3.ppc requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-1.fc11.ppc requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	guile-gnome-platform-2.15.93-8.fc10.ppc requires libffi.so.4
	gwave-2-11.20070514snap.fc10.ppc requires libffi.so.4
	hedgewars-0.9.7-2.fc11.ppc requires dejavu-fonts
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.ppc requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc requires libgnome-desktop-2.so.10
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts
	wormux-0.8.2-2.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	egoboo-data-2.7.5-2.fc11.noarch requires dejavu-fonts
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.ppc64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	ewftools-20080501-3.fc10.ppc64 requires /usr/bin/python2.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	hedgewars-0.9.7-2.fc11.ppc64 requires dejavu-fonts
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	padevchooser-0.9.4-0.7.svn20070925.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts
	wormux-0.8.2-2.fc11.ppc64 requires dejavu-fonts





From julian.mailinglists at googlemail.com  Sat Dec 27 16:10:05 2008
From: julian.mailinglists at googlemail.com (Julian Aloofi)
Date: Sat, 27 Dec 2008 17:10:05 +0100
Subject: Webspace
Message-ID: <1230394205.22502.9.camel@localhost.localdomain>

Hello,
I created a Fedora rpm package for MOC, a ncurses based audio player. I
removed the support for restricted file formats as MP3 and already
tested it extensively. Now I want to open a Review Request on Redhat
Bugzilla but I don't have access to any safe webspace. Which group can
I, as not yet involved person, join to get access to webspace on
fedorapeople.org? I already have a FAS-Account. Thanks for helping in
advance,
Julian Aloofi
-- 
I use this address only for mailing lists. If you want to contact me
directly please send a mail to julian at fedoraproject.org
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081227/ff998351/attachment.sig>

From sandeen at redhat.com  Sat Dec 27 18:00:26 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 27 Dec 2008 12:00:26 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <1230362747.21895.11.camel@localhost.localdomain>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<1230362747.21895.11.camel@localhost.localdomain>
Message-ID: <49566D3A.6010301@redhat.com>

Callum Lerwick wrote:
> On Wed, 2008-12-17 at 15:39 -0500, Yaakov Nemoy wrote:
>> /boot is a 100-200 MB partition on many machines. Unless Grub can
>> safely handled an encrypted partition on top of a Logical Volume
>> running on an encrypted Volume Group running on an encrypted Physical
>> Volume on an encrypted hard drive, with levels of Software RAID in
>> between each step, there's just no sense supporting /boot on anything
>> other than a 100-200 MB ext2 or ext3 volume.
> 
> Why do we even waste 128mb on an ext3 journal for /boot? It changes
> rarely and such a small filesystem with only a handful of files takes 0
> time to fsck. On all my machines /boot is a 256mb (plenty of room for
> the upcoming rescue image in /boot...)

On a 256mb filesystem the journal will only be 32mb by default.  Still a
chunk of the fs, but not half! :)

-Eric



From maxx at krakoa.dk  Sat Dec 27 18:31:09 2008
From: maxx at krakoa.dk (Mads Villadsen)
Date: Sat, 27 Dec 2008 19:31:09 +0100
Subject: Rawhide Live?
Message-ID: <1230402669.5025.0.camel@localhost.localdomain>

Is there anywhere I can download a live usb image of rawhide? Or will I
have to wait until the alpha release for that?

Kind regards.
-- 
Mads Villadsen <maxx at krakoa.dk>



From ivazqueznet at gmail.com  Sat Dec 27 18:39:54 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 27 Dec 2008 13:39:54 -0500
Subject: Rawhide Live?
In-Reply-To: <1230402669.5025.0.camel@localhost.localdomain>
References: <1230402669.5025.0.camel@localhost.localdomain>
Message-ID: <1230403194.9371.31.camel@ignacio.lan>

On Sat, 2008-12-27 at 19:31 +0100, Mads Villadsen wrote:
> Is there anywhere I can download a live usb image of rawhide? Or will I
> have to wait until the alpha release for that?

You'll have to generate it yourself using spin-kickstarts and
livecd-creator.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081227/f71040c4/attachment.sig>

From kevin.kofler at chello.at  Sat Dec 27 20:54:26 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 27 Dec 2008 21:54:26 +0100
Subject: CompsXml, make validate, etc.
References: <3170f42f0812260336ub60204ds40193df1a92ed51b@mail.gmail.com>
Message-ID: <gj64m2$l5u$1@ger.gmane.org>

Debarshi Ray wrote:
> Also I found that some of my packages are not in the comps-fn.xml.ins.
> So am I allowed to edit the files for Fedora 9 and 10, or should I
> restrict myself to updating comps-f11.xml.in only?

You're allowed to edit the files for F9 and F10, but please do not add new
groups, you can only add packages to existing groups. (Moving a package to
a different group, changing the mandatory/default/optional status of a
package or removing a package is also possible, but usually a bad idea,
such changes are best reserved for the next release only.) And of course
any changes won't affect the installer, they'll only be used when updates
are being used.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Dec 27 20:58:29 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 27 Dec 2008 21:58:29 +0100
Subject: Webspace
References: <1230394205.22502.9.camel@localhost.localdomain>
Message-ID: <gj64tl$l5u$3@ger.gmane.org>

Julian Aloofi wrote:
> I created a Fedora rpm package for MOC, a ncurses based audio player.

If it contains an executable named "moc", that's a file conflict, that name
is already used by Qt (currently qt3, in the future the default moc may
become the Qt 4 one, but we definitely don't want an unrelated program
calling itself moc, it'd confuse the heck out of Qt-using programs).

        Kevin Kofler



From kevin.kofler at chello.at  Sat Dec 27 20:55:49 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 27 Dec 2008 21:55:49 +0100
Subject: New symbols in kernel 2.6.27.9-159
References: <68720af30812260832k4e86d84dy82322b7639fa45c0@mail.gmail.com>
Message-ID: <gj64ol$l5u$2@ger.gmane.org>

Paulo Cavalcanti wrote:
> Is this a 2.6.27 or a 2.6.28 kernel?
> 
> fmode_t is supposed to be defined in kernel 2.6.28 not in 2.6.27.

It's a 2.6.27 with a newer ALSA backported, so some ALSA-related symbols
from 2.6.28 are already defined.

        Kevin Kofler



From seg at haxxed.com  Sun Dec 28 00:10:46 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 27 Dec 2008 18:10:46 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <49566D3A.6010301@redhat.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<1230362747.21895.11.camel@localhost.localdomain>
	<49566D3A.6010301@redhat.com>
Message-ID: <1230423046.21895.47.camel@localhost.localdomain>

On Sat, 2008-12-27 at 12:00 -0600, Eric Sandeen wrote:
> On a 256mb filesystem the journal will only be 32mb by default.  Still a
> chunk of the fs, but not half! :)

Hmmm, I think this has changed over the years, but it seems the recent
code looks like this:

int ext2fs_default_journal_size(__u64 blocks)
{
   if (blocks < 2048)
      return -1;
   if (blocks < 32768)
      return (1024);
   if (blocks < 256*1024)
      return (4096);
   if (blocks < 512*1024)
      return (8192);
   if (blocks < 1024*1024)
      return (16384);
   return 32768;
}

It's based on block size. So on a 256mb filesystem, the block size
defaults to 1k, and you get an 8mb journal.

Given /boot mostly stores a handful of kernels, a 4k block size works
just fine and gains a bit of space due to less metadata. (Helpful when
you're trying to maximize space on older systems with smaller drives...)
You then end up with a 16mb journal.

Not as wasteful as I thought, but still, really the journal isn't doing
anything but take up space.

I've been setting up /boot with options something like this on my
machines:

mke2fs -b 4096 -N 128 /dev/sda1

Ah, exercises in obsessive optimization...
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081227/1fc48c76/attachment.sig>

From vonbrand at inf.utfsm.cl  Sun Dec 28 00:44:07 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sat, 27 Dec 2008 21:44:07 -0300
Subject: Mailman breakage [Was: rawhide report: 20081227 changes]
In-Reply-To: <20081227103132.0F5E71F8259@releng2.fedora.phx.redhat.com>
References: <20081227103132.0F5E71F8259@releng2.fedora.phx.redhat.com>
Message-ID: <200812280044.mBS0i7C3011907@laptop14.inf.utfsm.cl>

Rawhide Report <rawhide at fedoraproject.org> wrote:

[...]

> rpmdevtools-7.0-1.fc11
> ----------------------
> * Fri Dec 26 17:00:00 2008 Ville Skytt???? <ville.skytta at iki.fi> - 7.0-1
                                        ~~
Yep, same UTF-8 mangling I see here with my mailman installation. Sigh...
-- 
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 sandeen at redhat.com  Sun Dec 28 01:39:20 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 27 Dec 2008 19:39:20 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <1230423046.21895.47.camel@localhost.localdomain>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<1230362747.21895.11.camel@localhost.localdomain>	<49566D3A.6010301@redhat.com>
	<1230423046.21895.47.camel@localhost.localdomain>
Message-ID: <4956D8C8.8000002@redhat.com>

Callum Lerwick wrote:
> On Sat, 2008-12-27 at 12:00 -0600, Eric Sandeen wrote:
>> On a 256mb filesystem the journal will only be 32mb by default.  Still a
>> chunk of the fs, but not half! :)
> 
> Hmmm, I think this has changed over the years, but it seems the recent
> code looks like this:
> 
> int ext2fs_default_journal_size(__u64 blocks)
> {
>    if (blocks < 2048)
>       return -1;
>    if (blocks < 32768)
>       return (1024);
>    if (blocks < 256*1024)
>       return (4096);
>    if (blocks < 512*1024)
>       return (8192);
>    if (blocks < 1024*1024)
>       return (16384);
>    return 32768;
> }
> 
> It's based on block size. So on a 256mb filesystem, the block size
> defaults to 1k, and you get an 8mb journal.

You're right, I used 4k blocks in my napkin-sketch, oops :)


-Eric



From julian.mailinglists at googlemail.com  Sun Dec 28 02:14:28 2008
From: julian.mailinglists at googlemail.com (Julian Aloofi)
Date: Sun, 28 Dec 2008 03:14:28 +0100
Subject: Webspace
In-Reply-To: <gj64tl$l5u$3@ger.gmane.org>
References: <1230394205.22502.9.camel@localhost.localdomain>
	<gj64tl$l5u$3@ger.gmane.org>
Message-ID: <1230430468.3384.1.camel@localhost.localdomain>

The upstream author renamed the executable to mocp, so there will be no
file conflicts. But that doesn't solve my problem...

Am Samstag, den 27.12.2008, 21:58 +0100 schrieb Kevin Kofler:
> Julian Aloofi wrote:
> > I created a Fedora rpm package for MOC, a ncurses based audio player.
> 
> If it contains an executable named "moc", that's a file conflict, that name
> is already used by Qt (currently qt3, in the future the default moc may
> become the Qt 4 one, but we definitely don't want an unrelated program
> calling itself moc, it'd confuse the heck out of Qt-using programs).
> 
>         Kevin Kofler
> 
-- 
I use this address only for mailing lists. If you want to contact me
directly please send a mail to julian at fedoraproject.org
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081228/ffdcd711/attachment.sig>

From bashton at brennanashton.com  Sun Dec 28 02:22:44 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sat, 27 Dec 2008 20:22:44 -0600
Subject: Webspace
In-Reply-To: <1230430468.3384.1.camel@localhost.localdomain>
References: <1230394205.22502.9.camel@localhost.localdomain>
	<gj64tl$l5u$3@ger.gmane.org>
	<1230430468.3384.1.camel@localhost.localdomain>
Message-ID: <981da310812271822l61968eb5oc1d0d1e7360926f1@mail.gmail.com>

2008/12/27 Julian Aloofi <julian.mailinglists at googlemail.com>:
> The upstream author renamed the executable to mocp, so there will be no
> file conflicts. But that doesn't solve my problem...
>
> Am Samstag, den 27.12.2008, 21:58 +0100 schrieb Kevin Kofler:
>> Julian Aloofi wrote:
>> > I created a Fedora rpm package for MOC, a ncurses based audio player.
>>
>> If it contains an executable named "moc", that's a file conflict, that name
>> is already used by Qt (currently qt3, in the future the default moc may
>> become the Qt 4 one, but we definitely don't want an unrelated program
>> calling itself moc, it'd confuse the heck out of Qt-using programs).
>>
>>         Kevin Kofler
>>
> --
> I use this address only for mailing lists. If you want to contact me
> directly please send a mail to julian at fedoraproject.org

Julian,

Have you headed over to #fedora-devel on IRC, someone there should be
able to help you out.

-Brennan Ashton



From seg at haxxed.com  Sun Dec 28 06:09:36 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 28 Dec 2008 00:09:36 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <494D3DB2.4000304@gmail.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
Message-ID: <1230444576.21895.99.camel@localhost.localdomain>

On Sat, 2008-12-20 at 12:47 -0600, Les Mikesell wrote:
> Can someone who likes (even tolerates) spatial mode describe why?  I'm 
> completely baffled as to why anyone would prefer windows left open all 
> over the place randomly instead of just explicitly opening ones yourself 
> in places where you want them.  For me, it is _always_ extra work to 
> close the unwanted windows compared to opening the ones I want.

Sigh, just for the (google) record:

1) I used Macs before I ever used Linux. The System 7 era, in
particular. My high school was entirely Mac based. What is foreign to
you is quite familiar to me.

2) It is not random. It is entirely non-random. It is persistent.
Everything is always where *you* left it. You are in control.

3) As you navigate commonly used directories, your windows quickly fall
in to places such that they tile nicely, always leaving the close boxes
of previous windows exposed. Tiling windows in this way becomes a
natural habit, and given the persistence you only have to do it once.
You get in the habit of hitting the close box on the previous window
without even thinking about it. Besides, there's shift-doubleclick, same
as on a Mac. (Or double-middle-click, doing the Mac one (or is that two)
better.)

3) Set "list" view as default. All my windows are in list mode. List
mode gives you the triangles. It's quite like having a GUI version of
"ls". (Icon mode seems pretty useless without the icon placement
persistence the Mac has. List mode should be default! Let's vote!!!)

4) Bookmark commonly used directory hierarchies. Dig in to them by
clicking the little triangles, reducing the number of windows needed.

<3

Though it does quite annoy me that box-select doesn't work in list mode,
like it does on a Mac, or an Atari ST, or Windows. This means you
absolutely can't do multi-select in list mode without using the
keyboard. This seems to be an artifact of just using a GTK treelist
widget...
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081228/89d8f0ce/attachment.sig>

From ricardo at fedoraproject.org  Sun Dec 28 07:08:46 2008
From: ricardo at fedoraproject.org (=?UTF-8?Q?Ricardo_Arg=C3=BCello?=)
Date: Sun, 28 Dec 2008 02:08:46 -0500
Subject: improve-relatime.patch dropped from F10
Message-ID: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>

Hi,

Why was the improve-relatime.patch dropped from F10's kernel? F9 had
relatime on by default using this patch.
I first thought the upstream kernel had the patch now, but
/proc/mounts does not show relatime in F10.

I found this bug, looks related:

  mkinitrd can't deal with the "relatime" mount option
  https://bugzilla.redhat.com/show_bug.cgi?id=430280

More info:
http://kerneltrap.org/node/14148
http://people.redhat.com/mingo/relatime-patches/improve-relatime.patch

-- 
Ricardo Arguello



From ricardo at fedoraproject.org  Sun Dec 28 07:25:16 2008
From: ricardo at fedoraproject.org (=?UTF-8?Q?Ricardo_Arg=C3=BCello?=)
Date: Sun, 28 Dec 2008 02:25:16 -0500
Subject: performance test by Phoronix
In-Reply-To: <20081222003921.7170d3c5@hammerfall>
References: <1229596333.3612.78.camel@eagle.danny.cz>
	<385866f0812180351w2d68c49ga915fb9ccf730b70@mail.gmail.com>
	<20081218131841.0726d6c0@brian.englab.brq.redhat.com>
	<20081222003921.7170d3c5@hammerfall>
Message-ID: <500f0ca00812272325g1df699c7t6541b74e8a251903@mail.gmail.com>

> Some random observations:
>  - SELinux did not cause any significant slowdown in F10
>   (I re-ran the test also with SELinux disabled.)
>  - The mount options for the ext3 root fs as shown in /proc/mounts:
>     - F10:    rw,errors=continue,user_xattr,acl,data=ordered
>     - Ubuntu: rw,relatime,errors=remount-ro,data=ordered

F10 has disabled relatime as a default mount option.
F9 had it enabled by default. Maybe that's the reason Ubuntu performs
better on I/O than F10.

Please read this for more information:
http://kerneltrap.org/node/14148

-- 
Ricardo Arguello



From seg at haxxed.com  Sun Dec 28 08:47:36 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 28 Dec 2008 02:47:36 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1229800620.23410.173.camel@dimi.lattica.com>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229719550.23410.79.camel@dimi.lattica.com>
	<1229722878.3861.0.camel@localhost.localdomain>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<1229800620.23410.173.camel@dimi.lattica.com>
Message-ID: <1230454057.21895.226.camel@localhost.localdomain>

On Sat, 2008-12-20 at 14:17 -0500, Dimi Paun wrote:
> But the pro-change people produced pretty good arguments for change:
>   1. both Windows and MacOS (between them they cover something like 95%
>      of computer users) use browser mode. These companies have done
>      extensive UI studies which we can't afford.

Mind you from 1983 to 2001, Classic MacOS, and the Lisa before it,
pretty much defined "spacial" mode. Quite a few usability studies were
done in this era...

http://en.wikipedia.org/wiki/Spatial_file_manager

OSX switched away only because of its NextStep roots, which was a
greatly differing GUI design to begin with.

http://en.wikipedia.org/wiki/Shelf_(computing)
http://en.wikipedia.org/wiki/Miller_Columns

Interestingly, Windows 95 started off with a kind of half-assed spacial
mode as default, and subsequently moved to browser mode as Internet
Explorer dug its claws deep into the core of the operating system.

Here's what a usability study looks like:

http://www.sigchi.org/chi96/proceedings/desbrief/Sullivan/kds_txt.htm

It would be interesting to know if later Windows moved away from spacial
for any reason other than "We're going to force everyone to use Internet
Explorer". (or "People got confused because we didn't properly implement
spacial in the first place")

Basic fact: Hierarchy quickly overwhelms puny human minds, no matter how
well it is presented. Hierarchy does not scale. The best option is to
keep things flat to begin with. We need to move to an attribute ("tag")
search based system. Think Google.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081228/9622a9d8/attachment.sig>

From rawhide at fedoraproject.org  Sun Dec 28 09:49:12 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 28 Dec 2008 09:49:12 +0000 (UTC)
Subject: rawhide report: 20081228 changes
Message-ID: <20081228094912.283E61F8259@releng2.fedora.phx.redhat.com>

Compose started at Sun Dec 28 06:01:08 UTC 2008

Updated Packages:

ImageMagick-6.4.5.5-5.fc11
--------------------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.4.5.5-5
- Remove 2 included copies of the non Free artbrush font (rh 477399)


TnL-data-071111-2.fc11
----------------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 071111-2
- Remove the non free Gunship and Commonwealth fonts (rh #477469)


asunder-1.6.2-1.fc11
--------------------
* Sat Dec 27 17:00:00 2008 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.6.2-1
- updated to 1.6.2

* Mon Sep 15 18:00:00 2008 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.6.1-1
- updated to 1.6.1


blender-2.48a-7.fc11
--------------------
* Sat Dec 27 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 2.48a-7
- Fix optflags use, this time for real

* Sat Dec 27 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 2.48a-6
- Use proper compiler flags (see #199418)
- Minor grammar & language fixes and tidy-ups


e16-0.16.8.14-3.fc11
--------------------
* Sat Dec 27 17:00:00 2008 Terje Rosten <terjeros at phys.ntnu.no> - 0.16.8.14-3
- Use Dejavu fonts


e16-docs-0.16.8.0.1-4.fc11
--------------------------
* Sat Dec 27 17:00:00 2008 Terje Rosten <terjeros at phys.ntnu.no> - 0.16.8.0.1-4
- Use Dejavu fonts


e16-epplets-0.10-4.fc11
-----------------------
* Sat Dec 27 17:00:00 2008 Terje Rosten <terjeros at phys.ntnu.no> - 0.10-4
- Use Dejavu fonts


egoboo-data-2.7.5-3.fc11
------------------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.7.5-3
- Fix dejavu font Requires


freecol-0.7.4-4.fc11
--------------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.7.4-4
- Drop unclearly licensed Plakat-Fraktur font (and stop using it)
- Put ShadowedBlack font in its own shadowedblack-fonts subpackage (rh 477388)


g-wrap-1.9.11-2.fc11
--------------------
* Sat Dec 27 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 1.9.11-2
- Patch for incorrect pkgconfig template


guile-gnome-platform-2.16.1-1.fc11
----------------------------------
* Sat Dec 27 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 2.16.1-1
- Update to 2.16.1
- Corrected license to GPLv2+


hedgewars-0.9.7-3.fc11
----------------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.9.7-3
- Fix dejavu font Requires


httpd-2.2.11-4
--------------
* Sat Dec 27 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 2.2.11-4
- Made default configuration using /var/run/httpd for pid file


isomaster-1.3.4-2.fc11
----------------------
* Sat Dec 27 17:00:00 2008 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.3.4-2
- fixed problem with old patch

* Sat Dec 27 17:00:00 2008 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.3.4-1
- updated to 1.3.4


jd-2.1.0-0.5.rc081223.svn2608_trunk.fc11
----------------------------------------
* Sun Dec 28 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2608 (patched against previous rc)


libewf-20080501-4.fc11
----------------------
* Sat Dec 27 17:00:00 2008 kwizart < kwizart at gmail.com > - 20080501-4
- Fix for python2.6


notification-daemon-engine-nodoka-0.1.0-5.fc11
----------------------------------------------
* Sat Dec 27 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.1.0-5
- Add support for rtl (rhbz #475381)


ogre-1.6.0-3.fc11
-----------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.6.0-3
- Remove non-free fonts from samples subpackage (rh 477434)


openoffice.org-voikko-3.0-5.fc11
--------------------------------
* Sun Dec 28 17:00:00 2008 Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> - 3.0-5
- Add patch from upstream to fix FTBFS with OOO300_m14, the grammar
  checking framework was changed


padevchooser-0.9.4-0.8.svn20070925.fc11
---------------------------------------
* Sat Dec 27 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.9.4-0.8.svn20070925
- Rebuild for new libgnome-desktop


perl-bioperl-1.5.9-0.1.1.fc11
-----------------------------
* Fri Dec 26 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.5.9-0.1.1
- Update to latest upstream, 1.5.9, which is release candidate 1 for 1.6.0
- Add BuildRequires for perl(Array::Compare) and perl(GraphViz).
- Fix patch to apply to new release.
- Remove Bio::PhyloNetwork from installation, currently has unfilled
  deps and not ready for primetime according to upstream.


poedit-1.4.2-2.fc11
-------------------
* Sat Dec 27 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 1.4.2-2
- We still need desktop-file-utils, just not the post/postun scriptlets

* Sat Dec 27 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 1.4.2-1
- Upstream 1.4.2
- Do not depend on desktop-file-utils (#463047)
- Fix source location


python-feedparser-4.1-6.fc11
----------------------------
* Sat Dec 27 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 4.1-6
- Patch for a utf8 decoding issue (#477024)


python-logilab-astng-0.17.4-1.fc11
----------------------------------
* Sat Dec 27 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 0.17.4-1
- Upstream 0.17.4


pyxattr-0.4.0-2.fc11
--------------------
* Sat Dec  6 17:00:00 2008 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 0.4.0-2
- added python-setuptools in BuildRequires which is needed in build process
since version 0.4.0 (thanks to Kevin Fenzi)

* Fri Dec  5 17:00:00 2008 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 0.4.0-1
- updated to 0.4.0
- License Tag adjusted to current licensing LGPLv2+
- modified Python Eggs support due to its usage in source distribution


scorched3d-41.3-4.fc11
----------------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 41.3-4
- Replace included vera font with symlinks to dejavu (rh 477454)


seahorse-adventures-1.0-3.fc11
------------------------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.0-3
- Replace included vera font copies with symlinks to dejavu (rh 477456)


selinux-policy-3.6.1-14.fc11
----------------------------
* Sat Dec 27 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.6.1-14
- Change userdom_read_all_users_state to include reading symbolic links in /proc


trackballs-1.1.4-7.fc11
-----------------------
* Sat Dec 27 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.1.4-7
- Replace included gnu freefont copy with a symlink to dejavu (rh 477470)


xscreensaver-5.07-5.fc11
------------------------
* Sat Dec 27 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.07-5
- Apply gdk trial patch from jwz (slightly modified)
- Fix warning on m6502.c


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 30
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-python-5.03.0-16.fc9.i386 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.i386 requires bitstream-vera-fonts
	enigma-1.01-6.3.i386 requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.i386 requires libffi.so.4
	gwave-2-11.20070514snap.fc10.i386 requires libguile-gnome-gobject-0.so.0
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	neverball-1.4.0-12.fc11.i386 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	perl-bioperl-1.5.9-0.1.1.fc11.noarch requires perl(Bio::Graphics)
	perl-bioperl-1.5.9-0.1.1.fc11.noarch requires perl(Bio::Graphics::Panel)
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.i386 requires dejavu-fonts
	wormux-0.8.2-2.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	banshee-devel-1.4.1-2.fc11.x86_64 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.i386 requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.x86_64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.x86_64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.x86_64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-1.fc11.x86_64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.x86_64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.x86_64 requires libguile-gnome-gobject-0.so.0()(64bit)
	gwave-2-11.20070514snap.fc10.x86_64 requires libffi.so.4()(64bit)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.x86_64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.x86_64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	perl-bioperl-1.5.9-0.1.1.fc11.noarch requires perl(Bio::Graphics)
	perl-bioperl-1.5.9-0.1.1.fc11.noarch requires perl(Bio::Graphics::Panel)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.x86_64 requires dejavu-fonts
	wormux-0.8.2-2.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.ppc requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc requires libpython2.5.so.1.0
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc requires bitstream-vera-fonts
	enigma-1.01-6.3.ppc requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-1.fc11.ppc requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.ppc requires libffi.so.4
	gwave-2-11.20070514snap.fc10.ppc requires libguile-gnome-gobject-0.so.0
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.ppc requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	perl-bioperl-1.5.9-0.1.1.fc11.noarch requires perl(Bio::Graphics)
	perl-bioperl-1.5.9-0.1.1.fc11.noarch requires perl(Bio::Graphics::Panel)
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	wesnoth-1.4.6-6.fc11.ppc requires dejavu-fonts
	wormux-0.8.2-2.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	csound-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	csound-python-5.03.0-16.fc9.ppc64 requires python(abi) = 0:2.5
	csound-python-5.03.0-16.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.ppc64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-1.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	perl-bioperl-1.5.9-0.1.1.fc11.noarch requires perl(Bio::Graphics)
	perl-bioperl-1.5.9-0.1.1.fc11.noarch requires perl(Bio::Graphics::Panel)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	wesnoth-1.4.6-6.fc11.ppc64 requires dejavu-fonts
	wormux-0.8.2-2.fc11.ppc64 requires dejavu-fonts





From kevin.kofler at chello.at  Sun Dec 28 11:53:19 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 28 Dec 2008 12:53:19 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
	<1230444576.21895.99.camel@localhost.localdomain>
Message-ID: <gj7pbf$k4k$1@ger.gmane.org>

Callum Lerwick wrote:
> 1) I used Macs before I ever used Linux. The System 7 era, in
> particular. My high school was entirely Mac based. What is foreign to
> you is quite familiar to me.

Yet Apple abandoned spatial in favor of column navigation (i.e. what you get
if you fire up Dolphin and select "Columns" in the toolbar).

        Kevin Kofler



From ville.skytta at iki.fi  Sun Dec 28 12:22:07 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 28 Dec 2008 14:22:07 +0200
Subject: Mailman breakage [Was: rawhide report: 20081227 changes]
In-Reply-To: <200812280044.mBS0i7C3011907@laptop14.inf.utfsm.cl>
References: <20081227103132.0F5E71F8259@releng2.fedora.phx.redhat.com>
	<200812280044.mBS0i7C3011907@laptop14.inf.utfsm.cl>
Message-ID: <200812281422.10249.ville.skytta@iki.fi>

On Sunday 28 December 2008, Horst H. von Brand wrote:
> Rawhide Report <rawhide at fedoraproject.org> wrote:
>
> [...]
>
> > rpmdevtools-7.0-1.fc11
> > ----------------------
> > * Fri Dec 26 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 7.0-1
>                                         ~~
> Yep, same UTF-8 mangling I see here with my mailman installation. Sigh...

Are you sure it's mailman's fault?  The copy I got of the original looked like 
it was sent by something that just dumped its data into the body of the 
non-MIME mail it created as raw UTF-8.  I suppose making the mails MIME 
messages and indicating the correct Content-Type with charset info and an 
appropriate Content-Transfer-Encoding would work better (+ possibly applying 
e.g. quoted-printable for extra safety).



From vonbrand at inf.utfsm.cl  Sun Dec 28 17:02:19 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 28 Dec 2008 14:02:19 -0300
Subject: Mailman breakage [Was: rawhide report: 20081227 changes]
In-Reply-To: <200812281422.10249.ville.skytta@iki.fi>
References: <20081227103132.0F5E71F8259@releng2.fedora.phx.redhat.com>
	<200812280044.mBS0i7C3011907@laptop14.inf.utfsm.cl>
	<200812281422.10249.ville.skytta@iki.fi>
Message-ID: <200812281702.mBSH2JIi031939@laptop14.inf.utfsm.cl>

Ville =?utf-8?q?Skytt=C3=A4?= <ville.skytta at iki.fi> wrote:
> On Sunday 28 December 2008, Horst H. von Brand wrote:
> > Rawhide Report <rawhide at fedoraproject.org> wrote:
> >
> > [...]
> >
> > > rpmdevtools-7.0-1.fc11
> > > ----------------------
> > > * Fri Dec 26 17:00:00 2008 Ville Skytt???????? <ville.skytta at iki.fi> - 7.0-1
> >                                         ~~
> > Yep, same UTF-8 mangling I see here with my mailman installation. Sigh...

> Are you sure it's mailman's fault?  The copy I got of the original looked
> like it was sent by something that just dumped its data into the body of
> the non-MIME mail it created as raw UTF-8.  I suppose making the mails
> MIME messages and indicating the correct Content-Type with charset info
> and an appropriate Content-Transfer-Encoding would work better (+
> possibly applying e.g. quoted-printable for extra safety).

AFAICS, Mailman just doesn't forward the headers telling the encoding of
the non-ASCII body.

See above, the mangled text was re-mangled.
-- 
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 mschwendt at gmail.com  Sun Dec 28 17:30:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 28 Dec 2008 18:30:33 +0100
Subject: Mailman breakage [Was: rawhide report: 20081227 changes]
In-Reply-To: <200812281702.mBSH2JIi031939@laptop14.inf.utfsm.cl>
References: <20081227103132.0F5E71F8259@releng2.fedora.phx.redhat.com>
	<200812280044.mBS0i7C3011907@laptop14.inf.utfsm.cl>
	<200812281422.10249.ville.skytta@iki.fi>
	<200812281702.mBSH2JIi031939@laptop14.inf.utfsm.cl>
Message-ID: <20081228183033.5b8b2541.mschwendt@gmail.com>

On Sun, 28 Dec 2008 14:02:19 -0300, Horst wrote:

> > > [...]
> > >
> > > > rpmdevtools-7.0-1.fc11
> > > > ----------------------
> > > > * Fri Dec 26 17:00:00 2008 Ville Skytt???? <ville.skytta at iki.fi> - 7.0-1
> > >                                         ~~
> > > Yep, same UTF-8 mangling I see here with my mailman installation. Sigh...
> 
> > Are you sure it's mailman's fault?  The copy I got of the original looked
> > like it was sent by something that just dumped its data into the body of
> > the non-MIME mail it created as raw UTF-8.  I suppose making the mails
> > MIME messages and indicating the correct Content-Type with charset info
> > and an appropriate Content-Transfer-Encoding would work better (+
> > possibly applying e.g. quoted-printable for extra safety).
> 
> AFAICS, Mailman just doesn't forward the headers telling the encoding of
> the non-ASCII body.

Are you sure there are such headers to begin with?

FWIW, the Fedora EPEL build report [posted to epel-devel-list] sets the
content type and the transfer encoding, and that works fine with UTF-8
symbols used in spec changelogs.



From hendrik.kaju at gmail.com  Sun Dec 28 18:22:21 2008
From: hendrik.kaju at gmail.com (Hendrik Kaju)
Date: Sun, 28 Dec 2008 20:22:21 +0200
Subject: Open Source survey
Message-ID: <1230488541.12797.3.camel@gecko3>

Dear developers

My name is Hendrik Kaju and I am a high school student and an open
source enthusiast from Estonia. As a part of my school project, I am
conducting a survey on open source software development (how developing
OSS is related to a developer's day job, etc). It is located at
http://www.surveygizmo.com/s/90385/open-source
I would really appreciate it if you could take a few minutes to fill out
this short survey.

Best regards,
Hendrik Kaju
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: See on s?numi digitaalselt	allkirjastatud osa
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081228/c9448172/attachment.sig>

From otto_rey at yahoo.com.ar  Sun Dec 28 19:18:22 2008
From: otto_rey at yahoo.com.ar (Otto Rey)
Date: Sun, 28 Dec 2008 11:18:22 -0800 (PST)
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
	<1230444576.21895.99.camel@localhost.localdomain>
	<gj7pbf$k4k$1@ger.gmane.org>
Message-ID: <735933.61949.qm@web52401.mail.re2.yahoo.com>

+1 Nautilus use Browser view for fedora 11



----- Mensaje original ----
De: Kevin Kofler <kevin.kofler at chello.at>
Para: fedora-devel-list at redhat.com
Enviado: domingo 28 de diciembre de 2008, 9:53:19
Asunto: Re: Call for vote: Nautilus use Browser view for fedora 11

Callum Lerwick wrote:
> 1) I used Macs before I ever used Linux. The System 7 era, in
> particular. My high school was entirely Mac based. What is foreign to
> you is quite familiar to me.

Yet Apple abandoned spatial in favor of column navigation (i.e. what you get
if you fire up Dolphin and select "Columns" in the toolbar).

        Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list



      ____________________________________________________________________________________
?Busc? desde tu celular!

Yahoo! oneSEARCH ahora est? en Claro

http://ar.mobile.yahoo.com/onesearch



From kevin at scrye.com  Sun Dec 28 19:57:36 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 28 Dec 2008 12:57:36 -0700
Subject: rpms/spicebird/F-10 find-external-requires, NONE, 1.1
 spicebird-beta-langpacks-0.7-20081121.tar.bz2, NONE, 1.1
 spicebird-mozconfig, NONE, 1.1 spicebird-open-browser.sh, NONE, 1.1
 spicebird-path.patch, NONE, 1.1 spicebird-redhat-default-prefs.js, NONE,
 1.1 spicebird.desktop, NONE, 1.1 spicebird.png, NONE, 1.1 spicebird.sh.in,
 NONE, 1.1 spicebird.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
In-Reply-To: <20081228193824.5A63770130@cvs1.fedora.phx.redhat.com>
References: <20081228193824.5A63770130@cvs1.fedora.phx.redhat.com>
Message-ID: <20081228125736.15cc865d@ohm.scrye.com>

On Sun, 28 Dec 2008 19:38:24 +0000 (UTC)
"Steven M. Parrish" <tuxbrewr at fedoraproject.org> wrote:

> Author: tuxbrewr
> 
> Update of /cvs/pkgs/rpms/spicebird/F-10
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23438
> 
> Modified Files:
> 	.cvsignore sources 
> Added Files:
> 	find-external-requires 
> 	spicebird-beta-langpacks-0.7-20081121.tar.bz2 
> 	spicebird-mozconfig spicebird-open-browser.sh 
> 	spicebird-path.patch spicebird-redhat-default-prefs.js 
> 	spicebird.desktop spicebird.png spicebird.sh.in
> spicebird.spec Log Message:
> Initial build for F10 branch
> 
> 
> --- NEW FILE find-external-requires ---
> #!/bin/sh
> 
> # Finds requirements provided outside of the current file set
> 
> filelist=`sed "s/[]['\"*?{}]/\\\\\&/g"`
> 
> provides=`echo $filelist | /usr/lib/rpm/find-provides`
> 
> {
> for f in $filelist ; do
> 	echo $f | /usr/lib/rpm/find-requires | while read req ; do
> 		found=0
> 		for p in $provides ; do
> 			if [ "$req" = "$p" ]; then
> 				found=1
> 			fi
> 		done
> 		if [ "$found" = "0" ]; then
> 			echo $req
> 		fi
> 	done
> done
> } | sort -u
> 
> --- NEW FILE spicebird-beta-langpacks-0.7-20081121.tar.bz2 ---

Please put binary files into the lookaside cache, not into CVS
directly. ;) 

cvs rm -f spicebird-beta-langpacks-0.7-20081121.tar.bz2
make upload FILES="spicebird-beta-langpacks-0.7-20081121.tar.bz2"
cvs commit spicebird-beta-langpacks-0.7-20081121.tar.bz2 .cvsignore sources

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081228/22e32143/attachment.sig>

From cdahlin at redhat.com  Sun Dec 28 20:38:52 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sun, 28 Dec 2008 15:38:52 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <20081217205116.GD4053@localhost.localdomain>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<20081217204320.GG1223969@hiwaay.net>
	<20081217205116.GD4053@localhost.localdomain>
Message-ID: <4957E3DC.5010202@redhat.com>

Paul W. Frields wrote:
> On Wed, Dec 17, 2008 at 02:43:20PM -0600, Chris Adams wrote:
>   
>> Once upon a time, Yaakov Nemoy <loupgaroublond at gmail.com> said:
>>     
>>> Better question is, why do you need ext4 on /boot?
>>>       
>> If all the rest of your partitions are ext4, why would you want to load
>> additional FS module(s) (ext2 or ext3+jbd) just for one filesystem?
>>     
>
> Doesn't the kernel now include those drivers, as opposed to having
> them as modules?
>
> $ grep '\(JBD\|EXT3\)' /boot/config-2.6.27.7-134.fc10.x86_64 
> CONFIG_EXT3_FS=y
> CONFIG_EXT3_FS_XATTR=y
> CONFIG_EXT3_FS_POSIX_ACL=y
> CONFIG_EXT3_FS_SECURITY=y
> CONFIG_JBD=y
> # CONFIG_JBD_DEBUG is not set
> CONFIG_JBD2=m
> CONFIG_JBD2_DEBUG=y
>
>   
And it will likely continue to be built in and used, as more and more 
solid state drives appear (journaling is a bad idea for solid state).

--CJD



From cdahlin at redhat.com  Sun Dec 28 20:49:20 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sun, 28 Dec 2008 15:49:20 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <494930CD.70709@herr-schmitt.de>
References: <494930CD.70709@herr-schmitt.de>
Message-ID: <4957E650.6010809@redhat.com>

Jochen Schmitt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hallo,
>
> nowaday I have read in the german fedora forum, that grub is not able
> to handle
> ext4 file systems. In opposite grub2 should be able to support ext4.
>
>   
I haven't looked at the code for grub2 myself, but most of the people I 
talk to that have cringe when they mention it. The people I talk to tend 
to be heavily involved in the boot process. As a piece of software 
engineering, it hasn't earned many fans among those most concerned with 
the change as far as I can tell.

--CJD



From chitlesh.goorah at gmail.com  Sun Dec 28 23:41:59 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Mon, 29 Dec 2008 00:41:59 +0100
Subject: Fwd: rpms/g-wrap/devel .cvsignore, 1.7, 1.8 g-wrap.spec, 1.47,
	1.48 sources, 1.8, 1.9
In-Reply-To: <20081226174951.F108D70105@cvs1.fedora.phx.redhat.com>
References: <20081226174951.F108D70105@cvs1.fedora.phx.redhat.com>
Message-ID: <50baabb30812281541r298bd75fg5c8520294e20c986@mail.gmail.com>

Hello Michel,

please next time when you are updating this package before committing
to any branch please build the packages that requires it.

g-wrap and friends are heavily broken !!!!!!!!!!!!!!!!!!!!!!!!!!
gwave (requiring guile-gnome-platform) is broken on rawhide because
that. Unfortunately I'm going on vacation as from tomorrow, I can't
build it any more until I get back (11 january) if you can fix gwave
and ensure that it is not crashing please do update gwave for me. On
gwave package review, i have entailed a testing procedure.

Just FYI,
all these g-wrap and friends keep on exchanging files between the
upstream source packages. The lastest source versions of all the
dependencies are NEVER compatible between them, thereby all packages
requiring them are broken. As maintainers we have to track the best
latest compatible set.

Before updating please ensure that you are not asking for 4 months of
hard work in the future. I have a long todo list for FEL pending
before F-11.

Chitlesh

---------- Forwarded message ----------
From: Michel Alexandre Salim <salimma at fedoraproject.org>
Date: Fri, Dec 26, 2008 at 6:49 PM
Subject: rpms/g-wrap/devel .cvsignore, 1.7, 1.8 g-wrap.spec, 1.47,
1.48 sources, 1.8, 1.9
To: cvsextras at fedoraproject.org, g-wrap-owner at fedoraproject.org


Author: salimma

Update of /cvs/pkgs/rpms/g-wrap/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6281

Modified Files:
       .cvsignore g-wrap.spec sources
Log Message:
* Fri Dec 26 2008 Michel Salim <salimma at fedoraproject.org> - 1.9.11-1
- Update to 1.9.11
- Use system libffi (bug #433083)



Index: .cvsignore
===================================================================
RCS file: /cvs/pkgs/rpms/g-wrap/devel/.cvsignore,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- .cvsignore  31 Aug 2007 20:19:59 -0000      1.7
+++ .cvsignore  26 Dec 2008 17:49:21 -0000      1.8
@@ -1 +1 @@
-g-wrap-1.9.9.tar.gz
+g-wrap-1.9.11.tar.gz


Index: g-wrap.spec
===================================================================
RCS file: /cvs/pkgs/rpms/g-wrap/devel/g-wrap.spec,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- g-wrap.spec 6 Sep 2008 13:26:21 -0000       1.47
+++ g-wrap.spec 26 Dec 2008 17:49:21 -0000      1.48
@@ -1,6 +1,6 @@
 Name:            g-wrap
-Version:         1.9.9
-Release:         7%{?dist}
+Version:         1.9.11
+Release:         1%{?dist}
 Summary:         A tool for creating Scheme interfaces to C libraries

 Group:           Development/Libraries
@@ -12,9 +12,9 @@
 #Patch3:          g-wrap-1.9.8-staticffi.patch
 BuildRoot:       %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

-BuildRequires:   guile-devel, guile-lib
+BuildRequires:   guile-devel, guile-lib, libffi-devel
 BuildRequires:   slib, glib2-devel, pkgconfig, autoconf
-Requires:        guile, guile-lib
+Requires:        guile-lib

 Requires(post):  /sbin/install-info
 Requires(preun): /sbin/install-info
@@ -30,7 +30,7 @@
 Group:           Development/Libraries

 Requires:        %{name} = %{version}-%{release}
-Requires:        pkgconfig, guile-devel, automake
+Requires:        pkgconfig, guile-devel, libffi-devel, automake

 %description     devel
 g-wrap-devel contains development libraries and headers for g-wrap.
@@ -55,7 +55,7 @@


 %build
-export CFLAGS="$RPM_OPT_FLAGS -fPIC"
+export CFLAGS="$RPM_OPT_FLAGS -fPIC `pkgconfig libffi --cflags`"
 %configure --disable-static

 #remove Rpath
@@ -127,6 +127,10 @@


 %changelog
+* Fri Dec 26 2008 Michel Salim <salimma at fedoraproject.org> - 1.9.11-1
+- Update to 1.9.11
+- Use system libffi (bug #433083)
+
 * Sat Sep 06 2008 Xavier Lamien <lxtnow[at]gmail.com> - 1.9.9-7
 - Remove out-dated patch -info.patch.
 - Rebuild for Rawhide bug #434278.


Index: sources
===================================================================
RCS file: /cvs/pkgs/rpms/g-wrap/devel/sources,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- sources     31 Aug 2007 20:19:59 -0000      1.8
+++ sources     26 Dec 2008 17:49:21 -0000      1.9
@@ -1 +1 @@
-9014d7ed8d395ff335a6a4bf5778ed4e  g-wrap-1.9.9.tar.gz
+f6f54c2a2ce3d8257ccaf19f923cbe45  g-wrap-1.9.11.tar.gz

--
fedora-extras-commits mailing list
fedora-extras-commits at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-commits



From snecklifter at gmail.com  Sun Dec 28 23:46:55 2008
From: snecklifter at gmail.com (Christopher Brown)
Date: Sun, 28 Dec 2008 23:46:55 +0000
Subject: improve-relatime.patch dropped from F10
In-Reply-To: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
References: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
Message-ID: <364d303b0812281546gfef472dp932c856a01b07d83@mail.gmail.com>

2008/12/28 Ricardo Arg?ello <ricardo at fedoraproject.org>:
> Hi,
>
> Why was the improve-relatime.patch dropped from F10's kernel? F9 had
> relatime on by default using this patch.
> I first thought the upstream kernel had the patch now, but
> /proc/mounts does not show relatime in F10.
>
> I found this bug, looks related:
>
>  mkinitrd can't deal with the "relatime" mount option
>  https://bugzilla.redhat.com/show_bug.cgi?id=430280
>
> More info:
> http://kerneltrap.org/node/14148
> http://people.redhat.com/mingo/relatime-patches/improve-relatime.patch

You should send this to the fedora-kernel list. Its non-subscription
and might get a better review.

Regards

-- 
Christopher Brown



From kevin.kofler at chello.at  Mon Dec 29 00:59:58 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 29 Dec 2008 01:59:58 +0100
Subject: Futuer of grub/grub2 to F11
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<20081217204320.GG1223969@hiwaay.net>
	<20081217205116.GD4053@localhost.localdomain>
	<4957E3DC.5010202@redhat.com>
Message-ID: <gj97ee$8hj$1@ger.gmane.org>

Casey Dahlin wrote:
> And it will likely continue to be built in and used, as more and more
> solid state drives appear (journaling is a bad idea for solid state).

ext3 is also journaled, so using ext3 rather than ext4 to avoid the
journaling doesn't make sense, you want ext2 if you don't want a journal.

        Kevin Kofler



From cdahlin at redhat.com  Mon Dec 29 02:29:50 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sun, 28 Dec 2008 21:29:50 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <gj97ee$8hj$1@ger.gmane.org>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<20081217204320.GG1223969@hiwaay.net>	<20081217205116.GD4053@localhost.localdomain>	<4957E3DC.5010202@redhat.com>
	<gj97ee$8hj$1@ger.gmane.org>
Message-ID: <4958361E.3070101@redhat.com>

Kevin Kofler wrote:
> Casey Dahlin wrote:
>   
>> And it will likely continue to be built in and used, as more and more
>> solid state drives appear (journaling is a bad idea for solid state).
>>     
>
> ext3 is also journaled, so using ext3 rather than ext4 to avoid the
> journaling doesn't make sense, you want ext2 if you don't want a journal.
>
>         Kevin Kofler
>
>   
That's what I meant to imply. AFAIK ext2/3 are essentially the same 
driver (ext3 is a strict superset of ext2, so the latter can be mounted 
with the former's driver) so I'm pretty sure if we get one we get the other.

--CJD



From cdahlin at redhat.com  Mon Dec 29 02:50:35 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sun, 28 Dec 2008 21:50:35 -0500
Subject: /*MerryChristmas.c*/
In-Reply-To: <16de708d0812241616p45e4fab2xc1817c507d0020ec@mail.gmail.com>
References: <4952A587.5000400@projetofedora.org>
	<16de708d0812241616p45e4fab2xc1817c507d0020ec@mail.gmail.com>
Message-ID: <49583AFB.5090903@redhat.com>

Arthur Pemberton wrote:
> On Wed, Dec 24, 2008 at 3:11 PM, Rodrigo Padula de Oliveira
> <rodrigopadula at projetofedora.org> wrote:
>   
>> /*MerryChristmas.c*/
>> void main (int argc, char* argv[])
>> {
>>    printf("\n Merry Christmas! \n");
>>    if (strcmp(argv[1],"girl") == 0)    /*general idea*/
>>        printf("Kisses! \n");
>>    else
>>        printf("Hugs! \n");
>> }
>>     
>
>
> #i!/bin/env python
> import sys
> print 'Kisses!' if len(sys.argv) == 2 and sys.argv[1].lower() ==
> 'girl' else 'Hugs!'
>
>   
#! /usr/bin/env ruby

class Object
  def response
    "Hugs!"
  end
end

class String
  def response
    return "Kisses!" if self.downcase == "girl"
    super
  end
end

puts "Merry Christmas!\n#{ARGV[0].response}"



From lyos.gemininorezel at gmail.com  Mon Dec 29 07:54:25 2008
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Mon, 29 Dec 2008 02:54:25 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
Message-ID: <49588231.2070800@gmail.com>

Yaakov Nemoy wrote:
> 2008/12/17 Jochen Schmitt <Jochen at herr-schmitt.de>:
>   
> /boot is a 100-200 MB partition on many machines. 

> ...there's just no sense supporting /boot on anything
> other than a 100-200 MB ext2 or ext3 volume.
>   
Sorry... but that's just plain wrong.

Maybe my use case is odd... but my /boot partition is a *MINIMUM* of 5GB 
on all of my computers.

Why?

1.) I have a rescue image setup to boot if I need it...
and
2.) I have a ghost image I made right after installing this version of 
fedora.

I have no use for such a tiny /boot partition like you say you use.

You need to keep in mind... that your use case is *NOT* the only one... 
or even an optimal one.

Never ASSume anything... especially that which can be tainted by your 
own bias.

Lyos Gemini Norezel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/cb48a35b/attachment.htm>

From cdahlin at redhat.com  Mon Dec 29 08:05:16 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 29 Dec 2008 03:05:16 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <49588231.2070800@gmail.com>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<49588231.2070800@gmail.com>
Message-ID: <495884BC.7040800@redhat.com>

Lyos Gemini Norezel wrote:
> Yaakov Nemoy wrote:
>> 2008/12/17 Jochen Schmitt <Jochen at herr-schmitt.de>:
>>   
>> /boot is a 100-200 MB partition on many machines. 
>
>> ...there's just no sense supporting /boot on anything
>> other than a 100-200 MB ext2 or ext3 volume.
>>   
> Sorry... but that's just plain wrong.
>
> Maybe my use case is odd... but my /boot partition is a *MINIMUM* of 
> 5GB on all of my computers.
>
> Why?
>
> 1.) I have a rescue image setup to boot if I need it...
> and
> 2.) I have a ghost image I made right after installing this version of 
> fedora.
>

I don't see why either of those should exist entirely in /boot. You are 
allowed further partitions. Nothing in /boot should remain relevant 
after we get a proper kernel in memory and enough modules to read the 
rest of the disk.

--CJD



From lyos.gemininorezel at gmail.com  Mon Dec 29 08:43:09 2008
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Mon, 29 Dec 2008 03:43:09 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <495884BC.7040800@redhat.com>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<49588231.2070800@gmail.com>
	<495884BC.7040800@redhat.com>
Message-ID: <49588D9D.5020303@gmail.com>

Casey Dahlin wrote:
> Lyos Gemini Norezel wrote:
>> Sorry... but that's just plain wrong.
>>
>> Maybe my use case is odd... but my /boot partition is a *MINIMUM* of 
>> 5GB on all of my computers.
>>
>> Why?
>>
>> 1.) I have a rescue image setup to boot if I need it...
>> and
>> 2.) I have a ghost image I made right after installing this version 
>> of fedora.
>>
>
> I don't see why either of those should exist entirely in /boot. You 
> are allowed further partitions. 

Where else would they be better placed?
I have no desire to clutter my disk with endless numbers of partitions, 
and placing them in the root partition is just plain stupid.

> Nothing in /boot should remain relevant after we get a proper kernel 
> in memory and enough modules to read the rest of the disk.
>
> --CJD

Again... where better to place the tools that can fix a broken system?

Keep in mind that these tools should rarely (if ever) be used.

After all... these are supposed to be the tools of last resort... where 
better to place them... than the partition that's not supposed to be 
touched?

The /boot partition is, in fact, the perfect location for such emergency 
tools.


Lyos Gemini Norezel



From cdahlin at redhat.com  Mon Dec 29 10:35:43 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 29 Dec 2008 05:35:43 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <20081217085108.6cdc5d21@infradead.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>
	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<4948220D.9070202@behdad.org>	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<20081217085108.6cdc5d21@infradead.org>
Message-ID: <4958A7FF.2000500@redhat.com>

Arjan van de Ven wrote:
> On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
> Seth Vidal <skvidal at fedoraproject.org> wrote:
>
>   
>>> Or hibernate?
>>>       
>> At least on my system hibernate takes as much time as a reboot.
>>
>>     
>
> btw this is a very fundamental property of hibernate. You need to do all
> disk IO to get the system state to disk. And then at resume, you need
> to do all disk IO to get the state from disk again. That's twice ;)
>
> This is compounded by the property that a hibernate tends to flush at
> least half the disk cache (it has to, to get space to work in), which
> you then need to page right back in, so even when you're back, the first
> minute or two sucks badly.
>
> I suspect you will always be able to boot faster than you can
> hibernate+resume.
>
>
>
>   

Slightly off subject, did sreadahead ever get publicly released? Did I 
miss it?

--CJD



From rawhide at fedoraproject.org  Mon Dec 29 10:35:52 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 29 Dec 2008 10:35:52 +0000 (UTC)
Subject: rawhide report: 20081229 changes
Message-ID: <20081229103552.AEFDD1F825C@releng2.fedora.phx.redhat.com>

Compose started at Mon Dec 29 06:01:08 UTC 2008

New package NaturalDocs
        Documentation generator for multiple programming languages
New package fswebcam
        Tiny and flexible webcam program
New package perl-ModelSim-List
        Analyse the 'list' output of the ModelSim simulator
New package perl-Perlilog
        Verilog environment and IP core handling in Perl
New package phatch
        Photo batch processor
New package spicebird
        Synovel Spicebird PIM client
New package trac-privateticketsplugin
        Trac extension to allow users to view only related tickets
New package xteddy
        Tool to sit around silently, look cute, and make you smile
New package yersinia
        Network protocols tester and attacker
Updated Packages:

bison-2.4.1-1.fc11
------------------
* Sun Dec 28 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 2.4.1-1
- Rebase to 2.4.1
- Resolves: #478348


crypto-utils-2.4.1-5
--------------------
* Sun Dec 28 17:00:00 2008 Elio Maldonado <emaldona at redhat.com> - 2.4.1-5
- genkey: fix server key name extension
- certwatch: code cleanup


csound-5.03.0-20.fc11
---------------------
* Sun Dec 28 17:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 5.03.0-20
- add sparc64 to list of 64 bit arches

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 5.03.0-19
- Fix locations for Python 2.6

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 5.03.0-18
- Rebuild for Python 2.6

* Thu May 22 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 5.03.0-17
- license tag fix


dnsmasq-2.46-1.fc11
-------------------
* Mon Dec 29 17:00:00 2008 Mat??j Cepl <mcepl at redhat.com> - 2.45-2
- rebuilt


e16-0.16.8.14-4.fc11
--------------------
* Sun Dec 28 17:00:00 2008 Terje Rosten <terjeros at phys.ntnu.no> - 0.16.8.14-4
- Various hacks (fonts dir, %pretrans) to make update smooth


gstreamermm-0.9.8-2.fc11
------------------------
* Sun Dec 28 17:00:00 2008 Denis Leroy <denis at poolshark.org> - 0.9.8-2
- Rebuild for pkgconfig


guile-gnome-platform-2.16.1-2.fc11
----------------------------------
* Sun Dec 28 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 2.16.1-2
- Multiarch fix: detect libdir at runtime for files in %{_datadir}


jd-2.1.0-1.fc11
---------------
* Mon Dec 29 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.1.0-1
- 2.1.0


krusader-2.0.0-0.3.beta2.fc11
-----------------------------
* Sun Dec 28 17:00:00 2008 Marcin Garski <mgarski[AT]post.pl> 2.0.0-0.3.beta2
- Update to 2.0.0-beta2


mantis-1.1.6-2.fc11
-------------------
* Sun Dec 28 17:00:00 2008 Sven Lankes <sven at lank.es> - 1.1.6-2
- add patch to suppress bogus warning during setup 
    (closes bz #437142)
- convert ChangeLog to UTF8
- remove .gitignore
- change mantis_offline.php-symlink to be relative


nip2-7.16.3-3.fc11
------------------
* Sat Dec 27 17:00:00 2008 Adam Goode <adam at spicenitz.org> - 7.16.3-3
- Fix build problem related to flex

* Mon Dec 22 17:00:00 2008 Adam Goode <adam at spicenitz.org> - 7.16.3-2
- Add gsl-devel and xdg-utils to build requires

* Sun Dec 21 17:00:00 2008 Adam Goode <adam at spicenitz.org> - 7.16.3-1
- New release
- Update description


perl-Class-MOP-0.74-1.fc11
--------------------------
* Sun Dec 28 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.74-1
- update to 0.74


perl-Moose-0.63-1.fc11
----------------------
* Sun Dec 28 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.63-1
- update to 0.63
- bump br versions on Moose, List::MoreUtils


perl-bioperl-1.5.9-0.2.1.fc11
-----------------------------
* Sun Dec 28 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.5.9-0.2.1
- Filter unwanted Requires: Bio::Graphics and Bio::Graphics::Panel
  fixes broken deps until the .pl demo scripts remove them to the
  appropriate module


vdr-1.6.0-16.fc11
-----------------
* Mon Dec 29 17:00:00 2008 Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> - 1.6.0-16
- Disable kernel DVB API check to fix build, upstream VDR 1.6.0 expects DVB
  API v3 but current Rawhide kernels have v5.


vips-7.16.4-1.fc11
------------------
* Sun Dec 28 17:00:00 2008 Adam Goode <adam at spicenitz.org> - 7.16.4-1
- New release


wesnoth-1.4.7-1.fc11
--------------------
* Sun Dec 28 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 1.4.7-1
- 1.4.7
- Remove font requirement


xorg-x11-drv-i810-2.5.99.1-0.3.fc11
-----------------------------------
* Mon Dec 29 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.5.99.1-0.3
- enable KMS code in driver


xorg-x11-server-1.5.99.3-5.fc11
-------------------------------
* Mon Dec 29 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.5.99.3-5
- remove unused build options - enable dri2


xscreensaver-5.08-1.fc11
------------------------
* Sun Dec 28 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.08-1
- Update to 5.08
- All non Fedora-specific patches went upstream
- Preserve all %release string for XScreenSaver.ad, util.h


Summary:
Added Packages: 9
Removed Packages: 0
Modified Packages: 20
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.i386 requires bitstream-vera-fonts
	enigma-1.01-6.3.i386 requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.i386 requires libffi.so.4
	gwave-2-11.20070514snap.fc10.i386 requires libguile-gnome-gobject-0.so.0
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	neverball-1.4.0-12.fc11.i386 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	trac-privateticketsplugin-1.1.1-0.2.svn5068.fc11.noarch requires trac < 0:0.11
	wormux-0.8.2-2.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	banshee-devel-1.4.1-2.fc11.x86_64 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.i386 requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.x86_64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.x86_64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.x86_64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.x86_64 requires libguile-gnome-gobject-0.so.0()(64bit)
	gwave-2-11.20070514snap.fc10.x86_64 requires libffi.so.4()(64bit)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.x86_64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.x86_64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	trac-privateticketsplugin-1.1.1-0.2.svn5068.fc11.noarch requires trac < 0:0.11
	wormux-0.8.2-2.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.ppc requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc requires pkgconfig(pkg-config) >= 0:0.21
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc requires bitstream-vera-fonts
	enigma-1.01-6.3.ppc requires dejavu-fonts-experimental
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.ppc requires libffi.so.4
	gwave-2-11.20070514snap.fc10.ppc requires libguile-gnome-gobject-0.so.0
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.ppc requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	trac-privateticketsplugin-1.1.1-0.2.svn5068.fc11.noarch requires trac < 0:0.11
	wormux-0.8.2-2.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	empathy-devel-2.25.3-2.fc11.ppc64 requires pkgconfig(pkg-config) >= 0:0.21
	enigma-1.01-6.3.ppc64 requires dejavu-fonts-experimental
	enigma-1.01-6.3.ppc64 requires bitstream-vera-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	trac-privateticketsplugin-1.1.1-0.2.svn5068.fc11.noarch requires trac < 0:0.11
	wormux-0.8.2-2.fc11.ppc64 requires dejavu-fonts





From dan at danny.cz  Mon Dec 29 10:42:59 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Mon, 29 Dec 2008 11:42:59 +0100
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <4958A7FF.2000500@redhat.com>
References: <gi5qm4$bbq$1@ger.gmane.org>
	<1229353608.12163.13.camel@localhost.localdomain>
	<gi5sg4$ikd$1@ger.gmane.org> <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>
	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>
	<20081216121759.GA2414@free.fr> <20081216141156.GA30911@localhost>
	<4947BA95.4010704@gmail.com> <49481793.9060406@behdad.org>
	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>
	<4948220D.9070202@behdad.org>
	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>
	<20081217085108.6cdc5d21@infradead.org> <4958A7FF.2000500@redhat.com>
Message-ID: <1230547379.3614.20.camel@eagle.danny.cz>

Casey Dahlin p??e v Po 29. 12. 2008 v 05:35 -0500:
> Arjan van de Ven wrote:
> > On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
> > Seth Vidal <skvidal at fedoraproject.org> wrote:
> >
> >   
> >>> Or hibernate?
> >>>       
> >> At least on my system hibernate takes as much time as a reboot.
> >>
> >>     
> >
> > btw this is a very fundamental property of hibernate. You need to do all
> > disk IO to get the system state to disk. And then at resume, you need
> > to do all disk IO to get the state from disk again. That's twice ;)
> >
> > This is compounded by the property that a hibernate tends to flush at
> > least half the disk cache (it has to, to get space to work in), which
> > you then need to page right back in, so even when you're back, the first
> > minute or two sucks badly.
> >
> > I suspect you will always be able to boot faster than you can
> > hibernate+resume.
> >
> >
> >
> >   
> 
> Slightly off subject, did sreadahead ever get publicly released? Did I 
> miss it?

It has been even submitted for review -
https://bugzilla.redhat.com/show_bug.cgi?id=464045


		Dan




From cdahlin at redhat.com  Mon Dec 29 10:44:11 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 29 Dec 2008 05:44:11 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1229469439.10880.39.camel@72-58-215-36.pools.spcsdns.net>
References: <gi5svv$jvc$1@ger.gmane.org>
	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<1229464318.2590.23.camel@localhost.localdomain>	<20081216223006.GC1358034@hiwaay.net>	<1229467644.5054.132.camel@erebor.bos.redhat.com>
	<1229469439.10880.39.camel@72-58-215-36.pools.spcsdns.net>
Message-ID: <4958A9FB.7000901@redhat.com>

Dan Williams wrote:
> On Tue, 2008-12-16 at 17:47 -0500, Jeremy Katz wrote:
>   
>> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
>>     
>>> Once upon a time, Jesse Keating <jkeating at redhat.com> said:
>>>       
>>>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>>>         
>>>>> so a good reason to power off is simply to save power
>>>>>           
>>>> Or to reboot for one of our frequent updates that require it.  kernel,
>>>> dbus, etc...
>>>>         
>>> Why does anything other than a kernel update require a reboot?
>>>       
>> The system bus cannot be restarted.  Similarly, any apps you have
>> running will be using old libraries so things like glibc you really want
>> to reboot for.  
>>     
>
> The problem is mainly one of state.  For example, NetworkManager has
> some code to handle reconnection to the system bus.  But to
> transparently handle bus restarts, NetworkManager would have to perform
> the following actions; none of this is NM or D-Bus specific, it would be
> the same problem in any system using separate services for specific
> functions, as is the unix way.
>
>   
*snip*
> We've discussed less-invasive ways of fixing this, like queuing signals
> in the services on the service-side in libdbus or so until the service
> reconnects to the system bus, but that could be quite tricky and error
> prone.  You cannot do a 75% solution here.
>
> Dan
>
>   

Of course all this is SEP when dbus becomes a kernel module :)

--CJD



From cdahlin at redhat.com  Mon Dec 29 10:45:11 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 29 Dec 2008 05:45:11 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <1230547379.3614.20.camel@eagle.danny.cz>
References: <gi5qm4$bbq$1@ger.gmane.org>	<1229353608.12163.13.camel@localhost.localdomain>	<gi5sg4$ikd$1@ger.gmane.org>
	<gi5svv$jvc$1@ger.gmane.org>	<20081215182823.GA28317@localhost>	<20081216120856.5339ec63@infradead.org>	<5256d0b0812160344x4617044x1b090f0eb632012e@mail.gmail.com>	<20081216121759.GA2414@free.fr>
	<20081216141156.GA30911@localhost>	<4947BA95.4010704@gmail.com>
	<49481793.9060406@behdad.org>	<alpine.LFD.2.00.0812161640470.14515@localhost.localdomain>	<4948220D.9070202@behdad.org>	<alpine.LFD.2.00.0812161716060.14515@localhost.localdomain>	<20081217085108.6cdc5d21@infradead.org>
	<4958A7FF.2000500@redhat.com>
	<1230547379.3614.20.camel@eagle.danny.cz>
Message-ID: <4958AA37.1050208@redhat.com>

Dan Hor?k wrote:
> Casey Dahlin p??e v Po 29. 12. 2008 v 05:35 -0500:
>   
>> Arjan van de Ven wrote:
>>     
>>> On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
>>> Seth Vidal <skvidal at fedoraproject.org> wrote:
>>>
>>>   
>>>       
>>>>> Or hibernate?
>>>>>       
>>>>>           
>>>> At least on my system hibernate takes as much time as a reboot.
>>>>
>>>>     
>>>>         
>>> btw this is a very fundamental property of hibernate. You need to do all
>>> disk IO to get the system state to disk. And then at resume, you need
>>> to do all disk IO to get the state from disk again. That's twice ;)
>>>
>>> This is compounded by the property that a hibernate tends to flush at
>>> least half the disk cache (it has to, to get space to work in), which
>>> you then need to page right back in, so even when you're back, the first
>>> minute or two sucks badly.
>>>
>>> I suspect you will always be able to boot faster than you can
>>> hibernate+resume.
>>>
>>>
>>>
>>>   
>>>       
>> Slightly off subject, did sreadahead ever get publicly released? Did I 
>> miss it?
>>     
>
> It has been even submitted for review -
> https://bugzilla.redhat.com/show_bug.cgi?id=464045
>
>
> 		Dan
>
>
>   
Good news. Its not a magic bullet any more than anything else but I like 
this app a lot.

--CJD



From nicolas.mailhot at laposte.net  Mon Dec 29 11:09:19 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 29 Dec 2008 12:09:19 +0100 (CET)
Subject: New font packaging guidelines
In-Reply-To: <604aa7910812231430u69b22963pb1ee7be17433d613@mail.gmail.com>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
	<604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
	<bde9bd3070e4c8aa2d2d78165dd820ff.squirrel@arekh.dyndns.org>
	<604aa7910812231026h1f0c1a90x72d0fbd23ee6ffca@mail.gmail.com>
	<604aa7910812231430u69b22963pb1ee7be17433d613@mail.gmail.com>
Message-ID: <2952b55620e7f759811ef604f03e1c9a.squirrel@arekh.dyndns.org>



Le Mar 23 d?cembre 2008 23:30, Jeff Spaleta a ?crit :

> Is policy compliance something which demands an update in f10 and f9?

Policy compliance should be done for new F10 and F9 packages but
definitely not for existing packages. This is why the compliance bugs
only ask for changes in rawhide.

-- 
Nicolas Mailhot



From cdahlin at redhat.com  Mon Dec 29 11:11:27 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 29 Dec 2008 06:11:27 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <49588D9D.5020303@gmail.com>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<49588231.2070800@gmail.com>	<495884BC.7040800@redhat.com>
	<49588D9D.5020303@gmail.com>
Message-ID: <4958B05F.3060006@redhat.com>

Lyos Gemini Norezel wrote:
> Casey Dahlin wrote:
>> Lyos Gemini Norezel wrote:
>>> Sorry... but that's just plain wrong.
>>>
>>> Maybe my use case is odd... but my /boot partition is a *MINIMUM* of 
>>> 5GB on all of my computers.
>>>
>>> Why?
>>>
>>> 1.) I have a rescue image setup to boot if I need it...
>>> and
>>> 2.) I have a ghost image I made right after installing this version 
>>> of fedora.
>>>
>>
>> I don't see why either of those should exist entirely in /boot. You 
>> are allowed further partitions. 
>
> Where else would they be better placed?
> I have no desire to clutter my disk with endless numbers of 
> partitions, and placing them in the root partition is just plain stupid.
>
>> Nothing in /boot should remain relevant after we get a proper kernel 
>> in memory and enough modules to read the rest of the disk.
>>
>> --CJD
>
> Again... where better to place the tools that can fix a broken system?
>
> Keep in mind that these tools should rarely (if ever) be used.
>
> After all... these are supposed to be the tools of last resort... 
> where better to place them... than the partition that's not supposed 
> to be touched?
>
> The /boot partition is, in fact, the perfect location for such 
> emergency tools.
>

No, you need a rescue partition. Possibly one that doesn't even appear 
in fstab on your running system.

On an unrelated note I don't see as much value in having a rescue image 
on the drive. If my system can't rescue itself, 9 times out of 10 the 
boot loader is what went, and then how do I start my rescue image?

--CJD

>
> Lyos Gemini Norezel
>



From nicolas.mailhot at laposte.net  Mon Dec 29 11:11:44 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 29 Dec 2008 12:11:44 +0100 (CET)
Subject: New font packaging guidelines
In-Reply-To: <604aa7910812231726u166a79dcx1f5bcf7eef15c582@mail.gmail.com>
References: <1229789615.16655.28.camel@arekh.okg>
	<20081222125642.GA20909@gallagher.di.uoa.gr>
	<1229954901.24585.44.camel@arekh.okg>
	<604aa7910812221653w72df2525o7e65dd31945fb17f@mail.gmail.com>
	<bde9bd3070e4c8aa2d2d78165dd820ff.squirrel@arekh.dyndns.org>
	<604aa7910812231026h1f0c1a90x72d0fbd23ee6ffca@mail.gmail.com>
	<604aa7910812231430u69b22963pb1ee7be17433d613@mail.gmail.com>
	<604aa7910812231726u166a79dcx1f5bcf7eef15c582@mail.gmail.com>
Message-ID: <206237aeefff580fe2fac86acb1090fa.squirrel@arekh.dyndns.org>



Le Mer 24 d?cembre 2008 02:26, Jeff Spaleta a ?crit :

> Do I need to just dep on dejavu-fonts-sans? Or should I dep on all the
> optional DejaVu fonts as well?

It's really up to the package maintainer to decide what his package
needs to perform like his users expect. I'd tend to add minimal deps
only, but ultimately balancing dependencies weight against feature
completeness is a packager choice.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Mon Dec 29 11:18:25 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 29 Dec 2008 12:18:25 +0100 (CET)
Subject: rawhide report: 20081223 changes
In-Reply-To: <1230140375.17296.21.camel@localhost.localdomain>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<4950FB14.5030305@fedoraproject.org>
	<1230134737.30521.2.camel@hughsie-work.lan>
	<1230140218.18082.917.camel@localhost.localdomain>
	<1230140375.17296.21.camel@localhost.localdomain>
Message-ID: <b0c2c50f8b5d36e500125be43c512f9f.squirrel@arekh.dyndns.org>



Le Mer 24 d?cembre 2008 18:39, Jesse Keating a ?crit :
> On Wed, 2008-12-24 at 11:36 -0600, Callum Lerwick wrote:
>> Noisy minority fallacy. I for one don't think it really matters and
>> if
>> anything has been an excellent exercise of our internationalization
>> capability. Look what it has done, it's tested the data flow from
>> the
>> developers text editor, through CVS, through our build system, our
>> reporting tools, the mailing list, everyone's mail clients, RPM,
>> yum,
>> PackageKit...
>
> Which could have easily been accomplished by the unicode bullet point.
> Or maybe the existing unicode chars in the developer names.

Unfortunately experience shows that different software will block on
different unicode points if its UTF-8 support is incomplete. And the
first reaction of a developper will always be to shoot the messenger
instead of fixing its app, as this thread shows.

Most developpers will be intimidated in not using anything but ASCII
in their names as soon as they hit someone else's bug.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Mon Dec 29 11:22:26 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 29 Dec 2008 12:22:26 +0100 (CET)
Subject: rawhide report: 20081223 changes
In-Reply-To: <1230056572.3313.22.camel@localhost.localdomain>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
	<20081223180341.GD2925@angus.ind.WPI.EDU>
	<f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>
	<1230056572.3313.22.camel@localhost.localdomain>
Message-ID: <4eff23ea79a59f0c844b987907ba1dc9.squirrel@arekh.dyndns.org>



Le Mar 23 d?cembre 2008 19:22, Jesse Keating a ?crit :
> On Tue, 2008-12-23 at 19:06 +0100, drago01 wrote:
>> > I agree.  Consistency is key to readability.  I guess we'll have
>> to go
>> > make a Packaging Guideline now that says what characters are
>> > appropriate for use as bullets in changelogs.
>>
>> yeah if common sense does not work we need a guideline.
>
> Seems like that was his goal all along.

I did ask for the format change to be reviewed FPC or upstream side
with an explanation on why restricting the existing format that has
been in use for many years (before PK was even written) was needed
yes.

> Terrorize us into forcing a
> policy on what is or is not allowed there.

I'm no the one pumping veiled (or not) threats with no technical
content on the list, sorry.

-- 
Nicolas Mailhot



From cdahlin at redhat.com  Mon Dec 29 11:23:04 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 29 Dec 2008 06:23:04 -0500
Subject: Fedora 10 - Boot Analysis
In-Reply-To: <gi8jp3$5na$1@ger.gmane.org>
References: <gi5qm4$bbq$1@ger.gmane.org>	<20081216120757.6932da20@infradead.org>	<4947C3B7.5080400@redhat.com>	<4947C8E0.6030002@hhs.nl>
	<gi8jp3$5na$1@ger.gmane.org>
Message-ID: <4958B318.4010905@redhat.com>

Harald Hoyer wrote:
> Hans de Goede wrote:
>> Harald Hoyer wrote:
>>> Arjan van de Ven wrote:
>>>> On Mon, 15 Dec 2008 15:47:32 +0100
>>>> Harald Hoyer <harald at redhat.com> wrote:
>>>>
>>>>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>>>>
>>>>> A brief Fedora 10 boot analysis.
>>>>>
>>>>> To reach the 20 Second Startup Feature 
>>>>
>>>> this begs the question, and you knew I as going to ask ;), if Fedora
>>>> wants to reach the 5 second boot that is quite possible on this
>>>> hardware, even without too insane compromises.
>>>> (which translates to something like 2 to 3 seconds on a full sized
>>>> laptop-with-ssd)
>>>>
>>>> If not, I would regret that but it's not something I would have to 
>>>> live
>>>> without; I can get a fast boot myself quite fine. If so, something 
>>>> needs to happen NOW for F11, with a real serious push
>>>> for this. It'll involve quite a few people and quite a few packages
>>>> that need to get things right, but it's not at all impossible nor does
>>>> it require impossible-for-fedora compromises.
>>>>
>>>>
>>>
>>> Push your kernel patches, so we have a kernel fast boot and sreadahead.
>>> Persuade our kernel maintainer to compile more modules in the kernel.
>>>
>>> But, we can't / don't want to drop gnome and most other services, 
>>> you dropped to reach 5 seconds.
>>>
>>
>> I agree with not dropping gnome :) But if we want faster startup we 
>> really should be taking a serious look at trimming startup services.
>>
>> Some ideas:
>> 1) Make more services not start when not needed, for example 
>> bluetooth when there is no bluetooth hardware, etc. We could even 
>> completely stop them from being a service controlled by runlevel and 
>> make them be started from udev instead.
>
> right, directly (and as an upstart event "/sbin/start bluetooth") or 
> via HAL/DeviceKit
>
>>
>> 2) Load some services after gdm is up, for example cron, anacron, at,
>> setroubleshootd
>
> or start them in parallel via upstart
>

parallel boot isn't much of a gain. The only real advantages are when 
there's lots of blocking on hardware other than the disk, and whatever 
is gained from flooding the io scheduler with more requests at once so 
it doesn't have to predict the future to avoid seeks. The later 
advantage disappears once we get readahead right, and by itself it isn't 
better than readahead.

Upstart isn't there to parallelize things. Its there to start things 
reactively as opposed to in response to arbitrary "runlevels."

--CJD



From bpepple at fedoraproject.org  Mon Dec 29 14:00:43 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 29 Dec 2008 09:00:43 -0500
Subject: Package Review Stats for the week ending December 28, 2008
Message-ID: <1230559243.2938.3.camel@localhost.localdomain>

Top three  FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending December 28th, 2008
were Manuel Wolfshant, Parag AN(????), and tied for 3rd was Kevin Fenzi,
Lubomir Rintel, and Mamoru Tasaka.  Below is the number of completed
package reviews done.

manuel wolfshant - 6
Parag AN(????) - 4
Kevin Fenzi - 2
Lubomir Rintel - 2
Mamoru Tasaka - 2
Brennan Ashton - 1
Christoph Wickert - 1
Clint Savage - 1
Conrad Meyer - 1
Fabian Affolter - 1
Jason Tibbitts - 1
Jesse Keating - 1
Kevin Kofler - 1
Orcan 'oget' Ogetbil - 1
Patrick Monnerat - 1
Rafa? Psota - 1
Robert Scheck - 1

Merge Reviews: 1
Review Requests: 26
Total Reviews Completed: 28

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/7c2ae243/attachment.sig>

From frank-buettner at gmx.net  Mon Dec 29 14:48:05 2008
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Mon, 29 Dec 2008 15:48:05 +0100
Subject: Problem with cvs update
Message-ID: <4958E325.9030009@gmx.net>

Hello,
after long time I had found some time to update some packages.
But the cvs uopdate will fail with:
Permission denied (publickey).
cvs [update aborted]: end of file from server (consult above messages if
any)

Can someone please help?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/dcb3bebf/attachment.bin>

From tmz at pobox.com  Mon Dec 29 15:10:44 2008
From: tmz at pobox.com (Todd Zullinger)
Date: Mon, 29 Dec 2008 10:10:44 -0500
Subject: Problem with cvs update
In-Reply-To: <4958E325.9030009@gmx.net>
References: <4958E325.9030009@gmx.net>
Message-ID: <20081229151044.GK12325@inocybe.teonanacatl.org>

Frank B?ttner wrote:
> after long time I had found some time to update some packages.
> But the cvs uopdate will fail with:
> Permission denied (publickey).
> cvs [update aborted]: end of file from server (consult above
> messages if any)
> 
> Can someone please help?

If you haven't used the Fedora CVS for a while, you may need to update
your ssh key and reset your Fedora Account System password.  After the
infrastructure intrusion last fall, passwords need to be reset and ssh
keys need to be re-uloaded.  DSA rsa keys are no longer accepted at
all, so if you have one of those, you need to generate a new RSA ssh
key to use with Fedora's systems.

You might also need to get a new SSL client certificate and update the
Fedora CA certificates.

You can do most of this via the FAS web site:

https://admin.fedoraproject.org/accounts/

After you update your ssh keys, password, ssl cert and such, run
fedora-packager-setup to download the Fedora CA certs.  The
fingerprints of those certs and for the ssh host keys of the Fedora
CVS server can be verified at:

https://admin.fedoraproject.org/fingerprints

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ocean:  A body of water occupying about two-thirds of a world made for
man -- who has no gills.
    -- Ambrose Bierce

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/ff8d5cce/attachment.sig>

From tgl at redhat.com  Mon Dec 29 15:13:19 2008
From: tgl at redhat.com (Tom Lane)
Date: Mon, 29 Dec 2008 10:13:19 -0500
Subject: Problem with cvs update 
In-Reply-To: <4958E325.9030009@gmx.net> 
References: <4958E325.9030009@gmx.net>
Message-ID: <7551.1230563599@sss.pgh.pa.us>

=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?= <frank-buettner at gmx.net> writes:
> after long time I had found some time to update some packages.
> But the cvs uopdate will fail with:
> Permission denied (publickey).
> cvs [update aborted]: end of file from server (consult above messages if
> any)

How long is "a long time" --- before the rekeying in August?
It looks like you need to update your Fedora certificates.
I've forgotten the directions but you should able to find them
on the wiki, or in the mail list archives from mid-August.

			regards, tom lane



From frank-buettner at gmx.net  Mon Dec 29 15:39:52 2008
From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=)
Date: Mon, 29 Dec 2008 16:39:52 +0100
Subject: Problem with cvs update
In-Reply-To: <20081229151044.GK12325@inocybe.teonanacatl.org>
References: <4958E325.9030009@gmx.net>
	<20081229151044.GK12325@inocybe.teonanacatl.org>
Message-ID: <4958EF48.7080501@gmx.net>

Todd Zullinger schrieb:

> If you haven't used the Fedora CVS for a while, you may need to update
> your ssh key and reset your Fedora Account System password.  After the
> infrastructure intrusion last fall, passwords need to be reset and ssh
> keys need to be re-uloaded.  DSA rsa keys are no longer accepted at
> all, so if you have one of those, you need to generate a new RSA ssh
> key to use with Fedora's systems.
> 
> You might also need to get a new SSL client certificate and update the
> Fedora CA certificates.
> 
> You can do most of this via the FAS web site:
> 
> https://admin.fedoraproject.org/accounts/
> 
> After you update your ssh keys, password, ssl cert and such, run
> fedora-packager-setup to download the Fedora CA certs.  The
> fingerprints of those certs and for the ssh host keys of the Fedora
> CVS server can be verified at:
> 
> https://admin.fedoraproject.org/fingerprints
> 
> 
Ok, I have update my passwort, generate an new SSH key and upload the
public part to ttps://admin.fedoraproject.org/accounts/ and download the
new client certificate. But the error is the same:(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/698618d6/attachment.bin>

From sundaram at fedoraproject.org  Mon Dec 29 16:05:34 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 29 Dec 2008 21:35:34 +0530
Subject: Problem with cvs update
In-Reply-To: <4958EF48.7080501@gmx.net>
References: <4958E325.9030009@gmx.net>	<20081229151044.GK12325@inocybe.teonanacatl.org>
	<4958EF48.7080501@gmx.net>
Message-ID: <4958F54E.70107@fedoraproject.org>

Frank B?ttner wrote:

>>
> Ok, I have update my passwort, generate an new SSH key and upload the
> public part to ttps://admin.fedoraproject.org/accounts/ and download the
> new client certificate. But the error is the same:(

Be patient. Give it an hour or so for the cron job to kick in and try 
again later.

Rahul




From frank-buettner at gmx.net  Mon Dec 29 16:54:03 2008
From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=)
Date: Mon, 29 Dec 2008 17:54:03 +0100
Subject: Problem with cvs update
In-Reply-To: <4958F54E.70107@fedoraproject.org>
References: <4958E325.9030009@gmx.net>	<20081229151044.GK12325@inocybe.teonanacatl.org>	<4958EF48.7080501@gmx.net>
	<4958F54E.70107@fedoraproject.org>
Message-ID: <495900AB.5040004@gmx.net>

Rahul Sundaram schrieb:

> Be patient. Give it an hour or so for the cron job to kick in and try
> again later.
> 
> Rahul
> 
> 

Yes this was it:)
Now I can login:)
Thanks for help.
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/13ab644b/attachment.bin>

From frank-buettner at gmx.net  Mon Dec 29 17:31:52 2008
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Mon, 29 Dec 2008 18:31:52 +0100
Subject: make build will fail
Message-ID: <49590988.3030709@gmx.net>

Hello,
now my second problem,
when I try to build the package via make build
I get this error:
nter passphrase for key '/home/frank/.ssh/fedora_rsa':
/usr/bin/plague-client build package name
Traceback (most recent call last):
  File "/usr/bin/plague-client", line 423, in ?
    cli = PlagueClient(os.path.expanduser(cfg_file))
  File "/usr/bin/plague-client", line 85, in __init__
    self._check_api_version(self._server)
  File "/usr/bin/plague-client", line 90, in _check_api_version
    server_ver = server.api_version()
  File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.4/xmlrpclib.py", line 1129, in request
    self.send_content(h, request_body)
  File "/usr/lib/python2.4/xmlrpclib.py", line 1243, in send_content
    connection.endheaders()
  File "/usr/lib/python2.4/httplib.py", line 804, in endheaders
    self._send_output()
  File "/usr/lib/python2.4/httplib.py", line 685, in _send_output
    self.send(msg)
  File "/usr/lib/python2.4/httplib.py", line 664, in send
    self.sock.sendall(str)
  File "/usr/lib/python2.4/site-packages/plague/SSLConnection.py", line
110, in sendall
    sent = con.send(data, flags)
OpenSSL.SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE',
'certificate verify failed')]

what certificates are wrong?

Thank's for the next help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/0577a19f/attachment.bin>

From silfreed at silfreed.net  Mon Dec 29 17:37:48 2008
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Mon, 29 Dec 2008 12:37:48 -0500
Subject: qgis 1.0.0 build error on F10
Message-ID: <49590AEC.80808@silfreed.net>

I'm trying to build qgis 1.0.0 for F10 [1] but am having a problem building it 
in koji.  I haven't had any problems building it in mock on local hosts, and 
it built fine in F11 [2].

-Doug

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=76638
[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=76637

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/82b971e9/attachment.sig>

From jkeating at redhat.com  Mon Dec 29 17:46:15 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 29 Dec 2008 09:46:15 -0800
Subject: rawhide report: 20081223 changes
In-Reply-To: <3c4f936ad4064b0ac24ef02f06d543d1.squirrel@arekh.dyndns.org>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
	<20081223180341.GD2925@angus.ind.WPI.EDU>
	<f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>
	<1230056572.3313.22.camel@localhost.localdomain>
	<4eff23ea79a59f0c844b987907ba1dc9.squirrel@arekh.dyndns.org>
	<3c4f936ad4064b0ac24ef02f06d543d1.squirrel@arekh.dyndns.org>
Message-ID: <1230572775.17296.52.camel@localhost.localdomain>

On Mon, 2008-12-29 at 13:11 +0100, Nicolas Mailhot wrote:
> Jesse,
> 
> Ultimately, I do not like the "going through FPC, FESCO or rpm.org
> upstream is too much work, just change your package because I say so,
> I don't care to explain myself" process. It's showing contempt to the
> other contributors that play by the rules.
> 
> Please do not force me to send this to fedora-devel. I won't resist
> posting unpleasant truths publicly forever if the public intimidation
> campaign continues.
> 

Given that everything on this thread I've posted, I've done to a public
list, I'm not sure what revealing you can do.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/b1be4926/attachment.sig>

From tony at bakeyournoodle.com  Mon Dec 29 20:10:28 2008
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Tue, 30 Dec 2008 07:10:28 +1100
Subject: make build will fail
In-Reply-To: <49590988.3030709@gmx.net>
References: <49590988.3030709@gmx.net>
Message-ID: <20081229201028.GB18035@ozlabs.org>

On Mon, Dec 29, 2008 at 06:31:52PM +0100, Frank B??ttner wrote:
> Hello,
> now my second problem,
> when I try to build the package via make build
> I get this error:
> nter passphrase for key '/home/frank/.ssh/fedora_rsa':
> /usr/bin/plague-client build package name
> Traceback (most recent call last):
>   File "/usr/bin/plague-client", line 423, in ?
>     cli = PlagueClient(os.path.expanduser(cfg_file))
<snip>
>   File "/usr/lib/python2.4/site-packages/plague/SSLConnection.py", line
> 110, in sendall
>     sent = con.send(data, flags)
> OpenSSL.SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE',
> 'certificate verify failed')]
> 
> what certificates are wrong?

Wild guess from a newbie.  I think you need to re-generate your certiciate via FAS.
https://admin.fedoraproject.org/accounts/user/gencert

Be careful to do this only once though as each new certicficate expires the
previous one.

I'm sure if I'm way off someone will correct both of us.

Yours Tony

  linux.conf.au    http://www.marchsouth.org/
  Jan 19 - 24 2009 The Australian Linux Technical Conference!



From frank-buettner at gmx.net  Mon Dec 29 20:24:46 2008
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Mon, 29 Dec 2008 21:24:46 +0100
Subject: make build will fail
In-Reply-To: <20081229201028.GB18035@ozlabs.org>
References: <49590988.3030709@gmx.net> <20081229201028.GB18035@ozlabs.org>
Message-ID: <4959320E.7000602@gmx.net>

Tony Breeds schrieb:
> 
> Wild guess from a newbie.  I think you need to re-generate your certiciate via FAS.
> https://admin.fedoraproject.org/accounts/user/gencert
> 
> Be careful to do this only once though as each new certicficate expires the
> previous one.
> 
> I'm sure if I'm way off someone will correct both of us.
> 
> Yours Tony
> 
>   linux.conf.au    http://www.marchsouth.org/
>   Jan 19 - 24 2009 The Australian Linux Technical Conference!
> 
I have replaced $HOME/.fedora.cert but the same result:(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/83675708/attachment.bin>

From konrad at tylerc.org  Mon Dec 29 21:08:06 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 29 Dec 2008 13:08:06 -0800
Subject: rawhide report: 20081223 changes
In-Reply-To: <1230572775.17296.52.camel@localhost.localdomain>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<3c4f936ad4064b0ac24ef02f06d543d1.squirrel@arekh.dyndns.org>
	<1230572775.17296.52.camel@localhost.localdomain>
Message-ID: <200812291308.06340.konrad@tylerc.org>

On Monday 29 December 2008 09:46:15 am Jesse Keating wrote:
> On Mon, 2008-12-29 at 13:11 +0100, Nicolas Mailhot wrote:
> > Jesse,
> >
> > Ultimately, I do not like the "going through FPC, FESCO or rpm.org
> > upstream is too much work, just change your package because I say so,
> > I don't care to explain myself" process. It's showing contempt to the
> > other contributors that play by the rules.
> >
> > Please do not force me to send this to fedora-devel. I won't resist
> > posting unpleasant truths publicly forever if the public intimidation
> > campaign continues.
>
> Given that everything on this thread I've posted, I've done to a public
> list, I'm not sure what revealing you can do.

I think maybe he knows about that transvestite hooker from Michigan.

-- 
Conrad Meyer <konrad at tylerc.org>




From dennisml at conversis.de  Mon Dec 29 21:14:43 2008
From: dennisml at conversis.de (Dennis J.)
Date: Mon, 29 Dec 2008 22:14:43 +0100
Subject: Reopening bugs
Message-ID: <49593DC3.20700@conversis.de>

Is there a way to reopen an existing bug in Bugzilla? The following bug got 
fixed in F9 but apparently the patch got dropped in the new udev versions 
in F10 so the problem is back again:

Cd tray is closed automatically after ejecting
https://bugzilla.redhat.com/show_bug.cgi?id=453095

Regards,
   Dennis



From jonstanley at gmail.com  Mon Dec 29 21:19:02 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Mon, 29 Dec 2008 16:19:02 -0500
Subject: make build will fail
In-Reply-To: <4959320E.7000602@gmx.net>
References: <49590988.3030709@gmx.net> <20081229201028.GB18035@ozlabs.org>
	<4959320E.7000602@gmx.net>
Message-ID: <da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>

2008/12/29 Frank B?ttner <frank-buettner at gmx.net>:

> I have replaced $HOME/.fedora.cert but the same result:(

You also need the appropriate CA certs.  The easiest way to get
everything in place is to run 'fedora-packager-setup' from the
fedora-packager package.



From jonstanley at gmail.com  Mon Dec 29 21:22:15 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Mon, 29 Dec 2008 16:22:15 -0500
Subject: Reopening bugs
In-Reply-To: <49593DC3.20700@conversis.de>
References: <49593DC3.20700@conversis.de>
Message-ID: <da159fda0812291322q6754c54fv25caf60e10d525e7@mail.gmail.com>

On Mon, Dec 29, 2008 at 4:14 PM, Dennis J. <dennisml at conversis.de> wrote:
> Is there a way to reopen an existing bug in Bugzilla? The following bug got
> fixed in F9 but apparently the patch got dropped in the new udev versions in
> F10 so the problem is back again:

Yes, you simply change the status to ASSIGNED again. Being you might
not have the required permissions, I did this for you.



From jamundso at gmail.com  Mon Dec 29 21:22:36 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Mon, 29 Dec 2008 15:22:36 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <200812291308.06340.konrad@tylerc.org>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<3c4f936ad4064b0ac24ef02f06d543d1.squirrel@arekh.dyndns.org>
	<1230572775.17296.52.camel@localhost.localdomain>
	<200812291308.06340.konrad@tylerc.org>
Message-ID: <6d06ce20812291322q39b6b91i1c2cf087a29ec912@mail.gmail.com>

On Mon, Dec 29, 2008 at 3:08 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> On Monday 29 December 2008 09:46:15 am Jesse Keating wrote:
>> On Mon, 2008-12-29 at 13:11 +0100, Nicolas Mailhot wrote:
>> > Jesse,
>> >
>> > Ultimately, I do not like the "going through FPC, FESCO or rpm.org
>> > upstream is too much work, just change your package because I say so,
>> > I don't care to explain myself" process. It's showing contempt to the
>> > other contributors that play by the rules.
>> >
>> > Please do not force me to send this to fedora-devel. I won't resist
>> > posting unpleasant truths publicly forever if the public intimidation
>> > campaign continues.
>>
>> Given that everything on this thread I've posted, I've done to a public
>> list, I'm not sure what revealing you can do.
>
> I think maybe he knows about that transvestite hooker from Michigan.

Hey, I've never even met Jesse!!
Oh, I thought that was "Minnesota". Er, never mind...

jerry

-- 
To be named later.



From gemi at bluewin.ch  Mon Dec 29 21:31:55 2008
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Mon, 29 Dec 2008 22:31:55 +0100
Subject: /*MerryChristmas.c*/
In-Reply-To: <49583AFB.5090903@redhat.com>
References: <4952A587.5000400@projetofedora.org>
	<16de708d0812241616p45e4fab2xc1817c507d0020ec@mail.gmail.com>
	<49583AFB.5090903@redhat.com>
Message-ID: <1230586315.4566.2.camel@localhost.localdomain>

On Sun, 2008-12-28 at 21:50 -0500, Casey Dahlin wrote:
> Arthur Pemberton wrote:
> > On Wed, Dec 24, 2008 at 3:11 PM, Rodrigo Padula de Oliveira
> > <rodrigopadula at projetofedora.org> wrote:
> >   
> >> /*MerryChristmas.c*/
> >> void main (int argc, char* argv[])
> >> {
> >>    printf("\n Merry Christmas! \n");
> >>    if (strcmp(argv[1],"girl") == 0)    /*general idea*/
> >>        printf("Kisses! \n");
> >>    else
> >>        printf("Hugs! \n");
> >> }
> >>     
> >
> >
> > #i!/bin/env python
> > import sys
> > print 'Kisses!' if len(sys.argv) == 2 and sys.argv[1].lower() ==
> > 'girl' else 'Hugs!'
> >
> >   
> #! /usr/bin/env ruby
> 
> class Object
>   def response
>     "Hugs!"
>   end
> end
> 
> class String
>   def response
>     return "Kisses!" if self.downcase == "girl"
>     super
>   end
> end
> 
> puts "Merry Christmas!\n#{ARGV[0].response}"

#!/usr/bin/sbcl --script
(princ #\newline)
(princ "Merry Christmas!")
(princ #\newline)

(let ((argv sb-ext:*posix-argv*))
  (if (> (length argv) 1)
      (let ((type (string-downcase (cadr argv))))
        (if (equal type "girl")
            (princ "Kisses!")
            (princ "Hugs!")))))

(princ #\newline)




From valent.turkovic at gmail.com  Mon Dec 29 21:36:44 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 29 Dec 2008 22:36:44 +0100
Subject: Fedora unusable on Asus eee 701
Message-ID: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>

Hi,
this bug [1] makes Fedora 10 unusable on Asus eee 701 because onboard
4GB drive is too small for default set of apps and after updates drive
keeps shrinking to 0MB free :(((

Please take this into consideration.

If you need some more feedback please let us know or if there is some
other way we users can help this bug gets fixed.

Cheers,
Valent.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=465405

-- 
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 konrad at tylerc.org  Mon Dec 29 21:40:25 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 29 Dec 2008 13:40:25 -0800
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
Message-ID: <200812291340.25845.konrad@tylerc.org>

On Monday 29 December 2008 01:36:44 pm Valent Turkovic wrote:
> Hi,
> this bug [1] makes Fedora 10 unusable on Asus eee 701 because onboard
> 4GB drive is too small for default set of apps and after updates drive
> keeps shrinking to 0MB free :(((
>
> Please take this into consideration.
>
> If you need some more feedback please let us know or if there is some
> other way we users can help this bug gets fixed.
>
> Cheers,
> Valent.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=465405

*Please* stop posting the particular bugs that affect you to the mailing list 
as if they are higher priority than any other bugs.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From rdieter at math.unl.edu  Tue Dec 30 01:25:00 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 29 Dec 2008 19:25 -0600
Subject: qgis 1.0.0 build error on F10
References: <49590AEC.80808@silfreed.net>
Message-ID: <gjbt79$vbt$1@ger.gmane.org>

Douglas E. Warner wrote:

> I'm trying to build qgis 1.0.0 for F10 [1] but am having a problem
> building it
> in koji. 

I'm working on a sip/PyQt4 update, and I think you hit the buildroot with a newer sip only (PyQt4 build is pending).  Once both are built, I'll try restarting your failed build.

-- Rex



From a.badger at gmail.com  Tue Dec 30 03:22:42 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 29 Dec 2008 19:22:42 -0800
Subject: rawhide report: 20081223 changes
In-Reply-To: <gis3dj$4sp$1@ger.gmane.org>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>	<1230037971.3558.38.camel@hughsie-work.lan>	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>	<20081223180341.GD2925@angus.ind.WPI.EDU>	<f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>	<1230056572.3313.22.camel@localhost.localdomain>
	<gis3dj$4sp$1@ger.gmane.org>
Message-ID: <49599402.4070203@gmail.com>

Rex Dieter wrote:
> Jesse Keating wrote:
> 
>> On Tue, 2008-12-23 at 19:06 +0100, drago01 wrote:
>>>> I agree.  Consistency is key to readability.  I guess we'll have to go
>>>> make a Packaging Guideline now that says what characters are
>>>> appropriate for use as bullets in changelogs.
>>> yeah if common sense does not work we need a guideline.
>> Seems like that was his goal all along.  Terrorize us into forcing a
>> policy on what is or is not allowed there.
> 
> The existing guidelines seem to cover this case (ie, the changelog as discussed doesn't follow any of the suggested formats):
> http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
> 
> That doesn't prevent concoction of something that technically does follow the format to introduce more odd stuff.
> 
When I voted on that I wasn't anticipating that it extended to the
bullet points, only to the header line (The date, name, version portion).

If people are reading that Guideline to show intended bullet points then
the Guideline is very flawed:

* Header
- First note
  ? First Subnote
    ? First Sub-subnote

You get the picture.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/a0db42f9/attachment.sig>

From rdieter at math.unl.edu  Tue Dec 30 04:06:43 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 29 Dec 2008 22:06:43 -0600
Subject: qgis 1.0.0 build error on F10
References: <49590AEC.80808@silfreed.net> <gjbt79$vbt$1@ger.gmane.org>
Message-ID: <gjc5m0$fj4$1@ger.gmane.org>

Rex Dieter wrote:

> Douglas E. Warner wrote:
> 
>> I'm trying to build qgis 1.0.0 for F10 [1] but am having a problem
>> building it
>> in koji.
> 
> I'm working on a sip/PyQt4 update, and I think you hit the buildroot with
> a newer sip only (PyQt4 build is pending).  Once both are built, I'll try
> restarting your failed build.

Looks like we have a winner:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1025667

-- Rex



From jamundso at gmail.com  Tue Dec 30 04:07:25 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Mon, 29 Dec 2008 22:07:25 -0600
Subject: rawhide report: 20081223 changes
In-Reply-To: <49599402.4070203@gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>
	<1230037971.3558.38.camel@hughsie-work.lan>
	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>
	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>
	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>
	<20081223180341.GD2925@angus.ind.WPI.EDU>
	<f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>
	<1230056572.3313.22.camel@localhost.localdomain>
	<gis3dj$4sp$1@ger.gmane.org> <49599402.4070203@gmail.com>
Message-ID: <6d06ce20812292007h7303a237uc8adc52d8b3e2b34@mail.gmail.com>

2008/12/29 Toshio Kuratomi <a.badger at gmail.com>:
> When I voted on that I wasn't anticipating that it extended to the
> bullet points, only to the header line (The date, name, version portion).
>
> If people are reading that Guideline to show intended bullet points then
> the Guideline is very flawed:
>
> * Header
> - First note
>  ? First Subnote
>    ? First Sub-subnote
>
> You get the picture.

No, "we" don't get it, and that's the joke, er point.
Personally, it was cute once.
But, really, inconsistencies with the first character cause a natural
interruption to the human scan. It's annoying, end of discussion. If
the protocol can't be followed, it needs to be forced.

jerry

-- 
To be named later.



From silfreed at silfreed.net  Tue Dec 30 04:07:00 2008
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Mon, 29 Dec 2008 23:07:00 -0500
Subject: qgis 1.0.0 build error on F10
In-Reply-To: <gjc5m0$fj4$1@ger.gmane.org>
References: <49590AEC.80808@silfreed.net> <gjbt79$vbt$1@ger.gmane.org>
	<gjc5m0$fj4$1@ger.gmane.org>
Message-ID: <49599E64.3050305@silfreed.net>

Rex Dieter wrote:
> Rex Dieter wrote:
>> I'm working on a sip/PyQt4 update, and I think you hit the buildroot with
>> a newer sip only (PyQt4 build is pending).  Once both are built, I'll try
>> restarting your failed build.
> 
> Looks like we have a winner:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1025667
> 

Thanks for the update and rebuilding my package!

-Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/626d7344/attachment.sig>

From a.badger at gmail.com  Tue Dec 30 06:40:40 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 29 Dec 2008 22:40:40 -0800
Subject: rawhide report: 20081223 changes
In-Reply-To: <6d06ce20812292007h7303a237uc8adc52d8b3e2b34@mail.gmail.com>
References: <20081223105547.98A711B8001@releng2.fedora.phx.redhat.com>	<1230037971.3558.38.camel@hughsie-work.lan>	<9497e9990812230605w7789e1b8k2a694ac20a431c27@mail.gmail.com>	<c486419048bbce638c7c3c7e0a802b12.squirrel@arekh.dyndns.org>	<f6ca9fed0812230947o6f8ed674ua21b1f0743beb9a9@mail.gmail.com>	<20081223180341.GD2925@angus.ind.WPI.EDU>	<f6ca9fed0812231006h37eb608eu3556a82a4afda881@mail.gmail.com>	<1230056572.3313.22.camel@localhost.localdomain>	<gis3dj$4sp$1@ger.gmane.org>
	<49599402.4070203@gmail.com>
	<6d06ce20812292007h7303a237uc8adc52d8b3e2b34@mail.gmail.com>
Message-ID: <4959C268.5090904@gmail.com>

Jerry Amundson wrote:
> 2008/12/29 Toshio Kuratomi <a.badger at gmail.com>:
>> When I voted on that I wasn't anticipating that it extended to the
>> bullet points, only to the header line (The date, name, version portion).
>>
>> If people are reading that Guideline to show intended bullet points then
>> the Guideline is very flawed:
>>
>> * Header
>> - First note
>>  ? First Subnote
>>    ? First Sub-subnote
>>
>> You get the picture.
> 
> No, "we" don't get it, and that's the joke, er point.
> Personally, it was cute once.
> But, really, inconsistencies with the first character cause a natural
> interruption to the human scan. It's annoying, end of discussion. If
> the protocol can't be followed, it needs to be forced.
> 
The point is that we weren't defining protocol for more than the header
line.  If you want to read the Guidelines as mandating "-" for the
"First Note" bullet point you're still out of luck for the bullet points
for each of the sub-notes.  So if it's annoying, you can revise the
ChangeLog section to mandate what the accepted bullets are and whether
they're interchangable or hierarchical and announce it here for
flam^Wdiscussion and get us (the packaging committee) to vote on it.
But the Guidelines weren't intended to mandate it currently and if
they're interpreted to mandate it, they don't fully cover the necessary
problem scope.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081229/0d1faeb4/attachment.sig>

From seg at haxxed.com  Tue Dec 30 07:48:19 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 30 Dec 2008 01:48:19 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <4958B05F.3060006@redhat.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<49588231.2070800@gmail.com>	<495884BC.7040800@redhat.com>
	<49588D9D.5020303@gmail.com>  <4958B05F.3060006@redhat.com>
Message-ID: <1230623299.6985.247.camel@localhost.localdomain>

On Mon, 2008-12-29 at 06:11 -0500, Casey Dahlin wrote:
> On an unrelated note I don't see as much value in having a rescue image 
> on the drive. If my system can't rescue itself, 9 times out of 10 the 
> boot loader is what went, and then how do I start my rescue image?

Rescue image in root is useful for:

1) Mounted filesystems (i.e. root) can't be shrunk.

2) Rebuilding the initrd when moving a system to a differing
motherboard, which often results in a non-bootable system due to
(apparently) not having the right ATA driver built into the initrd.
Unfortunately, the new IDE drivers no longer seem to fall back on
oldsk00l PIO IDE like the old ones did, even on non-SATA systems.

3) Spectacular upgrade failures. (Broken init, broken glibc, broken
rpm...)

And probably some other things I can't think of right now.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081230/05c21d2e/attachment.sig>

From nicu_fedora at nicubunu.ro  Tue Dec 30 07:54:39 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Tue, 30 Dec 2008 09:54:39 +0200
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
Message-ID: <4959D3BF.8070804@nicubunu.ro>

Valent Turkovic wrote:
> Hi,
> this bug [1] makes Fedora 10 unusable on Asus eee 701 because onboard
> 4GB drive is too small for default set of apps and after updates drive
> keeps shrinking to 0MB free :(((
> 
> Please take this into consideration.
> 
> If you need some more feedback please let us know or if there is some
> other way we users can help this bug gets fixed.

Maybe you are trying to install the wrong spin on the machine? I am 
quite positive the Desktop or Xfce spins will install in much less than 
that.

-- 
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 benny+usenet at amorsen.dk  Tue Dec 30 08:52:17 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Tue, 30 Dec 2008 09:52:17 +0100
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <4958B05F.3060006@redhat.com> (Casey Dahlin's message of "Mon\,
	29 Dec 2008 06\:11\:27 -0500")
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<49588231.2070800@gmail.com> <495884BC.7040800@redhat.com>
	<49588D9D.5020303@gmail.com> <4958B05F.3060006@redhat.com>
Message-ID: <m3hc4mniym.fsf@ursa.amorsen.dk>

Casey Dahlin <cdahlin at redhat.com> writes:

> On an unrelated note I don't see as much value in having a rescue
> image on the drive. If my system can't rescue itself, 9 times out of
> 10 the boot loader is what went, and then how do I start my rescue
> image?

If it's just the boot loader, fixing it is easy and takes just one
reboot. If, on the other hand, the initrd is messed up, fixing it can
take a lot of reboots with various attempts. Today, each of those
involves a PXE boot followed by fetching the stage 2 image over the
LAN. It would be a lot quicker to boot directly into a rescue image.

I am considering following Lyos Gemini Norezel's example. It would be
even nicer if the initrd had rudimentary recovery tools though. A
busybox with cat would have helped me out a lot on at least three
occassions, where I ended up repeatedly booting from rescue, unpacking
the initrd, and trying to figure out what was wrong inside it.


/Benny



From seg at haxxed.com  Tue Dec 30 10:03:50 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 30 Dec 2008 04:03:50 -0600
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <gj7pbf$k4k$1@ger.gmane.org>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
	<1230444576.21895.99.camel@localhost.localdomain>
	<gj7pbf$k4k$1@ger.gmane.org>
Message-ID: <1230631430.6985.327.camel@localhost.localdomain>

On Sun, 2008-12-28 at 12:53 +0100, Kevin Kofler wrote:
> Callum Lerwick wrote:
> > 1) I used Macs before I ever used Linux. The System 7 era, in
> > particular. My high school was entirely Mac based. What is foreign to
> > you is quite familiar to me.
> 
> Yet Apple abandoned spatial in favor of column navigation (i.e. what you get
> if you fire up Dolphin and select "Columns" in the toolbar).

... Yeah, because Steve Jobs is so well known for his detailed and
reasoned usability studies. Apple didn't abandon spatial, they abandoned
an entire operating system. Are you so sure it has nothing to do with
NIH syndrome after Steve Jobs was brought back to Apple? Are you so sure
that NeXT differed from Apple because of some kind of scientific
usability study, rather than an effort to differentiate NeXT from Apple?

Not sure what you're even trying to argue. The fact remains, classic Mac
OS was the second GUI I ever used for an extended time, before I ever
used Windows or Linux, and before OS X ever existed. Not everyone grew
up on Windows 98/XP/OSX/whatever.

(The first was the Atari ST, but I'd hardly use GEM as a good example of
user interface design... Hardwired four window limit, bleh...)

The main argument here seems to be that "browser" mode is what people
are used to. That does not mean it is the best. That just means it's
what people happened to learn 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081230/96ff5ba4/attachment.sig>

From rawhide at fedoraproject.org  Tue Dec 30 10:38:05 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 30 Dec 2008 10:38:05 +0000 (UTC)
Subject: rawhide report: 20081230 changes
Message-ID: <20081230103805.CFE911F825C@releng2.fedora.phx.redhat.com>

Compose started at Tue Dec 30 06:01:10 UTC 2008

Updated Packages:

alsa-plugins-1.0.18-2.fc11
--------------------------
* Sun Dec 28 17:00:00 2008 Eric Moret <eric.moret at gmail.com> - 1.0.18-2
- Updated to 1.0.18 final


bti-007-1.fc11
--------------
* Mon Dec 29 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 007-1
- Update to 0.0.7


cairo-dock-2.0.0-0.3.svn1455_trunk.fc11
---------------------------------------
* Tue Dec 30 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1455


cvs2svn-2.2.0-1.fc11
--------------------
* Mon Dec 29 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 2.2.0-1
- Upstream 2.2.0


ecryptfs-utils-67-1.fc11
------------------------
* Mon Dec 29 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> 67-1
- bump release for rebuild

* Mon Dec 29 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> 67-0
- updated to 67


empathy-2.25.3-4.fc11
---------------------
* Mon Dec 29 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 2.25.3-4
- Add patch to work around our broken pkgconfig.

* Mon Dec 29 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 2.25.3-3
- Rebuild.


enigma-1.01-7.1
---------------
* Mon Dec 29 17:00:00 2008 Thorsten Leemhuis <fedora[AT]leemhuis[DOT]info> - 1.01-7
- use file-based deps for fons
- use DejaVuSans instead of vera_sans


fuse-zip-0.2.7-1.fc11
---------------------
* Mon Dec 29 17:00:00 2008 Rakesh Pandit <rakesh at fedoraproject.org> 0.2.7-1
- Upgraded to 0.2.7

* Mon Dec 29 17:00:00 2008 Rakesh Pandit <rakesh at fedoraproject.org> 0.2.6-6
- fixed man page spelling mistake


icu-4.0-6.fc11
--------------
* Mon Dec 29 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 4.0-6
- Resolves rhbz#225896 clean up low hanging rpmlint warnings


jack-audio-connection-kit-0.116.1-2.fc11
----------------------------------------
* Mon Dec 29 17:00:00 2008 Andy Shevchenko <andy at smile.org.ua> - 0.116.1-2
- fix multiarch conflict again (#477718, #341621)


jd-2.1.0-2.fc11
---------------
* Tue Dec 30 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.1.0-2
- Workaround for the issue on res 868 in JD 6 thread (segv when
  bookmarking when bookmark is empty)


kernel-2.6.29-0.6.rc0.git2.fc11
-------------------------------
* Mon Dec 29 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-git2

* Sun Dec 28 17:00:00 2008 Roland McGrath <roland at redhat.com>
- utrace rebase

* Sun Dec 28 17:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.28-git1
  Drop utrace temporarily.


libcgroup-0.32.2-2.fc11
-----------------------
* Mon Dec 29 17:00:00 2008 Dhaval Giani <dhaval at linux.vnet.ibm.com> 0.32.2-2
- Fix build dependencies

* Mon Dec 29 17:00:00 2008 Dhaval Giani <dhaval at linux.vnet.ibm.com> 0.32.2-1
- Update to latest upstream


libstroke-0.5.1-21.fc11
-----------------------
* Mon Dec 29 17:00:00 2008 Chitlesh Goorah <chitlesh at fedoraproject.org> - 0.5.1-21
- fix for EL-5 build; pdgconfig as BR


libtopology-0.3-4.fc11
----------------------
* Tue Dec 30 17:00:00 2008 Tony Breeds <tony at bakeyournoodle.com> 0.3-4
- Conform with the new font packageing guidelines (#477415)


lilypond-2.12.0-1.fc11
----------------------
* Wed Dec 17 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 2.12.0-1
- New upstream, BZ 476836.
- Fixed Source0 URL.
- Patched to allow Python 2.6.
- Patch for parse-scm fix.


lilypond-doc-2.12.0-1.fc11
--------------------------
* Mon Dec 29 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> 2.12.0-1
- Update to 2.12.0.


liveusb-creator-3.0-4.fc11
--------------------------
* Mon Dec 29 17:00:00 2008 Luke Macken <lmacken at redhat.com> 3.0-4
- Latest upstream release.
- Fedora 10 support
- Update to the latest sugar spin
- Lots of bug fixes and code improvements
- Improved OLPC support with the --xo flag
- Translation improvements
    - Greek translation (Nikos Charonitakis)
    - Slovak translation (Ondrej Sulek)
    - Catalan translation (Xavier Conde)
    - French translation (PabloMartin-Gomez)
    - Serbian (Milos Komarcevic)
    - Chinese (sainrysec)


magic-7.5.168-1.fc11
--------------------

mlmmj-1.2.16-1.fc11
-------------------
* Mon Dec 29 17:00:00 2008 Michael Fleming <mfleming+rpm at enlartenment.com> 1.2.16-1
- New upstream release.
- New URL

* Tue Apr  8 18:00:00 2008 Michael Fleming <mfleming+rpm at enlartenment.com> 1.2.15-3
- Fix Requires (bz# 438079)


mod_security-2.5.7-1.fc11
-------------------------
* Mon Dec 29 17:00:00 2008 Michael Fleming <mfleming+rpm at enlartenment.com> 2.5.7-1
- Update to upstream 2.5.7
- Reinstate mlogc


nip2-7.16.4-1.fc11
------------------
* Mon Dec 29 17:00:00 2008 Adam Goode <adam at spicenitz.org> - 7.16.4-1
- New release
- Drop upstreamed flex patch


nntpgrab-0.4.1-1.fc11
---------------------
* Mon Dec 29 17:00:00 2008 Erik van Pienbroek <info at nntpgrab.nl> - 0.4.1-1
- Update to 0.4.1
- Fix a broken upgrade path


numpy-1.2.1-1.fc11
------------------
* Fri Dec 19 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> 1.2.1-1
- Update to 1.2.1.


opencv-1.0.0-12.fc11
--------------------
* Mon Dec 29 17:00:00 2008 Rakesh Pandit <rakesh at fedoraproject.org> - 1.0.0-12
- fix URL field


perl-Data-ICal-0.13-4.fc11
--------------------------
* Tue Dec 30 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> 0.13-4
- BR: perl(Test::Pod::Coverage), perl(Test::Pod).


perl-Geo-IP-1.36-1.fc11
-----------------------

purple-facebookchat-1.46-1.fc11
-------------------------------
* Mon Dec 29 17:00:00 2008 Ismael Olea <ismael at olea.org> 1.46-1
- updating to 1.46


python-GeoIP-1.2.4-1.fc11
-------------------------
* Mon Dec 29 17:00:00 2008 Michael Fleming <mfleming+rpm at enlartenment.com> 1.2.4-1
- Update to 1.2.4


python-kiwi-1.9.23-1.fc11
-------------------------
* Mon Dec 29 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 1.9.23-1
- Upstream 1.9.23


qgis-1.0.0-1.fc11
-----------------

quassel-0.3.1-2.fc11
--------------------
* Mon Dec 29 17:00:00 2008 Steven M. Parrish <tuxbrewr at fedoraproject.org> 0.3.1-2
- Fix bug #477850


rdiff-backup-1.2.3-1.fc11
-------------------------
* Mon Dec 29 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 1.2.3-1
- Update to 1.2.3
- Also fixes bug 477507


shorewall-4.2.3-2.fc11
----------------------
* Tue Dec 30 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.3-2
- Add upstream patch patch-perl-4.2.3.1


spicebird-0.7-2.fc11
--------------------
* Mon Dec 29 17:00:00 2008 Steven M. Parrish <tuxbrewr at fedoraproject.org> 0.7-2
- Updated SPEC file to address https://bugzilla.redhat.com/show_bug.cgi?id=453936#c16


tasque-0.1.8-1.fc11
-------------------
* Mon Dec 29 17:00:00 2008 David Kaylor<dkaylor at gmail.com> - 0.1.8-1
- Update to version 0.1.8
- libdir bug is partially fixed.  Create a patch for the remaining files.


vdrift-20080805-3.fc11
----------------------
* Mon Nov 24 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 20080805-3
- Cleaned up summary.


xscreensaver-5.08-4.fc11
------------------------
* Tue Dec 30 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.08-4
- Fix the process of "make update-po -C po", reported by jwz


yaz-3.0.41-1.fc11
-----------------
* Mon Dec 29 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 3.0.41-1
- Upstream 3.0.41
- Always use system libtool
- Remove TODO from docs
- Package bib1-attr.7 with libyaz


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 39
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.i386 requires libffi.so.4
	gwave-2-11.20070514snap.fc10.i386 requires libguile-gnome-gobject-0.so.0
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	neverball-1.4.0-12.fc11.i386 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.i386 requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.i386 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	trac-privateticketsplugin-1.1.1-0.2.svn5068.fc11.noarch requires trac < 0:0.11
	wormux-0.8.2-2.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.i386 requires pkgconfig(ndesk-dbus-1.0)
	banshee-devel-1.4.1-2.fc11.x86_64 requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	desktop-data-model-1.2.5-2.fc11.i386 requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.i386 requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.x86_64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.x86_64 requires libguile-gnome-gobject-0.so.0()(64bit)
	gwave-2-11.20070514snap.fc10.x86_64 requires libffi.so.4()(64bit)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.x86_64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.x86_64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	trac-privateticketsplugin-1.1.1-0.2.svn5068.fc11.noarch requires trac < 0:0.11
	wormux-0.8.2-2.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	banshee-devel-1.4.1-2.fc11.ppc requires pkgconfig(ndesk-dbus-1.0)
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-2.fc11.ppc requires libempathy.so.14
	desktop-data-model-1.2.5-2.fc11.ppc requires libgnome-desktop-2.so.10
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.ppc requires libffi.so.4
	gwave-2-11.20070514snap.fc10.ppc requires libguile-gnome-gobject-0.so.0
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.ppc requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pyflowtools-0.3.4-3.fc11.ppc requires libpython2.5.so.1.0
	pyflowtools-0.3.4-3.fc11.ppc requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	trac-privateticketsplugin-1.1.1-0.2.svn5068.fc11.noarch requires trac < 0:0.11
	wormux-0.8.2-2.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	desktop-data-model-1.2.5-2.fc11.ppc64 requires libempathy.so.14()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires libpython2.5.so.1.0()(64bit)
	pyflowtools-0.3.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	trac-privateticketsplugin-1.1.1-0.2.svn5068.fc11.noarch requires trac < 0:0.11
	wormux-0.8.2-2.fc11.ppc64 requires dejavu-fonts





From ml at bendler-net.de  Tue Dec 30 11:30:51 2008
From: ml at bendler-net.de (Thomas Bendler)
Date: Tue, 30 Dec 2008 12:30:51 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
In-Reply-To: <1230631430.6985.327.camel@localhost.localdomain>
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
	<1230444576.21895.99.camel@localhost.localdomain>
	<gj7pbf$k4k$1@ger.gmane.org>
	<1230631430.6985.327.camel@localhost.localdomain>
Message-ID: <e5f36bc70812300330o3d6c85d9s12e1c4b5c76ad3fd@mail.gmail.com>

2008/12/30 Callum Lerwick <seg at haxxed.com>

> [...]
> The main argument here seems to be that "browser" mode is what people
> are used to. That does not mean it is the best. That just means it's
> what people happened to learn first.


But then the answer to the question spatial or browser mode is quite simple.
The question is, what kind of distribution is Fedora? Is it a playground for
technical nerds, use spatial mode (because it might be the best mode). Is it
a distribution for normal end users, use browser mode (because the majority
of people is used to this mode). But don't expect that Fedora will change to
what people are used to, this is nothing that Fedora can do now, maybe
sometime in the future (Microsoft could, but they don't do it).

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081230/6a34fa3f/attachment.htm>

From jamatos at fc.up.pt  Tue Dec 30 11:32:40 2008
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Tue, 30 Dec 2008 11:32:40 +0000
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <4959D3BF.8070804@nicubunu.ro>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<4959D3BF.8070804@nicubunu.ro>
Message-ID: <200812301132.40788.jamatos@fc.up.pt>

On Tuesday 30 December 2008 07:54:39 Nicu Buculei wrote:
> Maybe you are trying to install the wrong spin on the machine? I am
> quite positive the Desktop or Xfce spins will install in much less than
> that.

My wife has installed the KDE spin on a eee 901 with no problems.

It has a primary SSD of 4 GB and the secondary has 16 GB, the system fits well 
in the primary.
-- 
Jos? Ab?lio



From frank-buettner at gmx.net  Tue Dec 30 11:39:25 2008
From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=)
Date: Tue, 30 Dec 2008 12:39:25 +0100
Subject: make build will fail
In-Reply-To: <da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>
References: <49590988.3030709@gmx.net>
	<20081229201028.GB18035@ozlabs.org>	<4959320E.7000602@gmx.net>
	<da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>
Message-ID: <495A086D.30703@gmx.net>

Jon Stanley schrieb:
> 2008/12/29 Frank B?ttner <frank-buettner at gmx.net>:
> 
>> I have replaced $HOME/.fedora.cert but the same result:(
> 
> You also need the appropriate CA certs.  The easiest way to get
> everything in place is to run 'fedora-packager-setup' from the
> fedora-packager package.
> 

Hello,
can you tell me ,where must I put this certificates?
And where can I get it, because an fedora-packager will not be presented
at EPEL.

Thanks

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081230/c2777d5e/attachment.bin>

From foss.mailinglists at gmail.com  Tue Dec 30 12:19:16 2008
From: foss.mailinglists at gmail.com (Sankarshan Mukhopadhyay)
Date: Tue, 30 Dec 2008 17:49:16 +0530
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
Message-ID: <35586fc00812300419g6070f807p5491bfe7e053a947@mail.gmail.com>

On Tue, Dec 30, 2008 at 3:06 AM, Valent Turkovic
<valent.turkovic at gmail.com> wrote:

> this bug [1] makes Fedora 10 unusable on Asus eee 701 because onboard
> 4GB drive is too small for default set of apps and after updates drive
> keeps shrinking to 0MB free :(((

Are you using a spin or, a standard install set ?

-- 

http://www.gutenberg.net - Fine literature digitally re-published
http://www.plos.org - Public Library of Science
http://www.creativecommons.org - Flexible copyright for creative work



From wolfy at nobugconsulting.ro  Tue Dec 30 12:49:25 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Tue, 30 Dec 2008 14:49:25 +0200
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <49588D9D.5020303@gmail.com>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<49588231.2070800@gmail.com>	<495884BC.7040800@redhat.com>
	<49588D9D.5020303@gmail.com>
Message-ID: <495A18D5.3030602@nobugconsulting.ro>

On 12/29/2008 10:43 AM, Lyos Gemini Norezel wrote:
> Casey Dahlin wrote:
>> Lyos Gemini Norezel wrote:
>>> Sorry... but that's just plain wrong.
>>>
>>> Maybe my use case is odd... but my /boot partition is a *MINIMUM* of 
>>> 5GB on all of my computers.
>>>
>>> Why?
>>>
>>> 1.) I have a rescue image setup to boot if I need it...
>>> and
>>> 2.) I have a ghost image I made right after installing this version 
>>> of fedora.
>>>
>>
>> I don't see why either of those should exist entirely in /boot. You 
>> are allowed further partitions. 
>
> Where else would they be better placed?
in /dev/sda2, also known as "hidden rescue partition".


> I have no desire to clutter my disk with endless numbers of partitions, 
indeed. only one additional partition is enough. and guess what ? that's 
what numberless laptop manufacturers do in order to store a ghost-ed 
backup of the main partition


> and placing them in the root partition is just plain stupid.
I agree with you here

> Again... where better to place the tools that can fix a broken system?
ughm ... did I mention /dev/sda2, also known as "hidden rescue partition" ?



From aportal at univ-montp2.fr  Tue Dec 30 14:10:24 2008
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Tue, 30 Dec 2008 15:10:24 +0100
Subject: make build will fail
In-Reply-To: <495A086D.30703@gmx.net>
References: <49590988.3030709@gmx.net>
	<da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>
	<495A086D.30703@gmx.net>
Message-ID: <200812301510.24979.aportal@univ-montp2.fr>

Le mardi 30 d?cembre 2008 ? 12:39, Frank B?ttner a ?crit?:
> Hello,
> can you tell me ,where must I put this certificates?
> And where can I get it, because an fedora-packager will not be presented
> at EPEL.

yum install koji

Alain
-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From kevin.kofler at chello.at  Tue Dec 30 14:41:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 30 Dec 2008 15:41:47 +0100
Subject: Call for vote: Nautilus use Browser view for fedora 11
References: <6e24a8e80812181256i73d6e797qb275a0049a8983fd@mail.gmail.com>
	<1229723272.23410.84.camel@dimi.lattica.com>
	<1229723428.3861.3.camel@localhost.localdomain>
	<1229724098.23410.88.camel@dimi.lattica.com>
	<200812200032.mBK0Wo3H004758@laptop14.inf.utfsm.cl>
	<1229734702.23410.103.camel@dimi.lattica.com>
	<604aa7910812191740s74ad36cbtcde30002275f2663@mail.gmail.com>
	<1229753424.23410.153.camel@dimi.lattica.com>
	<604aa7910812200100x38b60c95r206d9f8da5c26d3d@mail.gmail.com>
	<6e24a8e80812201002l79df90efl718259721dd9ee09@mail.gmail.com>
	<1dedbbfc0812201031k4f334c8ao36ca1710863eb06f@mail.gmail.com>
	<494D3DB2.4000304@gmail.com>
	<1230444576.21895.99.camel@localhost.localdomain>
	<gj7pbf$k4k$1@ger.gmane.org>
	<1230631430.6985.327.camel@localhost.localdomain>
Message-ID: <gjdbvb$5l2$2@ger.gmane.org>

Callum Lerwick wrote:
> The main argument here seems to be that "browser" mode is what people
> are used to. That does not mean it is the best. That just means it's
> what people happened to learn first.

But in the real world, most users won't be complete computer newbies like
the folks selected for those usability studies trying to find the absolute
best interface, they will have existing experience and they will adapt more
easily to a suboptimal, but familiar UI than to a "perfect" but foreign UI.

        Kevin Kofler



From jonstanley at gmail.com  Tue Dec 30 14:58:01 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Tue, 30 Dec 2008 09:58:01 -0500
Subject: make build will fail
In-Reply-To: <495A086D.30703@gmx.net>
References: <49590988.3030709@gmx.net> <20081229201028.GB18035@ozlabs.org>
	<4959320E.7000602@gmx.net>
	<da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>
	<495A086D.30703@gmx.net>
Message-ID: <da159fda0812300658g38c7ca61r1803bc1c10beff1c@mail.gmail.com>

2008/12/30 Frank B?ttner <frank-buettner at gmx.net>:

> Hello,
> can you tell me ,where must I put this certificates?
> And where can I get it, because an fedora-packager will not be presented
> at EPEL.

The fedora-packager package is indeed in EPEL.



From selinux at gmail.com  Tue Dec 30 15:08:04 2008
From: selinux at gmail.com (Tom London)
Date: Tue, 30 Dec 2008 07:08:04 -0800
Subject: rawhide report: 20081230 changes
In-Reply-To: <20081230103805.CFE911F825C@releng2.fedora.phx.redhat.com>
References: <20081230103805.CFE911F825C@releng2.fedora.phx.redhat.com>
Message-ID: <4c4ba1530812300708v61e2991fja2faf7fecf84c657@mail.gmail.com>

On Tue, Dec 30, 2008 at 2:38 AM, Rawhide Report
<rawhide at fedoraproject.org> wrote:

> kernel-2.6.29-0.6.rc0.git2.fc11
> -------------------------------
> * Mon Dec 29 17:00:00 2008 Dave Jones <davej at redhat.com>
> - 2.6.28-git2
>
> * Sun Dec 28 17:00:00 2008 Roland McGrath <roland at redhat.com>
> - utrace rebase
>
> * Sun Dec 28 17:00:00 2008 Dave Jones <davej at redhat.com>
> - 2.6.28-git1
>  Drop utrace temporarily.
>
>
kernel-2.6.29-0.6.rc0.git2.fc11.x86_64  (along with recent xorg-x11
updates: xorg-x11-server-Xorg-1.5.99.3-5.fc11.x86_64,
xorg-x11-server-common-1.5.99.3-5.fc11.x86_64,
xorg-x11-drv-i810-2.5.99.1-0.3.fc11.x86_64) works fine with "Desktop
Effects" (i.e., compiz) disabled, but produces a complete "white
screen" (when compiz is "turned on"?).  Compiz works fine with new
xorg-x11 packages and older kernel (e.g., kernel-2.6.28-3.fc11.x86_64)

System is Thinkpad X61 with Intel 965 graphics.

I've BZ'ed it here: https://bugzilla.redhat.com/show_bug.cgi?id=478424

Can anyone provide/verify the command-line command for turning off
compiz/desktop-effects?

I believe it used to be:
     "gconftool-2 -s /apps/gnome-session/rh/window_manager -t string metacity"
but this settings appears "gone".

Is it
    "gconftool-2 -s /desktop/gnome/session/required_components/windowmanager"
 -t string metacity
?

tom
-- 
Tom London



From valent.turkovic at gmail.com  Tue Dec 30 17:13:56 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 30 Dec 2008 18:13:56 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <200812291340.25845.konrad@tylerc.org>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
Message-ID: <64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>

On Mon, Dec 29, 2008 at 10:40 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> On Monday 29 December 2008 01:36:44 pm Valent Turkovic wrote:
>> Hi,
>> this bug [1] makes Fedora 10 unusable on Asus eee 701 because onboard
>> 4GB drive is too small for default set of apps and after updates drive
>> keeps shrinking to 0MB free :(((
>>
>> Please take this into consideration.
>>
>> If you need some more feedback please let us know or if there is some
>> other way we users can help this bug gets fixed.
>>
>> Cheers,
>> Valent.
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=465405
>
> *Please* stop posting the particular bugs that affect you to the mailing list
> as if they are higher priority than any other bugs.
>
> Regards,
> --
> Conrad Meyer <konrad at tylerc.org>
>

I'm not saying that this bug has some too high importance but to say
that all bugs are created equal is not true.
Also I heard a lot of positive feedback when some specific bugs got
mentioned on this list, if you believe it is now important you can
choose to ignore that thread.

Regards,
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 Dec 30 17:18:04 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 30 Dec 2008 18:18:04 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <35586fc00812300419g6070f807p5491bfe7e053a947@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<35586fc00812300419g6070f807p5491bfe7e053a947@mail.gmail.com>
Message-ID: <64b14b300812300918q36810121l32974b8fef9c871a@mail.gmail.com>

On Tue, Dec 30, 2008 at 1:19 PM, Sankarshan Mukhopadhyay
<foss.mailinglists at gmail.com> wrote:
> On Tue, Dec 30, 2008 at 3:06 AM, Valent Turkovic
> <valent.turkovic at gmail.com> wrote:
>
>> this bug [1] makes Fedora 10 unusable on Asus eee 701 because onboard
>> 4GB drive is too small for default set of apps and after updates drive
>> keeps shrinking to 0MB free :(((
>
> Are you using a spin or, a standard install set ?
>
> --
>
> http://www.gutenberg.net - Fine literature digitally re-published
> http://www.plos.org - Public Library of Science
> http://www.creativecommons.org - Flexible copyright for creative work
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


I'm using standard Fedora desktop spin (CD Gnome spin). I removed some
locals after install and installed some additiona apps that are
essential but are missing from desktop spin - like OpenOffice.

I had around 20 MB before removing some languages that I'm not using.
Now I have around 200MB free space but after any update tha space is
shringink. Because of this bug I can't use external SD 8GB card that I
used when I had Fedora 9 installed on Asus 701.

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 Dec 30 17:18:42 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 30 Dec 2008 18:18:42 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <200812301132.40788.jamatos@fc.up.pt>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<4959D3BF.8070804@nicubunu.ro> <200812301132.40788.jamatos@fc.up.pt>
Message-ID: <64b14b300812300918w3ca6f687wf2d11e9d8fedf704@mail.gmail.com>

On Tue, Dec 30, 2008 at 12:32 PM, Jos? Matos <jamatos at fc.up.pt> wrote:
> On Tuesday 30 December 2008 07:54:39 Nicu Buculei wrote:
>> Maybe you are trying to install the wrong spin on the machine? I am
>> quite positive the Desktop or Xfce spins will install in much less than
>> that.
>
> My wife has installed the KDE spin on a eee 901 with no problems.
>
> It has a primary SSD of 4 GB and the secondary has 16 GB, the system fits well
> in the primary.
> --
> Jos? Ab?lio

I believe this bug is isolated for Asus 701, please feel free to
correct me if I'm wrong.

-- 
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 Dec 30 17:21:34 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 30 Dec 2008 18:21:34 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <4959D3BF.8070804@nicubunu.ro>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<4959D3BF.8070804@nicubunu.ro>
Message-ID: <64b14b300812300921k747bbbb1v4d9e9ab25206940b@mail.gmail.com>

On Tue, Dec 30, 2008 at 8:54 AM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> Valent Turkovic wrote:
>>
>> Hi,
>> this bug [1] makes Fedora 10 unusable on Asus eee 701 because onboard
>> 4GB drive is too small for default set of apps and after updates drive
>> keeps shrinking to 0MB free :(((
>>
>> Please take this into consideration.
>>
>> If you need some more feedback please let us know or if there is some
>> other way we users can help this bug gets fixed.
>
> Maybe you are trying to install the wrong spin on the machine? I am quite
> positive the Desktop or Xfce spins will install in much less than that.
>

Desktop spin after install takes around 2.6GB of space, then there is
swap and Desktop spin is far from usable for my use cases so I need
additiona apps... the space gets eaten really fast.

I had no issue with space when I had an option of using 8GB SD card
with Fedora 9, now because of this bug I have no option but to manage
on only 4GB :(((

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 davej at redhat.com  Tue Dec 30 18:21:14 2008
From: davej at redhat.com (Dave Jones)
Date: Tue, 30 Dec 2008 13:21:14 -0500
Subject: rawhide report: 20081230 changes
In-Reply-To: <4c4ba1530812300708v61e2991fja2faf7fecf84c657@mail.gmail.com>
References: <20081230103805.CFE911F825C@releng2.fedora.phx.redhat.com>
	<4c4ba1530812300708v61e2991fja2faf7fecf84c657@mail.gmail.com>
Message-ID: <20081230182114.GA13920@redhat.com>

On Tue, Dec 30, 2008 at 07:08:04AM -0800, Tom London wrote:
 > 
 > > kernel-2.6.29-0.6.rc0.git2.fc11
 > > -------------------------------
 > >
 > kernel-2.6.29-0.6.rc0.git2.fc11.x86_64  (along with recent xorg-x11
 > updates: xorg-x11-server-Xorg-1.5.99.3-5.fc11.x86_64,
 > xorg-x11-server-common-1.5.99.3-5.fc11.x86_64,
 > xorg-x11-drv-i810-2.5.99.1-0.3.fc11.x86_64) works fine with "Desktop
 > Effects" (i.e., compiz) disabled, but produces a complete "white
 > screen" (when compiz is "turned on"?).  Compiz works fine with new
 > xorg-x11 packages and older kernel (e.g., kernel-2.6.28-3.fc11.x86_64)
 > 
 > System is Thinkpad X61 with Intel 965 graphics.
 > 
 > I've BZ'ed it here: https://bugzilla.redhat.com/show_bug.cgi?id=478424

Thanks. At this stage, the kernel is "whoa, it builds!" stage, so I'm
not overly surprised that some stuff broke.

	Dave

-- 
http://www.codemonkey.org.uk



From lsof at nodata.co.uk  Tue Dec 30 19:19:32 2008
From: lsof at nodata.co.uk (nodata)
Date: Tue, 30 Dec 2008 20:19:32 +0100
Subject: Encrypted home directory
In-Reply-To: <4950DC98.2070804@christensenplace.us>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<1dedbbfc0812211047t5f37d3bai4f52da83ba7a520c@mail.gmail.com>
	<20081221201523.GC10113@amd.home.annexia.org>
	<20081221214630.669fbad3@lain.camperquake.de>
	<20081222101133.GB12869@amd.home.annexia.org>
	<385866f0812220810o1f514700x279be52a564c7c1c@mail.gmail.com>
	<a2e85ed0812220848i78abd7e6p339908a0be5ba8be@mail.gmail.com>
	<20081223073237.GA3047@wolff.to>
	<a2e85ed0812230009o67d4a134i72d4d7d2b2b2150e@mail.gmail.com>
	<20081223081330.GA8132@wolff.to>
	<a2e85ed0812230030qc218327o5921defb00771d5c@mail.gmail.com>
	<20081223102713.604b66cf@dhcp03.addix.net>
	<4950DC98.2070804@christensenplace.us>
Message-ID: <1230664772.29687.0.camel@sb-home>

Am Dienstag, den 23.12.2008, 07:42 -0500 schrieb Eric Christensen:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ralf Ertzinger wrote:
> > Hi.
> > 
> > On Tue, 23 Dec 2008 10:30:31 +0200, Nikolay Vladimirov wrote:
> > 
> >> Ok. I'm not really sure about this but I think that full disk
> >> encryption on a software level
> >> with a key storng enough will bring some performance loss. And some
> >> people just want
> >> some confidential files to be encrypted.
> > 
> > I'm running full-LV encryption for /home (and some other directories) in
> > my laptop, and the performance loss is nonexistant for me. Getting the
> > bits off the rotating rust takes quite longer then decrypting them.
> > 
> > After all, all the cores in that thing have to be good for something.
> > 
> > (Core Duo, 1.6GHz)
> > 
> I've been running full disk encryption via LUKS since F8 with a 6 year
> old laptop.  I don't see any noticeable performance loss.

You would with an Atom.



From lsof at nodata.co.uk  Tue Dec 30 19:20:38 2008
From: lsof at nodata.co.uk (nodata)
Date: Tue, 30 Dec 2008 20:20:38 +0100
Subject: Encrypted home directory
In-Reply-To: <494E8B53.4050005@redhat.com>
References: <a3c040240812211013y526bfd91t388e4ae1e5a222ef@mail.gmail.com>
	<494E8B53.4050005@redhat.com>
Message-ID: <1230664838.29687.1.camel@sb-home>

Am Sonntag, den 21.12.2008, 12:30 -0600 schrieb Eric Sandeen:
> eCryptfs is still somewhat fragile at times; under constrained usecases
> it's reasonably ok but if you stray from that things can go badly...
> The stuff Ubuntu has done is interesting but I'm wondering if anyone
> there has really given the kernelspace side a good workout.  (I've
> worked on eCryptfs a lot, and it's pretty nifty, but there are still
> some kinks to work out).

Yes, filenames are not encrypted. Maybe this matters, maybe not.
customer-name-finances.odt might be quite a private filename..



From singularitaet at gmx.net  Tue Dec 30 20:09:41 2008
From: singularitaet at gmx.net (Stefan Grosse)
Date: Tue, 30 Dec 2008 21:09:41 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300812300918q36810121l32974b8fef9c871a@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<35586fc00812300419g6070f807p5491bfe7e053a947@mail.gmail.com>
	<64b14b300812300918q36810121l32974b8fef9c871a@mail.gmail.com>
Message-ID: <20081230210941.02be930e@gmx.net>

On Tue, 30 Dec 2008 18:18:04 +0100 "Valent Turkovic"

VT> >> this bug [1] makes Fedora 10 unusable on Asus eee 701 because
VT> >> onboard 4GB drive is too small for default set of apps and after
VT> >> updates drive keeps shrinking to 0MB free :(((

VT> I'm using standard Fedora desktop spin (CD Gnome spin). I removed
VT> some locals after install and installed some additiona apps that are
VT> essential but are missing from desktop spin - like OpenOffice.

Dear Ikea, I cannot fit the Billy shelves that I bought into my VW
beetle. Please consider this as a major failure in
the construction of billy shelves.

Happy New Year! ;-)

Stefan

PS I suppose you haven't been successfull installing XP including OO?



From adrian at lisas.de  Tue Dec 30 20:24:12 2008
From: adrian at lisas.de (Adrian Reber)
Date: Tue, 30 Dec 2008 21:24:12 +0100
Subject: libcdio update (rawhide)
Message-ID: <20081230202412.GA15976@lisas.de>


I want to update libcdio to 0.81. libcdio 0.81 requires a rebuild of all
application linking against it. If I used repoquery correctly following
packages in fedora and rpmfusion need a rebuild:

vlc: GPLv2+
libcddb: LGPLv2+
gvfs: LGPLv2+
kover: GPLv2+
oxine: GPLv2+
vcdimager: GPLv2+
bmpx: GPLv2
xine-lib-extras-freeworld: GPLv2+
gstreamer-plugins-ugly: LGPLv2+
xmms2: LGPLv2+ and GPLv2+ and BSD
mednafen: GPLv2+

libcdio also changes the license to GPLv3+ which is a problem only for
bmpx which, according to RPM, is GPLv2.

I tried to rebuild all packages against the new libcdio 0.81 and the
following rebuilds where successful:

libcddb
gvfs
kover
vcdimager
bmpx
gstreamer-plugins-ugly
xmms2
mednafen

I was not able to rebuild the following packages, but all of them are
right now not rebuildable at all. Even with the current libcdio.

vlc
oxine
xine-lib-extras-freeworld

I can do all the necessary rebuilds of the rebuildable packages.

I will commit libcdio 0.81 in the next few days to rawhide.

		Adrian



From konrad at tylerc.org  Wed Dec 31 01:14:23 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Tue, 30 Dec 2008 17:14:23 -0800
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
Message-ID: <200812301714.24094.konrad@tylerc.org>

On Tuesday 30 December 2008 09:13:56 am Valent Turkovic wrote:
> On Mon, Dec 29, 2008 at 10:40 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> > *Please* stop posting the particular bugs that affect you to the mailing
> > list as if they are higher priority than any other bugs.
> >
> > Regards,
> > --
> > Conrad Meyer <konrad at tylerc.org>
>
> I'm not saying that this bug has some too high importance but to say
> that all bugs are created equal is not true.

That's why there is a priority setting for each bug on bugzilla.

> Also I heard a lot of positive feedback when some specific bugs got
> mentioned on this list, if you believe it is now important you can
> choose to ignore that thread.

(I believe you meant 'not' instead of 'now'.) That strategy doesn't really 
work. Ignoring spam that is sent to onesself regularly doesn't stop it from 
being sent. Please don't contribute to the internet's spam problem. I don't 
believe there is any added value in your regular mailings of the list with 
your own bugs.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From seg at haxxed.com  Wed Dec 31 01:21:26 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 30 Dec 2008 19:21:26 -0600
Subject: Confirmed premature hard disk failure
Message-ID: <1230686486.6985.516.camel@localhost.localdomain>

Now one occurrence doesn't prove it was the Load_Cycle_Count problem
that killed the drive, but this drive is definitely prematurely failed.
This is going to be spammy, I think it is important to document this so
we can all learn from it...

The drive I posted about a while back:

https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00426.html

Is now definitely failing as of about 3-4 weeks ago. It's at the stage
where the drive still seems to be mostly readable, but IO bandwidth has
dropped like a rock. Booting Fedora takes like 20 minutes. Same thing
two previous failed drives did.

The drive has a manufacture date of May 2007. I have no reason to
believe the drive has been mistreated, no more than typical laptop wear
and tear. It is a "desktop replacement" laptop and is rarely
transported.

Fortunately /home seems to be readable. Media errors show up in the
syslog, but no IO errors are turning up in user space. The WinXP
partition seems to be trashed, however. So much for my wife's Half Life
2 and Spore savegames...

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
         res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
         res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
         res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
         res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
         res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
         res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
        00 08 59 f1 
sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
end_request: I/O error, dev sda, sector 547313
ata1: EH complete
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Full smartctl -a output, after salvaging some data:

smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Scorpio family
Device Model:     WDC WD600VE-11KWT0
Serial Number:    WD-WXEY06009078
Firmware Version: 01.03K01
User Capacity:    60,011,642,880 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Tue Dec 30 17:09:36 2008 CST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      ( 121)	The previous self-test completed having
					the read element of the test failed.
Total time to complete Offline 
data collection: 		 (3180) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					No General Purpose Logging support.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (  44) minutes.
Conveyance self-test routine
recommended polling time: 	 (   6) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   198   198   051    Pre-fail  Always       -       5472
  3 Spin_Up_Time            0x0003   150   119   021    Pre-fail  Always       -       1466
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3359
  5 Reallocated_Sector_Ct   0x0033   197   197   140    Pre-fail  Always       -       19
  7 Seek_Error_Rate         0x000f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   092   092   000    Old_age   Always       -       6564
 10 Spin_Retry_Count        0x0012   092   085   051    Old_age   Always       -       22
 11 Calibration_Retry_Count 0x0012   100   100   051    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       359
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       350
193 Load_Cycle_Count        0x0032   061   061   000    Old_age   Always       -       419536
194 Temperature_Celsius     0x0022   087   071   000    Old_age   Always       -       56
196 Reallocated_Event_Count 0x0032   196   196   000    Old_age   Always       -       4
197 Current_Pending_Sector  0x0012   192   190   000    Old_age   Always       -       86
198 Offline_Uncorrectable   0x0010   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0009   200   200   051    Pre-fail  Offline      -       3

SMART Error Log Version: 1
ATA Error Count: 2803 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 2803 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 18 f1 41 e8 e2  Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 40 c9 41 e8 02 08      01:07:07.212  READ DMA
  27 00 00 00 00 00 00 08      01:07:07.211  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 00 0a      01:07:07.208  IDENTIFY DEVICE
  ef 03 45 00 00 00 00 0a      01:07:07.206  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 00 08      01:07:07.205  READ NATIVE MAX ADDRESS EXT

Error 2802 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 18 f1 41 e8 e2  Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 40 c9 41 e8 02 08      01:07:04.430  READ DMA
  27 00 00 00 00 00 00 08      01:07:04.429  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 00 0a      01:07:04.427  IDENTIFY DEVICE
  ef 03 45 00 00 00 00 0a      01:07:04.427  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 00 08      01:07:04.426  READ NATIVE MAX ADDRESS EXT

Error 2801 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 18 f1 41 e8 e2  Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 40 c9 41 e8 02 08      01:07:01.254  READ DMA
  27 00 00 00 00 00 00 08      01:07:01.254  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 00 0a      01:07:01.251  IDENTIFY DEVICE
  ef 03 45 00 00 00 00 0a      01:07:01.248  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 00 08      01:07:01.248  READ NATIVE MAX ADDRESS EXT

Error 2800 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 18 f1 41 e8 e2  Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 40 c9 41 e8 02 08      01:06:58.277  READ DMA
  27 00 00 00 00 00 00 08      01:06:58.277  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 00 0a      01:06:58.274  IDENTIFY DEVICE
  ef 03 45 00 00 00 00 0a      01:06:58.271  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 00 08      01:06:58.271  READ NATIVE MAX ADDRESS EXT

Error 2799 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 18 f1 41 e8 e2  Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 40 c9 41 e8 02 08      01:06:55.684  READ DMA
  27 00 00 00 00 00 00 08      01:06:55.684  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 00 0a      01:06:55.681  IDENTIFY DEVICE
  ef 03 45 00 00 00 00 0a      01:06:55.678  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 00 08      01:06:55.678  READ NATIVE MAX ADDRESS EXT

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%      6564         789370
# 2  Conveyance offline  Completed: read failure       90%      6564         789370
# 3  Extended offline    Completed: read failure       90%      6562         789370
# 4  Extended offline    Completed: read failure       90%      6562         789369
# 5  Extended offline    Completed: read failure       90%      6560         85755114
# 6  Extended offline    Completed without error       00%      6455         -
# 7  Extended offline    Interrupted (host reset)      60%      6455         -
# 8  Extended offline    Completed without error       00%      4402         -
# 9  Extended offline    Completed without error       00%         0         -
#10  Short offline       Completed without error       00%         0         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.


Self tests 1-4 were done just today. Test 5 was done when the drive
first started failing 3-4 weeks ago, after which the machine was kept
off until now. 6 and 7 are from when I first noticed
Current_Pending_Sector was nonzero, maybe a month or two ago. 8 is from
my post in July. 9 and 10 are from when the drive was new.

Things to note:

1) The SMART health status is PASSED. Just like every other failed drive
I've had...

2) None of the attributes are failed.

3) By the time the self tests start failing, it is too late, you are
already losing data.

We can not trust the drive to assess itself properly. If we ever get a
SMART desktop alert thing going, we MUST look directly at the
attributes, and come to our own conclusion.

Any questions before I RMA the drive?
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081230/a29a158d/attachment.sig>

From jamundso at gmail.com  Wed Dec 31 01:49:07 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Tue, 30 Dec 2008 19:49:07 -0600
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <200812301714.24094.konrad@tylerc.org>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
Message-ID: <6d06ce20812301749m429564c5ja36fd07f250dff6@mail.gmail.com>

On 12/30/08, Conrad Meyer <konrad at tylerc.org> wrote:
> On Tuesday 30 December 2008 09:13:56 am Valent Turkovic wrote:
>> On Mon, Dec 29, 2008 at 10:40 PM, Conrad Meyer <konrad at tylerc.org> wrote:
>> > *Please* stop posting the particular bugs that affect you to the mailing
>> > list as if they are higher priority than any other bugs.
>> >
>> > Regards,
>> > --
>> > Conrad Meyer <konrad at tylerc.org>
>>
>> I'm not saying that this bug has some too high importance but to say
>> that all bugs are created equal is not true.
>
> That's why there is a priority setting for each bug on bugzilla.

And said priority setting is known to be universally ignored.

>> Also I heard a lot of positive feedback when some specific bugs got
>> mentioned on this list, if you believe it is now important you can
>> choose to ignore that thread.
>
> (I believe you meant 'not' instead of 'now'.) That strategy doesn't really
> work. Ignoring spam that is sent to onesself regularly doesn't stop it from
> being sent. Please don't contribute to the internet's spam problem. I don't
> believe there is any added value in your regular mailings of the list with
> your own bugs.

Don't be so hasty to judge. They should not become frequent list
postings, true, but sometimes they can be a handy "heads up" that can
apply to others.

jerry

-- 
To be named later.



From qixi17998 at gmail.com  Wed Dec 31 02:33:34 2008
From: qixi17998 at gmail.com (=?gb2312?Q?=D0=FB=D4=C6=BB=D4?=)
Date: Wed, 31 Dec 2008 10:33:34 +0800
Subject: when update mysql to 5.1.x?
Message-ID: <1230690814.8810.3.camel@localhost.localdomain>

when update mysql to 5.1.x? 
        



From duck at duckland.org  Wed Dec 31 02:37:22 2008
From: duck at duckland.org (Don Harper)
Date: Tue, 30 Dec 2008 20:37:22 -0600
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <6d06ce20812301749m429564c5ja36fd07f250dff6@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<6d06ce20812301749m429564c5ja36fd07f250dff6@mail.gmail.com>
Message-ID: <20081231023722.GE11236@duckland.org>

On Tue, Dec 30, 2008 at 07:49:07PM -0600, Jerry Amundson wrote to To Development discussions related to Fedora:
> On 12/30/08, Conrad Meyer <konrad at tylerc.org> wrote:
> > On Tuesday 30 December 2008 09:13:56 am Valent Turkovic wrote:
> >> On Mon, Dec 29, 2008 at 10:40 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> >> > *Please* stop posting the particular bugs that affect you to the mailing
> >> > list as if they are higher priority than any other bugs.
> >> Also I heard a lot of positive feedback when some specific bugs got
> >> mentioned on this list, if you believe it is now important you can
> >> choose to ignore that thread.
> > (I believe you meant 'not' instead of 'now'.) That strategy doesn't really
> > work. Ignoring spam that is sent to onesself regularly doesn't stop it from
> > being sent. Please don't contribute to the internet's spam problem. I don't
> > believe there is any added value in your regular mailings of the list with
> > your own bugs.
> Don't be so hasty to judge. They should not become frequent list
> postings, true, but sometimes they can be a handy "heads up" that can
> apply to others.

For example, I have started to comment on the bug since I saw it
mentioned here (my 701 works).

Don

-- 
Don Harper, RHCE                                email: duck at duckland.org
Just a systems kinda guy...                      http://www.duckland.org
        OK, the joke is over. Bring back the Constitution.
      If you don't know who and what you're fighting for, you will be, I
 think, utterly ineffective in the world, and especially in the world of
                                         politics.. -- E. J. Dionne, Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081230/821a02f0/attachment.sig>

From tgl at redhat.com  Wed Dec 31 02:54:39 2008
From: tgl at redhat.com (Tom Lane)
Date: Tue, 30 Dec 2008 21:54:39 -0500
Subject: when update mysql to 5.1.x? 
In-Reply-To: <1230690814.8810.3.camel@localhost.localdomain> 
References: <1230690814.8810.3.camel@localhost.localdomain>
Message-ID: <19768.1230692079@sss.pgh.pa.us>

=?gb2312?Q?=D0=FB=D4=C6=BB=D4?= <qixi17998 at gmail.com> writes:
> when update mysql to 5.1.x? 

I plan to look into that in January.

This:
http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html
doesn't exactly leave one with a warm feeling about the stability of
5.1, but hopefully it's good enough for rawhide.  It's a pretty safe
bet that updating to 5.1 will break some stuff that depends on mysql,
so I think we need to make the cutover near the start of a fedora
devel cycle, not near the end.

			regards, tom lane



From pbrobinson at gmail.com  Wed Dec 31 03:36:55 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 31 Dec 2008 12:36:55 +0900
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <200812301132.40788.jamatos@fc.up.pt>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<4959D3BF.8070804@nicubunu.ro> <200812301132.40788.jamatos@fc.up.pt>
Message-ID: <5256d0b0812301936h3b5cfaedgcd29f985e47ecd53@mail.gmail.com>

>> Maybe you are trying to install the wrong spin on the machine? I am
>> quite positive the Desktop or Xfce spins will install in much less than
>> that.
>
> My wife has installed the KDE spin on a eee 901 with no problems.
>
> It has a primary SSD of 4 GB and the secondary has 16 GB, the system fits well
> in the primary.

The 901 has completely different hardware and the 901 works fine. The
issue is with the 701, 900 and possibly others. I think its the non
Atom based eeePCs that are affected.

Peter



From cra at WPI.EDU  Wed Dec 31 04:48:51 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 30 Dec 2008 23:48:51 -0500
Subject: Confirmed premature hard disk failure
In-Reply-To: <1230686486.6985.516.camel@localhost.localdomain>
References: <1230686486.6985.516.camel@localhost.localdomain>
Message-ID: <20081231044851.GA27670@angus.ind.WPI.EDU>

On Tue, Dec 30, 2008 at 07:21:26PM -0600, Callum Lerwick wrote:
>   5 Reallocated_Sector_Ct 0x0033 197 197 140 Pre-fail Always - 19
> 197 Current_Pending_Sector 0x0012 192 190 000 Old_age Always - 86

> off until now. 6 and 7 are from when I first noticed
> Current_Pending_Sector was nonzero, maybe a month or two ago. 8 is from
> my post in July. 9 and 10 are from when the drive was new.

> 1) The SMART health status is PASSED. Just like every other failed drive
> I've had...

Don't look at that alone.

> 2) None of the attributes are failed.

I consider > 0 on Current_Pending_Sector or Reallocated_Sector_Ct to 
be failing.

> 3) By the time the self tests start failing, it is too late, you are
> already losing data.

If Current_Pending_Sector or Reallocated_Sector_Ct increases > 0, 
replace the drive immediately.

> We can not trust the drive to assess itself properly. If we ever get a
> SMART desktop alert thing going, we MUST look directly at the
> attributes, and come to our own conclusion.

Yes, we should consider any drive to be failed if it gets any pending 
or reallocated sectors.

> Any questions before I RMA the drive?

Why did you wait until you had many pending/reallocated sectors before 
RMAing it instead of RMAing it as soon as you had 1 bad sector?



From lyos.gemininorezel at gmail.com  Wed Dec 31 05:30:10 2008
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 31 Dec 2008 00:30:10 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <495A18D5.3030602@nobugconsulting.ro>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<49588231.2070800@gmail.com>	<495884BC.7040800@redhat.com>	<49588D9D.5020303@gmail.com>
	<495A18D5.3030602@nobugconsulting.ro>
Message-ID: <495B0362.6030906@gmail.com>

Manuel Wolfshant wrote:
> On 12/29/2008 10:43 AM, Lyos Gemini Norezel wrote:
>> Casey Dahlin wrote:
>>> Lyos Gemini Norezel wrote:
>>> I don't see why either of those should exist entirely in /boot. You 
>>> are allowed further partitions. 
>>
>> Where else would they be better placed?
> in /dev/sda2, also known as "hidden rescue partition".
>
>> I have no desire to clutter my disk with endless numbers of partitions, 
> indeed. only one additional partition is enough. and guess what ? 
> that's what numberless laptop manufacturers do in order to store a 
> ghost-ed backup of the main partition

Most laptops (ie., Win$hit boxen) don't need a /boot or even a swap 
partition.

If you have /dev/sda1 as a /boot partition, /dev/sda2 as a /rescue 
partition, /dev/sda3 as a swap partition, /dev/sda4 becomes an extended 
partition... and /dev/sda5 winds up as your /root partition.

Therefore... if you insist on using a rescue partition... you are, 
automatically, forcing a minimum of 5 partitions on the drive.

My setup only requires 3:
/dev/sda1 = /boot >= 5GB
/dev/sda2 = swap >= 2x size of RAM
/dev/sda3 = /root (remainder here)

hence... no 'extended' partition setup... simple configuration, standard 
across all of my computers, and a simple system (as a general rule) is 
simpler/easier to recover.

I'm also working with Coreboot (formerly LinuxBIOS)... trying to get all 
of my computers (laptops included) supported.
If I succeed then I will have means to initialize a recovery directly 
from the BIOS... even if the boot loader is corrupted.

Lyos Gemini Norezel



From rawhide at fedoraproject.org  Wed Dec 31 09:41:02 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 31 Dec 2008 09:41:02 +0000 (UTC)
Subject: rawhide report: 20081231 changes
Message-ID: <20081231094102.E1CBF1F825C@releng2.fedora.phx.redhat.com>

Compose started at Wed Dec 31 06:01:03 UTC 2008

New package beanstalkd
        A fast, distributed, in-memory workqueue service
New package perl-Hardware-Verilog-Parser
        Complete grammar for parsing Verilog code using perl
New package qmtest
        QMTest is an automated software test execution tool
New package synopsis
        Source-code Introspection Tool
Updated Packages:

cherokee-0.11.2-4.fc11
----------------------
* Tue Dec 30 17:00:00 2008 Pavel Lisy <pavel.lisy at gmail.com> - 0.11.2-4
- Resolves bz 472749 and 472747, changed Requires: spawn-fcgi


claws-mail-3.7.0-1.fc11
-----------------------
* Tue Dec 30 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.7.0-1
- version upgrade


claws-mail-plugins-3.7.0-1.fc11
-------------------------------
* Tue Dec 30 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.7.0-1
- version upgrade


deluge-1.1.0-0.1.rc2.fc11
-------------------------
* Mon Dec 29 17:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 1.1.0-0.1.rc2
- Update to new upstream release candidate (1.1.0 RC2)


desktop-data-model-1.2.5-3.fc11
-------------------------------
* Tue Dec 30 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1.2.5-3
- rebuild for dependancies


dhcp-forwarder-0.8-1.fc11
-------------------------
* Tue Dec 30 17:00:00 2008 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.8-1
- updated to 0.8
- license is now GPLv3, not GPLv2


fuse-encfs-1.5-3.fc11
---------------------
* Tue Dec 30 17:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 1.5-3
- Fixed URL


gammu-1.22.1-2.fc11
-------------------
* Tue Dec 30 17:00:00 2008 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> - 1.22.1-2
- Update release.
- -DENABLE_SHARED=ON replaced by -DBUILD_SHARED_LIBS=ON


gtk-nodoka-engine-0.7.2-2.fc11
------------------------------
* Tue Dec 30 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.7.2-2
- Add support for GtkScale trough-side-details and fill-level (rhbz #477941)
- Support selection and hilight coloring for separator (rhbz #478443)


gtk-sharp2-2.12.7-3.fc11
------------------------
* Tue Dec 30 17:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 2.12.7-3
- build 32 bit sparc sparcv9


haproxy-1.3.15.7-1.fc11
-----------------------
* Tue Dec 30 17:00:00 2008 Jeremy Hinegardner <jeremy at hinegardner dot org> - 1.3.15.7-1
- update to 1.3.15.7
- remove upstream patches, they are now part of source distribution


jna-3.0.9-3.fc11
----------------
* Tue Dec 30 17:00:00 2008 Colin Walters <walters at redhat.com> - 3.0.9-3
- Add patch to allow opening current process


kBuild-0.1.5-0.1.20081106svn.fc11
---------------------------------
* Tue Dec 30 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.1.5-0.1.20081106svn
- Update to build VirtualBox OSE 2.1.0


mgopen-fonts-0.20050515-9.fc11
------------------------------
* Tue Dec 30 17:00:00 2008 Sarantis Paskalis <paskalis at di.uoa.gr> - 0.20050515-9
- Restructure spec file according to
  https://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes
- Provide fontconfig files for the fonts
- Provide alias for VAG rounded --> Modata (bug #472835)

* Fri Dec 19 17:00:00 2008 Jason L Tibbitts III <tibbs at math.uh.edu> - 0.20050515-8
- It was decided that the license for these fonts is sufficiently different
  from Vera to require a different license tag.

* Mon Mar  3 17:00:00 2008 Sarantis Paskalis <paskalis at di.uoa.gr> 0.20050515-7
- Drop ancient Conflicts < fontconfig-2.3.93
- Convert LICENCE file to UTF-8
- Fix License description to Bitstream Vera
- Spec cleanup


mono-2.2-15.RC1.20081229svn122181.fc11
--------------------------------------
* Mon Dec 29 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-15.RC1.20081229svn122181
- Update from svn


mono-tools-2.2-9.RC1.20081230svn122166.fc11
-------------------------------------------
* Tue Dec 30 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> -.2.2-9.RC1.20081230svn122166
- update from svn


monodevelop-1.9.1-6.pre1.20081230svn122192.fc11
-----------------------------------------------
* Tue Dec 30 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.1-7.pre1.20081230svn122192
- Update from svn


ndesk-dbus-0.6.1a-3.fc11
------------------------
* Tue Dec 30 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.6.1a-3
- rebuild to get provides pkgconfig(ndesk-dbus-1.0)


nginx-0.6.34-1.fc11
-------------------
* Tue Dec 30 17:00:00 2008 Jeremy Hinegardner <jeremy at hinegardner dot org> - 0.6.34-1
- update to 0.6.34


papyrus-0.7.1-5.fc10
--------------------
* Sun Dec 21 17:00:00 2008 Tim Niemueller <tim at niemueller.de> - 0.7.1-5
- Header fixes for F-10
- Drawing fixes (invalid use of std::valarray)

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.7.1-4
- Fix Patch0:/%patch mismatch.


perl-MooseX-Object-Pluggable-0.0009-1.fc11
------------------------------------------
* Tue Dec 30 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.0009-1
- update to 0.0009


perl-MooseX-Params-Validate-0.07-1.fc11
---------------------------------------
* Sat Nov  8 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.07-1
- update to 0.07
- change from Build.PL to Makefile.PL incantation (now using Module::Install)
- update br's


perl-MooseX-Types-0.08-2.fc11
-----------------------------
* Tue Dec 30 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.08-2
- add br on Test::Exception

* Tue Dec 30 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.08-1
- update to 0.08

* Mon Nov 10 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.07-1
- update to 0.07, adjust BR accordingly.  Note especially dep on Moose >= 0.61


perl-Mouse-0.14-1.fc11
----------------------
* Tue Dec 30 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.14-1
- update to 0.14


pyflowtools-0.3.4-4.fc11
------------------------
* Tue Dec 30 17:00:00 2008 Paul P. Komkoff Jr <i at stingr.net> - 0.3.4-4
- new years rebuild


pylint-0.15.2-1.fc11
--------------------
* Tue Dec 30 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 0.15.2-1
- Upstream 0.15.2


python-logilab-common-0.37.0-1.fc11
-----------------------------------
* Tue Dec 30 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 0.37.0-1
- Upstream 0.37.0


python-twisted-8.2.0-1.fc11
---------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.


python-twisted-conch-8.2.0-1.fc11
---------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.


python-twisted-core-8.2.0-1.fc11
--------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.


python-twisted-lore-8.2.0-1.fc11
--------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.
- Remove no longer installed "bookify" program.


python-twisted-mail-8.2.0-1.fc11
--------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.


python-twisted-names-8.2.0-1.fc11
---------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.


python-twisted-news-8.2.0-1.fc11
--------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.


python-twisted-runner-8.2.0-1.fc11
----------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.


python-twisted-web-8.2.0-1.fc11
-------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.


python-twisted-words-8.2.0-1.fc11
---------------------------------
* Mon Dec 29 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 8.2.0-1
- Update to 8.2.0.
- Change back spec cosmetic details from Paul's to Thomas' preference.
- Remove no longer installed t-im man page.


qt-4.4.3-8.fc11
---------------
* Tue Dec 30 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.4.3-8
- qt-copy-patches-20081225


trac-privateticketsplugin-2.0.2-0.1.svn5073.fc11
------------------------------------------------
* Tue Dec 30 17:00:00 2008 Jon Stanley <jonstanley at gmail.com> - 2.0.2-0.1.svn5073
- Rebuild for Trac 0.11 in F11


vamp-plugin-sdk-2.0-2.fc11
--------------------------
* Tue Dec 30 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 2.0-2
- More libdir fixes (bug #469777)


vdr-ttxtsubs-0.0.7-1.fc11
-------------------------
* Fri Dec 19 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.0.7-1
- 0.0.7.

* Mon Dec 15 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.0.6-1
- 0.0.6 (new community upstream), patches applied upstream.


vnc-ltsp-config-4.0-5.fc10
--------------------------
* Mon Feb 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.0-5
- omit /etc/services munging (#431628)


xorg-x11-drv-openchrome-0.2.903-4.fc11
--------------------------------------
* Tue Dec 30 17:00:00 2008 Xavier Bachelot <xavier at bachelot.org> - 0.2.903-4
- Fix autoreconf call.

* Mon Dec 29 17:00:00 2008 Xavier Bachelot <xavier at bachelot.org> - 0.2.903-3
- Update to latest snapshot (svn 696), fix RHBZ#446489.
- Make debug build optional and disable it.


xsettings-kde-0.9-1.fc11
------------------------
* Tue Dec 30 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.9-1
- resurrect latest kde4-enabled version, yay.


Summary:
Added Packages: 4
Removed Packages: 0
Modified Packages: 44
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	bigboard-0.6.4-3.fc11.i386 requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.i386 requires libempathy.so.14
	bigboard-0.6.4-3.fc11.i386 requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.i386 requires libgnome-desktop-2.so.10
	bzr-gtk-0.95.0-2.fc10.i386 requires python(abi) = 0:2.5
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	fedora-business-cards-0.2.4-1.fc11.noarch requires mgopen-fonts
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.i386 requires libffi.so.4
	gwave-2-11.20070514snap.fc10.i386 requires libguile-gnome-gobject-0.so.0
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	neverball-1.4.0-12.fc11.i386 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	wormux-0.8.2-2.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.x86_64 requires python(abi) = 0:2.5
	bzr-gtk-0.95.0-2.fc10.x86_64 requires python(abi) = 0:2.5
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	fedora-business-cards-0.2.4-1.fc11.noarch requires mgopen-fonts
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.x86_64 requires libguile-gnome-gobject-0.so.0()(64bit)
	gwave-2-11.20070514snap.fc10.x86_64 requires libffi.so.4()(64bit)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.i386 requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.x86_64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.x86_64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.x86_64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	wormux-0.8.2-2.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc requires python(abi) = 0:2.5
	bigboard-0.6.4-3.fc11.ppc requires libempathy.so.14
	bigboard-0.6.4-3.fc11.ppc requires libempathy-gtk.so.15
	bigboard-0.6.4-3.fc11.ppc requires libgnome-desktop-2.so.10
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc requires python(abi) = 0:2.5
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	fedora-business-cards-0.2.4-1.fc11.noarch requires mgopen-fonts
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gwave-2-11.20070514snap.fc10.ppc requires libffi.so.4
	gwave-2-11.20070514snap.fc10.ppc requires libguile-gnome-gobject-0.so.0
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc requires libexiv2.so.4
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.ppc requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	wormux-0.8.2-2.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy-gtk.so.15()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires libempathy.so.14()(64bit)
	bigboard-0.6.4-3.fc11.ppc64 requires python(abi) = 0:2.5
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	bzr-gtk-0.95.0-2.fc10.ppc64 requires python(abi) = 0:2.5
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	fedora-business-cards-0.2.4-1.fc11.noarch requires mgopen-fonts
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-compiz-manager-0.10.4-6.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:koffice-krita-1.9.98.3-1.fc11.ppc64 requires libexiv2.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	wormux-0.8.2-2.fc11.ppc64 requires dejavu-fonts





From kevin.kofler at chello.at  Wed Dec 31 11:28:04 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Dec 2008 12:28:04 +0100
Subject: when update mysql to 5.1.x?
References: <1230690814.8810.3.camel@localhost.localdomain>
Message-ID: <gjfl04$s9k$1@ger.gmane.org>

??? wrote:
> when update mysql to 5.1.x?

If you can't wait, you can try this:
http://blog.famillecollet.com/post/2008/11/29/mysql-5.1.30-1
Not an official Fedora package though.

        Kevin Kofler



From promac at gmail.com  Wed Dec 31 11:48:21 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 31 Dec 2008 09:48:21 -0200
Subject: Confirmed premature hard disk failure
In-Reply-To: <20081231044851.GA27670@angus.ind.WPI.EDU>
References: <1230686486.6985.516.camel@localhost.localdomain>
	<20081231044851.GA27670@angus.ind.WPI.EDU>
Message-ID: <68720af30812310348j7f3e6de7oac362a73c6fb1717@mail.gmail.com>

On Wed, Dec 31, 2008 at 2:48 AM, Chuck Anderson <cra at wpi.edu> wrote:

> On Tue, Dec 30, 2008 at 07:21:26PM -0600, Callum Lerwick wrote:
> >   5 Reallocated_Sector_Ct 0x0033 197 197 140 Pre-fail Always - 19
> > 197 Current_Pending_Sector 0x0012 192 190 000 Old_age Always - 86
>
> > off until now. 6 and 7 are from when I first noticed
> > Current_Pending_Sector was nonzero, maybe a month or two ago. 8 is from
> > my post in July. 9 and 10 are from when the drive was new.
>
> > 1) The SMART health status is PASSED. Just like every other failed drive
> > I've had...
>
> Don't look at that alone.
>
> > 2) None of the attributes are failed.
>
> I consider > 0 on Current_Pending_Sector or Reallocated_Sector_Ct to
> be failing.
>
> > 3) By the time the self tests start failing, it is too late, you are
> > already losing data.
>
> If Current_Pending_Sector or Reallocated_Sector_Ct increases > 0,
> replace the drive immediately.
>
> > We can not trust the drive to assess itself properly. If we ever get a
> > SMART desktop alert thing going, we MUST look directly at the
> > attributes, and come to our own conclusion.
>
> Yes, we should consider any drive to be failed if it gets any pending
> or reallocated sectors.
>
> > Any questions before I RMA the drive?
>
> Why did you wait until you had many pending/reallocated sectors before
> RMAing it instead of RMAing it as soon as you had 1 bad sector?
>
>
I have a friend in the same situation. His drive is failing the same way as
yours,
and the boot is taking too long. However, he always used Ubuntu.

When I warned him, 6 month ago, about the problem, it was too late. He
already had
a high score for the load cycle.

What I do not understand is why the major distributions do not change the
default power save
scheme for laptop disks. It is a so simple solution, and I do not see any
drawback.
Because of the battery life? Most people use their laptops on AC power
almost all the time.

Even having all partitions backed up with partimage, it is a pain on the
neck replacing
a laptop disk.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081231/de2cf692/attachment.htm>

From benny+usenet at amorsen.dk  Wed Dec 31 12:25:34 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 31 Dec 2008 13:25:34 +0100
Subject: Confirmed premature hard disk failure
In-Reply-To: <20081231044851.GA27670@angus.ind.WPI.EDU> (Chuck Anderson's
	message of "Tue\, 30 Dec 2008 23\:48\:51 -0500")
References: <1230686486.6985.516.camel@localhost.localdomain>
	<20081231044851.GA27670@angus.ind.WPI.EDU>
Message-ID: <m3k59gsf9d.fsf@ursa.amorsen.dk>

Chuck Anderson <cra at WPI.EDU> writes:

> Why did you wait until you had many pending/reallocated sectors before 
> RMAing it instead of RMAing it as soon as you had 1 bad sector?

Which vendors accept RMA's for a reallocated sector for a consumer
drive?


/Benny



From gnomeuser at gmail.com  Wed Dec 31 13:47:02 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Wed, 31 Dec 2008 14:47:02 +0100
Subject: Confirmed premature hard disk failure
In-Reply-To: <20081231044851.GA27670@angus.ind.WPI.EDU>
References: <1230686486.6985.516.camel@localhost.localdomain>
	<20081231044851.GA27670@angus.ind.WPI.EDU>
Message-ID: <1dedbbfc0812310547k61e979adna4c52a2cb547ebc5@mail.gmail.com>

2008/12/31 Chuck Anderson <cra at wpi.edu>

> On Tue, Dec 30, 2008 at 07:21:26PM -0600, Callum Lerwick wrote:
> >   5 Reallocated_Sector_Ct 0x0033 197 197 140 Pre-fail Always - 19
> > 197 Current_Pending_Sector 0x0012 192 190 000 Old_age Always - 86
>
> > off until now. 6 and 7 are from when I first noticed
> > Current_Pending_Sector was nonzero, maybe a month or two ago. 8 is from
> > my post in July. 9 and 10 are from when the drive was new.
>
> > 1) The SMART health status is PASSED. Just like every other failed drive
> > I've had...
>
> Don't look at that alone.
>
> > 2) None of the attributes are failed.
>
> I consider > 0 on Current_Pending_Sector or Reallocated_Sector_Ct to
> be failing.
>
> > 3) By the time the self tests start failing, it is too late, you are
> > already losing data.
>
> If Current_Pending_Sector or Reallocated_Sector_Ct increases > 0,
> replace the drive immediately.
>
> > We can not trust the drive to assess itself properly. If we ever get a
> > SMART desktop alert thing going, we MUST look directly at the
> > attributes, and come to our own conclusion.
>
> Yes, we should consider any drive to be failed if it gets any pending
> or reallocated sectors.
>
> > Any questions before I RMA the drive?
>
> Why did you wait until you had many pending/reallocated sectors before
> RMAing it instead of RMAing it as soon as you had 1 bad sector?


I wonder if this new wonder tool davidz is working on Devicekit-disks will
be able to give the user some more understandable warnings in this area. I
e.g. have in the past 1? years lost 3 drives, probably all problems of which
I could have gotten early warnings and taken action instead of weeping over
spilled data.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081231/3e2c9acc/attachment.htm>

From cra at WPI.EDU  Wed Dec 31 15:12:04 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 31 Dec 2008 10:12:04 -0500
Subject: Confirmed premature hard disk failure
In-Reply-To: <m3k59gsf9d.fsf@ursa.amorsen.dk>
References: <1230686486.6985.516.camel@localhost.localdomain>
	<20081231044851.GA27670@angus.ind.WPI.EDU>
	<m3k59gsf9d.fsf@ursa.amorsen.dk>
Message-ID: <20081231151204.GA1430@angus.ind.WPI.EDU>

On Wed, Dec 31, 2008 at 01:25:34PM +0100, Benny Amorsen wrote:
> Chuck Anderson <cra at WPI.EDU> writes:
> 
> > Why did you wait until you had many pending/reallocated sectors before 
> > RMAing it instead of RMAing it as soon as you had 1 bad sector?
> 
> Which vendors accept RMA's for a reallocated sector for a consumer
> drive?

I've had Dell and Seagate do it.  Seagate will replace a drive just by 
filling out a web form--no justification needed at all.



From cra at WPI.EDU  Wed Dec 31 15:17:30 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 31 Dec 2008 10:17:30 -0500
Subject: Confirmed premature hard disk failure
In-Reply-To: <20081231151204.GA1430@angus.ind.WPI.EDU>
References: <1230686486.6985.516.camel@localhost.localdomain>
	<20081231044851.GA27670@angus.ind.WPI.EDU>
	<m3k59gsf9d.fsf@ursa.amorsen.dk>
	<20081231151204.GA1430@angus.ind.WPI.EDU>
Message-ID: <20081231151730.GB1430@angus.ind.WPI.EDU>

On Wed, Dec 31, 2008 at 10:12:04AM -0500, Chuck Anderson wrote:
> On Wed, Dec 31, 2008 at 01:25:34PM +0100, Benny Amorsen wrote:
> > Chuck Anderson <cra at WPI.EDU> writes:
> > 
> > > Why did you wait until you had many pending/reallocated sectors before 
> > > RMAing it instead of RMAing it as soon as you had 1 bad sector?
> > 
> > Which vendors accept RMA's for a reallocated sector for a consumer
> > drive?
> 
> I've had Dell and Seagate do it.  Seagate will replace a drive just by 
> filling out a web form--no justification needed at all.

Oh, and IBM too.  Of course, these were all under warranty.



From loganjerry at gmail.com  Wed Dec 31 22:37:47 2008
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 31 Dec 2008 15:37:47 -0700
Subject: Getting started with Rawhide
Message-ID: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>

I've had some bug reports recently against a couple of my packages.
These bugs apparently manifest only in Rawhide.  So now I am trying to
get a virtual machine setup with Rawhide installed so I can debug
these problems.  I'd like to keep it around long-term, too, so I can
help debug things as they come up.

However, I've had a few ... issues ... getting started with Rawhide.
Is there a "Getting started with Rawhide" guide anywhere?

First, I couldn't get the Rawhide CD image to finish an installation.
Weirdly, it failed in different ways every time I tried to use it.  So
I tried to use the F10 -> Rawhide update method with yum documented
here [1].  I installed from my F10 DVD, then *without updating F10*,
changed repositories and did an update from the Rawhide repository.

It appears that glibc in Rawhide (2.8.90) is older than the glibc in
the initial F10 release (2.9).  Am I seeing that correctly?  If so,
should I downgrade, or wait for Rawhide to catch up?

Can anybody tell me how to get a screen resolution higher than 800x600
in the virtual machine?

Incidentally, the yum upgrade spit out somewhere around a million [2]
warnings that /usr/lib64/libxcb-xlib.so.0 is not a symbolic link,
apparently every time that ldconfig ran.  Since "rpm -V libxcb"
produces no output, this appears to be intentional.  F10 gets this
right (/usr/lib64/libxcb-xlib.so.0 is a symbolic link to
/usr/lib64/libxcb-xlib.so.0.0.0).

If I can get the kernel to stay up long enough to do anything, I'll
start trying things out and flinging bug reports where appropriate.
So far, it hasn't stayed up for very long.  Good thing I've still got
the F10 kernel around...

Footnotes:
[1] http://fedoraproject.org/wiki/Releases/Rawhide
[2] I may be exaggerating slightly.
-- 
Jerry James
http://loganjerry.googlepages.com/